Tom Lane [Sat, 4 Apr 2009 17:40:36 +0000 (17:40 +0000)]
A session that does not have any live snapshots does not have to be waited for
when we are waiting for old snapshots to go away during a concurrent index
build. In particular, this rule lets us avoid waiting for
idle-in-transaction sessions.
This logic could be improved further if we had some way to wake up when
the session we are currently waiting for goes idle-in-transaction. However
that would be a significantly more complex/invasive patch, so it'll have to
wait for some other day.
Tom Lane [Sat, 4 Apr 2009 04:53:25 +0000 (04:53 +0000)]
Rewrite interval_hash() so that the hashcodes are equal for values that
interval_eq() considers equal. I'm not sure how that fundamental requirement
escaped us through multiple revisions of this hash function, but there it is;
it's been wrong since interval_hash was first written for PG 7.1.
Per bug #4748 from Roman Kononov.
Backpatch to all supported releases.
This patch changes the contents of hash indexes for interval columns. That's
no particular problem for PG 8.4, since we've broken on-disk compatibility
of hash indexes already; but it will require a migration warning note in
the next minor releases of all existing branches: "if you have any hash
indexes on columns of type interval, REINDEX them after updating".
To implement this without almost duplicating the reloption table, treat
relopt_kind as a bitmask instead of an integer value. This decreases the
range of allowed values, but it's not clear that there's need for that much
values anyway.
This patch also makes heap_reloptions explicitly a no-op for relation kinds
other than heap and TOAST tables.
Patch by ITAGAKI Takahiro with minor edits from me. (In particular I removed
the bit about adding relation kind to an error message, which I intend to
commit separately.)
Tom Lane [Sat, 4 Apr 2009 00:41:11 +0000 (00:41 +0000)]
Make \dt \di and friends more consistent about the treatment of
TOAST tables and indexes; to wit, never show either. (You can
examine them with plain \d if you're really so inclined.)
Tom Lane [Fri, 3 Apr 2009 23:27:17 +0000 (23:27 +0000)]
Use (unsigned char) cast in argument of pg_tolower(). Maybe it works on
Windows without that, but we shouldn't put bad examples where people might
copy them. Also, reformat slightly to improve the odds that pgindent
won't go nuts on this.
Tom Lane [Fri, 3 Apr 2009 18:17:43 +0000 (18:17 +0000)]
Add a comment documenting the question of whether PrefetchBuffer should
try to protect an already-existing buffer from being evicted. This was
left as an open issue when the posix_fadvise patch was committed. I'm
not sure there's any evidence to justify more work in this area, but we
should have some record about it in the source code.
Tom Lane [Fri, 3 Apr 2009 16:59:43 +0000 (16:59 +0000)]
Defend against possible crash if a plpython function does not specify names
for its arguments. Also add a regression test, since someone apparently
changed every single plpython test case to use only named parameters; else
we'd have noticed this sooner.
Euler Taveira de Oliveira, per a report from Alvaro
Magnus Hagander [Fri, 3 Apr 2009 11:52:08 +0000 (11:52 +0000)]
Make directory name comparisons on Win32 case insensitive.
This method will not catch all different ways since the locale
handling in NTFS doesn't provide an easy way to do that, but it
will hopefully solve the most common cases causing startup
problems when the backend is found in the system PATH.
Tom Lane [Thu, 2 Apr 2009 22:39:30 +0000 (22:39 +0000)]
Refactor ExecProject and associated routines so that fast-path code is used
for simple Var targetlist entries all the time, even when there are other
entries that are not simple Vars. Also, ensure that we prefetch attributes
(with slot_getsomeattrs) for all Vars in the targetlist, even those buried
within expressions. In combination these changes seem to significantly
reduce the runtime for cases where tlists are mostly but not exclusively
Vars. Per my proposal of yesterday.
Tom Lane [Thu, 2 Apr 2009 17:30:53 +0000 (17:30 +0000)]
Fix SetClientEncoding() to maintain a cache of previously selected encoding
conversion functions. This allows transaction rollback to revert to a
previous client_encoding setting without doing fresh catalog lookups.
I believe that this explains and fixes the recent report of "failed to commit
client_encoding" failures.
This bug is present in 8.3.x, but it doesn't seem prudent to back-patch
the fix, at least not till it's had some time for field testing in HEAD.
In passing, remove SetDefaultClientEncoding(), which was used nowhere.
Tom Lane [Thu, 2 Apr 2009 03:51:43 +0000 (03:51 +0000)]
Fix GUC's reports of assign_hook failure to always include the parameter value
we failed to assign, even in "can't happen" cases. Motivated by wondering
what's going on in a recent trouble report where "failed to commit" did
happen.
Tom Lane [Thu, 2 Apr 2009 01:16:11 +0000 (01:16 +0000)]
plpgsql's exec_simple_cast_value() mistakenly supposed that it could bypass
casting effort whenever the input value was NULL. However this prevents
application of not-null domain constraints in the cases that use this
function, as illustrated in bug #4741. Since this function isn't meant
for use in performance-critical paths anyway, this certainly seems like
another case of "premature optimization is the root of all evil".
Back-patch as far as 8.2; older versions made no effort to enforce
domain constraints here anyway.
Tom Lane [Tue, 31 Mar 2009 22:54:31 +0000 (22:54 +0000)]
Fix contrib/pgstattuple and contrib/pageinspect to prevent attempts to read
temporary tables of other sessions; that is unsafe because of the way our
buffer management works. Per report from Stuart Bishop.
This is redundant with the bufmgr.c checks in HEAD, but not at all redundant
in the back branches.
Tom Lane [Tue, 31 Mar 2009 22:12:48 +0000 (22:12 +0000)]
Modify the relcache to record the temp status of both local and nonlocal
temp relations; this is no more expensive than before, now that we have
pg_class.relistemp. Insert tests into bufmgr.c to prevent attempting
to fetch pages from nonlocal temp relations. This provides a low-level
defense against bugs-of-omission allowing temp pages to be loaded into shared
buffers, as in the contrib/pgstattuple problem reported by Stuart Bishop.
While at it, tweak a bunch of places to use new relcache tests (instead of
expensive probes into pg_namespace) to detect local or nonlocal temp tables.
Tom Lane [Tue, 31 Mar 2009 17:59:56 +0000 (17:59 +0000)]
Add a "relistemp" boolean column to pg_class, which is true for temporary
relations (including a temp table's indexes and toast table/index), and
false for normal relations. For ease of checking, this commit just adds
the column and fills it correctly --- revising the relation access machinery
to use it will come separately.
Fix a rare race condition when commit_siblings > 0 and a transaction commits
at the same instant as a new backend is spawned. Since CountActiveBackends()
doesn't hold ProcArrayLock, it needs to be prepared for the case that a
pointer at the end of the proc array is still NULL even though numProcs says
it should be valid, since it doesn't hold ProcArrayLock. Backpatch to 8.1.
8.0 and earlier had this right, but it was broken in the split of PGPROC and
sinval shared memory arrays.
Tom Lane [Mon, 30 Mar 2009 17:30:44 +0000 (17:30 +0000)]
Fix window function plan generation to cope with volatile sort expressions.
(Not clear how useful these really are, but failing is no good...)
Per report from David Fetter and Robert Treat.
Tom Lane [Mon, 30 Mar 2009 04:08:43 +0000 (04:08 +0000)]
Fix an oversight in the support for storing/retrieving "minimal tuples" in
TupleTableSlots. We have functions for retrieving a minimal tuple from a slot
after storing a regular tuple in it, or vice versa; but these were implemented
by converting the internal storage from one format to the other. The problem
with that is it invalidates any pass-by-reference Datums that were already
fetched from the slot, since they'll be pointing into the just-freed version
of the tuple. The known problem cases involve fetching both a whole-row
variable and a pass-by-reference value from a slot that is fed from a
tuplestore or tuplesort object. The added regression tests illustrate some
simple cases, but there may be other failure scenarios traceable to the same
bug. Note that the added tests probably only fail on unpatched code if it's
built with --enable-cassert; otherwise the bug leads to fetching from freed
memory, which will not have been overwritten without additional conditions.
Fix by allowing a slot to contain both formats simultaneously; which turns out
not to complicate the logic much at all, if anything it seems less contorted
than before.
Back-patch to 8.2, where minimal tuples were introduced.
Tom Lane [Fri, 27 Mar 2009 19:58:11 +0000 (19:58 +0000)]
On Solaris, we should only force use of our own getopt(); it's okay to use
the system's getopt_long(). The previous coding was the result of a sloppy
discussion that failed to draw this distinction. The result was that PG
programs don't handle options as users of that platform expect. Per
gripe from Chuck McDevitt.
Although this is a pre-existing bug, I'm not backpatching since I think we
could do with a bit of beta testing before concluding this is really OK.
Tom Lane [Fri, 27 Mar 2009 18:30:21 +0000 (18:30 +0000)]
Fix possible failures when a tuplestore switches from in-memory to on-disk
mode while callers hold pointers to in-memory tuples. I reported this for
the case of nodeWindowAgg's primary scan tuple, but inspection of the code
shows that all of the calls in nodeWindowAgg and nodeCtescan are at risk.
For the moment, fix it with a rather brute-force approach of copying
whenever one of the at-risk callers requests a tuple. Later we might
think of some sort of reference-count approach to reduce tuple copying.
Peter Eisentraut [Thu, 26 Mar 2009 22:26:08 +0000 (22:26 +0000)]
Gettext plural support
In the backend, I changed only a handful of exemplary or important-looking
instances to make use of the plural support; there is probably more work
there. For the rest of the source, this should cover all relevant cases.
Tom Lane [Thu, 26 Mar 2009 17:15:35 +0000 (17:15 +0000)]
If we expect a hash join to be performed in multiple batches, suppress
"physical tlist" optimization on the outer relation (ie, force a projection
step to occur in its scan). This avoids storing useless column values when
the outer relation's tuples are written to temporary batch files.
Modified version of a patch by Michael Henderson and Ramon Lawrence.
Tom Lane [Wed, 25 Mar 2009 22:19:02 +0000 (22:19 +0000)]
Adjust the APIs for GIN opclass support functions to allow the extractQuery()
method to pass extra data to the consistent() and comparePartial() methods.
This is the core infrastructure needed to support the soon-to-appear
contrib/btree_gin module. The APIs are still upward compatible with the
definitions used in 8.3 and before, although *not* with the previous 8.4devel
function definitions.
catversion bump for changes in pg_proc entries (although these are just
cosmetic, since GIN doesn't actually look at the function signature before
calling it...)
Tom Lane [Wed, 25 Mar 2009 15:03:13 +0000 (15:03 +0000)]
Fix old thinko in pgp.h: the idea is to declare some named enum types,
not global variables of anonymous enum types. This didn't actually hurt
much because most linkers will just merge the duplicated definitions ...
but some will complain. Per bug #4731 from Ceriel Jacobs.
Backpatch to 8.1 --- the declarations don't exist before that.
Tom Lane [Tue, 24 Mar 2009 22:06:03 +0000 (22:06 +0000)]
Install a search tree depth limit in GIN bulk-insert operations, to prevent
them from degrading badly when the input is sorted or nearly so. In this
scenario the tree is unbalanced to the point of becoming a mere linked list,
so insertions become O(N^2). The easiest and most safely back-patchable
solution is to stop growing the tree sooner, ie limit the growth of N. We
might later consider a rebalancing tree algorithm, but it's not clear that
the benefit would be worth the cost and complexity. Per report from Sergey
Burladyan and an earlier complaint from Heikki.
Back-patch to 8.2; older versions didn't have GIN indexes.
Tom Lane [Tue, 24 Mar 2009 20:17:18 +0000 (20:17 +0000)]
Implement "fastupdate" support for GIN indexes, in which we try to accumulate
multiple index entries in a holding area before adding them to the main index
structure. This helps because bulk insert is (usually) significantly faster
than retail insert for GIN.
This patch also removes GIN support for amgettuple-style index scans. The
API defined for amgettuple is difficult to support with fastupdate, and
the previously committed partial-match feature didn't really work with
it either. We might eventually figure a way to put back amgettuple
support, but it won't happen for 8.4.
catversion bumped because of change in GIN's pg_am entry, and because
the format of GIN indexes changed on-disk (there's a metapage now,
and possibly a pending list).
Tom Lane [Mon, 23 Mar 2009 01:52:38 +0000 (01:52 +0000)]
More fixes for 8.4 DTrace probes. Remove useless BUFFER_HIT/BUFFER_MISS
probes --- the BUFFER_READ_DONE probe provides the same information and more
besides. Expand the LOCK_WAIT_START/DONE probe arguments so that there's
actually some chance of telling what is being waited for. Update and
clean up the documentation.