PostgreSQL 9.1.9 commit log

commit   : 114fca526e4f843d17f9a052f81f580d9d006ef1    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 1 Apr 2013 14:23:05 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 1 Apr 2013 14:23:05 -0400    

commit   : 5e3d2123a0c30f499ed1ba411e68007a11838723    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 1 Apr 2013 14:11:21 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 1 Apr 2013 14:11:21 -0400    

Security: CVE-2013-1899, CVE-2013-1901  

commit   : ddf177228fb303e2fd855b399ab8098daa2d3376    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 1 Apr 2013 14:01:04 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 1 Apr 2013 14:01:04 -0400    

An oversight in commit e710b65c1c56ca7b91f662c63d37ff2e72862a94 allowed  
database names beginning with "-" to be treated as though they were secure  
command-line switches; and this switch processing occurs before client  
authentication, so that even an unprivileged remote attacker could exploit  
the bug, needing only connectivity to the postmaster's port.  Assorted  
exploits for this are possible, some requiring a valid database login,  
some not.  The worst known problem is that the "-r" switch can be invoked  
to redirect the process's stderr output, so that subsequent error messages  
will be appended to any file the server can write.  This can for example be  
used to corrupt the server's configuration files, so that it will fail when  
next restarted.  Complete destruction of database tables is also possible.  
  
Fix by keeping the database name extracted from a startup packet fully  
separate from command-line switches, as had already been done with the  
user name field.  
  
The Postgres project thanks Mitsumasa Kondo for discovering this bug,  
Kyotaro Horiguchi for drafting the fix, and Noah Misch for recognizing  
the full extent of the danger.  
  
Security: CVE-2013-1899  

commit   : b403f4107ba74bcf29499ba3e77e0eae70e62679    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 1 Apr 2013 13:09:35 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 1 Apr 2013 13:09:35 -0400    

The pg_start_backup() and pg_stop_backup() functions checked the privileges  
of the initially-authenticated user rather than the current user, which is  
wrong.  For example, a user-defined index function could successfully call  
these functions when executed by ANALYZE within autovacuum.  This could  
allow an attacker with valid but low-privilege database access to interfere  
with creation of routine backups.  Reported and fixed by Noah Misch.  
  
Security: CVE-2013-1901  

commit   : 54d4a8f023783dd05d5f09136724997a73e33aa9    
  
author   : Peter Eisentraut <[email protected]>    
date     : Sun, 31 Mar 2013 23:40:34 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Sun, 31 Mar 2013 23:40:34 -0400    

commit   : ad480bd25308933153dc323af3678254a06eec5a    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 31 Mar 2013 18:33:07 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 31 Mar 2013 18:33:07 -0400    

In commit 0f61d4dd1b4f95832dcd81c9688dac56fd6b5687, I added code to copy up  
column width estimates for each column of a subquery.  That code supposed  
that the subquery couldn't have any output columns that didn't correspond  
to known columns of the current query level --- which is true when a query  
is parsed from scratch, but the assumption fails when planning a view that  
depends on another view that's been redefined (adding output columns) since  
the upper view was made.  This results in an assertion failure or even a  
crash, as per bug #8025 from lindebg.  Remove the Assert and instead skip  
the column if its resno is out of the expected range.  

commit   : 861aac58708db46c105299ac854b448e756aee1a    
  
author   : Alvaro Herrera <[email protected]>    
date     : Sun, 31 Mar 2013 16:41:13 -0300    
  
committer: Alvaro Herrera <[email protected]>    
date     : Sun, 31 Mar 2013 16:41:13 -0300    

commit   : ce4f365188b662e46527bd85fb93aec26bf4deb1    
  
author   : Bruce Momjian <[email protected]>    
date     : Sat, 30 Mar 2013 22:20:53 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Sat, 30 Mar 2013 22:20:53 -0400    

Now that pg_dump no longer dumps invalid indexes, per commit  
683abc73dff549e94555d4020dae8d02f32ed78b, have pg_upgrade also skip  
them.  Previously pg_upgrade threw an error if invalid indexes existed.  
  
Backpatch to 9.2, 9.1, and 9.0 (where pg_upgrade was added to git)  

commit   : 7bc2e68c60e7067943d1ffdb1430cea1ffce1ce2    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 28 Mar 2013 23:15:02 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 28 Mar 2013 23:15:02 -0400    

I changed this in commit fd15dba543247eb1ce879d22632b9fdb4c230831, but  
missed the fact that the SGML documentation of the function specified  
exactly what it did.  Well, one of the two places where it's specified  
documented that --- probably I looked at the other place and thought  
nothing needed to be done.  Sync the two places where encode() and  
decode() are described.  

commit   : 721478d868cdfd18057cd545312de8d2eff24595    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 28 Mar 2013 15:25:58 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 28 Mar 2013 15:25:58 -0400    

DST law changes in Chile, Haiti, Morocco, Paraguay, some Russian areas.  
Historical corrections for numerous places.  

commit   : 915d8230cb066a44b0caf39adc0a5c2de5595b49    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 27 Mar 2013 18:50:29 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 27 Mar 2013 18:50:29 -0400    

Previously, if the postmaster initialized OpenSSL's PRNG (which it will do  
when ssl=on in postgresql.conf), the same pseudo-random state would be  
inherited by each forked child process.  The problem is masked to a  
considerable extent if the incoming connection uses SSL encryption, but  
when it does not, identical pseudo-random state is made available to  
functions like contrib/pgcrypto.  The process's PID does get mixed into any  
requested random output, but on most systems that still only results in 32K  
or so distinct random sequences available across all Postgres sessions.  
This might allow an attacker who has database access to guess the results  
of "secure" operations happening in another session.  
  
To fix, forcibly reset the PRNG after fork().  Each child process that has  
need for random numbers from OpenSSL's generator will thereby be forced to  
go through OpenSSL's normal initialization sequence, which should provide  
much greater variability of the sequences.  There are other ways we might  
do this that would be slightly cheaper, but this approach seems the most  
future-proof against SSL-related code changes.  
  
This has been assigned CVE-2013-1900, but since the issue and the patch  
have already been publicized on pgsql-hackers, there's no point in trying  
to hide this commit.  
  
Back-patch to all supported branches.  
  
Marko Kreen  

commit   : f4ecfbcaf046845b58c551184449e8e438d44c69    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Wed, 27 Mar 2013 21:51:27 +0200    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Wed, 27 Mar 2013 21:51:27 +0200    

In a heap update, if the old and new tuple were on different pages, and the  
new page no longer existed (because it was subsequently truncated away by  
vacuum), heap_xlog_update forgot to release the pin on the old buffer. This  
bug was introduced by the "Fix multiple problems in WAL replay" patch,  
commit 3bbf668de9f1bc172371681e80a4e769b6d014c8 (on master branch).  
  
With full_page_writes=off, this triggered an "incorrect local pin count"  
error later in replay, if the old page was vacuumed.  
  
This fixes bug #7969, reported by Yunong Xiao. Backpatch to 9.0, like the  
commit that introduced this bug.  

commit   : 30de42d254d7b31161bfd0388677712694108906    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 26 Mar 2013 17:43:26 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 26 Mar 2013 17:43:26 -0400    

Dumping invalid indexes can cause problems at restore time, for example  
if the reason the index creation failed was because it tried to enforce  
a uniqueness condition not satisfied by the table's data.  Also, if the  
index creation is in fact still in progress, it seems reasonable to  
consider it to be an uncommitted DDL change, which pg_dump wouldn't be  
expected to dump anyway.  
  
Back-patch to all active versions, and teach them to ignore invalid  
indexes in servers back to 8.2, where the concept was introduced.  
  
Michael Paquier  

commit   : 2e4acef357c6eec6b6ae8a7a3b464c96e3f343c7    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Mon, 25 Mar 2013 20:19:22 +0200    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Mon, 25 Mar 2013 20:19:22 +0200    

If you have clusters of different versions pointing to the same tablespace  
location, we would incorrectly include all the data belonging to the other  
versions, too.  
  
Fixes bug #7986, reported by Sergey Burladyan.  

commit   : aa5d7d58ba40187bd8c6a2216bfd24514da78003    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Mon, 25 Mar 2013 11:03:20 +0200    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Mon, 25 Mar 2013 11:03:20 +0200    

These programs don't work against 9.0 or earlier servers, so check that when  
the connection is made. That's better than a cryptic error message you got  
before.  
  
Also, these programs won't work with a 9.3 server, because the WAL streaming  
protocol was changed in a non-backwards-compatible way. As a general rule,  
we don't make any guarantee that an old client will work with a new server,  
so check that. However, allow a 9.1 client to connect to a 9.2 server, to  
avoid breaking environments that currently work; a 9.1 client happens to  
work with a 9.2 server, even though we didn't make any great effort to  
ensure that.  
  
This patch is for the 9.1 and 9.2 branches, I'll commit a similar patch to  
master later. Although this isn't a critical bug fix, it seems safe enough  
to back-patch. The error message you got when connecting to a 9.3devel  
server without this patch was cryptic enough to warrant backpatching.  

commit   : f1bd8a82d7bc127d752e22689ebed9632555cc28    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 23 Mar 2013 19:16:46 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 23 Mar 2013 19:16:46 -0400    

Most (all?) of Russia has moved to what's effectively year-round daylight  
savings time, so that the "standard" zone names now mean an hour later  
than they used to.  Update that, notably changing MSK as per recent  
complaint from Sergey Konoplev, but also CHOT, GET, IRKT, KGT, KRAT,  
MAGT, NOVT, OMST, VLAT, YAKT, YEKT.  The corresponding DST abbreviations  
are presumably now obsolete, but I left them in place with their old  
definitions, just to reduce any possible breakage from this change.  
  
Also add VOLT (Europe/Volgograd), which for some reason we never had  
before, as well as MIST (Antarctica/Macquarie), and fix obsolete  
definitions of MAWT, TKT, and WST.  

commit   : 7a9670b044bd74c183f28ae801158a9857653933    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 23 Mar 2013 14:06:40 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 23 Mar 2013 14:06:40 -0400    

Doing that results in a broken index entry in PDF output.  We had only  
a few like that, which is probably why nobody noticed before.  
Standardize on putting the <term> first.  
  
Josh Kupershmidt  

commit   : 4400976281d07b880c5c311c55e9ec95805b3c66    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 18 Mar 2013 13:34:27 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 18 Mar 2013 13:34:27 -0400    

The docs showed that early-January dates can be considered part of the  
previous year for week-counting purposes, but failed to say explicitly  
that late-December dates can also be considered part of the next year.  
Fix that, and add a cross-reference to the "isoyear" field.  Per bug  
#7967 from Pawel Kobylak.  

commit   : cce7486127f27e6cf2ee56dfcfeb9e7c20a39b90    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 10 Mar 2013 19:18:49 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 10 Mar 2013 19:18:49 -0400    

When RETURNING is specified, ExecDelete would return a virtual-tuple slot  
that could contain pointers into an already-unpinned disk buffer.  Another  
process could change the buffer contents before we get around to using the  
data, resulting in garbage results or even a crash.  This seems of fairly  
low probability, which may explain why there are no known field reports of  
the problem, but it's definitely possible.  Fix by forcing the result slot  
to be "materialized" before we release pin on the disk buffer.  
  
Back-patch to 9.0; in earlier branches there is no bug because  
ExecProcessReturning sent the tuple to the destination immediately.  Also,  
this is already fixed in HEAD as part of the writable-foreign-tables patch  
(where the fix is necessary for DELETE RETURNING to work at all with  
postgres_fdw).  

commit   : ef2a82bebd991fc2ddc8a1ba37c657173b21910b    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 7 Mar 2013 11:51:13 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 7 Mar 2013 11:51:13 -0500    

The previous coding of this function could get into situations where it  
would never terminate, because successive passes would re-add EMPTY arcs  
that had been removed by the previous pass.  Rewrite the function  
completely using a new algorithm that is guaranteed to terminate, and  
also seems to be usually faster than the old one.  Per Tcl bugs 3604074  
and 3606683.  
  
Tom Lane and Don Porter  

commit   : 81e2255fc77a273c8de41fca73741ceac6b75288    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 5 Mar 2013 13:02:38 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 5 Mar 2013 13:02:38 -0500    

formatting.c used locale-dependent case folding rules in some code paths  
where the result isn't supposed to be locale-dependent, for example  
to_char(timestamp, 'DAY').  Since the source data is always just ASCII  
in these cases, that usually didn't matter ... but it does matter in  
Turkish locales, which have unusual treatment of "i" and "I".  To confuse  
matters even more, the misbehavior was only visible in UTF8 encoding,  
because in single-byte encodings we used pg_toupper/pg_tolower which  
don't have locale-specific behavior for ASCII characters.  Fix by providing  
intentionally ASCII-only case-folding functions and using these where  
appropriate.  Per bug #7913 from Adnan Dursun.  Back-patch to all active  
branches, since it's been like this for a long time.  

commit   : 3a779366025504d6993e6a3b1281cd114a0abb71    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 4 Mar 2013 15:13:31 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 4 Mar 2013 15:13:31 -0500    

I fixed this code back in commit 841b4a2d5, but didn't think carefully  
enough about the behavior near zero, which meant it improperly rejected  
1999-12-31 24:00:00.  Per report from Magnus Hagander.  

commit   : c0d35067a57581f7685dc2134a1c4511d925fe4d    
  
author   : Peter Eisentraut <[email protected]>    
date     : Sun, 3 Mar 2013 08:49:49 -0500    
  
committer: Peter Eisentraut <[email protected]>    
date     : Sun, 3 Mar 2013 08:49:49 -0500    

Josh Kupershmidt  

commit   : b2da7c805cb38b6e880c3218699ce8533eb9b151    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 1 Mar 2013 21:33:42 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 1 Mar 2013 21:33:42 -0500    

Careless use of TopMemoryContext for I/O function data meant that repeated  
use of spi_prepare and spi_freeplan would leak memory at the session level,  
as per report from Christian Schröder.  In addition, spi_prepare  
leaked a lot of transient data within the current plperl function's SPI  
Proc context, which would be a problem for repeated use of spi_prepare  
within a single plperl function call; and it wasn't terribly careful  
about releasing permanent allocations in event of an error, either.  
  
In passing, clean up some copy-and-pasteos in query-lookup error messages.  
  
Alex Hunsaker and Tom Lane  

commit   : f5185db27f53b85c1386e589d7dfd9e291f3c967    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 27 Feb 2013 10:40:14 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 27 Feb 2013 10:40:14 -0500    

parseqatom() failed to check for an error return (NULL result) from its  
recursive call to parsebranch(), and in consequence could crash with a  
null-pointer dereference after an error return.  This bug has been there  
since day one, but wasn't noticed before, probably because most error cases  
in parsebranch() didn't actually lead to returning NULL.  Add the missing  
error check, and also tweak parsebranch() to exit in a less indirect  
fashion after a call to parseqatom() fails.  
  
Report by Tomasz Karlik, fix by me.  

commit   : bd0bfe1f8081a1e52d8cf1463c435d5f769c7339    
  
author   : Peter Eisentraut <[email protected]>    
date     : Mon, 25 Feb 2013 17:58:14 -0500    
  
committer: Peter Eisentraut <[email protected]>    
date     : Mon, 25 Feb 2013 17:58:14 -0500    

commit   : e4e35491fcfeeff98ef3454dc4fd060d4812b6f2    
  
author   : Peter Eisentraut <[email protected]>    
date     : Sun, 24 Feb 2013 15:38:07 -0500    
  
committer: Peter Eisentraut <[email protected]>    
date     : Sun, 24 Feb 2013 15:38:07 -0500    

It is obviously no longer true.  

commit   : e779194708f6d4a3ca942c15cd431698cdbbaac4    
  
author   : Peter Eisentraut <[email protected]>    
date     : Sat, 23 Feb 2013 23:30:14 -0500    
  
committer: Peter Eisentraut <[email protected]>    
date     : Sat, 23 Feb 2013 23:30:14 -0500    

commit   : 957bafb2091136161cb7f1a8a56439310c6bd1b2    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Wed, 20 Feb 2013 17:08:54 +0200    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Wed, 20 Feb 2013 17:08:54 +0200    

If a database name contained a '=' character, pg_dumpall failed. The problem  
was in the way pg_dumpall passes the database name to pg_dump on the  
command line. If it contained a '=' character, pg_dump would interpret it  
as a libpq connection string instead of a plain database name.  
  
To fix, pass the database name to pg_dump as a connection string,  
"dbname=foo", with the database name escaped if necessary.  
  
Back-patch to all supported branches.  

commit   : 23ef96327f9ea2a0213d05831175a3ac1b472f29    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Wed, 20 Feb 2013 16:22:47 +0200    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Wed, 20 Feb 2013 16:22:47 +0200    

Back-patch to all supported branches.  

commit   : f73a16340c3eba317ab433466b9ad9eb2f962020    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 13 Feb 2013 14:07:17 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 13 Feb 2013 14:07:17 -0500    

Cases such as similarity('', '') produced a NaN result due to computing  
0/0.  Per discussion, make it return zero instead.  
  
This appears to be the basic cause of bug #7867 from Michele Baravalle,  
although it remains unclear why her installation doesn't think Cyrillic  
letters are letters.  
  
Back-patch to all active branches.  

commit   : 52c889ea4f7696157fde4b74ae62fbe014d06087    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 13 Feb 2013 12:48:15 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 13 Feb 2013 12:48:15 -0500    

Since a backend adds itself to the global listener array during  
Exec_ListenPreCommit, it's inappropriate for it to remove itself during  
Exec_UnlistenCommit or Exec_UnlistenAllCommit --- that leads to failure  
when committing a transaction that did UNLISTEN then LISTEN, since we end  
up not registered though we should be.  (This leads to missing later  
notifications, or to Assert failures in assert-enabled builds.)  Instead  
deal with deregistering at the bottom of AtCommit_Notify, when we know the  
final state of the listenChannels list.  
  
Also, simplify the representation of registration status by replacing the  
transient backendHasExecutedInitialListen flag with an amRegisteredListener  
flag.  
  
Per report from Greg Sabino Mullane.  Back-patch to 9.0, where the problem  
was introduced during the LISTEN/NOTIFY rewrite.  

commit   : bffee6c52c7ae618a7f06da023bfdb66deb0bdb1    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 10 Feb 2013 16:21:37 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 10 Feb 2013 16:21:37 -0500    

After further reflection I was unconvinced that the existing coding is  
guaranteed to return valid union datums in every code path for multi-column  
indexes.  Fix that by forcing a gistunionsubkey() call at the end of the  
recursion.  Having done that, we can remove some clearly-redundant calls  
elsewhere.  This should be a little faster for multi-column indexes (since  
the previous coding would uselessly do such a call for each column while  
unwinding the recursion), as well as much harder to break.  
  
Also, simplify the handling of cases where one side or the other of a  
primary split contains only don't-care tuples.  The previous coding used a  
very ugly hack in removeDontCares() that essentially forced one random  
tuple to be treated as non-don't-care, providing a random initial choice of  
seed datum for the secondary split.  It seems unlikely that that method  
will give better-than-random splits.  Instead, treat such a split as  
degenerate and just let the next column determine the split, the same way  
that we handle fully degenerate cases where the two sides produce identical  
union datums.  

commit   : 0ddfa3b64a187c052c1e3891a9400f8a97520872    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 10 Feb 2013 13:07:50 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 10 Feb 2013 13:07:50 -0500    

This LOG message was put in over five years ago with the evident  
expectation that we'd make all GiST opclasses support secondary split  
directly.  However, no such thing ever happened, and indeed the number of  
opclasses supporting it decreased to zero in 9.2.  The reason is that  
improving on the default implementation isn't that easy --- the  
opclass-specific code that did exist, before 9.2, doesn't appear to have  
been any improvement over the default.  
  
Hence, remove the message altogether.  There's certainly no point in  
nagging users about this in released branches, but I doubt that we'll  
ever implement complete opclass-specific support anyway.  

commit   : a0698406f4c8b4944c6e248c7e8672c4f54db01a    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 10 Feb 2013 11:58:28 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 10 Feb 2013 11:58:28 -0500    

Improve comments, rename some variables and functions, slightly simplify  
a couple of APIs, in an attempt to make this code readable by people other  
than its original author.  
  
Even though this is essentially just cosmetic, back-patch to all active  
branches, because otherwise it's going to make back-patching future fixes  
in this file very painful.  

commit   : 4d4c00850dedb4395138d825cfa3c69545c17f0b    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 8 Feb 2013 18:03:28 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 8 Feb 2013 18:03:28 -0500    

While there's considerable doubt that we want fuzzy behavior in the  
geometric operators at all (let alone as currently implemented), nobody is  
stepping forward to redesign that stuff.  In the meantime it behooves us  
to make sure that index searches agree with the behavior of the underlying  
operators.  This patch fixes two problems in this area.  
  
First, gist_box_same was using fuzzy equality, but it really needs to use  
exact equality to prevent not-quite-identical upper index keys from being  
treated as identical, which for example would prevent an existing upper  
key from being extended by an amount less than epsilon.  This would result  
in inconsistent indexes.  (The next release notes will need to recommend  
that users reindex GiST indexes on boxes, polygons, circles, and points,  
since all four opclasses use gist_box_same.)  
  
Second, gist_point_consistent used exact comparisons for upper-page  
comparisons in ~= searches, when it needs to use fuzzy comparisons to  
ensure it finds all matches; and it used fuzzy comparisons for point <@ box  
searches, when it needs to use exact comparisons because that's what the  
<@ operator (rather inconsistently) does.  
  
The added regression test cases illustrate all three misbehaviors.  
  
Back-patch to all active branches.  (8.4 did not have GiST point_ops,  
but it still seems prudent to apply the gist_box_same patch to it.)  
  
Alexander Korotkov, reviewed by Noah Misch  

commit   : cd3dfb02d8008ee4cca4b948172d3189d0163b06    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 7 Feb 2013 19:14:13 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 7 Feb 2013 19:14:13 -0500    

The previous coding supposed that the first differing bytes in two varlena  
datums must have the same sign difference as their overall comparison  
result.  This is obviously bogus for text strings in non-C locales, and  
probably wrong for numeric, and even for bytea I think it was wrong on  
machines where char is signed.  When the assumption failed, the function  
could deliver a zero or negative penalty in situations where such a result  
is quite ridiculous, leading the core GiST code to make very bad page-split  
decisions.  
  
To fix, take the absolute values of the byte-level differences.  Also,  
switch the code to using unsigned char not just char, so that the behavior  
will be consistent whether char is signed or not.  
  
Per investigation of a trouble report from Tomas Vondra.  Back-patch to all  
supported branches.  

commit   : 500889a9d27cd4a59995b9e28b51022a4872efb3    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 7 Feb 2013 18:22:32 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 7 Feb 2013 18:22:32 -0500    

gbt_var_bin_union() failed to do the right thing when the existing range  
needed to be widened at both ends rather than just one end.  This could  
result in an invalid index in which keys that are present would not be  
found by searches, because the searches would not think they need to  
descend to the relevant leaf pages.  This error affected all the varlena  
datatypes supported by btree_gist (text, bytea, bit, numeric).  
  
Per investigation of a trouble report from Tomas Vondra.  (There is also  
an issue in gbt_var_penalty(), but that should only result in inefficiency  
not wrong answers.  I'm committing this separately so that we have a git  
state in which it can be tested that bad penalty results don't produce  
invalid indexes.)  Back-patch to all supported branches.  

commit   : bb5e312bdc784d406dfddf0e7e1bb23d4114db74    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 7 Feb 2013 17:44:16 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 7 Feb 2013 17:44:16 -0500    

When considering a non-last column in a multi-column GiST index,  
gistsplit.c tries to improve on the split chosen by the opclass-specific  
pickSplit function by considering penalties for the next column.  However,  
there were two bugs in this code: it failed to recompute the union keys for  
the leftmost index columns, even though these might well change after  
reassigning tuples; and it included the old union keys in the recomputation  
for the columns it did recompute, so that those keys couldn't get smaller  
even if they should.  The first problem could result in an invalid index  
in which searches wouldn't find index entries that are in fact present;  
the second would make the index less efficient to search.  
  
Both of these errors were caused by misuse of gistMakeUnionItVec, whose  
API was designed in a way that just begged such errors to be made.  There  
is no situation in which it's safe or useful to compute the union keys for  
a subset of the index columns, and there is no caller that wants any  
previous union keys to be included in the computation; so the undocumented  
choice to treat the union keys as in/out rather than pure output parameters  
is a waste of code as well as being dangerous.  
  
Hence, rather than just making a minimal patch, I've changed the API of  
gistMakeUnionItVec to remove the "startkey" parameter (it now always  
processes all index columns) and treat the attr/isnull arrays as purely  
output parameters.  
  
In passing, also get rid of a couple of unnecessary and dangerous uses  
of static variables in gistutil.c.  It's remarkable that the one in  
gistMakeUnionKey hasn't given us portability troubles before now, because  
in addition to posing a re-entrancy hazard, it was unsafely assuming that  
a static char[] array would have at least Datum alignment.  
  
Per investigation of a trouble report from Tomas Vondra.  (There are also  
some bugs in contrib/btree_gist to be fixed, but that seems like material  
for a separate patch.)  Back-patch to all supported branches.  

commit   : d6f9b2cac36da23373946ff382db0e6217c813a1    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 7 Feb 2013 14:44:15 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 7 Feb 2013 14:44:15 -0500    

Normally, we suppress sending a tabstats message to the collector unless  
there were some actual table stats to send.  However, during backend exit  
we should force out the message if there are any transaction commit/abort  
counts to send, else the session's last few commit/abort counts will never  
get reported at all.  We had logic for this, but the short-circuit test  
at the top of pgstat_report_stat() ignored the "force" flag, with the  
consequence that session-ending transactions that touched no database-local  
tables would not get counted.  Seems to be an oversight in my commit  
641912b4d17fd214a5e5bae4e7bb9ddbc28b144b, which added the "force" flag.  
That was back in 8.3, so back-patch to all supported versions.