PostgreSQL 9.0.13 commit log

Stamp 9.0.13.

  
commit   : a941e89a385c16d5b22f90ad61a103001e2a9faf    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 1 Apr 2013 14:25:34 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 1 Apr 2013 14:25:34 -0400    

Click here for diff

  
  

Update release notes for 9.2.4, 9.1.9, 9.0.13, 8.4.17.

  
commit   : 07918b41f485a86748375d5dadb3d2d2ef6f4155    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 1 Apr 2013 14:11:26 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 1 Apr 2013 14:11:26 -0400    

Click here for diff

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

Fix insecure parsing of server command-line switches.

  
commit   : 3d21a0f3009ad0ba3236499e3851732352e35af6    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 1 Apr 2013 14:01:09 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 1 Apr 2013 14:01:09 -0400    

Click here for diff

  
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  
  

Translation updates

  
commit   : 315af6942017a0b30c94331666b75101e74a2286    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Sun, 31 Mar 2013 23:38:50 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Sun, 31 Mar 2013 23:38:50 -0400    

Click here for diff

  
  

Translation updates

  
commit   : aab4cbfafb57491fbc538a7a92ffe3aec8653fb1    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Sun, 31 Mar 2013 16:40:25 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Sun, 31 Mar 2013 16:40:25 -0300    

Click here for diff

  
  

  
commit   : fb7890aedbd4d67bc1ddee65f9249f5b6ccc9d49    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Sat, 30 Mar 2013 22:20:53 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Sat, 30 Mar 2013 22:20:53 -0400    

Click here for diff

  
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)  
  

Document encode(bytea, ‘escape’)’s behavior correctly.

  
commit   : 01accb380b11b7b874601c6c14c0554a83f35958    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 28 Mar 2013 23:15:05 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 28 Mar 2013 23:15:05 -0400    

Click here for diff

  
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.  
  

Update time zone data files to tzdata release 2013b.

  
commit   : 18bc72e01fb58b8a1a7a528052cf5253d1dd9158    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 28 Mar 2013 15:26:04 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 28 Mar 2013 15:26:04 -0400    

Click here for diff

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

Reset OpenSSL randomness state in each postmaster child process.

  
commit   : 6dd88dad8515332ea5dd4290afe47c6b02dd17ca    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 27 Mar 2013 18:50:32 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 27 Mar 2013 18:50:32 -0400    

Click here for diff

  
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  
  

Fix buffer pin leak in heap update redo routine.

  
commit   : 336e493934bd912128d738404e104be108943fba    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 27 Mar 2013 21:51:27 +0200    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 27 Mar 2013 21:51:27 +0200    

Click here for diff

  
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.  
  

Ignore invalid indexes in pg_dump.

  
commit   : f4428cc21ddab3761a090a4f4d82bd6aa6e5d82f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 26 Mar 2013 17:43:30 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 26 Mar 2013 17:43:30 -0400    

Click here for diff

  
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  
  

Update time zone abbreviation lists for changes missed since 2006.

  
commit   : 40ce24c591c1f1a4707078da04d09797898c4e2c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 23 Mar 2013 19:16:51 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 23 Mar 2013 19:16:51 -0400    

Click here for diff

  
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.  
  

Don’t put before in items.

  
commit   : 716bcb66651c8680ee413703222219608e71c459    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 23 Mar 2013 14:06:44 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 23 Mar 2013 14:06:44 -0400    

Click here for diff

  
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  
  

Improve documentation of EXTRACT(WEEK).

  
commit   : a26e342b8d7cf56c3c6c6545bec33d86eee4378a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 18 Mar 2013 13:34:31 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 18 Mar 2013 13:34:31 -0400    

Click here for diff

  
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.  
  

Fix race condition in DELETE RETURNING.

  
commit   : 8d4bb31618c6f4f251e372cef62a86bb2f9cd1b4    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 10 Mar 2013 19:18:53 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 10 Mar 2013 19:18:53 -0400    

Click here for diff

  
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).  
  

Fix infinite-loop risk in fixempties() stage of regex compilation.

  
commit   : 1dd92380b00781b8318d6d3fb2817468e43fe3a5    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 7 Mar 2013 11:51:18 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 7 Mar 2013 11:51:18 -0500    

Click here for diff

  
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  
  

Fix to_char() to use ASCII-only case-folding rules where appropriate.

  
commit   : a382997ee07a8550f4ea23b5a542b046268a273c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 5 Mar 2013 13:02:43 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 5 Mar 2013 13:02:43 -0500    

Click here for diff

  
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.  
  

Fix overflow check in tm2timestamp (this time for sure).

  
commit   : da5f032a8350a77aeed4f9d459633055f0adb645    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 4 Mar 2013 15:13:31 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 4 Mar 2013 15:13:31 -0500    

Click here for diff

  
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.  
  

doc: Awkward phrasing fix

  
commit   : ffc9daf90549c4412c2ffd82532eb84ca17f5e14    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Sun, 3 Mar 2013 08:49:49 -0500    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Sun, 3 Mar 2013 08:49:49 -0500    

Click here for diff

  
Josh Kupershmidt  
  

Eliminate memory leaks in plperl’s spi_prepare() function.

  
commit   : 18c6dd8b6d613c1b5c5de7fb795d296392c15a74    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 1 Mar 2013 21:33:46 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 1 Mar 2013 21:33:46 -0500    

Click here for diff

  
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  
  

Add missing error check in regexp parser.

  
commit   : 0c54796b5c7458449152d3f812eee5b6cb014c93    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 27 Feb 2013 10:40:20 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 27 Feb 2013 10:40:20 -0500    

Click here for diff

  
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.  
  

doc: Fix markup typo

  
commit   : c191ec79a10670577090d06414c39ad3ff69f521    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 25 Feb 2013 17:58:14 -0500    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 25 Feb 2013 17:58:14 -0500    

Click here for diff

  
  

doc: Remove PostgreSQL version number from xml2 deprecation notice

  
commit   : 4675fd41c72d5a1474c920ab7d37c7f96b9a727e    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Sun, 24 Feb 2013 15:38:07 -0500    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Sun, 24 Feb 2013 15:38:07 -0500    

Click here for diff

  
It is obviously no longer true.  
  

Correct tense in log message

  
commit   : a8d80461a201051b67c286e1a83d00844d7cc6d8    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Sat, 23 Feb 2013 23:30:14 -0500    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Sat, 23 Feb 2013 23:30:14 -0500    

Click here for diff

  
  

Fix pg_dumpall with database names containing =

  
commit   : 8b4ced45ecbc63a5ffade472e7fc3316cd60bd7f    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 20 Feb 2013 17:08:54 +0200    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 20 Feb 2013 17:08:54 +0200    

Click here for diff

  
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.  
  

Don’t pass NULL to fprintf, if a bogus connection string is given to pg_dump.

  
commit   : feae7c3d2bedfccf8c61fafd372b9ddcdae8cc0d    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 20 Feb 2013 16:22:47 +0200    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 20 Feb 2013 16:22:47 +0200    

Click here for diff

  
Back-patch to all supported branches.  
  

Fix contrib/pg_trgm’s similarity() function for trigram-free strings.

  
commit   : 04d7fa5e31f094bd1d87e2da93ba1786a882884f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 13 Feb 2013 14:07:22 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 13 Feb 2013 14:07:22 -0500    

Click here for diff

  
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.  
  

Fix bogus when-to-deregister-from-listener-array logic.

  
commit   : ae1525fdcba5aae4f0efa5ea9803e615644b3e71    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 13 Feb 2013 12:48:20 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 13 Feb 2013 12:48:20 -0500    

Click here for diff

  
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.  
  

Further cleanup of gistsplit.c.

  
commit   : 639f5adb97801539b2bd7c35b9e20b14e034d763    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 10 Feb 2013 16:21:42 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 10 Feb 2013 16:21:42 -0500    

Click here for diff

  
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.  
  

Remove useless picksplit-doesn’t-support-secondary-split log spam.

  
commit   : 782365a6bdff3ec0162771d0f4111897065ffb7d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 10 Feb 2013 13:07:55 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 10 Feb 2013 13:07:55 -0500    

Click here for diff

  
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.  
  

Document and clean up gistsplit.c.

  
commit   : a260208afaf93a48da9813e9efccbea8f59a8fa3    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 10 Feb 2013 11:58:33 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 10 Feb 2013 11:58:33 -0500    

Click here for diff

  
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.  
  

Fix gist_box_same and gist_point_consistent to handle fuzziness correctly.

  
commit   : ccb5def02e71c385cabe05f89e95b99ff7df48b8    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 8 Feb 2013 18:03:33 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 8 Feb 2013 18:03:33 -0500    

Click here for diff

  
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  
  

Make contrib/btree_gist’s GiST penalty function a bit saner.

  
commit   : f504baaf5535fe0b9298f963e6130fd3d8bab642    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 7 Feb 2013 19:14:17 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 7 Feb 2013 19:14:17 -0500    

Click here for diff

  
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.  
  

Fix erroneous range-union logic for varlena types in contrib/btree_gist.

  
commit   : 45b315efd83553871e8e966c1c03441b5601a306    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 7 Feb 2013 18:22:38 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 7 Feb 2013 18:22:38 -0500    

Click here for diff

  
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.  
  

Repair bugs in GiST page splitting code for multi-column indexes.

  
commit   : 932ab7462be18fb905dc2ebd57c729838175947f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 7 Feb 2013 17:44:21 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 7 Feb 2013 17:44:21 -0500    

Click here for diff

  
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.  
  

Fix possible failure to send final transaction counts to stats collector.

  
commit   : 1618b87eb1722c6331b47dd9a2cc801408b99b13    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 7 Feb 2013 14:44:20 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 7 Feb 2013 14:44:20 -0500    

Click here for diff

  
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.