is in progress on the same hashtable.  This seems the least invasive way to
fix the recently-recognized problem that a split could cause the scan to
visit entries twice or (with much lower probability) miss them entirely.
The only field-reported problem caused by this is the "failed to re-find
shared lock object" PANIC in COMMIT PREPARED reported by Michel Dorochevsky,
which was caused by multiply visited entries.  However, it seems certain
that mdsync() is vulnerable to missing required fsync's due to missed
entries, and I am fearful that RelationCacheInitializePhase2() might be at
risk as well.  Because of that and the generalized hazard presented by this
bug, back-patch all the supported branches.

Along the way, fix pg_prepared_statement() and pg_cursor() to not assume
that the hashtables they are examining will stay static between calls.
This is risky regardless of the newly noted dynahash problem, because
hash_seq_search() has never promised to cope with deletion of table entries
other than the just-returned one.  There may be no bug here because the only
supported way to call these functions is via ExecMakeTableFunctionResult()
which will cycle them to completion before doing anything very interesting,
but it seems best to get rid of the assumption.  This affects 8.2 and HEAD
only, since those functions weren't there earlier.

completing CREATE { TEMP | TEMPORARY } TABLE, we should also suggest
VIEW and SEQUENCE. Per Greg Sabino Mullane.

table entries describing functions with periods.

we can complete "TABLE". The previous coding only looked for "CREATE TEMP".

Note that I didn't add TEMPORARY to the list of suggested completions
after we've seen "CREATE", since TEMP is equivalent and more concise. But
if the user has already manually typed TEMPORARY, we may as well
complete TABLE for them.

RESET SESSION, RESET PLANS, and RESET TEMP are now DISCARD ALL,
DISCARD PLANS, and DISCARD TEMP, respectively. This is to avoid
confusion with the pre-existing RESET variants: the DISCARD
commands are not actually similar to RESET. Patch from Marko
Kreen, with some minor editorialization.

like Slony can figure out which options were enabled in the build.

Dave Page

Dave Page

Jun Kuwamura

   <H3 id="item3.6">3.6) What is the upgrade process for
   PostgreSQL?</H3>

to reference both versioning and specific upgrade instructions.

errorcode 298 when unlocking a semaphore more than once.

Per report from Marcin Waldowski.

Per buildfarm member mastodon.

thanks Marko Kreen

> 	o -Allow commenting of variables in postgresql.conf to restore them

(it's so nice to have a buildfarm member that actively rejects naked
uses of strcasecmp).  This coding is still pretty awful, though, since
it's going to be O(N^2) in the number of guc variables.  May I direct
your attention to bsearch?

are mostly excluded by constraints: do the CE test a bit earlier to save
some adjust_appendrel_attrs() work on excluded children, and arrange to
use array indexing rather than rt_fetch() to fetch RTEs in the main body
of the planner.  The latter is something I'd wanted to do for awhile anyway,
but seeing list_nth_cell() as 35% of the runtime gets one's attention.

Joachim Wieland

are removed from the configuration file.

Joachim Wieland

library.  New configure option --with-ossp-uuid to activate.

will be excluded by constraint exclusion anyway.  Greg Stark

child attnums are the same, before it grovels through each and every child
column looking for a name match.  Saves some time in large inheritance trees,
per example from Greg.

values: don't throw away perfectly good hash bits, and increase the shift
distances so as to provide more separation in the common case where some of
the key values are small integers (and so their hashes are too, because
hashfunc.c doesn't try all that hard).  This reduces the runtime of
SearchCatCache by a factor of 4 in an example provided by Greg Stark,
in which the planner spends a whole lot of time searching the two-key
STATRELATT cache.  It seems unlikely to hurt in other cases, but maybe
we could do even better?

when a relation is opened multiple times in the same transaction.  This is
particularly useful for system catalogs, which we may heap_open or index_open
many times in a transaction, and it doesn't really cost anything extra even
if the rel is touched but once.  Motivated by study of an example from Greg
Stark, in which pgstat_initstats() accounted for an unreasonably large
fraction of the runtime.

In very large queries this accounts for a noticeable fraction of
planning time.  Per an example from Greg Stark.

multiple releases.

checklist.