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.
Tom Lane [Sun, 22 Mar 2009 22:39:05 +0000 (22:39 +0000)]
Add isExtend to the parameters of the buffer_read_start and buffer_read_done
DTrace probes, so that ordinary reads can be distinguished from relation
extension operations. Move buffer_read_start probe to before the
smgrnblocks() call that's needed in the isExtend case, since really that step
should be charged as part of the time needed for the extension operation.
(This makes it slightly harder to match the read_start with the associated
read_done, since now you can't match them on blockNumber, but it should still
be possible since isExtend operations on the same relation can never be
interleaved.) Per recent discussion.
In passing, add the page identity (forkNum/blockNum) to the parameters of the
buffer_flush_start/buffer_flush_done probes, which were unaccountably lacking
the info.
Tom Lane [Sun, 22 Mar 2009 18:06:35 +0000 (18:06 +0000)]
Clean up pg_SSPI_error() coding a little bit: make the messages more
consistent, translate where intended, const-ify declarations.
Resolves a gripe from Alvaro as well as some stuff I didn't like.
Tom Lane [Sun, 22 Mar 2009 16:44:26 +0000 (16:44 +0000)]
Remove the -d and -D options of pg_dump and pg_dumpall. The functionality
is still available, but you must now write the long equivalent --inserts
or --column-inserts. This change is made to eliminate confusion with the
use of -d to specify a database name in most other Postgres client programs.
Original patch by Greg Mullane, modified per subsequent discussion.
Tom Lane [Sun, 22 Mar 2009 01:12:32 +0000 (01:12 +0000)]
Remove the datetime keywords ABSTIME and RELTIME, which we'd been treating as
noise words for the last twelve years, for compatibility with Berkeley-era
output formatting of the special INVALID values for those datatypes.
Considering that the datatypes themselves have been deprecated for awhile,
this is taking backwards compatibility a little far. Per gripe from Josh
Berkus.
Tom Lane [Sat, 21 Mar 2009 00:04:40 +0000 (00:04 +0000)]
Optimize multi-batch hash joins when the outer relation has a nonuniform
distribution, by creating a special fast path for the (first few) most common
values of the outer relation. Tuples having hashvalues matching the MCVs
are effectively forced to be in the first batch, so that we never write
them out to the batch temp files.
Bryce Cutt and Ramon Lawrence, with some editorialization by me.
Don't set the signal handler for SIGQUIT on Windows. Buildfarm shows that
reinstalling the default signal handler doesn't work as it is on Windows.
Presumably core dumps on SIGQUIT are not a problem on Windows, so rather
than figure out what header files or other changes are required to make it
work, just don't bother.
Don't intercept SIGQUIT as a signal to trigger failover; that's what
postmaster uses for immediate shutdown. Trap SIGUSR1 as the preferred
signal for that.
Per report by Fujii Masao and subsequent discussion on -hackers.
Fix Windows-specific race condition in syslogger. This could've been
the cause of the "could not write to log file: Bad file descriptor"
errors reported at
http://archives.postgresql.org//pgsql-general/2008-06/msg00193.php
Backpatch to 8.3, the race condition was introduced by the CSV logging
patch.