- 08 9月, 2007 2 次提交
-
-
由 Teodor Sigaev 提交于
big misalignement, then it tries to split page basing on distribution of boxe's centers. Per report from Dolafi, Tom <dolafit@janelia.hhmi.org> Backpatch is needed, change doesn't affect on-disk storage.
-
由 Teodor Sigaev 提交于
- change the alignment requirement of lexemes in TSVector slightly. Lexeme strings were always padded to 2-byte aligned length to make sure that if there's position array (uint16[]) it has the right alignment. The patch changes that so that the padding is not done when there's no positions. That makes the storage of tsvectors without positions slightly more compact. - added some #include "miscadmin.h" lines I missed in the earlier when I added calls to check_stack_depth(). - Reimplement the send/recv functions, and added a comment above them describing the on-wire format. The CRC is now recalculated in tsquery as well per previous discussion.
-
- 07 9月, 2007 5 次提交
-
-
由 Teodor Sigaev 提交于
- add code to check that the query tree is well-formed. It was indeed possible to send malformed queries in binary mode, which produced all kinds of strange results. - make the left-field a uint32. There's no reason to arbitrarily limit it to 16-bits, and it won't increase the disk/memory footprint either now that QueryOperator and QueryOperand are separate structs. - add check_stack_depth() call to all recursive functions I found. Some of them might have a natural limit so that you can't force arbitrarily deep recursions, but check_stack_depth() is cheap enough that seems best to just stick it into anything that might be a problem.
-
由 Teodor Sigaev 提交于
small editorization by me - Brake the QueryItem struct into QueryOperator and QueryOperand. Type was really the only common field between them. QueryItem still exists, and is used in the TSQuery struct as before, but it's now a union of the two. Many other changes fell from that, like separation of pushval_asis function into pushValue, pushOperator and pushStop. - Moved some structs that were for internal use only from header files to the right .c-files. - Moved tsvector parser to a new tsvector_parser.c file. Parser code was about half of the size of tsvector.c, it's also used from tsquery.c, and it has some data structures of its own, so it seems better to separate it. Cleaned up the API so that TSVectorParserState is not accessed from outside tsvector_parser.c. - Separated enumerations (#defines, really) used for QueryItem.type field and as return codes from gettoken_query. It was just accidental code sharing. - Removed ParseQueryNode struct used internally by makepol and friends. push*-functions now construct QueryItems directly. - Changed int4 variables to just ints for variables like "i" or "array size", where the storage-size was not significant.
-
由 Teodor Sigaev 提交于
-
由 Tom Lane 提交于
databases, per gripe from hubert depesz lubaczewski. Patch from Simon Riggs.
-
由 Tom Lane 提交于
null::char(3) to a simple Const node. (It already worked for non-null values, but not when we skipped evaluation of a strict coercion function.) This prevents loss of typmod knowledge in situations such as exhibited in bug #3598. Unfortunately there seems no good way to fix that bug in 8.1 and 8.2, because they simply don't carry a typmod for a plain Const node. In passing I made all the other callers of makeNullConst supply "real" typmod values too, though I think it probably doesn't matter anywhere else.
-
- 06 9月, 2007 3 次提交
-
-
由 Tom Lane 提交于
that examine fields that could change under them. This is just to make really sure that when we are fetching a value 'only once', that's what actually happens. Possibly this is a bug that should be back-patched, but in the absence of solid evidence that it's needed, I won't bother.
-
由 Tom Lane 提交于
so that different prepared xacts can be told apart in the pg_locks view. Per suggestion from Florian.
-
由 Tom Lane 提交于
rows will normally never obtain an XID at all. We already did things this way for subtransactions, but this patch extends the concept to top-level transactions. In applications where there are lots of short read-only transactions, this should improve performance noticeably; not so much from removal of the actual XID-assignments, as from reduction of overhead that's driven by the rate of XID consumption. We add a concept of a "virtual transaction ID" so that active transactions can be uniquely identified even if they don't have a regular XID. This is a much lighter-weight concept: uniqueness of VXIDs is only guaranteed over the short term, and no on-disk record is made about them. Florian Pflug, with some editorialization by Tom.
-
- 05 9月, 2007 1 次提交
-
-
由 Andrew Dunstan 提交于
This just provides text values, we're not exposing the underlying Oid representation. Catalog version bumped.
-
- 04 9月, 2007 3 次提交
-
-
由 Michael Meskes 提交于
-
由 Tom Lane 提交于
instead of the initial policy of whatever isalpha() likes. Per discussion.
-
由 Tom Lane 提交于
(Actually, it works as a plain statement too, but I didn't document that because it seems a bit useless.) Unify VariableResetStmt with VariableSetStmt, and clean up some ancient cruft in the representation of same.
-
- 03 9月, 2007 5 次提交
-
-
由 Tom Lane 提交于
This business with two independent build systems does kinda suck.
-
由 Tom Lane 提交于
initcap style --- the vast majority of the existing descriptions do not use an initial cap. I didn't change places where the first word was all-cap. initdb not forced because this doesn't change any regression test results.
-
由 Tom Lane 提交于
been shown to be sensitive to concurrent autovacuum. Per Alvaro.
-
由 Tom Lane 提交于
operator-family rewrite. I had mistakenly supposed that these could use the pg_amproc entries for text[] and inet[] respectively. However, binary compatibility of the underlying types does not make two array types binary compatible (since they must differ in the header field that gives the element type OID), and so the index support code doesn't consider those entries applicable. Add back the missing pg_amproc entries, and add an opr_sanity query to try to catch such mistakes in future. Per report from Gregory Maxwell.
-
由 Tom Lane 提交于
There are still some loose ends: I didn't do anything about the SET FROM CURRENT idea yet, and it's not real clear whether we are happy with the interaction of SET LOCAL with function-local settings. The documentation is a bit spartan, too.
-
- 02 9月, 2007 1 次提交
-
-
由 Tom Lane 提交于
regardless of the number of tuples involved, it's incorrect to skip it when memtupcount = 1; the number of cycles saved is minuscule anyway. An alternative solution would be to pull the state changes out to the call site in tuplesort_performsort, but keeping them near the corresponding changes in make_bounded_heap seems marginally cleaner. Noticed by Greg Stark.
-
- 01 9月, 2007 2 次提交
-
-
由 Tom Lane 提交于
the number of rows likely to be produced by a query such as SELECT * FROM t1 LEFT JOIN t2 USING (key) WHERE t2.key IS NULL; What this is doing is selecting for t1 rows with no match in t2, and thus it may produce a significant number of rows even if the t2.key table column contains no nulls at all. 8.2 thinks the table column's null fraction is relevant and thus may estimate no rows out, which results in terrible plans if there are more joins above this one. A proper fix for this will involve passing much more information about the context of a clause to the selectivity estimator functions than we ever have. There's no time left to write such a patch for 8.3, and it wouldn't be back-patchable into 8.2 anyway. Instead, put in an ad-hoc test to defeat the normal table-stats-based estimation when an IS NULL test is evaluated at an outer join, and just use a constant estimate instead --- I went with 0.5 for lack of a better idea. This won't catch every case but it will catch the typical ways of writing such queries, and it seems unlikely to make things worse for other queries.
-
由 Tom Lane 提交于
generating the tuples has resjunk output columns. This is not possible for simple table scans but can happen when evaluating a whole-row Var for a view. Per example from Patryk Kordylewski. The problem exists back to 8.0 but I'm not going to risk back-patching further than 8.2 because of the many changes in this area.
-
- 31 8月, 2007 2 次提交
-
-
由 Tom Lane 提交于
processing routines. Per Heikki.
-
由 Tom Lane 提交于
sets for outer joins, in the light of bug #3588 and additional thought and experimentation. The original methodology was fatally flawed for nests of more than two outer joins: it got the relationships between adjacent joins right, but didn't always come to the right conclusions about whether a join could be interchanged with one two or more levels below it. This was largely caused by a mistaken idea that we should use the min_lefthand + min_righthand sets of a sub-join as the minimum left or right input set of an upper join when we conclude that the sub-join can't commute with the upper one. If there's a still-lower join that the sub-join *can* commute with, this method led us to think that that one could commute with the topmost join; which it can't. Another problem (not directly connected to bug #3588) was that make_outerjoininfo's processing-order-dependent method for enforcing outer join identity #3 didn't work right: if we decided that join A could safely commute with lower join B, we dropped all information about sub-joins under B that join A could perhaps not safely commute with, because we removed B's entire min_righthand from A's. To fix, make an explicit computation of all inner join combinations that occur below an outer join, and add to that the full syntactic relsets of any lower outer joins that we determine it can't commute with. This method gives much more direct enforcement of the outer join rearrangement identities, and it turns out not to cost a lot of additional bookkeeping. Thanks to Richard Harris for the bug report and test case.
-
- 30 8月, 2007 3 次提交
-
-
由 Tom Lane 提交于
case, per Florian Pflug. Not back-patched since it's unclear that anyone but me still cares ...
-
由 Tom Lane 提交于
checks for individual-table-size functions, since anyone in the database could get approximate values from pg_class.relpages anyway. Allow database-size to users with CONNECT privilege for the target database (note that this is granted by default). Allow tablespace-size if the user has CREATE privilege on the tablespace (which is *not* granted by default), or if the tablespace is the default tablespace for the current database (since we treat that as implicitly allowing use of the tablespace).
-
由 Tom Lane 提交于
read from the temp file didn't match the file length reported by ftello(), the wrong variable's value was printed, and so the message made no sense. Clean up a couple other coding infelicities while at it.
-
- 29 8月, 2007 2 次提交
-
-
由 Michael Meskes 提交于
-
由 Tom Lane 提交于
restart point. Per suggestion from Simon Riggs.
-
- 28 8月, 2007 1 次提交
-
-
由 Tom Lane 提交于
even if the "deadlock detected" ERROR message is suppressed by an exception catcher. Be clearer about the event sequence when a soft deadlock is fixed: the fixing process might or might not still have to wait, so log that separately. Fix race condition when someone releases us from the lock partway through printing all this junk --- we'd not get confused about our state, but the log message sequence could have been misleading, ie, a "still waiting" message with no subsequent "acquired" message. Greg Stark and Tom Lane.
-
- 27 8月, 2007 8 次提交
-
-
由 Magnus Hagander 提交于
pending decision on exactly what will happen with contrib/tsearch2 now that it's in core.
-
由 Magnus Hagander 提交于
-
由 Magnus Hagander 提交于
-
由 Tom Lane 提交于
namespace isn't necessarily first in the search path (there could be implicit schemas ahead of it). Examples are test=# set search_path TO s1; test=# create view pg_timezone_names as select * from pg_timezone_names(); ERROR: "pg_timezone_names" is already a view test=# create table pg_class (f1 int primary key); ERROR: permission denied: "pg_class" is a system catalog You'd expect these commands to create the requested objects in s1, since names beginning with pg_ aren't supposed to be reserved anymore. What is happening is that we create the requested base table and then execute additional commands (here, CREATE RULE or CREATE INDEX), and that code is passed the same RangeVar that was in the original command. Since that RangeVar has schemaname = NULL, the secondary commands think they should do a path search, and that means they find system catalogs that are implicitly in front of s1 in the search path. This is perilously close to being a security hole: if the secondary command failed to apply a permission check then it'd be possible for unprivileged users to make schema modifications to system catalogs. But as far as I can find, there is no code path in which a check doesn't occur. Which makes it just a weird corner-case bug for people who are silly enough to want to name their tables the same as a system catalog. The relevant code has changed quite a bit since 8.2, which means this patch wouldn't work as-is in the back branches. Since it's a corner case no one has reported from the field, I'm not going to bother trying to back-patch.
-
由 Tom Lane 提交于
days that was obsolete the moment we had IN (SELECT ...) capability. It's arguably a security hole since it applied no permissions check to the table it searched, and since it was never documented anywhere, removing it seems more appropriate than fixing it.
-
由 Tom Lane 提交于
and pg_tablespace_size to superusers. Perhaps we could weaken the first case to just require SELECT privilege, but that doesn't work for the other cases, so use ownership as the common concept.
-
由 Tom Lane 提交于
While it's not clear that TID linkage info is of any great use to a nefarious user, it's certainly unexpected that these functions wouldn't insist on read privileges.
-
由 Tom Lane 提交于
sub-select returns zero rows. Per complaint from Jens Schicke. Since this is more in the nature of a definition change than a bug, not back-patched.
-
- 26 8月, 2007 2 次提交
-
-
由 Tom Lane 提交于
but just hardwire the specified timezone database path into the executable. Per discussion, this avoids some packaging disadvantages of using a symlink.
-
由 Tom Lane 提交于
relcache entry after having heap_close'd it. This could lead to misbehavior if a relcache flush wiped out the cache entry meanwhile. In 8.2 there is a very real risk of CREATE INDEX CONCURRENTLY using the wrong relid for locking and waiting purposes. I think the bug is only cosmetic in 8.0 and 8.1, because their transgression is limited to using RelationGetRelationName(rel) in an ereport message immediately after heap_close, and there's no way (except with special debugging options) for a cache flush to occur in that interval. Not quite sure that it's cosmetic in 7.4, but seems best to patch anyway. Found by trying to run the regression tests with CLOBBER_CACHE_ALWAYS enabled. Maybe we should try to do that on a regular basis --- it's awfully slow, but perhaps some fast buildfarm machine could do it once in awhile.
-