PostgreSQL 9.2.6 commit log

commit   : 8b47c9d413b10a482b21aa9aad9d4f8569de8798    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 2 Dec 2013 16:00:18 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 2 Dec 2013 16:00:18 -0500    

commit   : 4993336220996955c41e273bdee4b65895054053    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 2 Dec 2013 15:54:01 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 2 Dec 2013 15:54:01 -0500    

commit   : 715f44be058c4c270af9ef60493ed74539b513d1    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 2 Dec 2013 13:28:24 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 2 Dec 2013 13:28:24 -0300    

The backpatch of a95335b544d9c8377e9dc7a399d8e9a155895f82 to 9.2, 9.1  
and 9.0 was incomplete, missing changes to xlog.c, primarily the call  
to TrimMultiXact(). Testing presumably didn't show a problem without  
these changes because TrimMultiXact() performs defense-in-depth work,  
which is not strictly necessary.  
  
It also missed moving StartupMultiXact() which would have been  
problematic if a restartpoing happened in exactly the wrong moment,  
causing a transient error.  
  
Andres Freund  

commit   : ff61dd206699187ca6d0b11ae3a173b690fd4bc4    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 2 Dec 2013 00:08:10 -0500    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 2 Dec 2013 00:08:10 -0500    

commit   : c89acb41f51abebe4bdc812a172df325a3e8533e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 1 Dec 2013 14:11:44 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 1 Dec 2013 14:11:44 -0500    

DST law changes in Argentina, Brazil, Jordan, Libya, Liechtenstein,  
Morocco, Palestine.  New timezone abbreviations WIB, WIT, WITA for  
Indonesia.  

commit   : 9aa888e8bb634f194cdb38f12edc1231db09c56e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 1 Dec 2013 14:09:31 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 1 Dec 2013 14:09:31 -0500    

Needed so that timezone data update patches can be cherry-picked  
into older branches conveniently.  

commit   : 27b33245a5f505794a0e8dd4cdb9342f8cf2cc0a    
  
author   : Kevin Grittner <kgrittn@postgresql.org>    
date     : Sat, 30 Nov 2013 11:33:54 -0600    
  
committer: Kevin Grittner <kgrittn@postgresql.org>    
date     : Sat, 30 Nov 2013 11:33:54 -0600    

pg_dumpall's charter is to be able to recreate a database cluster's  
contents in a virgin installation, but it was failing to honor that  
contract if the cluster had any ALTER DATABASE SET  
default_transaction_read_only settings.  By including a SET command  
for the connection for each connection opened by pg_dumpall output,  
errors are avoided and the source cluster is successfully  
recreated.  
  
There was discussion of whether to also set this for the connection  
applying pg_dump output, but it was felt that it was both less  
appropriate in that context, and far easier to work around.  
  
Backpatch to all supported branches.  

commit   : 8f8c666144226860d8d766054f6c8f3d78862e8b    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 29 Nov 2013 11:26:41 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 29 Nov 2013 11:26:41 -0300    

Commit 9dc842f08 of 8.2 era prevented MultiXact truncation during crash  
recovery, because there was no guarantee that enough state had been  
setup, and because it wasn't deemed to be a good idea to remove data  
during crash recovery anyway.  Since then, due to Hot-Standby, streaming  
replication and PITR, the amount of time a cluster can spend doing crash  
recovery has increased significantly, to the point that a cluster may  
even never come out of it.  This has made not truncating the content of  
pg_multixact/ not defensible anymore.  
  
To fix, take care to setup enough state for multixact truncation before  
crash recovery starts (easy since checkpoints contain the required  
information), and move the current end-of-recovery actions to a new  
TrimMultiXact() function, analogous to TrimCLOG().  
  
At some later point, this should probably done similarly to the way  
clog.c is doing it, which is to just WAL log truncations, but we can't  
do that for the back branches.  
  
Back-patch to 9.0.  8.4 also has the problem, but since there's no hot  
standby there, it's much less pressing.  In 9.2 and earlier, this patch  
is simpler than in newer branches, because multixact access during  
recovery isn't required.  Add appropriate checks to make sure that's not  
happening.  
  
Andres Freund  

commit   : 19af7d4f0314068fda7b392ccc1f9f7df50ac0a6    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 29 Nov 2013 18:34:14 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 29 Nov 2013 18:34:14 -0500    

Ensure that the invocation command for postgres or pg_ctl runservice  
double-quotes the executable's pathname; failure to do this leads to  
trouble when the path contains spaces.  
  
Also, ensure that the path ends in ".exe" in both cases and uses  
backslashes rather than slashes as directory separators.  The latter issue  
is reported to confuse some third-party tools such as Symantec Backup Exec.  
  
Also, rewrite the function to avoid buffer overrun issues by using a  
PQExpBuffer instead of a fixed-size static buffer.  Combinations of  
very long executable pathnames and very long data directory pathnames  
could have caused trouble before, for example.  
  
Back-patch to all active branches, since this code has been like this  
for a long while.  
  
Naoya Anzai and Tom Lane, reviewed by Rajeev Rastogi  

commit   : f0e3e05ddab7df93db74f4d191a246f4942f5bd7    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 29 Nov 2013 17:35:15 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 29 Nov 2013 17:35:15 -0500    

The various places that transferred fast-path locks to the main lock table  
neglected to release the PGPROC's backendLock if SetupLockInTable failed  
due to being out of shared memory.  In most cases this is no big deal since  
ensuing error cleanup would release all held LWLocks anyway.  But there are  
some hot-standby functions that don't consider failure of  
FastPathTransferRelationLocks to be a hard error, and in those cases this  
oversight could lead to system lockup.  For consistency, make all of these  
places look the same as FastPathTransferRelationLocks.  
  
Noted while looking for the cause of Dan Wood's bugs --- this wasn't it,  
but it's a bug anyway.  

commit   : 9457508f6b07acc2a5b79fd735f023d0df4882fb    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 28 Nov 2013 12:17:53 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 28 Nov 2013 12:17:53 -0500    

We have for a long time checked the head pointer of each of the backend's  
proclock lists and skipped acquiring the corresponding locktable partition  
lock if the head pointer was NULL.  This was safe enough in the days when  
proclock lists were changed only by the owning backend, but it is pretty  
questionable now that the fast-path patch added cases where backends add  
entries to other backends' proclock lists.  However, we don't really wish  
to revert to locking each partition lock every time, because in simple  
transactions that would add a lot of useless lock/unlock cycles on  
already-heavily-contended LWLocks.  Fortunately, the only way that another  
backend could be modifying our proclock list at this point would be if it  
was promoting a formerly fast-path lock of ours; and any such lock must be  
one that we'd decided not to delete in the previous loop over the locallock  
table.  So it's okay if we miss seeing it in this loop; we'd just decide  
not to delete it again.  However, once we've detected a non-empty list,  
we'd better re-fetch the list head pointer after acquiring the partition  
lock.  This guards against possibly fetching a corrupt-but-non-null pointer  
if pointer fetch/store isn't atomic.  It's not clear if any practical  
architectures are like that, but we've never assumed that before and don't  
wish to start here.  In any case, the situation certainly deserves a code  
comment.  
  
While at it, refactor the partition traversal loop to use a for() construct  
instead of a while() loop with goto's.  
  
Back-patch, just in case the risk is real and not hypothetical.  

commit   : 62e69cb6fbb7bcba058f1dcb4bb4a9063a3d9b8a    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 27 Nov 2013 21:50:27 -0500    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 27 Nov 2013 21:50:27 -0500    

From: Andreas Karlsson <andreas@proxel.se>  

commit   : 024edb4543d4159c587e71fff3d6ab6a85a10beb    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 27 Nov 2013 18:10:06 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 27 Nov 2013 18:10:06 -0500    

When acquiring a lock in fast-path mode, we must reset the locallock  
object's lock and proclock fields to NULL.  They are not necessarily that  
way to start with, because the locallock could be left over from a failed  
lock acquisition attempt earlier in the transaction.  Failure to do this  
led to all sorts of interesting misbehaviors when LockRelease tried to  
clean up no-longer-related lock and proclock objects in shared memory.  
Per report from Dan Wood.  
  
In passing, modify LockRelease to elog not just Assert if it doesn't find  
lock and proclock objects for a formerly fast-path lock, matching the code  
in FastPathGetRelationLockEntry and LockRefindAndRelease.  This isn't a  
bug but it will help in diagnosing any future bugs in this area.  
  
Also, modify FastPathTransferRelationLocks and FastPathGetRelationLockEntry  
to break out of their loops over the fastpath array once they've found the  
sole matching entry.  This was inconsistently done in some search loops  
and not others.  
  
Improve assorted related comments, too.  
  
Back-patch to 9.2 where the fast-path mechanism was introduced.  

commit   : 0b132b90424646a4251ef0f51c3babc2bb0725a6    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 27 Nov 2013 13:10:16 +0200    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 27 Nov 2013 13:10:16 +0200    

Vacuum recognizes that it can update relfrozenxid by checking whether it has  
processed all pages of a relation. Unfortunately it performed that check  
after truncating the dead pages at the end of the relation, and used the new  
number of pages to decide whether all pages have been scanned. If the new  
number of pages happened to be smaller or equal to the number of pages  
scanned, it incorrectly decided that all pages were scanned.  
  
This can lead to relfrozenxid being updated, even though some pages were  
skipped that still contain old XIDs. That can lead to data loss due to xid  
wraparounds with some rows suddenly missing. This likely has escaped notice  
so far because it takes a large number (~2^31) of xids being used to see the  
effect, while a full-table vacuum before that would fix the issue.  
  
The incorrect logic was introduced by commit  
b4b6923e03f4d29636a94f6f4cc2f5cf6298b8c8. Backpatch this fix down to 8.4,  
like that commit.  
  
Andres Freund, with some modifications by me.  

commit   : 0cedfa766d5e467a1f9848adac829a0d36d6f510    
  
author   : Michael Meskes <meskes@postgresql.org>    
date     : Wed, 27 Nov 2013 11:02:13 +0100    
  
committer: Michael Meskes <meskes@postgresql.org>    
date     : Wed, 27 Nov 2013 11:02:13 +0100    

Patch by Böszörményi Zoltán <zb@cybertec.at>  

commit   : 6bb2972c094032edc88e7c4fc518afe1e7b5d579    
  
author   : Michael Meskes <meskes@postgresql.org>    
date     : Wed, 27 Nov 2013 11:03:59 +0100    
  
committer: Michael Meskes <meskes@postgresql.org>    
date     : Wed, 27 Nov 2013 11:03:59 +0100    

The latest fixes removed a limitation that was still in the docs, so Zoltan updated the docs, too.  

commit   : 744fa4d8eaa18c83c65f0942a5327f767513054c    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Wed, 27 Nov 2013 13:45:41 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Wed, 27 Nov 2013 13:45:41 +0900    

Backpatch to 9.1.  
  
Josh Kupershmidt  

commit   : b05c415c8115840f5340d65be0ca3dd437edd5bd    
  
author   : Michael Meskes <meskes@postgresql.org>    
date     : Tue, 26 Nov 2013 17:12:39 +0100    
  
committer: Michael Meskes <meskes@postgresql.org>    
date     : Tue, 26 Nov 2013 17:12:39 +0100    

int main(void)  
{  
    exec sql begin declare section;  
    varchar a[50], b[50];  
    exec sql end declare section;  
  
    return 0;  
}  
  
Since varchars are internally turned into custom structs and  
the type name is emitted for these variable declarations,  
the preprocessed code previously had:  
  
struct varchar_1  { ... }  a _,_  struct varchar_2  { ... }  b ;  
  
The comma in the generated C file was a syntax error.  
  
There are no regression test changes since it's not exercised.  
  
Patch by Boszormenyi Zoltan <zb@cybertec.at>  

commit   : 0aec900bf0af687211701f39c7bb93bdda887c2c    
  
author   : Michael Meskes <meskes@postgresql.org>    
date     : Tue, 26 Nov 2013 17:16:39 +0100    
  
committer: Michael Meskes <meskes@postgresql.org>    
date     : Tue, 26 Nov 2013 17:16:39 +0100    

Patch by Boszormenyi Zoltan <zb@cybertec.at>  

commit   : b6da09fcba668e672bf15982dea0c369390007cb    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 23 Nov 2013 22:45:46 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 23 Nov 2013 22:45:46 -0500    

This function formerly crashed if called as a statement-level trigger,  
or if a column-name argument wasn't given.  
  
In passing, add the trigger name to all error messages from the function.  
(None of them are expected cases, so this shouldn't pose any compatibility  
risk.)  
  
Marc Cousin, reviewed by Sawada Masahiko  

commit   : 96ac8b51821ac6726cd72a639d3a0a1a5f52bd41    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 23 Nov 2013 20:04:03 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 23 Nov 2013 20:04:03 -0500    

The previous coding labeled expressions such as pg_index.indkey[1:3] as  
being of int2vector type; which is not right because the subscript bounds  
of such a result don't, in general, satisfy the restrictions of int2vector.  
To fix, implicitly promote the result of slicing int2vector to int2[],  
or oidvector to oid[].  This is similar to what we've done with domains  
over arrays, which is a good analogy because these types are very much  
like restricted domains of the corresponding regular-array types.  
  
A side-effect is that we now also forbid array-element updates on such  
columns, eg while "update pg_index set indkey[4] = 42" would have worked  
before if you were superuser (and corrupted your catalogs irretrievably,  
no doubt) it's now disallowed.  This seems like a good thing since, again,  
some choices of subscripting would've led to results not satisfying the  
restrictions of int2vector.  The case of an array-slice update was  
rejected before, though with a different error message than you get now.  
We could make these cases work in future if we added a cast from int2[]  
to int2vector (with a cast function checking the subscript restrictions)  
but it seems unlikely that there's any value in that.  
  
Per report from Ronan Dunklau.  Back-patch to all supported branches  
because of the crash risks involved.  

commit   : e86f2a0529b60d2a977597f1bd6266e580e9a175    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 23 Nov 2013 18:24:26 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 23 Nov 2013 18:24:26 -0500    

If logging is enabled, either ereport() or fprintf() might stomp on errno  
internally, causing this function to return the wrong result.  That might  
only end in a misleading error report, but in any code that's examining  
errno to decide what to do next, the consequences could be far graver.  
  
This has been broken since the very first version of this file in 2006  
... it's a bit astonishing that we didn't identify this long ago.  
  
Reported by Amit Kapila, though this isn't his proposed fix.  

commit   : 654e006bbaa00610055273e1e08723b1f63ea6ce    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Sat, 23 Nov 2013 07:25:37 -0500    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Sat, 23 Nov 2013 07:25:37 -0500    

A pointer to a C string was treated as a pointer to a "name" datum and  
passed to SPI_execute_plan().  This pointer would then end up being  
passed through datumCopy(), which would try to copy the entire 64 bytes  
of name data, thus running past the end of the C string.  Fix by  
converting the string to a proper name structure.  
  
Found by LLVM AddressSanitizer.  

commit   : c0aa210f6ebab06ca3933c735c7c6d2b8bdd024e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 22 Nov 2013 14:37:29 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 22 Nov 2013 14:37:29 -0500    

pullup_replace_vars()'s decisions about whether a pulled-up replacement  
expression needs to be wrapped in a PlaceHolderVar depend on the assumption  
that what looks like a Var behaves like a Var.  However, if the Var is a  
join alias reference, later flattening of join aliases might replace the  
Var with something that's not a Var at all, and should have been wrapped.  
  
To fix, do a forcible pass of flatten_join_alias_vars() on the subquery  
targetlist before we start to copy items out of it.  We'll re-run that  
processing on the pulled-up expressions later, but that's harmless.  
  
Per report from Ken Tanzer; the added regression test case is based on his  
example.  This bug has been there since the PlaceHolderVar mechanism was  
invented, but has escaped detection because the circumstances that trigger  
it are fairly narrow.  You need a flattenable query underneath an outer  
join, which contains another flattenable query inside a join of its own,  
with a dangerous expression (a constant or something else non-strict)  
in that one's targetlist.  
  
Having seen this, I'm wondering if it wouldn't be prudent to do all  
alias-variable flattening earlier, perhaps even in the rewriter.  
But that would probably not be a back-patchable change.  

commit   : 2583fa810b32ca5f8746698235e217bd4f1c3b59    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 22 Nov 2013 12:07:53 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 22 Nov 2013 12:07:53 -0500    

The command we're telling people to type needs to include double-quoting  
around the unfortunately-chosen extension name.  Twiddle the textual  
quoting so that it looks somewhat sane.  Per gripe from roadrunner6.  

commit   : f22624cea54f2ef5f3bcf8de379e7592139e773c    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 22 Nov 2013 14:38:59 +0200    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 22 Nov 2013 14:38:59 +0200    

These bugs can cause data loss on standbys started with hot_standby=on at  
the moment they start to accept read only queries, by marking committed  
transactions as uncommited. The likelihood of such corruptions is small  
unless the primary has a high transaction rate.  
  
5a031a5556ff83b8a9646892715d7fef415b83c3 fixed bugs in HS's startup logic  
by maintaining less state until at least STANDBY_SNAPSHOT_PENDING state  
was reached, missing the fact that both clog and subtrans are written to  
before that. This only failed to fail in common cases because the usage  
of ExtendCLOG in procarray.c was superflous since clog extensions are  
actually WAL logged.  
  
f44eedc3f0f347a856eea8590730769125964597/I then tried to fix the missing  
extensions of pg_subtrans due to the former commit's changes - which are  
not WAL logged - by performing the extensions when switching to a state  
> STANDBY_INITIALIZED and not performing xid assignments before that -  
again missing the fact that ExtendCLOG is unneccessary - but screwed up  
twice: Once because latestObservedXid wasn't updated anymore in that  
state due to the earlier commit and once by having an off-by-one error in  
the loop performing extensions. This means that whenever a  
CLOG_XACTS_PER_PAGE (32768 with default settings) boundary was crossed  
between the start of the checkpoint recovery started from and the first  
xl_running_xact record old transactions commit bits in pg_clog could be  
overwritten if they started and committed in that window.  
  
Fix this mess by not performing ExtendCLOG() in HS at all anymore since  
it's unneeded and evidently dangerous and by performing subtrans  
extensions even before reaching STANDBY_SNAPSHOT_PENDING.  
  
Analysis and patch by Andres Freund. Reported by Christophe Pettus.  
Backpatch down to 9.0, like the previous commit that caused this.  

commit   : 3379263b6ded774acb96288d1e67caa37dcba0de    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 18 Nov 2013 09:51:09 +0200    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 18 Nov 2013 09:51:09 +0200    

Previously, if VACUUM skipped vacuuming a page because it's pinned, it  
didn't count that page as scanned. However, that meant that relfrozenxid  
was not bumped up either, which prevented anti-wraparound vacuum from  
doing its job.  
  
Report by Миша Тюрин, analysis and patch by Sergey Burladyn and Jeff Janes.  
Backpatch to 9.2, where the skip-locked-pages behavior was introduced.  

commit   : b18882aed6bf7190677c351199f95d409559bbc0    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 15 Nov 2013 18:34:14 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 15 Nov 2013 18:34:14 -0500    

A couple of places that should have been iterating over WORDS_PER_CHUNK  
words were iterating over WORDS_PER_PAGE words instead.  This thinko  
accidentally failed to fail, because (at least on common architectures  
with default BLCKSZ) WORDS_PER_CHUNK is a bit less than WORDS_PER_PAGE,  
and the extra words being looked at were always zero so nothing happened.  
Still, it's a bug waiting to happen if anybody ever fools with the  
parameters affecting TIDBitmap sizes, and it's a small waste of cycles  
too.  So back-patch to all active branches.  
  
Etsuro Fujita  

commit   : 51b6ae6bba75bca2374a24cf7c740da74c955ad5    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 15 Nov 2013 16:46:25 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 15 Nov 2013 16:46:25 -0500    

Bug #8591 from Claudio Freire demonstrates that get_eclass_for_sort_expr  
must be able to compute valid em_nullable_relids for any new equivalence  
class members it creates.  I'd worried about this in the commit message  
for db9f0e1d9a4a0842c814a464cdc9758c3f20b96c, but claimed that it wasn't a  
problem because multi-member ECs should already exist when it runs.  That  
is transparently wrong, though, because this function is also called by  
initialize_mergeclause_eclasses, which runs during deconstruct_jointree.  
The example given in the bug report (which the new regression test item  
is based upon) fails because the COALESCE() expression is first seen by  
initialize_mergeclause_eclasses rather than process_equivalence.  
  
Fixing this requires passing the appropriate nullable_relids set to  
get_eclass_for_sort_expr, and it requires new code to compute that set  
for top-level expressions such as ORDER BY, GROUP BY, etc.  We store  
the top-level nullable_relids in a new field in PlannerInfo to avoid  
computing it many times.  In the back branches, I've added the new  
field at the end of the struct to minimize ABI breakage for planner  
plugins.  There doesn't seem to be a good alternative to changing  
get_eclass_for_sort_expr's API signature, though.  There probably aren't  
any third-party extensions calling that function directly; moreover,  
if there are, they probably need to think about what to pass for  
nullable_relids anyway.  
  
Back-patch to 9.2, like the previous patch in this area.  

commit   : 42f8e268c9b3e89dbb50c2dabdef5109655248ae    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 13 Nov 2013 13:26:33 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 13 Nov 2013 13:26:33 -0500    

The previous text was a bit misleading, as well as unnecessarily vague  
about what information would be discarded.  Per gripe from Craig Skinner.  

commit   : d147aedbfedf210e676c5c59166d32af1de79e1f    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Tue, 12 Nov 2013 12:53:32 +0100    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Tue, 12 Nov 2013 12:53:32 +0100    

Per report from Colin 't Hart  

commit   : 449d5acd7d02fae0086ecfbbd45a13f28a40e795    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 11 Nov 2013 16:36:27 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 11 Nov 2013 16:36:27 -0500    

Simple oversight in commit 1cb108efb0e60d87e4adec38e7636b6e8efbeb57 ---  
recursively examining a subquery output column is only sane if the  
original Var refers to a single output column.  Found by Kevin Grittner.  

commit   : c6ec8793aa59d1842082e14b4b4aae7d4bd883fd    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Mon, 11 Nov 2013 14:34:06 +0100    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Mon, 11 Nov 2013 14:34:06 +0100    

This can happen exactly at the switch of a logical WAL file  
(segment number ending in FE), when running pg_basebackup connected  
to a standby server, and would cause the backup to abort with  
the error message "streaming header too small".  
  
There is nothing wrong with an empty message, it's just unnecessary,  
and the rest of the code can handle the case of an empty message,  
so this patch just removes the error condition when the size is  
exactly zero.  

commit   : 9a45a655977266c5367d658bab8384d8d4c77127    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 8 Nov 2013 22:21:42 +0200    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 8 Nov 2013 22:21:42 +0200    

If a page is deleted, and reused for something else, just as a search is  
following a rightlink to it from its left sibling, the search would continue  
scanning whatever the new contents of the page are. That could lead to  
incorrect query results, or even something more curious if the page is  
reused for a different kind of a page.  
  
To fix, modify the search algorithm to lock the next page before releasing  
the previous one, and refrain from deleting pages from the leftmost branch  
of the tree.  
  
Add a new Concurrency section to the README, explaining why this works.  
There is a lot more one could say about concurrency in GIN, but that's for  
another patch.  
  
Backpatch to all supported versions.  

commit   : f7171c7e26d7e2a7117dbc3d3a9fa863a2decf59    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 8 Nov 2013 11:37:04 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 8 Nov 2013 11:37:04 -0500    

This change prevents us from doing inappropriate subquery flattening in  
cases such as dangerous functions hidden inside a sub-SELECT in the  
targetlist of another sub-SELECT.  That could result in unexpected behavior  
due to multiple evaluations of a volatile function, as in a recent  
complaint from Etienne Dube.  It's been questionable from the very  
beginning whether these functions should look into subqueries (as noted in  
their comments), and this case seems to provide proof that they should.  
  
Because the new code only descends into SubLinks, not SubPlans or  
InitPlans, the change only affects the planner's behavior during  
prepjointree processing and not later on --- for example, you can still get  
it to use a volatile function in an indexqual if you wrap the function in  
(SELECT ...).  That's a historical behavior, for sure, but it's reasonable  
given that the executor's evaluation rules for subplans don't depend on  
whether there are volatile functions inside them.  In any case, we need to  
constrain the behavioral change as narrowly as we can to make this  
reasonable to back-patch.  

commit   : 733e49ecff050f6520123fba469934426a788cfd    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 8 Nov 2013 08:59:49 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 8 Nov 2013 08:59:49 -0500    

contain_volatile_functions() is best applied to the output of  
expression_planner(), not its input, so that insertion of function  
default arguments and constant-folding have been done.  (See comments  
at CheckMutability, for instance.)  It's perhaps unlikely that anyone  
will notice a difference in practice, but still we should do it properly.  
  
In passing, change variable type from Node* to Expr* to reduce the net  
number of casts needed.  
  
Noted while perusing uses of contain_volatile_functions().  

commit   : 64f5962fe9d782c1c2b0baf9216ec301cac80dfa    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 7 Nov 2013 16:33:25 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 7 Nov 2013 16:33:25 -0500    

Back-patch commits 8e68816cc2567642c6fcca4eaac66c25e0ae5ced and  
8dace66e0735ca39b779922d02c24ea2686e6521 into the stable branches.  
Buildfarm testing revealed no great portability surprises, and it  
seems useful to have this robustness improvement in all branches.  

commit   : 8bd5a6af629141e0de1798570ea51db4bdabf6fe    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 7 Nov 2013 14:41:43 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 7 Nov 2013 14:41:43 -0500    

ExecBuildSlotValueDescription() printed "null" for each dropped column in  
a row being complained of by ExecConstraints().  This has some sanity in  
terms of the underlying implementation, but is of course pretty surprising  
to users.  To fix, we must pass the target relation's descriptor to  
ExecBuildSlotValueDescription(), because the slot descriptor it had been  
using doesn't get labeled with attisdropped markers.  
  
Per bug #8408 from Maxim Boguk.  Back-patch to 9.2 where the feature of  
printing row values in NOT NULL and CHECK constraint violation messages  
was introduced.  
  
Michael Paquier and Tom Lane  

commit   : aa8a2c3a612a867fc5348bd6ff68f619212e3c1b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 7 Nov 2013 13:13:19 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 7 Nov 2013 13:13:19 -0500    

Before jamming a desired targetlist into a plan node, one really ought to  
make sure the plan node can handle projections, and insert a buffering  
Result plan node if not.  planagg.c forgot to do this, which is a hangover  
from the days when it only dealt with IndexScan plan types.  MergeAppend  
doesn't project though, not to mention that it gets unhappy if you remove  
its possibly-resjunk sort columns.  The code accidentally failed to fail  
for cases in which the min/max argument was a simple Var, because the new  
targetlist would be equivalent to the original "flat" tlist anyway.  
For any more complex case, it's been broken since 9.1 where we introduced  
the ability to optimize min/max using MergeAppend, as reported by Raphael  
Bauduin.  Fix by duplicating the logic from grouping_planner that decides  
whether we need a Result node.  
  
In 9.2 and 9.1, this requires back-porting the tlist_same_exprs() function  
introduced in commit 4387cf956b9eb13aad569634e0c4df081d76e2e3, else we'd  
uselessly add a Result node in cases that worked before.  It's rather  
tempting to back-patch that whole commit so that we can avoid extra Result  
nodes in mainline cases too; but I'll refrain, since that code hasn't  
really seen all that much field testing yet.  

commit   : 74aea2af96e5a97513c7d7c10e4c9d70ab6ed31d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 6 Nov 2013 13:26:38 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 6 Nov 2013 13:26:38 -0500    

These things didn't work because the planner omitted to do the necessary  
preprocessing of a WindowFunc's argument list.  Add the few dozen lines  
of code needed to handle that.  
  
Although this sounds like a feature addition, it's really a bug fix because  
the default-argument case was likely to crash previously, due to lack of  
checking of the number of supplied arguments in the built-in window  
functions.  It's not a security issue because there's no way for a  
non-superuser to create a window function definition with defaults that  
refers to a built-in C function, but nonetheless people might be annoyed  
that it crashes rather than producing a useful error message.  So  
back-patch as far as the patch applies easily, which turns out to be 9.2.  
I'll put a band-aid in earlier versions as a separate patch.  
  
(Note that these features still don't work for aggregates, and fixing that  
case will be harder since we represent aggregate arg lists as target lists  
not bare expression lists.  There's no crash risk though because CREATE  
AGGREGATE doesn't accept defaults, and we reject named-argument notation  
when parsing an aggregate call.)  

commit   : 599942cf49d747ce4f1baabe10dc62690810bca3    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 5 Nov 2013 21:58:16 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 5 Nov 2013 21:58:16 -0500    

For rather inscrutable reasons, SQL:2008 disallows copying-and-modifying a  
window definition that has any explicit framing clause.  The error message  
we gave for this only made sense if the referencing window definition  
itself contains an explicit framing clause, which it might well not.  
Moreover, in the context of an OVER clause it's not exactly obvious that  
"OVER (windowname)" implies copy-and-modify while "OVER windowname" does  
not.  This has led to multiple complaints, eg bug #5199 from Iliya  
Krapchatov.  Change to a hopefully more intelligible error message, and  
in the case where we have just "OVER (windowname)", add a HINT suggesting  
that omitting the parentheses will fix it.  Also improve the related  
documentation.  Back-patch to all supported branches.  

commit   : 85de126246cd44315965c08f4af3d7d75fb9c5f1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 3 Nov 2013 11:33:13 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 3 Nov 2013 11:33:13 -0500    

Historically, printtup() has assumed that it could prevent memory leakage  
by pfree'ing the string result of each output function and manually  
managing detoasting of toasted values.  This amounts to assuming that  
datatype output functions never leak any memory internally; an assumption  
we've already decided to be bogus elsewhere, for example in COPY OUT.  
range_out in particular is known to leak multiple kilobytes per call, as  
noted in bug #8573 from Godfried Vanluffelen.  While we could go in and fix  
that leak, it wouldn't be very notationally convenient, and in any case  
there have been and undoubtedly will again be other leaks in other output  
functions.  So what seems like the best solution is to run the output  
functions in a temporary memory context that can be reset after each row,  
as we're doing in COPY OUT.  Some quick experimentation suggests this is  
actually a tad faster than the retail pfree's anyway.  
  
This patch fixes all the variants of printtup, except for debugtup()  
which is used in standalone mode.  It doesn't seem worth worrying  
about query-lifespan leaks in standalone mode, and fixing that case  
would be a bit tedious since debugtup() doesn't currently have any  
startup or shutdown functions.  
  
While at it, remove manual detoast management from several other  
output-function call sites that had copied it from printtup().  This  
doesn't make a lot of difference right now, but in view of recent  
discussions about supporting "non-flattened" Datums, we're going to  
want that code gone eventually anyway.  
  
Back-patch to 9.2 where range_out was introduced.  We might eventually  
decide to back-patch this further, but in the absence of known major  
leaks in older output functions, I'll refrain for now.  

commit   : f2d6bdf8480bf4f3ecd787a8b02e393860bf824b    
  
author   : Michael Meskes <meskes@postgresql.org>    
date     : Sun, 3 Nov 2013 15:37:34 +0100    
  
committer: Michael Meskes <meskes@postgresql.org>    
date     : Sun, 3 Nov 2013 15:37:34 +0100    

commit   : a1c3d54fb6b9fd974fa4d0166bfd1fde30c8d8c2    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 2 Nov 2013 16:45:42 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 2 Nov 2013 16:45:42 -0400    

The original coding thought this case was impossible, but it can happen  
if the bgwriter or checkpointer processes decide to write out an index  
page while creation is still proceeding, leading to a bogus "unexpected  
spgdoinsert() failure" error.  Problem reported by Jonathan S. Katz.  
  
Teodor Sigaev  

commit   : 2f2507e38374b7e2d5badc210a8d1fa6fecab60a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 1 Nov 2013 16:09:57 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 1 Nov 2013 16:09:57 -0400    

Callers expect that they only have to set the right resource owner when  
creating a BufFile, not during subsequent operations on it.  While we could  
insist this be fixed at the caller level, it seems more sensible for the  
BufFile to take care of it.  Without this, some temp files belonging to  
a BufFile can go away too soon, eg at the end of a subtransaction,  
leading to errors or crashes.  
  
Reported and fixed by Andres Freund.  Back-patch to all active branches.  

commit   : 2e2134954ad1bf46f4ce9ffd0ddfaf369c66e10e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 1 Nov 2013 12:13:26 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 1 Nov 2013 12:13:26 -0400    

Formerly, when using a SQL-spec timezone setting with a fixed GMT offset  
(called a "brute force" timezone in the code), the session_timezone  
variable was not updated to match the nominal timezone; rather, all code  
was expected to ignore session_timezone if HasCTZSet was true.  This is  
of course obviously fragile, though a search of the code finds only  
timeofday() failing to honor the rule.  A bigger problem was that  
DetermineTimeZoneOffset() supposed that if its pg_tz parameter was  
pointer-equal to session_timezone, then HasCTZSet should override the  
parameter.  This would cause datetime input containing an explicit zone  
name to be treated as referencing the brute-force zone instead, if the  
zone name happened to match the session timezone that had prevailed  
before installing the brute-force zone setting (as reported in bug #8572).  
The same malady could affect AT TIME ZONE operators.  
  
To fix, set up session_timezone so that it matches the brute-force zone  
specification, which we can do using the POSIX timezone definition syntax  
"<abbrev>offset", and get rid of the bogus lookaside check in  
DetermineTimeZoneOffset().  Aside from fixing the erroneous behavior in  
datetime parsing and AT TIME ZONE, this will cause the timeofday() function  
to print its result in the user-requested time zone rather than some  
previously-set zone.  It might also affect results in third-party  
extensions, if there are any that make use of session_timezone without  
considering HasCTZSet, but in all cases the new behavior should be saner  
than before.  
  
Back-patch to all supported branches.  

commit   : a37f94ae4106634babe53a30a0cfc80380c12431    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 28 Oct 2013 20:49:32 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 28 Oct 2013 20:49:32 -0400    

The C and POSIX standards state that strncpy's behavior is undefined when  
source and destination areas overlap.  While it remains dubious whether any  
implementations really misbehave when the pointers are exactly equal, some  
platforms are now starting to force the issue by complaining when an  
undefined call occurs.  (In particular OS X 10.9 has been seen to dump core  
here, though the exact set of circumstances needed to trigger that remain  
elusive.  Similar behavior can be expected to be optional on Linux and  
other platforms in the near future.)  So tweak the code to explicitly do  
nothing when nothing need be done.  
  
Back-patch to all active branches.  In HEAD, this also lets us get rid of  
an exception in valgrind.supp.  
  
Per discussion of a report from Matthias Schmitt.  

commit   : 9060cb96805e0d3cfe74c0919feb5e2ce1034ffc    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 28 Oct 2013 11:45:50 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 28 Oct 2013 11:45:50 -0400    

The NetBSD shell apparently returns non-zero from an unset command if  
the variable is already unset. This matters when, as in pg_upgrade's  
test.sh, we are working under 'set -e'. To protect against this, we  
first set the PG variables to an empty string before unsetting them  
completely.  
  
Error found on buildfarm member coypu, solution from Rémi Zara.  

commit   : 4da24f12e63313b7dbb6b3e3d0317e04045df636    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 23 Oct 2013 14:03:54 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 23 Oct 2013 14:03:54 +0300    

Use a critical section when setting the all-visible flag on an empty page,  
and WAL-logging it. log_newpage_buffer() contains an assertion that it  
must be called inside a critical section, and it's the right thing to do  
when modifying a buffer anyway.  
  
Also, the page should be marked dirty before calling log_newpage_buffer(),  
per the comment in log_newpage_buffer() and src/backend/access/transam/README.  
  
Patch by Andres Freund, in response to my report. Backpatch to 9.2, like  
the patch that introduced these bugs (a6370fd9).  

commit   : b89cedeffb9e5a4a4c9ac501c245ee92cf85aa5f    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 2 Jul 2013 20:32:09 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 2 Jul 2013 20:32:09 -0400    

The web site is dead, and the Wayback Machine shows that it didn't have  
much useful content before.  

commit   : 2a5496f5a7fa5c80e900bd5b4e82a8efcc201573    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 15 Oct 2013 10:34:04 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 15 Oct 2013 10:34:04 -0400    

Backpatch through 9.1.  
  
KONDO Mitsumasa  

commit   : 5fbed6b1e1f9e7145679a9f90b5f8b6587f9cc19    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 9 Oct 2013 08:44:52 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 9 Oct 2013 08:44:52 -0400    

Backpatch through 8.4  
  
Per suggestion by Amit Langote