PostgreSQL 9.1.4 commit log

Stamp 9.1.4.

  
commit   : 8e61ded616bdce65c43254b010f801f39b29ce3b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 31 May 2012 19:07:09 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 31 May 2012 19:07:09 -0400    

Click here for diff

  
  

Update release notes for 9.1.4, 9.0.8, 8.4.12, 8.3.19.

  
commit   : 7651ec79879d36a68c9ab32a700ee034f7367701    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 31 May 2012 19:03:39 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 31 May 2012 19:03:39 -0400    

Click here for diff

  
  

Translation updates

  
commit   : 8620f6f18eee348075f7e3430c04d7784edf1b5c    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 31 May 2012 23:31:41 +0300    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 31 May 2012 23:31:41 +0300    

Click here for diff

  
  

Revert back-branch changes in behavior of age(xid).

  
commit   : 3dfaea4727fb3d98e28f4cb9d707c33e2bdbfa7d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 31 May 2012 11:12:26 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 31 May 2012 11:12:26 -0400    

Click here for diff

  
Per discussion, it does not seem like a good idea to change the behavior of  
age(xid) in a minor release, even though the old definition causes the  
function to fail on hot standby slaves.  Therefore, revert commit  
5829387381d2e4edf84652bb5a712f6185860670 and follow-on commits in the back  
branches only.  
  

Update time zone data files to tzdata release 2012c.

  
commit   : 56901beb806bde7af419ad67f49086aaca4fc8df    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 31 May 2012 00:48:04 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 31 May 2012 00:48:04 -0400    

Click here for diff

  
DST law changes in Antarctica, Armenia, Chile, Cuba, Falkland Islands,  
Gaza, Haiti, Hebron, Morocco, Syria, Tokelau Islands.  
Historical corrections for Canada.  
  

Ignore SECURITY DEFINER and SET attributes for a PL’s call handler.

  
commit   : d72a3bd75813615898db27d4bbd2dca5cac9615a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 30 May 2012 23:28:10 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 30 May 2012 23:28:10 -0400    

Click here for diff

  
It's not very sensible to set such attributes on a handler function;  
but if one were to do so, fmgr.c went into infinite recursion because  
it would call fmgr_security_definer instead of the handler function proper.  
There is no way for fmgr_security_definer to know that it ought to call the  
handler and not the original function referenced by the FmgrInfo's fn_oid,  
so it tries to do the latter, causing the whole process to start over  
again.  
  
Ordinarily such misconfiguration of a procedural language's handler could  
be written off as superuser error.  However, because we allow non-superuser  
database owners to create procedural languages and the handler for such a  
language becomes owned by the database owner, it is possible for a database  
owner to crash the backend, which ideally shouldn't be possible without  
superuser privileges.  In 9.2 and up we will adjust things so that the  
handler functions are always owned by superusers, but in existing branches  
this is a minor security fix.  
  
Problem noted by Noah Misch (after several of us had failed to detect  
it :-().  This is CVE-2012-2655.  
  

Expand the allowed range of timezone offsets to +/-15:59:59 from Greenwich.

  
commit   : fea3ea1f23fb7f72aad28a55a09a60897a08dd3d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 30 May 2012 19:58:41 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 30 May 2012 19:58:41 -0400    

Click here for diff

  
We used to only allow offsets less than +/-13 hours, then it was +/14,  
then it was +/-15.  That's still not good enough though, as per today's bug  
report from Patric Bechtel.  This time I actually looked through the Olson  
timezone database to find the largest offsets used anywhere.  The winners  
are Asia/Manila, at -15:56:00 until 1844, and America/Metlakatla, at  
+15:13:42 until 1867.  So we'd better allow offsets less than +/-16 hours.  
  
Given the history, we are way overdue to have some greppable #define  
symbols controlling this, so make some ... and also remove an obsolete  
comment that didn't get fixed the last time.  
  
Back-patch to all supported branches.  
  

Fix incorrect password transformation in contrib/pgcrypto’s DES crypt().

  
commit   : 8db2e820c96a0ce33d3c15f476aa78bebce2c732    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 30 May 2012 10:53:36 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 30 May 2012 10:53:36 -0400    

Click here for diff

  
Overly tight coding caused the password transformation loop to stop  
examining input once it had processed a byte equal to 0x80.  Thus, if the  
given password string contained such a byte (which is possible though not  
highly likely in UTF8, and perhaps also in other non-ASCII encodings), all  
subsequent characters would not contribute to the hash, making the password  
much weaker than it appears on the surface.  
  
This would only affect cases where applications used DES crypt() to encode  
passwords before storing them in the database.  If a weak password has been  
created in this fashion, the hash will stop matching after this update has  
been applied, so it will be easy to tell if any passwords were unexpectedly  
weak.  Changing to a different password would be a good idea in such a case.  
(Since DES has been considered inadequately secure for some time, changing  
to a different encryption algorithm can also be recommended.)  
  
This code, and the bug, are shared with at least PHP, FreeBSD, and OpenBSD.  
Since the other projects have already published their fixes, there is no  
point in trying to keep this commit private.  
  
This bug has been assigned CVE-2012-2143, and credit for its discovery goes  
to Rubin Xu and Joseph Bonneau.  
  

Teach AbortOutOfAnyTransaction to clean up partially-started transactions.

  
commit   : cc2469b0925812424efc8aa24234fc3090a5e85e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 28 May 2012 23:57:14 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 28 May 2012 23:57:14 -0400    

Click here for diff

  
AbortOutOfAnyTransaction failed to do anything if the state it saw on  
entry corresponded to failing partway through StartTransaction.  I fixed  
AbortCurrentTransaction to cope with that case way back in commit  
60b2444cc3ba037630c9b940c3c9ef01b954b87b, but evidently overlooked that  
AbortOutOfAnyTransaction should do likewise.  
  
Back-patch to all supported branches.  It's not clear that this omission  
has any more-than-cosmetic consequences, but it's also not clear that it  
doesn't, so back-patching seems the least risky choice.  
  

Fix handling of pg_stat_statements.stat temporary file

  
commit   : 2791f2180d8e7c469fac2a4d88fc449689e4c970    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Sun, 27 May 2012 10:54:31 +0200    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Sun, 27 May 2012 10:54:31 +0200    

Click here for diff

  
Write the file to a temporary name and then rename() it into the  
permanent name, to ensure it can't end up half-written and corrupt  
in case of a crash during shutdown.  
  
Unlink the file after it has been read so it's removed from the data  
directory and not included in base backups going to replication slaves.  
  

Prevent synchronized scanning when systable_beginscan chooses a heapscan.

  
commit   : 6c1bf45ea50a652d2b8efa778cabb63fdf422e70    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 26 May 2012 19:09:59 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 26 May 2012 19:09:59 -0400    

Click here for diff

  
The only interesting-for-performance case wherein we force heapscan here  
is when we're rebuilding the relcache init file, and the only such case  
that is likely to be examining a catalog big enough to be syncscanned is  
RelationBuildTupleDesc.  But the early-exit optimization in that code gets  
broken if we start the scan at a random place within the catalog, so that  
allowing syncscan is actually a big deoptimization if pg_attribute is large  
(at least for the normal case where the rows for core system catalogs have  
never been changed since initdb).  Hence, prevent syncscan here.  Per my  
testing pursuant to complaints from Jeff Frost and Greg Sabino Mullane,  
though neither of them seem to have actually hit this specific problem.  
  
Back-patch to 8.3, where syncscan was introduced.  
  

Fix string truncation to be multibyte-aware in text_name and bpchar_name.

  
commit   : 71e985a07a7ae9319c00629f319a4c30a9e32fd6    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 25 May 2012 17:34:58 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 25 May 2012 17:34:58 -0400    

Click here for diff

  
Previously, casts to name could generate invalidly-encoded results.  
  
Also, make these functions match namein() more exactly, by consistently  
using palloc0() instead of ad-hoc zeroing code.  
  
Back-patch to all supported branches.  
  
Karl Schnaitter and Tom Lane  
  

Use binary search instead of brute-force scan in findNamespace().

  
commit   : 1a93588ffcad3e4876c9610c0a35d79c7fcdeffe    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 25 May 2012 14:35:41 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 25 May 2012 14:35:41 -0400    

Click here for diff

  
The previous coding presented a significant bottleneck when dumping  
databases containing many thousands of schemas, since the total time  
spent searching would increase roughly as O(N^2) in the number of objects.  
Noted by Jeff Janes, though I rewrote his proposed patch to use the  
existing findObjectByOid infrastructure.  
  
Since this is a longstanding performance bug, backpatch to all supported  
versions.  
  

pg_standby: Remove tabs from string literals

  
commit   : 4615d2ca28fe9dff6e5ebaebd6caf190a0c78ba5    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 23 May 2012 19:58:17 +0300    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 23 May 2012 19:58:17 +0300    

Click here for diff

  
And align a bit better with the rest of the debug output.  
  

Ensure that seqscans check for interrupts at least once per page.

  
commit   : 276bea211f08a3b0d6d5753b654322c8efb781d1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 22 May 2012 19:42:12 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 22 May 2012 19:42:12 -0400    

Click here for diff

  
If a seqscan encounters many consecutive pages containing only dead tuples,  
it can remain in the loop in heapgettup for a long time, and there was no  
CHECK_FOR_INTERRUPTS anywhere in that loop.  This meant there were  
real-world situations where a query would be effectively uncancelable for  
long stretches.  Add a check placed to occur once per page, which should be  
enough to provide reasonable response time without adding any measurable  
overhead.  
  
Report and patch by Merlin Moncure (though I tweaked it a bit).  
Back-patch to all supported branches.  
  

Fix error message for COMMENT/SECURITY LABEL ON COLUMN xxx IS ‘yyy’

  
commit   : ae7c8b290f525504978c01d77366a753505d10d5    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Tue, 22 May 2012 11:19:33 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Tue, 22 May 2012 11:19:33 -0400    

Click here for diff

  
When the column name is an unqualified name, rather than table.column,  
the error message complains about too many dotted names, which is  
wrong.  Report by Peter Eisentraut based on examination of the  
sepgsql regression test output, but the problem also affects COMMENT.  
New wording as suggested by Tom Lane.  
  

Move postmaster’s RemovePgTempFiles call to a less randomly chosen place.

  
commit   : 9255d21d2fe5209c96b712f96c799fe594f00f4b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 21 May 2012 22:50:35 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 21 May 2012 22:50:35 -0400    

Click here for diff

  
There is no reason to do this as early as possible in postmaster startup,  
and good reason not to do it until we have completely created the  
postmaster's lock file, namely that it might contribute to pg_ctl thinking  
that postmaster startup has timed out.  (This would require a rather  
unusual amount of time to be spent scanning temp file directories, but we  
have at least one field report of it happening reproducibly.)  
  
Back-patch to 9.1.  Before that, pg_ctl didn't wait for additional info to  
be added to the lock file, so it wasn't a problem.  
  
Note that this is not a complete fix to the slow-start issue in 9.1,  
because we still had identify_system_timezone being run during postmaster  
start in 9.1.  But that's at least a reasonably well-defined delay, with  
an easy workaround if needed, whereas the temp-files scan is not so  
predictable and cannot be avoided.  
  

Fix bug in to_tsquery().

  
commit   : 435a1437961d72c98a1dbd27c8a9fb75024730f9    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 15 May 2012 19:22:56 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 15 May 2012 19:22:56 +0300    

Click here for diff

  
We were using memcpy() to copy to a possibly overlapping memory region,  
which is a no-no. Use memmove() instead.  
  

  
commit   : 69c058ffc8949c6d86240b096196c4b6b64d87e0    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 13 May 2012 18:06:57 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 13 May 2012 18:06:57 -0400    

Click here for diff

  
If the tablespace directory is missing entirely, we allow DROP TABLESPACE  
to go through, on the grounds that it should be possible to clean up the  
catalog entry in such a situation.  However, we forgot that the pg_tblspc  
symlink might still be there.  We should try to remove the symlink too  
(but not fail if it's no longer there), since not doing so can lead to  
weird behavior subsequently, as per report from Michael Nolan.  
  
There was some discussion of adding dependency links to prevent DROP  
TABLESPACE when the catalogs still contain references to the tablespace.  
That might be worth doing too, but it's an orthogonal question, and in  
any case wouldn't be back-patchable.  
  
Back-patch to 9.0, which is as far back as the logic looks like this.  
We could possibly do something similar in 8.x, but given the lack of  
reports I'm not sure it's worth the trouble, and anyway the case could  
not arise in the form the logic is meant to cover (namely, a post-DROP  
transaction rollback having resurrected the pg_tablespace entry after  
some or all of the filesystem infrastructure is gone).  
  

Ensure backwards compatibility for GetStableLatestTransactionId()

  
commit   : 436af241c88a2f9b971dbe248e6ec6360438033c    
  
author   : Simon Riggs <simon@2ndQuadrant.com>    
date     : Sat, 12 May 2012 13:25:34 +0100    
  
committer: Simon Riggs <simon@2ndQuadrant.com>    
date     : Sat, 12 May 2012 13:25:34 +0100    

Click here for diff

  
  

Fix contrib/citext’s upgrade script to handle array and domain cases.

  
commit   : 2c1382d96c575a79a2ce014dda90fd1de78b3612    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 11 May 2012 15:22:37 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 11 May 2012 15:22:37 -0400    

Click here for diff

  
We previously recognized that citext wouldn't get marked as collatable  
during pg_upgrade from a pre-9.1 installation, and hacked its  
create-from-unpackaged script to manually perform the necessary catalog  
adjustments.  However, we overlooked the fact that domains over citext,  
as well as the citext[] array type, need the same adjustments.  Extend  
the script to handle those cases.  
  
Also, the documentation suggested that this was only an issue in pg_upgrade  
scenarios, which is quite wrong; loading any dump containing citext from a  
pre-9.1 server will also result in the type being wrongly marked.  
  
I approached the documentation problem by changing the 9.1.2 release note  
paragraphs about this issue, which is historically inaccurate.  But it  
seems better than having the information scattered in multiple places, and  
leaving incorrect info in the 9.1.2 notes would be bad anyway.  We'll still  
need to mention the issue again in the 9.1.4 notes, but perhaps they can  
just reference 9.1.2 for fix instructions.  
  
Per report from Evan Carroll.  Back-patch into 9.1.  
  

Prevent loss of init fork when truncating an unlogged table.

  
commit   : 2ca6bac892aa650154f591c730359a968bea726a    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 11 May 2012 09:46:42 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 11 May 2012 09:46:42 -0400    

Click here for diff

  
Fixes bug #6635, reported by Akira Kurosawa.  
  

Remove extraneous #include “storage/proc.h”

  
commit   : f93e45d4071af89cf1b37c76fbd5976d11d77347    
  
author   : Simon Riggs <simon@2ndQuadrant.com>    
date     : Fri, 11 May 2012 14:46:19 +0100    
  
committer: Simon Riggs <simon@2ndQuadrant.com>    
date     : Fri, 11 May 2012 14:46:19 +0100    

Click here for diff

  
  

Ensure age() returns a stable value rather than the latest value

  
commit   : 1a4bc2db6cb80a6e52aed8f5a68b895231653d6c    
  
author   : Simon Riggs <simon@2ndQuadrant.com>    
date     : Fri, 11 May 2012 14:38:11 +0100    
  
committer: Simon Riggs <simon@2ndQuadrant.com>    
date     : Fri, 11 May 2012 14:38:11 +0100    

Click here for diff

  
  

On GiST page split, release the locks on child pages before recursing up.

  
commit   : 153b1dbaa0b94143041ab1e0cf249a02380f0acf    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 11 May 2012 12:35:33 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 11 May 2012 12:35:33 +0300    

Click here for diff

  
When inserting the downlinks for a split gist page, we used hold the locks  
on the child pages until the insertion into the parent - and recursively its  
parent if it had to be split too - were all completed. Change that so that  
the locks on child pages are released after the insertion in the immediate  
parent is done, before recursing further up the tree.  
  
This reduces the number of lwlocks that are held simultaneously. Holding  
many locks is bad for concurrency, and in extreme cases you can even hit  
the limit of 100 simultaneously held lwlocks in a backend. If you're really  
unlucky, you can hit the limit while in a critical section, which brings  
down the whole system.  
  
This fixes bug #6629 reported by Tom Forbes. Backpatch to 9.1. The page  
splitting code was rewritten in 9.1, and the old code did not have this  
problem.  
  

Fix Windows implementation of PGSemaphoreLock.

  
commit   : 1b48f6af315e9db89aaf43e8c8c9de903294fbdf    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 10 May 2012 13:36:18 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 10 May 2012 13:36:18 -0400    

Click here for diff

  
The original coding failed to reset ImmediateInterruptOK before returning,  
which would potentially allow a subsequent query-cancel interrupt to be  
accepted at an unsafe point.  This is a really nasty bug since it's so hard  
to predict the consequences, but they could be unpleasant.  
  
Also, ensure that signal handlers are serviced before this function  
returns, even if the semaphore is already set.  This should make the  
behavior more like Unix.  
  
Back-patch to all supported versions.  
  

Only attempt to show collations on servers >= 9.1.

  
commit   : 71ca53608de1763c0d82bf463580a30f634eba56    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Thu, 10 May 2012 09:11:38 +0200    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Thu, 10 May 2012 09:11:38 +0200    

Click here for diff

  
Show a proper error message instead of a SQL error.  
  
Josh Kupershmidt  
  

PL/pgSQL RETURN NEXT was leaking converted tuples, causing out of memory when looping through large numbers of rows. Flag the converted tuples to be freed. Complaint and patch by Joe.

  
commit   : 05a86891232e1bd5e43d559f30bec2fc00131f37    
  
author   : Joe Conway <mail@joeconway.com>    
date     : Wed, 9 May 2012 22:53:17 -0700    
  
committer: Joe Conway <mail@joeconway.com>    
date     : Wed, 9 May 2012 22:53:17 -0700    

Click here for diff

  
  

Avoid xid error from age() function when run on Hot Standby

  
commit   : e7c43ddc266172f409f5d5bb3e571cafe7d14fa2    
  
author   : Simon Riggs <simon@2ndQuadrant.com>    
date     : Wed, 9 May 2012 13:59:30 +0100    
  
committer: Simon Riggs <simon@2ndQuadrant.com>    
date     : Wed, 9 May 2012 13:59:30 +0100    

Click here for diff

  
  

Overdue code review for transaction-level advisory locks patch.

  
commit   : 1c0e678678a661f8437ed238a5c515b81547aaf4    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 4 May 2012 17:43:35 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 4 May 2012 17:43:35 -0400    

Click here for diff

  
Commit 62c7bd31c8878dd45c9b9b2429ab7a12103f3590 had assorted problems, most  
visibly that it broke PREPARE TRANSACTION in the presence of session-level  
advisory locks (which should be ignored by PREPARE), as per a recent  
complaint from Stephen Rees.  More abstractly, the patch made the  
LockMethodData.transactional flag not merely useless but outright  
dangerous, because in point of fact that flag no longer tells you anything  
at all about whether a lock is held transactionally.  This fix therefore  
removes that flag altogether.  We now rely entirely on the convention  
already in use in lock.c that transactional lock holds must be owned by  
some ResourceOwner, while session holds are never so owned.  Setting the  
locallock struct's owner link to NULL thus denotes a session hold, and  
there is no redundant marker for that.  
  
PREPARE TRANSACTION now works again when there are session-level advisory  
locks, and it is also able to transfer transactional advisory locks to the  
prepared transaction, but for implementation reasons it throws an error if  
we hold both types of lock on a single lockable object.  Perhaps it will be  
worth improving that someday.  
  
Assorted other minor cleanup and documentation editing, as well.  
  
Back-patch to 9.1, except that in the 9.1 branch I did not remove the  
LockMethodData.transactional flag for fear of causing an ABI break for  
any external code that might be examining those structs.  
  

  
commit   : 6d362ec209f0174f36a78936c5269f8d5f2cd26e    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Thu, 3 May 2012 13:01:31 +0200    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Thu, 3 May 2012 13:01:31 +0200    

Click here for diff

  
This backatches Heikki's patch in 140a4fbf1a87891a79a2c61a08416828d39f286a  
to make sure the documentation on the website gets updated, since  
we're regularly receiving complains about this link.  
  

Fix printing of whole-row Vars at top level of a SELECT targetlist.

  
commit   : 08bc189ee746606b6417ed4a2f0f9d7901c5b8e1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 27 Apr 2012 19:49:26 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 27 Apr 2012 19:49:26 -0400    

Click here for diff

  
Normally whole-row Vars are printed as "tabname.*".  However, that does not  
work at top level of a targetlist, because per SQL standard the parser will  
think that the "*" should result in column-by-column expansion; which is  
not at all what a whole-row Var implies.  We used to just print the table  
name in such cases, which works most of the time; but it fails if the table  
name matches a column name available anywhere in the FROM clause.  This  
could lead for instance to a view being interpreted differently after dump  
and reload.  Adding parentheses doesn't fix it, but there is a reasonably  
simple kluge we can use instead: attach a no-op cast, so that the "*" isn't  
syntactically at top level anymore.  This makes the printing of such  
whole-row Vars a lot more consistent with other Vars, and may indeed fix  
more cases than just the reported one; I'm suspicious that cases involving  
schema qualification probably didn't work properly before, either.  
  
Per bug report and fix proposal from Abbas Butt, though this patch is quite  
different in detail from his.  
  
Back-patch to all supported versions.  
  

Fix syslogger’s rotation disable/re-enable logic.

  
commit   : 1869f000b0a31d71906ad6ac6e86b08a65f723f0    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 27 Apr 2012 00:12:47 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 27 Apr 2012 00:12:47 -0400    

Click here for diff

  
If it fails to open a new log file, the syslogger assumes there's something  
wrong with its parameters (such as log_directory), and stops attempting  
automatic time-based or size-based log file rotations.  Sending it SIGHUP  
is supposed to start that up again.  However, the original coding for that  
was really bogus, involving clobbering a couple of GUC variables and hoping  
that SIGHUP processing would restore them.  Get rid of that technique in  
favor of maintaining a separate flag showing we've turned rotation off.  
Per report from Mark Kirkwood.  
  
Also, the syslogger will automatically attempt to create the log_directory  
directory if it doesn't exist, but that was only happening at startup.  
For consistency and ease of use, it should do the same whenever the value  
of log_directory is changed by SIGHUP.  
  
Back-patch to all supported branches.  
  

PL/Python: Accept strings in functions returning composite types

  
commit   : 4fa520f147992616a08e5dbb34620dc46d664fc2    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 26 Apr 2012 21:03:48 +0300    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 26 Apr 2012 21:03:48 +0300    

Click here for diff

  
Before 9.1, PL/Python functions returning composite types could return  
a string and it would be parsed using record_in.  The 9.1 changes made  
PL/Python only expect dictionaries, tuples, or objects supporting  
getattr as output of composite functions, resulting in a regression  
and a confusing error message, as the strings were interpreted as  
sequences and the code for transforming lists to database tuples was  
used.  Fix this by treating strings separately as before, before  
checking for the other types.  
  
The reason why it's important to support string to database tuple  
conversion is that trigger functions on tables with composite columns  
get the composite row passed in as a string (from record_out).  
Without supporting converting this back using record_in, this makes it  
impossible to implement pass-through behavior for these columns, as  
PL/Python no longer accepts strings for composite values.  
  
A better solution would be to fix the code that transforms composite  
inputs into Python objects to produce dictionaries that would then be  
correctly interpreted by the Python->PostgreSQL counterpart code.  But  
that would be too invasive to backpatch to 9.1, and it is too late in  
the 9.2 cycle to attempt it.  It should be revisited in the future,  
though.  
  
Reported as bug #6559 by Kirill Simonov.  
  
Jan Urbański  
  

Fix planner’s handling of RETURNING lists in writable CTEs.

  
commit   : dc7521dcb9410167a4748d9702bfe05746d7d27a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 25 Apr 2012 20:20:43 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 25 Apr 2012 20:20:43 -0400    

Click here for diff

  
setrefs.c failed to do "rtoffset" adjustment of Vars in RETURNING lists,  
which meant they were left with the wrong varnos when the RETURNING list  
was in a subquery.  That was never possible before writable CTEs, of  
course, but now it's broken.  The executor fails to notice any problem  
because ExecEvalVar just references the ecxt_scantuple for any normal  
varno; but EXPLAIN breaks when the varno is wrong, as illustrated in a  
recent complaint from Bartosz Dmytrak.  
  
Since the eventual rtoffset of the subquery is not known at the time  
we are preparing its plan node, the previous scheme of executing  
set_returning_clause_references() at that time cannot handle this  
adjustment.  Fortunately, it turns out that we don't really need to do it  
that way, because all the needed information is available during normal  
setrefs.c execution; we just have to dig it out of the ModifyTable node.  
So, do that, and get rid of the kluge of early setrefs processing of  
RETURNING lists.  (This is a little bit of a cheat in the case of inherited  
UPDATE/DELETE, because we are not passing a "root" struct that corresponds  
exactly to what the subplan was built with.  But that doesn't matter, and  
anyway this is less ugly than early setrefs processing was.)  
  
Back-patch to 9.1, where the problem became possible to hit.  
  

Fix edge-case behavior of pg_next_dst_boundary().

  
commit   : bf0d462a9d85037558861d9c6d50d2eaa284cc34    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 25 Apr 2012 17:25:18 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 25 Apr 2012 17:25:18 -0400    

Click here for diff

  
Due to rather sloppy thinking (on my part, I'm afraid) about the  
appropriate behavior for boundary conditions, pg_next_dst_boundary() gave  
undefined, platform-dependent results when the input time is exactly the  
last recorded DST transition time for the specified time zone, as a result  
of fetching values one past the end of its data arrays.  
  
Change its specification to be that it always finds the next DST boundary  
*after* the input time, and adjust code to match that.  The sole existing  
caller, DetermineTimeZoneOffset, doesn't actually care about this  
distinction, since it always uses a probe time earlier than the instant  
that it does care about.  So it seemed best to me to change the API to make  
the result=1 and result=0 cases more consistent, specifically to ensure  
that the "before" outputs always describe the state at the given time,  
rather than hacking the code to obey the previous API comment exactly.  
  
Per bug #6605 from Sergey Burladyan.  Back-patch to all supported versions.  
  

PL/Python: Improve error messages

  
commit   : f33f1a875f9b799da202408e118a47e4ee2bab7b    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 25 Apr 2012 21:11:59 +0300    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 25 Apr 2012 21:11:59 +0300    

Click here for diff

  
  

Revert recent commit re positional arguments.

  
commit   : 342901930c1baefe49688c7d25a69196cf644180    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Wed, 18 Apr 2012 10:58:24 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Wed, 18 Apr 2012 10:58:24 -0400    

Click here for diff

  
  

Fix copyfuncs/equalfuncs support for ReassignOwnedStmt.

  
commit   : f8c53d5b411da9518876c93161199e38eaaa5118    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Wed, 18 Apr 2012 10:45:18 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Wed, 18 Apr 2012 10:45:18 -0400    

Click here for diff

  
Noah Misch  
  

Don’t override arguments set via options with positional arguments.

  
commit   : a146e7be893446521362d60d302d50dfe1001f13    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Tue, 17 Apr 2012 18:37:42 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Tue, 17 Apr 2012 18:37:42 -0400    

Click here for diff

  
A number of utility programs were rather careless about paremeters  
that can be set via both an option argument and a positional  
argument. This leads to results which can violate the Principal  
Of Least Astonishment. These changes refuse to use positional  
arguments to override settings that have been made via positional  
arguments. The changes are backpatched to all live branches.  
  

Don’t wait for the commit record to be replicated if we wrote no WAL.

  
commit   : 10fcfada235af6186c9474230483ab0fe5c9610d    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 17 Apr 2012 16:28:31 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 17 Apr 2012 16:28:31 +0300    

Click here for diff

  
When using synchronous replication, we waited for the commit record to be  
replicated, but if we our transaction didn't write any other WAL records,  
that's not required because we don't even flush the WAL locally to disk in  
that case. This lead to long waits when committing a transaction that only  
modified a temporary table. Bug spotted by Thom Brown.  
  

Clamp indexscan filter condition cost estimate to be not less than zero.

  
commit   : 79853989c577cc90754d7562363bf802157864ae    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 11 Apr 2012 20:24:25 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 11 Apr 2012 20:24:25 -0400    

Click here for diff

  
cost_index tries to estimate the per-tuple costs of evaluating filter  
conditions (a/k/a qpquals) by subtracting the estimated cost of the  
indexqual conditions from that of the baserestrictinfo conditions.  This is  
correct so long as the indexquals list is a subset of the baserestrictinfo  
list.  However, in the presence of derived indexable conditions it's  
completely wrong, leading to bogus or even negative scan cost estimates,  
as seen for example in bug #6579 from Istvan Endredy.  In practice the  
problem isn't severe except in the specific case of a LIKE optimization on  
a functional index containing a very expensive function.  
  
A proper fix for this might change cost estimates by more than people would  
like for stable branches, so in the back branches let's just clamp the cost  
difference to be not less than zero.  That will at least prevent completely  
insane behavior, while not changing the results normally.  
  

Ignore missing schemas during non-interactive assignment of search_path.

  
commit   : 35400e14b8e0dea994862d0f16d275b35b5e31b3    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 11 Apr 2012 12:02:14 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 11 Apr 2012 12:02:14 -0400    

Click here for diff

  
This aligns 9.1's behavior with that of older branches.  HEAD is now even  
laxer, ignoring missing schemas all the time, but that seems like too big  
a change for a released branch.  Per complaint from Robert Haas.  
  

Fix pg_upgrade to properly upgrade a table that is stored in the cluster default tablespace, but part of a database that is in a user-defined tablespace. Caused “file not found” error during upgrade.

  
commit   : 6cc2ed14f166604b11f85188724c47325ab37b4b    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 10 Apr 2012 19:57:14 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 10 Apr 2012 19:57:14 -0400    

Click here for diff

  
Per bug report from Ants Aasma.  
  
Backpatch to 9.1 and 9.0.  
  

Adjust various references to GEQO being non-deterministic.

  
commit   : 5cf6fddd63c29daab6daa6d0981d51c5f64b876a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Apr 2012 20:49:06 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Apr 2012 20:49:06 -0400    

Click here for diff

  
It's still non-deterministic in some sense ... but given fixed settings  
and identical planning problems, it will now always choose the same plan,  
so we probably shouldn't tar it with that brush.  Per bug #6565 from  
Guillaume Cottenceau.  Back-patch to 9.0 where the behavior was fixed.  
  

Fix an Assert that turns out to be reachable after all.

  
commit   : 0e20abdb47e3499353ac4fd1b2d21e82ec6b1461    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Apr 2012 11:58:24 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Apr 2012 11:58:24 -0400    

Click here for diff

  
estimate_num_groups() gets unhappy with  
	create table empty();  
	select * from empty except select * from empty e2;  
I can't see any actual use-case for such a query (and the table is illegal  
per SQL spec), but it seems like a good idea that it not cause an assert  
failure.  
  

set_stack_base() no longer needs to be called in PostgresMain.

  
commit   : 88e071533fba70747aaf8d9b32fb927b7157ad16    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Sun, 8 Apr 2012 19:39:12 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Sun, 8 Apr 2012 19:39:12 +0300    

Click here for diff

  
This was a thinko in previous commit. Now that stack base pointer is now set  
in PostmasterMain and SubPostmasterMain, it doesn't need to be set in  
PostgresMain anymore.  
  

Do stack-depth checking in all postmaster children.

  
commit   : ef29bb1f7254222835267cc03389ed12602c677c    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Sun, 8 Apr 2012 18:28:12 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Sun, 8 Apr 2012 18:28:12 +0300    

Click here for diff

  
We used to only initialize the stack base pointer when starting up a regular  
backend, not in other processes. In particular, autovacuum workers can run  
arbitrary user code, and without stack-depth checking, infinite recursion  
in e.g an index expression will bring down the whole cluster.  
  
The comment about PL/Java using set_stack_base() is not yet true. As the  
code stands, PL/java still modifies the stack_base_ptr variable directly.  
However, it's been discussed in the PL/Java mailing list that it should be  
changed to use the function, because PL/Java is currently oblivious to the  
register stack used on Itanium. There's another issues with PL/Java, namely  
that the stack base pointer it sets is not really the base of the stack, it  
could be something close to the bottom of the stack. That's a separate issue  
that might need some further changes to this code, but that's a different  
story.  
  
Backpatch to all supported releases.  
  

Update URL for pgtclng project.

  
commit   : 63d8636c50f2ca053aa6a214340bb322bc5687d5    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 6 Apr 2012 19:00:18 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 6 Apr 2012 19:00:18 -0400    

Click here for diff

  
Thom Brown  
  

Fix misleading output from gin_desc().

  
commit   : e2923d341994a0aa3881ca29f345c40a98b6cb60    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 6 Apr 2012 18:10:26 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 6 Apr 2012 18:10:26 -0400    

Click here for diff

  
XLOG_GIN_UPDATE_META_PAGE and XLOG_GIN_DELETE_LISTPAGE records were printed  
with a list link field labeled as "blkno", which was confusing, especially  
when the link was empty (InvalidBlockNumber).  Print the metapage block  
number instead, since that's what's actually being updated.  We could  
include the link values too as a separate field, but not clear it's worth  
the trouble.  
  
Back-patch to 8.4 where the dubious code was added.  
  

Fix syslogger to not lose log coherency under high load.

  
commit   : 60243e89a707bb141aa1b164c2d6fb59e3e22408    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 4 Apr 2012 15:05:16 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 4 Apr 2012 15:05:16 -0400    

Click here for diff

  
The original coding of the syslogger had an arbitrary limit of 20 large  
messages concurrently in progress, after which it would just punt and dump  
message fragments to the output file separately.  Our ambitions are a bit  
higher than that now, so allow the data structure to expand as necessary.  
  
Reported and patched by Andrew Dunstan; some editing by Tom  
  

  
commit   : 8d2a5fb219aab954fe6642a2c1abdaa058ddeaef    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 3 Apr 2012 20:43:20 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 3 Apr 2012 20:43:20 -0400    

Click here for diff

  
dblink_exec leaked temporary database connections if any error occurred  
after connection setup, for example  
	SELECT dblink_exec('...connect string...', 'select 1/0');  
Add a PG_TRY block to ensure PQfinish gets done when it is needed.  
(dblink_record_internal is on the hairy edge of needing similar treatment,  
but seems not to be actively broken at the moment.)  
  
Also, in 9.0 and up, only one of the three functions using tuplestore  
return mode was properly checking that the query context would allow  
a tuplestore result.  
  
Noted while reviewing dblink patch.  Back-patch to all supported branches.  
  

Fix O(N^2) behavior in pg_dump when many objects are in dependency loops.

  
commit   : 99e2076bc73fe20c856986c50f4eafefa23edc38    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 31 Mar 2012 15:51:11 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 31 Mar 2012 15:51:11 -0400    

Click here for diff

  
Combining the loop workspace with the record of already-processed objects  
might have been a cute trick, but it behaves horridly if there are many  
dependency loops to repair: the time spent in the first step of findLoop()  
grows as O(N^2).  Instead use a separate flag array indexed by dump ID,  
which we can check in constant time.  The length of the workspace array  
is now never more than the actual length of a dependency chain, which  
should be reasonably short in all cases of practical interest.  The code  
is noticeably easier to understand this way, too.  
  
Per gripe from Mike Roest.  Since this is a longstanding performance bug,  
backpatch to all supported versions.  
  

Fix O(N^2) behavior in pg_dump for large numbers of owned sequences.

  
commit   : fa76bb0168326b322a5dbb2cdffed51c79289cde    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 31 Mar 2012 14:42:23 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 31 Mar 2012 14:42:23 -0400    

Click here for diff

  
The loop that matched owned sequences to their owning tables required time  
proportional to number of owned sequences times number of tables; although  
this work was only expended in selective-dump situations, which is probably  
why the issue wasn't recognized long since.  Refactor slightly so that we  
can perform this work after the index array for findTableByOid has been  
set up, reducing the time to O(M log N).  
  
Per gripe from Mike Roest.  Since this is a longstanding performance bug,  
backpatch to all supported versions.  
  

  
commit   : dde1813dff577991a71bd3beedb333cd2ad2559f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 29 Mar 2012 17:52:33 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 29 Mar 2012 17:52:33 -0400    

Click here for diff

  
The DBLINK_GET_CONN and DBLINK_GET_NAMED_CONN macros did not set the  
surrounding function's conname variable, causing errors to be incorrectly  
reported as having occurred on the "unnamed" connection in some cases.  
This bug was actually visible in two cases in the regression tests,  
but apparently whoever added those cases wasn't paying attention.  
  
Noted by Kyotaro Horiguchi, though this is different from his proposed  
patch.  
  
Back-patch to 8.4; 8.3 does not have the same type of error reporting  
so the patch is not relevant.  
  

Correct epoch of txid_current() when executed on a Hot Standby server. Initialise ckptXidEpoch from starting checkpoint and maintain the correct value as we roll forwards. This allows GetNextXidAndEpoch() to return the correct epoch when executed during recovery. Backpatch to 9.0 when the problem is first observable by a user.

  
commit   : 20d98ab6e4110087d1816cd105a40fcc8ce0a307    
  
author   : Simon Riggs <simon@2ndQuadrant.com>    
date     : Thu, 29 Mar 2012 14:57:08 +0100    
  
committer: Simon Riggs <simon@2ndQuadrant.com>    
date     : Thu, 29 Mar 2012 14:57:08 +0100    

Click here for diff

  
Bug report from Daniel Farina  
  

pg_basebackup: Error handling fixes.

  
commit   : 4d278b785e22ff8d56ac86d5ed1871e096b2ea80    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Wed, 28 Mar 2012 12:19:22 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Wed, 28 Mar 2012 12:19:22 -0400    

Click here for diff

  
Thomas Ogrisegg and Fujii Masao  
  

Fix COPY FROM for null marker strings that correspond to invalid encoding.

  
commit   : 9f0a01707607e476ac3a89854777cdba76e0ff37    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 25 Mar 2012 23:17:27 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 25 Mar 2012 23:17:27 -0400    

Click here for diff

  
The COPY documentation says "COPY FROM matches the input against the null  
string before removing backslashes".  It is therefore reasonable to presume  
that null markers like E'\\0' will work ... and they did, until someone put  
the tests in the wrong order during microoptimization-driven rewrites.  
Since then, we've been failing if the null marker is something that would  
de-escape to an invalidly-encoded string.  Since null markers generally  
need to be something that can't appear in the data, this represents a  
nontrivial loss of functionality; surprising nobody noticed it earlier.  
  
Per report from Jeff Davis.  Backpatch to 8.4 where this got broken.  
  

Fix planner’s handling of outer PlaceHolderVars within subqueries.

  
commit   : 811a2cbc167bfef4e5a88d468d5258385318ad87    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 24 Mar 2012 16:21:48 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 24 Mar 2012 16:21:48 -0400    

Click here for diff

  
For some reason, in the original coding of the PlaceHolderVar mechanism  
I had supposed that PlaceHolderVars couldn't propagate into subqueries.  
That is of course entirely possible.  When it happens, we need to treat  
an outer-level PlaceHolderVar much like an outer Var or Aggref, that is  
SS_replace_correlation_vars() needs to replace the PlaceHolderVar with  
a Param, and then when building the finished SubPlan we have to provide  
the PlaceHolderVar expression as an actual parameter for the SubPlan.  
The handling of the contained expression is a bit delicate but it can be  
treated exactly like an Aggref's expression.  
  
In addition to the missing logic in subselect.c, prepjointree.c was failing  
to search subqueries for PlaceHolderVars that need their relids adjusted  
during subquery pullup.  It looks like everyplace else that touches  
PlaceHolderVars got it right, though.  
  
Per report from Mark Murawski.  In 9.1 and HEAD, queries affected by this  
oversight would fail with "ERROR: Upper-level PlaceHolderVar found where  
not expected".  But in 9.0 and 8.4, you'd silently get possibly-wrong  
answers, since the value transmitted into the subquery wouldn't go to null  
when it should.  
  

Cast some printf arguments to avoid possibly-nonportable behavior.

  
commit   : eca0c389f185b6bd76b4ca77195aa47d2e90dbb2    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 23 Mar 2012 20:18:08 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 23 Mar 2012 20:18:08 -0400    

Click here for diff

  
Per compiler warnings on buildfarm member black_firefly.  
  

Update docs on numeric storage requirements.

  
commit   : 10b2e7404f80ef26a3a6df6b1a9121bd16efb905    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Thu, 22 Mar 2012 15:40:27 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Thu, 22 Mar 2012 15:40:27 -0400    

Click here for diff

  
Since 9.1, the minimum overhead is three bytes, not five.  
  
Fujii Masao  
  

Fix GET DIAGNOSTICS for case of assignment to function’s first variable.

  
commit   : f318ee848c9a7c3dd289fe67245e4a12ba136bca    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 22 Mar 2012 14:13:17 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 22 Mar 2012 14:13:17 -0400    

Click here for diff

  
An incorrect and entirely unnecessary "safety check" in exec_stmt_getdiag()  
caused the code to treat an assignment to a variable with dno zero as a  
no-op.  Unfortunately, that's a perfectly valid dno.  This has been broken  
since GET DIAGNOSTICS was invented.  It's not terribly surprising that the  
bug went unnoticed for so long, since in most cases you probably wouldn't  
use the function's first-created variable (normally its first parameter)  
as a GET DIAGNOSTICS target.  Nonetheless, it's broken.  Per bug #6551  
from Adam Buraczewski.  
  

Back-patch contrib/vacuumlo’s new -l (limit) option into 9.0 and 9.1.

  
commit   : 5bd06e619c82c3b2e29fed40aae5fc39a9620908    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 21 Mar 2012 13:04:07 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 21 Mar 2012 13:04:07 -0400    

Click here for diff

  
Since 9.0, removing lots of large objects in a single transaction risks  
exceeding max_locks_per_transaction, because we merged large object removal  
into the generic object-drop mechanism, which takes out an exclusive lock  
on each object to be dropped.  This creates a hazard for contrib/vacuumlo,  
which has historically tried to drop all unreferenced large objects in one  
transaction.  There doesn't seem to be any correctness requirement to do it  
that way, though; we only need to drop enough large objects per transaction  
to amortize the commit costs.  
  
To prevent a regression from pre-9.0 releases wherein vacuumlo worked just  
fine, back-patch commits b69f2e36402aaa222ed03c1769b3de6d5be5f302 and  
64c604898e812aa93c124c666e8709fff1b8dd26, which break vacuumlo's deletions  
into multiple transactions with a user-controllable upper limit on the  
number of objects dropped per transaction.  
  
Tim Lewis, Robert Haas, Tom Lane  
  

Don’t allow CREATE TABLE AS to put relations in pg_global.

  
commit   : 16f42be840bc7a96fb008055632388954c3548ba    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Wed, 21 Mar 2012 12:38:34 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Wed, 21 Mar 2012 12:38:34 -0400    

Click here for diff

  
This was never intended to be allowed, and is blocked for an ordinary  
CREATE TABLE, but CREATE TABLE AS slipped through the cracks.  This  
commit won't do anything to fix existing cases where this has loophole  
has been exploited, but it still seems prudent to lock it down going  
forward.  
  
Back-branch commit only, as this problem has been refactored away  
on the master branch.  
  
Andres Freund  
  

Fix bug where walsender goes into a busy loop if connection is terminated.

  
commit   : 04e9dc6e01dd8acb1b477c1649172dfbda822581    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 21 Mar 2012 17:43:53 +0200    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 21 Mar 2012 17:43:53 +0200    

Click here for diff

  
The problem was that ResetLatch was not being called in the walsender loop  
if the connection was terminated, so WaitLatch never sleeps until the  
terminated connection is detected. In the master-branch, this was already  
fixed as a side-effect of some refactoring of the loop. This commit  
backports that refactoring to 9.1. 9.0 does not have this bug, because we  
didn't use latches back then.  
  
Fujii Masao  
  

Update struct Trigger in docs

  
commit   : 52b03fbdfed752ff10620d44eb808b09baf29add    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 20 Mar 2012 13:14:16 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 20 Mar 2012 13:14:16 -0300    

Click here for diff

  
  

plperl: Package-qualify _TD

  
commit   : bceef1bcbefec400e35789c3ffb9fbdd1ee534d9    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 19 Mar 2012 17:29:05 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 19 Mar 2012 17:29:05 -0300    

Click here for diff

  
Failing to do so causes trigger invocation to fail when they are nested  
within a function invocation that changes the current package.  
  
Backpatch to 9.1; previous releases used a different method to obtain  
_TD.  Per bug report from Mark Murawski (bug #6511)  
  
Author: Alex Hunsaker  
  

In pg_upgrade, remove dependency on pg_config, as that might not be in the non-development install. Instead, use the LOAD mechanism to check for the pg_upgrade_support shared object, like we do for other shared object checks.

  
commit   : 28155746150f584e8147e2e3f68fec8c0d819cbf    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 19 Mar 2012 09:31:50 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 19 Mar 2012 09:31:50 -0400    

Click here for diff

  
Backpatch to 9.1.  
  
Report from Àlvaro  
  

Honor inputdir and outputdir when converting regression files.

  
commit   : ed79eddba9367f1e35e480e87cbaafc18b9f75ca    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Sat, 17 Mar 2012 17:30:52 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Sat, 17 Mar 2012 17:30:52 -0400    

Click here for diff

  
When converting source files, pg_regress' inputdir and outputdir options were  
ignored when computing the locations of the destination files. In consequence,  
these options were effectively unusable when the regression inputs need to  
be adjusted by pg_regress. This patch makes pg_regress put the converted files  
in the same place that these options specify non-converted input or results  
files are to be found. Backpatched to all live branches.  
  

pg_restore: Fix memory and file descriptor leak with directory format

  
commit   : b6948e15464d7e86c0d892619d9c90c9cfd124f1    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 16 Mar 2012 19:53:31 +0200    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 16 Mar 2012 19:53:31 +0200    

Click here for diff

  
found by Coverity  
  

Revisit handling of UNION ALL subqueries with non-Var output columns.

  
commit   : 805f798e0ef0030b0f475a7a56322c51b5ef38b3    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 16 Mar 2012 13:11:20 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 16 Mar 2012 13:11:20 -0400    

Click here for diff

  
In commit 57664ed25e5dea117158a2e663c29e60b3546e1c I tried to fix a bug  
reported by Teodor Sigaev by making non-simple-Var output columns distinct  
(by wrapping their expressions with dummy PlaceHolderVar nodes).  This did  
not work too well.  Commit b28ffd0fcc583c1811e5295279e7d4366c3cae6c fixed  
some ensuing problems with matching to child indexes, but per a recent  
report from Claus Stadler, constraint exclusion of UNION ALL subqueries was  
still broken, because constant-simplification didn't handle the injected  
PlaceHolderVars well either.  On reflection, the original patch was quite  
misguided: there is no reason to expect that EquivalenceClass child members  
will be distinct.  So instead of trying to make them so, we should ensure  
that we can cope with the situation when they're not.  
  
Accordingly, this patch reverts the code changes in the above-mentioned  
commits (though the regression test cases they added stay).  Instead, I've  
added assorted defenses to make sure that duplicate EC child members don't  
cause any problems.  Teodor's original problem ("MergeAppend child's  
targetlist doesn't match MergeAppend") is addressed more directly by  
revising prepare_sort_from_pathkeys to let the parent MergeAppend's sort  
list guide creation of each child's sort list.  
  
In passing, get rid of add_sort_column; as far as I can tell, testing for  
duplicate sort keys at this stage is dead code.  Certainly it doesn't  
trigger often enough to be worth expending cycles on in ordinary queries.  
And keeping the test would've greatly complicated the new logic in  
prepare_sort_from_pathkeys, because comparing pathkey list entries against  
a previous output array requires that we not skip any entries in the list.  
  
Back-patch to 9.1, like the previous patches.  The only known issue in  
this area that wasn't caused by the ill-advised previous patches was the  
MergeAppend planning failure, which of course is not relevant before 9.1.  
It's possible that we need some of the new defenses against duplicate child  
EC entries in older branches, but until there's some clear evidence of that  
I'm going to refrain from back-patching further.  
  

Patch some corner-case bugs in pl/python.

  
commit   : 0cb4a0bfb80c7d75c745faf3597bed5c3f9a3c49    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 13 Mar 2012 15:26:36 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 13 Mar 2012 15:26:36 -0400    

Click here for diff

  
Dave Malcolm of Red Hat is working on a static code analysis tool for  
Python-related C code.  It reported a number of problems in plpython,  
most of which were failures to check for NULL results from object-creation  
functions, so would only be an issue in very-low-memory situations.  
  
Patch in HEAD and 9.1.  We could go further back but it's not clear that  
these issues are important enough to justify the work.  
  
Jan Urbański  
  

Remove tabs in SGML files

  
commit   : 5a264d4aa09466746de6311e3728d094f01f325f    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 12 Mar 2012 10:13:39 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 12 Mar 2012 10:13:39 -0400    

Click here for diff

  
  

Add description for –no-locale and –text-search-config.

  
commit   : 66d3e691dbfdd4af56e19303bbfa36dbdd561dce    
  
author   : Tatsuo Ishii <ishii@postgresql.org>    
date     : Sun, 11 Mar 2012 19:24:34 +0900    
  
committer: Tatsuo Ishii <ishii@postgresql.org>    
date     : Sun, 11 Mar 2012 19:24:34 +0900    

Click here for diff

  
  

ecpg: Fix off-by-one error in memory copying

  
commit   : 3043608cf72b0abd8b022034080f44cc29ff0cf5    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 8 Mar 2012 22:29:01 +0200    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 8 Mar 2012 22:29:01 +0200    

Click here for diff

  
In a rare case, one byte past the end of memory belonging to the  
sqlca_t structure would be written to.  
  
found by Coverity  
  

ecpg: Fix rare memory leaks

  
commit   : 6f59d42b943e721c6ddf9513e3e82067ca40bce5    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 8 Mar 2012 22:21:12 +0200    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 8 Mar 2012 22:21:12 +0200    

Click here for diff

  
found by Coverity  
  

psql: Fix invalid memory access

  
commit   : 46c9f5d6f0bf680708fbd7c1972a31b58fab5f35    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 7 Mar 2012 23:46:41 +0200    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 7 Mar 2012 23:46:41 +0200    

Click here for diff

  
Due to an apparent thinko, when printing a table in expanded mode  
(\x), space would be allocated for 1 slot plus 1 byte per line,  
instead of 1 slot per line plus 1 slot for the NULL terminator.  When  
the line count is small, reading or writing the terminator would  
therefore access memory beyond what was allocated.  
  

libpq: Fix memory leak

  
commit   : 0ba7ff5fa542c1cf77bac001c534ff0c82b2fde2    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 7 Mar 2012 23:35:03 +0200    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 7 Mar 2012 23:35:03 +0200    

Click here for diff

  
If a client encoding is specified as a connection parameter (or  
environment variable), internal storage allocated for it would never  
be freed.  
  

Fix some issues with temp/transient tables in extension scripts.

  
commit   : ad05b5d28d99e1511a10b542c72ada2e97cc0228    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 8 Mar 2012 15:52:34 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 8 Mar 2012 15:52:34 -0500    

Click here for diff

  
Phil Sorber reported that a rewriting ALTER TABLE within an extension  
update script failed, because it creates and then drops a placeholder  
table; the drop was being disallowed because the table was marked as an  
extension member.  We could hack that specific case but it seems likely  
that there might be related cases now or in the future, so the most  
practical solution seems to be to create an exception to the general rule  
that extension member objects can only be dropped by dropping the owning  
extension.  To wit: if the DROP is issued within the extension's own  
creation or update scripts, we'll allow it, implicitly performing an  
"ALTER EXTENSION DROP object" first.  This will simplify cases such as  
extension downgrade scripts anyway.  
  
No docs change since we don't seem to have documented the idea that you  
would need ALTER EXTENSION DROP for such an action to begin with.  
  
Also, arrange for explicitly temporary tables to not get linked as  
extension members in the first place, and the same for the magic  
pg_temp_nnn schemas that are created to hold them.  This prevents assorted  
unpleasant results if an extension script creates a temp table: the forced  
drop at session end would either fail or remove the entire extension, and  
neither of those outcomes is desirable.  Note that this doesn't fix the  
ALTER TABLE scenario, since the placeholder table is not temp (unless the  
table being rewritten is).  
  
Back-patch to 9.1.  
  

Attempt to reduce locale dependencies in regression tests.

  
commit   : 610fd3442d12f0a2774456be795120759fd3f9c3    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Wed, 7 Mar 2012 17:19:18 -0500    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Wed, 7 Mar 2012 17:19:18 -0500    

Click here for diff

  
Commit 3e9a2672d25aed15ae6b4a09decbd8927d069868 fixed this for master,  
but REL9_1_STABLE also needs fixing; this is a back-branch commit only.  
  
Tomas Vondra  
  

Improve documentation around logging_collector and use of stderr.

  
commit   : e076ee6d3f1bf9ece52eb7c9dacea8f91e4c991c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 5 Mar 2012 14:08:57 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 5 Mar 2012 14:08:57 -0500    

Click here for diff

  
In backup.sgml, point out that you need to be using the logging collector  
if you want to log messages from a failing archive_command script.  (This  
is an oversimplification, in that it will work without the collector as  
long as you're not sending postmaster stderr to /dev/null; but it seems  
like a good idea to encourage use of the collector to avoid problems  
with multiple processes concurrently scribbling on one file.)  
  
In config.sgml, do some wordsmithing of logging_collector discussion.  
  
Per bug #6518 from Janning Vygen  
  

Allow child-relation entries to be made in ec_has_const EquivalenceClasses.

  
commit   : ef03b34550e3577c4be3baa25b70787f5646c57b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 2 Mar 2012 14:28:49 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 2 Mar 2012 14:28:49 -0500    

Click here for diff

  
This fixes an oversight in commit 11cad29c91524aac1d0b61e0ea0357398ab79bf8,  
which introduced MergeAppend plans.  Before that happened, we never  
particularly cared about the sort ordering of scans of inheritance child  
relations, since appending their outputs together would destroy any  
ordering anyway.  But now it's important to be able to match child relation  
sort orderings to those of the surrounding query.  The original coding of  
add_child_rel_equivalences skipped ec_has_const EquivalenceClasses, on the  
originally-correct grounds that adding child expressions to them was  
useless.  The effect of this is that when a parent variable is equated to  
a constant, we can't recognize that index columns on the equivalent child  
variables are not sort-significant; that is, we can't recognize that a  
child index on, say, (x, y) is able to generate output in "ORDER BY y"  
order when there is a clause "WHERE x = constant".  Adding child  
expressions to the (x, constant) EquivalenceClass fixes this, without any  
downside that I can see other than a few more planner cycles expended on  
such queries.  
  
Per recent gripe from Robert McGehee.  Back-patch to 9.1 where MergeAppend  
was introduced.  
  

Simplify references to backslash-doubling in func.sgml.

  
commit   : af1967239a90a5860e2158ebe814a7bcd42e6c6b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 29 Feb 2012 12:11:10 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 29 Feb 2012 12:11:10 -0500    

Click here for diff

  
Several places were still written as though standard_conforming_strings  
didn't exist, much less be the default.  Now that it is on by default,  
we can simplify the text and just insert occasional notes suggesting that  
you might have to think harder if it's turned off.  Per discussion of a  
suggestion from Hannes Frederic Sowa.  
  
Back-patch to 9.1 where standard_conforming_strings was made the default.  
  

Correctly detect SSI conflicts of prepared transactions after crash.

  
commit   : 86073a2b7acc58fce8701a9207a46adb41fbd8cc    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 29 Feb 2012 15:22:49 +0200    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 29 Feb 2012 15:22:49 +0200    

Click here for diff

  
A prepared transaction can get new conflicts in and out after preparing, so  
we cannot rely on the in- and out-flags stored in the statefile at prepare-  
time. As a quick fix, make the conservative assumption that after a restart,  
all prepared transactions are considered to have both in- and out-conflicts.  
That can lead to unnecessary rollbacks after a crash, but that shouldn't be  
a big problem in practice; you don't want prepared transactions to hang  
around for a long time anyway.  
  
Dan Ports  
  

Fix some more bugs in GIN’s WAL replay logic.

  
commit   : 57b100fe0fb1d0d5803789d3113b89fa18a34fad    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 26 Feb 2012 15:12:23 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 26 Feb 2012 15:12:23 -0500    

Click here for diff

  
In commit 4016bdef8aded77b4903c457050622a5a1815c16 I fixed a bunch of  
ginxlog.c bugs having to do with not handling XLogReadBuffer failures  
correctly.  However, in ginRedoUpdateMetapage and ginRedoDeleteListPages,  
I unaccountably thought that failure to read the metapage would be  
impossible and just put in an elog(PANIC) call.  This is of course wrong:  
failure is exactly what will happen if the index got dropped (or rebuilt)  
between creation of the WAL record and the crash we're trying to recover  
from.  I believe this explains Nicholas Wilson's recent report of these  
errors getting reached.  
  
Also, fix memory leak in forgetIncompleteSplit.  This wasn't of much  
concern when the code was written, but in a long-running standby server  
page split records could be expected to accumulate indefinitely.  
  
Back-patch to 8.4 --- before that, GIN didn't have a metapage.