PostgreSQL 9.2.0 commit log

commit   : ef47adb414e46099155c34529a2a5caeea02fc41    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 6 Sep 2012 17:26:17 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 6 Sep 2012 17:26:17 -0400    

commit   : ee121a6473c00d0c791e3ed1c2f8e555e66a0ea0    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Thu, 6 Sep 2012 15:43:46 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Thu, 6 Sep 2012 15:43:46 -0400    

This affects initdb, clusterdb, reindexdb, and vacuumdb in master  
and 9.2; in earlier branches, only initdb is affected.  

commit   : 1bc414ca7642bf32be80fcbe4760fca0307d2e12    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 5 Sep 2012 23:33:52 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 5 Sep 2012 23:33:52 -0400    

commit   : 6acf90bc6e2bbd03a931d4edfa5fbe580df41515    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 5 Sep 2012 23:37:45 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 5 Sep 2012 23:37:45 -0400    

Shigeru Hanada  

commit   : bdf8f58397dc83618dccd8f85a46a02933a7f86f    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Wed, 5 Sep 2012 23:13:14 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Wed, 5 Sep 2012 23:13:14 -0400    

If we call pg_ctl stop, the server might continue and thus  
hold a log file for a short time after it has deleted its pid file,  
(which is when pg_ctl will exit), and so a subsequent attempt to  
open the log file might fail.  
  
We therefore try to open it a few times, sleeping one second between  
tries, to give the server time to exit.  
  
This corrects an error that was observed on the buildfarm.  
  
Backpatched to 9.2,  

commit   : 4b8dacfcef7ad16939ec8695019747fb45a80847    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 5 Sep 2012 18:10:15 -0700    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 5 Sep 2012 18:10:15 -0700    

When the startup process restores a WAL file from the archive, it deletes  
any old file with the same name and renames the new file in its place. On  
Windows, however, when a file is deleted, it still lingers as long as a  
process holds a file handle open on it. With cascading replication, a  
walsender process can hold the old file open, so the rename() in the startup  
process would fail. To fix that, rename the old file to a temporary name, to  
make the original file name available for reuse, before deleting the old  
file.  

commit   : 308d4ec4c677a2ced29b82dde811b1cbba8c3201    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 5 Sep 2012 21:49:11 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 5 Sep 2012 21:49:11 -0400    

Give the correct name of the GUC parameter being complained of.  
Also, emit a more suitable SQLSTATE (INVALID_PARAMETER_VALUE,  
not the default INTERNAL_ERROR).  
  
Gurjeet Singh, errcode adjustment by me  

commit   : 8a66a37d6df5a27cc2b5ec3b59322c974e0b1ef6    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 5 Sep 2012 21:28:27 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 5 Sep 2012 21:28:27 -0400    

Also, set the release date to 2012-09-10, since we're pretty well  
committed to that now.  

commit   : 216c0e30076aa6abecc6ab013b45e9567fcdff45    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Wed, 5 Sep 2012 17:55:47 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Wed, 5 Sep 2012 17:55:47 -0400    

Call pg_dumpall using -f switch instead of redirection, to avoid  
writing the output in text mode and generating spurious carriage  
returns. Remove to carriage return ignoring hack introduced by  
commit e442b0f0c6fd26738bafdeb5222511b586dfe4b9.  
  
Backpatch to 9.2.  

commit   : 5654fd1771398c9f85f91aef53361c96f4eef49c    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Wed, 5 Sep 2012 17:48:06 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Wed, 5 Sep 2012 17:48:06 -0400    

pg_upgrade opened the output from pg_dumpall in text mode and  
wrote the split files in text mode. This caused unwanted eating  
of intended carriage returns on input and production of spurious  
carriage returns on output. To avoid this, open all these files  
in binary mode. On non-Windows platforms, this change has no  
effect.  
  
Backpatch to 9.0. On 9.0 and 9.1, we also switch from redirecting  
pg_dumpall's output to using pg_dumpall's -f switch, for the same  
reason.  

commit   : 8e6f6b8ef2b990712d999f2f32c610376c1ebf57    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 5 Sep 2012 16:43:41 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 5 Sep 2012 16:43:41 -0400    

Perl, for some unaccountable reason, believes it's a good idea to reset  
SIGFPE handling to SIG_IGN.  Which wouldn't be a good idea even if it  
worked; but on some platforms (Linux at least) it doesn't work at all,  
instead resulting in forced process termination if the signal occurs.  
Given the lack of other complaints, it seems safe to assume that Perl  
never actually provokes SIGFPE and so there is no value in the setting  
anyway.  Hence, reset it to our normal handler after initializing Perl.  
  
Report, analysis and patch by Andres Freund.  

commit   : 970212f911728097b44ac231438c5cf4d45b2089    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 5 Sep 2012 14:36:51 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 5 Sep 2012 14:36:51 -0400    

This is just neatnik-ism, but since we do it for comparable code in elog.c,  
we may as well do it here.  

commit   : 3d975d0fc5d7fd28839e3cf1871a479bfc0bcd28    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 4 Sep 2012 22:07:35 -0700    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 4 Sep 2012 22:07:35 -0700    

Reported by Peter Eisentraut.  

commit   : c4f18483b69830c725a9d45332144eb1926c5c26    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 5 Sep 2012 00:01:13 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 5 Sep 2012 00:01:13 -0400    

Backpatch to 9.2.  

commit   : af35e66f04fe7e0430046e0bc83d8d117e95ba2f    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 4 Sep 2012 18:47:03 -0700    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 4 Sep 2012 18:47:03 -0700    

The cascading replication code assumed that the current RecoveryTargetTLI  
never changes, but that's not true with recovery_target_timeline='latest'.  
The obvious upshot of that is that RecoveryTargetTLI in shared memory needs  
to be protected by a lock. A less obvious consequence is that when a  
cascading standby is connected, and the standby switches to a new target  
timeline after scanning the archive, it will continue to stream WAL to the  
cascading standby, but from a wrong file, ie. the file of the previous  
timeline. For example, if the standby is currently streaming from the middle  
of file 000000010000000000000005, and the timeline changes, the standby  
will continue to stream from that file. However, the WAL on the new  
timeline is in file 000000020000000000000005, so the standby sends garbage  
from 000000010000000000000005 to the cascading standby, instead of the  
correct WAL from file 000000020000000000000005.  
  
This also fixes a related bug where a partial WAL segment is restored from  
the archive and streamed to a cascading standby. The code assumed that when  
a WAL segment is copied from the archive, it can immediately be fully  
streamed to a cascading standby. However, if the segment is only partially  
filled, ie. has the right size, but only N first bytes contain valid WAL,  
that's not safe. That can happen if a partial WAL segment is manually copied  
to the archive, or if a partial WAL segment is archived because a server is  
started up on a new timeline within that segment. The cascading standby will  
get confused if the WAL it received is not valid, and will get stuck until  
it's restarted. This patch fixes that problem by not allowing WAL restored  
from the archive to be streamed to a cascading standby until it's been  
replayed, and thus validated.  

commit   : 3e22659e0cb2181d71818eea96dc831a7e37cd69    
  
author   : Kevin Grittner <kgrittn@postgresql.org>    
date     : Tue, 4 Sep 2012 21:14:25 -0500    
  
committer: Kevin Grittner <kgrittn@postgresql.org>    
date     : Tue, 4 Sep 2012 21:14:25 -0500    

Serializable Snapshot Isolation used for serializable transactions  
depends on acquiring SIRead locks on all heap relation tuples which  
are used to generate the query result, so that a later delete or  
update of any of the tuples can flag a read-write conflict between  
transactions.  This is normally handled in heapam.c, with tuple level  
locking.  Since an index-only scan avoids heap access in many cases,  
building the result from the index tuple, the necessary predicate  
locks were not being acquired for all tuples in an index-only scan.  
  
To prevent problems with tuple IDs which are vacuumed and re-used  
while the transaction still matters, the xmin of the tuple is part of  
the tag for the tuple lock.  Since xmin is not available to the  
index-only scan for result rows generated from the index tuples, it  
is not possible to acquire a tuple-level predicate lock in such  
cases, in spite of having the tid.  If we went to the heap to get the  
xmin value, it would no longer be an index-only scan.  Rather than  
prohibit index-only scans under serializable transaction isolation,  
we acquire an SIRead lock on the page containing the tuple, when it  
was not necessary to visit the heap for other reasons.  
  
Backpatch to 9.2.  
  
Kevin Grittner and Tom Lane  

commit   : 8e39fd97f1566820f7dfd2b4d36dc6bd41211747    
  
author   : Kevin Grittner <kgrittn@postgresql.org>    
date     : Tue, 4 Sep 2012 20:40:48 -0500    
  
committer: Kevin Grittner <kgrittn@postgresql.org>    
date     : Tue, 4 Sep 2012 20:40:48 -0500    

Each setup block is run as a single PQexec submission, and some  
statements such as VACUUM cannot be combined with others in such a  
block.  
  
Backpatch to 9.2.  
  
Kevin Grittner and Tom Lane  

commit   : fb18e4dd078eb2c114276ab6cb880a4f5f2e0d9f    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Tue, 4 Sep 2012 09:40:49 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Tue, 4 Sep 2012 09:40:49 -0400    

commit   : 469530b37094515717947a997e7e77737bb70a60    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 4 Sep 2012 09:17:19 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 4 Sep 2012 09:17:19 -0400    

Backpatch to 9.2.  

commit   : ee7a48c5b37a3e37b0c2a934c86c9385c5ad8caf    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Tue, 4 Sep 2012 14:37:14 +0200    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Tue, 4 Sep 2012 14:37:14 +0200    

commit   : 14fd5b3b9e396ce29d1f9e5b983081f77460b996    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Tue, 4 Sep 2012 05:51:44 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Tue, 4 Sep 2012 05:51:44 -0400    

commit   : b5d437c011e9d739b79aa37ca19baca56b334ab7    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 3 Sep 2012 22:58:38 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 3 Sep 2012 22:58:38 -0400    

commit   : 765b5c41ba70098086988b4c7ba84162cd88e1de    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 3 Sep 2012 22:32:56 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 3 Sep 2012 22:32:56 -0400    

Backpatch to 9.2.  

commit   : d0a51117da92efd8cba426f6591fc1cfe6a497a3    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 3 Sep 2012 22:15:09 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 3 Sep 2012 22:15:09 -0400    

Backpatch to 9.2.  

commit   : f88ad86fba2a1700c96953ee26ed700f08fa5d7e    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 3 Sep 2012 18:11:02 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 3 Sep 2012 18:11:02 -0400    

pg_upgrade produces a platform-specific script to remove the old  
directory, but on Windows it has not been making sure that the  
paths it writes as arguments for rmdir and del use the backslash  
path separator, which will cause these scripts to fail.  
  
The fix is backpatched to Release 9.0.  

commit   : c879e82b3746150171fcec605a6d5b2b21e5c6cf    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 3 Sep 2012 15:32:58 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 3 Sep 2012 15:32:58 -0400    

Backpatch to 9.2 - code before that is quite different and should  
not have these defects.  

commit   : 5c7e91e9c3d6716641ba52286c6d3daa6b1c13c0    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 3 Sep 2012 15:03:08 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 3 Sep 2012 15:03:08 -0400    

This syncs contrib/pg_upgrade in the 9.2 branch with HEAD, except for the  
HEAD changes related to converting XLogRecPtr to 64-bit int.  It includes  
back-patching these commits:  
  
666d494d19dbd5dc7a177709a2f7069913f8ab89  
pg_upgrade: abstract out copying of files from old cluster to new  
7afa8bed65ea925208f128048f3a528a64e1319a  
pg_upgrade: Run the created scripts in the test suite  
ab577e63faf792593ca728625a8ef0b1dfaf7500  
Remove analyze_new_cluster.sh on make clean, too  
34c02044ed7e7defde5a853b26dcd806c872d974  
Fix thinko in comment  
088c065ce8e405fafbfa966937184ece9defcf20  
pg_upgrade: Fix exec_prog API to be less flaky  
f763b77193b04eba03a1f4ce46df34dc0348419e  
Fix pg_upgrade to cope with non-default unix_socket_directory scenarios.  

commit   : b681a874d97a16693c59228660f8d8a75f723bf3    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 3 Sep 2012 11:24:36 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 3 Sep 2012 11:24:36 -0400    

Formerly it would only show them for relkinds 'r' and 'f' (plain tables  
and foreign tables).  However, as of 9.2, views can also have reloptions,  
namely security_barrier.  The relkind restriction seems pointless and  
not at all future-proof, so just print reloptions whenever there are any.  
  
In passing, make some cosmetic improvements to the code that pulls the  
"tableinfo" fields out of the PGresult.  
  
Noted and patched by Dean Rasheed, with adjustment for all relkinds by me.  

commit   : 2d038749017de2d293a524b3f9df7eaae30dbf6a    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 31 Aug 2012 20:50:31 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 31 Aug 2012 20:50:31 -0400    

This was removed in commit cd004067742ee16ee63e55abfb4acbd5f09fbaab,  
we're not quite sure why, but there have been reports of crashes due  
to AS Perl being built with it when we are not, and it certainly  
seems like the right thing to do. There is still some uncertainty  
as to why it sometimes fails and sometimes doesn't.  
  
Original patch from Owais Khani, substantially reworked and  
extended by Andrew Dunstan.  

commit   : e46794420ee37f15d3a6da771b7703fcd9b1ea91    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 31 Aug 2012 14:18:02 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 31 Aug 2012 14:18:02 -0400    

We previously supposed that any given platform would supply both or neither  
of these functions, so that one configure test would be sufficient.  It now  
appears that at least on AIX this is not the case ... which is likely an  
AIX bug, but nonetheless we need to cope with it.  So use separate tests.  
Per bug #6758; thanks to Andrew Hastie for doing the followup testing  
needed to confirm what was happening.  
  
Backpatch to 9.1, where we began using these functions.  

commit   : d2528e5dbf1ad6e391f40712a27d4d199b43100d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 30 Aug 2012 23:47:46 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 30 Aug 2012 23:47:46 -0400    

This back-ports commits c8ba697a4bdb934f0c51424c654e8db6133ea255 and  
e5db11c5582b469c04a11f217a0f32c827da5dd7, which fix one definite and one  
speculative bug in gistchoose, and make the code a lot more intelligible as  
well.  In 9.2 only, this also affects the largely-copied-and-pasted logic  
in gistRelocateBuildBuffersOnSplit.  
  
The impact of the bugs was that the functions might make poor decisions  
as to which index tree branch to push a new entry down into, resulting in  
GiST index bloat and poor performance.  The fixes rectify these decisions  
for future insertions, but a REINDEX would be needed to clean up any  
existing index bloat.  
  
Alexander Korotkov, Robert Haas, Tom Lane  

commit   : d561fc5396e537452065c3531cb43edf11a8dbf0    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Thu, 30 Aug 2012 15:06:55 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Thu, 30 Aug 2012 15:06:55 -0400    

Jeff Janes  

commit   : 36bffe4ffa5a7492d78a889e7feb0838be5449f1    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Thu, 30 Aug 2012 14:14:22 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Thu, 30 Aug 2012 14:14:22 -0400    

The existing documentation in Linux Memory Overcommit seemed to  
assume that PostgreSQL itself could never be the problem, or at  
least it didn't tell you what to do about it.  
  
Per discussion with Craig Ringer and Kevin Grittner.  

commit   : 640393080d863c69ae65ba0205e05cd3d4d438b0    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Thu, 30 Aug 2012 13:26:45 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Thu, 30 Aug 2012 13:26:45 -0400    

Per note from Peter Eisentraut.  

commit   : dc1a36f11ad629808795785fc55c495510db40a9    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 28 Aug 2012 16:11:44 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 28 Aug 2012 16:11:44 -0400    

commit   : 3ca1d62080a9e148b71a2aaa4ee1d210ce92ad68    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 28 Aug 2012 09:46:08 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 28 Aug 2012 09:46:08 -0400    

commit   : 53c0ccc8d520ce1a65bc81edbef78223d8222124    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 28 Aug 2012 03:10:04 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 28 Aug 2012 03:10:04 -0400    

commit   : a63b7744fa4abdabc977dd4525d0444ddf10f9ed    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 27 Aug 2012 20:54:00 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 27 Aug 2012 20:54:00 -0400    

Clarify the compatibility notes about EXTRACT() and about statistics  
timing columns.  

commit   : 60888e232f0a0264ab5c8bb2bf8860932f58723d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 27 Aug 2012 20:17:16 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 27 Aug 2012 20:17:16 -0400    

This is so that these sections will have stable HTML tags that one can  
link to, rather than things like "AEN1902".  Perhaps we should mount a  
campaign to do this everywhere, but I've found myself pointing at  
syntax.sgml subsections often enough to be sure it's useful here.  

commit   : a6f43529ea6c3abd9207cea140ab231ac078746a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 27 Aug 2012 12:45:51 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 27 Aug 2012 12:45:51 -0400    

This threw ERROR, not the expected NOTICE, if the index didn't exist.  
The bug was actually visible in not-as-expected regression test output,  
so somebody wasn't paying too close attention in commit  
8cb53654dbdb4c386369eb988062d0bbb6de725e.  
Per report from Brendan Byrd.  

commit   : 81bcc8bc4ca6335f0b5b2029ebe84fbd788556fe    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 27 Aug 2012 00:49:39 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 27 Aug 2012 00:49:39 -0400    

It still thought that the --xlog-method option argument could be  
empty, as in a previous version of this feature.  

commit   : 019498f0c8f00138eadc98ecda69645929011364    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 24 Aug 2012 22:36:24 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 24 Aug 2012 22:36:24 -0400    

commit   : 2e435eb38a9a01894bff6eb2c627083133d729ee    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 24 Aug 2012 22:35:53 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 24 Aug 2012 22:35:53 -0400    

commit   : c3ca786df656d447ca02d51ed3a888468ed6e88d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 24 Aug 2012 13:09:12 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 24 Aug 2012 13:09:12 -0400    

The GUC check hooks for transaction_read_only and transaction_isolation  
tried to check RecoveryInProgress(), so as to disallow setting read/write  
mode or serializable isolation level (respectively) in hot standby  
sessions.  However, GUC check hooks can be called in many situations where  
we're not connected to shared memory at all, resulting in a crash in  
RecoveryInProgress().  Among other cases, this results in EXEC_BACKEND  
builds crashing during child process start if default_transaction_isolation  
is serializable, as reported by Heikki Linnakangas.  Protect those calls  
by silently allowing any setting when not inside a transaction; which is  
okay anyway since these GUCs are always reset at start of transaction.  
  
Also, add a check to GetSerializableTransactionSnapshot() to complain  
if we are in hot standby.  We need that check despite the one in  
check_XactIsoLevel() because default_transaction_isolation could be  
serializable.  We don't want to complain any sooner than this in such  
cases, since that would prevent running transactions at all in such a  
state; but a transaction can be run, if SET TRANSACTION ISOLATION is done  
before setting a snapshot.  Per report some months ago from Robert Haas.  
  
Back-patch to 9.1, since these problems were introduced by the SSI patch.  
  
Kevin Grittner and Tom Lane, with ideas from Heikki Linnakangas  

commit   : 5171a400cb15a94b6a2aa8ea2ad7a0128d080830    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 24 Aug 2012 00:06:59 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 24 Aug 2012 00:06:59 -0400    

commit   : 1c8c084cdc136388835e0d703a5e26272e0a8f2f    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 23 Aug 2012 22:33:04 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 23 Aug 2012 22:33:04 -0400    

When an invalid query parameter is reported, some memory leaks.  
  
found by Coverity  

commit   : f3df4cd22c45057bd24acec4efd21896b892c65e    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 23 Aug 2012 21:24:06 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 23 Aug 2012 21:24:06 -0400    

commit   : e8c736ca71b3d7aa65ea05a133b4f2a65a11e812    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 23 Aug 2012 18:06:49 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 23 Aug 2012 18:06:49 -0400    

commit   : fb7b6197b9ed2fe9813ccc0cb4ff548ae255d80d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 23 Aug 2012 17:25:17 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 23 Aug 2012 17:25:17 -0400    

If we revoke a grant option from some role X, but X still holds the option  
via another grant, we should not recursively revoke the privilege from  
role(s) Y that X had granted it to.  This was supposedly fixed as one  
aspect of commit 4b2dafcc0b1a579ef5daaa2728223006d1ff98e9, but I must not  
have tested it, because in fact that code never worked: it forgot to shift  
the grant-option bits back over when masking the bits being revoked.  
  
Per bug #6728 from Daniel German.  Back-patch to all active branches,  
since this has been wrong since 8.0.  

commit   : ebcc0158f174336fc50ad33fe4cfa642bdff64a8    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 23 Aug 2012 11:57:34 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 23 Aug 2012 11:57:34 +0300    

commit   : ead31d1a72b1a99b2741c42adc951564992fb24f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 22 Aug 2012 23:55:34 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 22 Aug 2012 23:55:34 -0400    

As of 9.2, constraint exclusion should work okay with prepared statements:  
the planner will try custom plans with actual values of the parameters,  
and observe that they are a lot cheaper than the generic plan, and thus  
never fall back to using the generic plan.  Noted by Tatsuhito Kasahara.  

commit   : d3337731277c3f65209fc39986627c66033812e9    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 22 Aug 2012 17:58:06 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 22 Aug 2012 17:58:06 -0400    

This is open to debate of course, but it's past time we had *something*  
here.  

commit   : a902d46475e702eb37a5dff51f68948d6d5536f7    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 22 Aug 2012 17:37:02 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 22 Aug 2012 17:37:02 -0400    

A very large number of small improvements ...  

commit   : 9e8f8ef1f072c6d990f334ffbb977eb7486c54f6    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 22 Aug 2012 14:04:02 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 22 Aug 2012 14:04:02 -0400    

The docs claimed that this mode only waits for the standby to receive WAL  
data, but actually it waits for the data to be written out to the standby's  
OS; which is a pretty significant difference because it removes the risk of  
crash of the walreceiver process.  

commit   : 3f9abab59021fff43dade76bfeea139ccbbb38dc    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 21 Aug 2012 22:56:10 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 21 Aug 2012 22:56:10 -0400    

I was unable to entirely resist the temptation to copy-edit related  
entries, but will save most of that for a separate pass.  

commit   : 1ace786878b7f71547faa427c323fffb29cefea6    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 21 Aug 2012 15:18:36 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 21 Aug 2012 15:18:36 -0400    

If a view has circular dependencies, pg_dump splits it into a CREATE TABLE  
and a CREATE RULE command to break the dependency loop.  However, if the  
view has reloptions, those options cannot be applied in the CREATE TABLE  
command, because views and tables have different allowed reloptions so  
CREATE TABLE would reject them.  Instead apply the reloptions after the  
CREATE RULE, using ALTER VIEW SET.  

commit   : e0badf67e9cd409ea35f2c2d5e3ca36ffecb47d7    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 20 Aug 2012 13:24:58 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 20 Aug 2012 13:24:58 -0400    

Extraction of trigrams did not process LIKE escape sequences properly,  
leading to possible misidentification of trigrams near escapes, resulting  
in incorrect index search results.  
  
Fujii Masao  

commit   : 33f40976a716287ecddfb01f446797d8df215125    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 17 Aug 2012 00:05:33 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 17 Aug 2012 00:05:33 -0400    

We had put a test for libxml2's xmlStructuredErrorContext variable in  
configure, but of course that doesn't work on Windows builds.  The next  
best alternative seems to be to test the LIBXML_VERSION symbol provided  
by xmlversion.h.  
  
Per report from Talha Bin Rizwan, though this fixes it in a different way  
than his proposed patch.  

commit   : 26893906896d25b0119c57c90474c153bb8083c9    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 16 Aug 2012 13:04:03 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 16 Aug 2012 13:04:03 -0400    

In the initial cut at the "parameterized paths" feature, I'd simplified  
create_index_paths() to the point where it would only generate a single  
parameterized bitmap path per relation.  Experimentation with an example  
supplied by Josh Berkus convinces me that that's not good enough: we really  
need to consider a bitmap path for each possible outer relation.  Otherwise  
we have regressions relative to pre-9.2 versions, in which the planner  
picks a plain indexscan where it should have used a bitmap scan in queries  
involving three or more tables.  Indeed, after fixing this, several queries  
in the regression tests show improved plans as a result of using bitmap not  
plain indexscans.  

commit   : d6524697dba5967c7951c9a47107054660804900    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 16 Aug 2012 12:42:11 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 16 Aug 2012 12:42:11 +0300    

We use a hash table to track the parents of inner pages, but when inserting  
to a leaf page, the caller of gistbufferinginserttuples() must pass a  
correct block number of the leaf's parent page. Before gistProcessItup()  
descends to a child page, it checks if the downlink needs to be adjusted to  
accommodate the new tuple, and updates the downlink if necessary. However,  
updating the downlink might require splitting the page, which might move the  
downlink to a page to the right. gistProcessItup() doesn't realize that, so  
when it descends to the leaf page, it might pass an out-of-date parent block  
number as a result. Fix that by returning the block a tuple was inserted to  
from gistbufferinginserttuples().  
  
This fixes the bug reported by Zdeněk Jílovec.  

commit   : caf97eb72e2e08378aefdd8f75c10b73fd04172b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 15 Aug 2012 19:01:23 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 15 Aug 2012 19:01:23 -0400    

The previous coding essentially assumed that nodes would be rescanned in  
the same order they were initialized in; or at least that the "leader" of  
a group of CTEscans would be rescanned before any others were required to  
execute.  Unfortunately, that isn't even a little bit true.  It's possible  
to devise queries in which the leader isn't rescanned until other CTEscans  
on the same CTE have run to completion, or even in which the leader never  
gets a rescan call at all.  
  
The fix makes the leader specially responsible only for initial creation  
and final destruction of the tuplestore; rescan resets are now a  
symmetrically shared responsibility.  This means that we might reset the  
tuplestore multiple times when restarting a plan subtree containing  
multiple CTEscans; but resetting an already-empty tuplestore is cheap  
enough that that doesn't seem like a problem.  
  
Per report from Adam Mackler; the new regression test cases are based on  
his example query.  
  
Back-patch to 8.4 where CTE scans were introduced.  

commit   : 82634a88d1ba2fdc3308d589b0b8f3bfdbd880f1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 15 Aug 2012 11:27:00 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 15 Aug 2012 11:27:00 -0400    

This situation creates a dependency loop that confuses pg_dump and probably  
other things.  Moreover, since the mental model is that the extension  
"contains" schemas it owns, but "is contained in" its extschema (even  
though neither is strictly true), having both true at once is confusing for  
people too.  So prevent the situation from being set up.  
  
Reported and patched by Thom Brown.  Back-patch to 9.1 where extensions  
were added.  

commit   : 43ccd309cbf4e9b09ac59130c9b31a1c58a9ff2d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 15 Aug 2012 00:07:15 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 15 Aug 2012 00:07:15 -0400    

This essentially reverts commit e54b10a62db2991235fe800c629baef4531a6d67,  
in which I'd decided that the "last ditch" join logic was useless.  The  
folly of that is now exposed by a report from Pavel Stehule: although the  
function should always find at least one join in a self-contained join  
problem, it can still fail to do so in a sub-problem created by artificial  
from_collapse_limit or join_collapse_limit constraints.  Adjust the  
comments to describe this, and simplify the code a bit to match the new  
coding of the earlier loop in the function.  
  
I'm not terribly happy about this: I still subscribe to the opinion stated  
in the previous commit message that the "last ditch" code can obscure logic  
bugs elsewhere.  But the alternative seems to be to complicate the earlier  
tests for does-this-relation-have-a-join-clause to the point where they can  
tell whether the join clauses link outside the current join sub-problem.  
And that looks messy, slow, and possibly a source of bugs in itself.  
In any case, now is not the time to be inserting experimental code into  
9.2, so let's just go back to the time-tested solution.  

commit   : d5bcb33603a8ef1ac7779ff0e7d4550ce522673e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 14 Aug 2012 18:38:49 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 14 Aug 2012 18:38:49 -0400    

commit   : 333a54a584c6f85d586ea0ee36013c1506892dd6    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 14 Aug 2012 18:24:11 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 14 Aug 2012 18:24:11 -0400    

commit   : 2ec75967d9ddd20378e03a5e7c46cb126972747c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 14 Aug 2012 18:28:37 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 14 Aug 2012 18:28:37 -0400    

libxslt offers the ability to read and write both files and URLs through  
stylesheet commands, thus allowing unprivileged database users to both read  
and write data with the privileges of the database server.  Disable that  
through proper use of libxslt's security options.  
  
Also, remove xslt_process()'s ability to fetch documents and stylesheets  
from external files/URLs.  While this was a documented "feature", it was  
long regarded as a terrible idea.  The fix for CVE-2012-3489 broke that  
capability, and rather than expend effort on trying to fix it, we're just  
going to summarily remove it.  
  
While the ability to write as well as read makes this security hole  
considerably worse than CVE-2012-3489, the problem is mitigated by the fact  
that xslt_process() is not available unless contrib/xml2 is installed,  
and the longstanding warnings about security risks from that should have  
discouraged prudent DBAs from installing it in security-exposed databases.  
  
Reported and fixed by Peter Eisentraut.  
  
Security: CVE-2012-3488  

commit   : aa2bc1f23f84924da20551a7338c0aaa743d490d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 14 Aug 2012 18:25:39 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 14 Aug 2012 18:25:39 -0400    

xml_parse() would attempt to fetch external files or URLs as needed to  
resolve DTD and entity references in an XML value, thus allowing  
unprivileged database users to attempt to fetch data with the privileges  
of the database server.  While the external data wouldn't get returned  
directly to the user, portions of it could be exposed in error messages  
if the data didn't parse as valid XML; and in any case the mere ability  
to check existence of a file might be useful to an attacker.  
  
The ideal solution to this would still allow fetching of references that  
are listed in the host system's XML catalogs, so that documents can be  
validated according to installed DTDs.  However, doing that with the  
available libxml2 APIs appears complex and error-prone, so we're not going  
to risk it in a security patch that necessarily hasn't gotten wide review.  
So this patch merely shuts off all access, causing any external fetch to  
silently expand to an empty string.  A future patch may improve this.  
  
In HEAD and 9.2, also suppress warnings about undefined entities, which  
would otherwise occur as a result of not loading referenced DTDs.  Previous  
branches don't show such warnings anyway, due to different error handling  
arrangements.  
  
Credit to Noah Misch for first reporting the problem, and for much work  
towards a solution, though this simplistic approach was not his preference.  
Also thanks to Daniel Veillard for consultation.  
  
Security: CVE-2012-3489  

commit   : 2152001773ecddb838b4c7566e332dd184e7d769    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 14 Aug 2012 16:37:40 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 14 Aug 2012 16:37:40 -0400    

commit   : 30f891151ed63db9434170aa17da8f4179ae4fb0    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 14 Aug 2012 12:36:34 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 14 Aug 2012 12:36:34 -0400    

Backpatch to 9.2.  

commit   : dabbd3ee4174a1ca9458a3b387840a9571089a18    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 14 Aug 2012 10:54:30 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 14 Aug 2012 10:54:30 -0400    

DST law changes in Morocco; Tokelau has relocated to the other side of  
the International Date Line; and apparently Olson had Tokelau's GMT  
offset wrong by an hour even before that.  
  
There are also a large number of non-significant changes in this update.  
Upstream took the opportunity to remove trailing whitespace, and the  
SCCS-style version numbers on the individual files are gone too.  

commit   : ce36ecda518397122045e1a0953c465446b19d47    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 11 Aug 2012 13:51:22 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 11 Aug 2012 13:51:22 -0400    

Jeff Janes  

commit   : ca07d7ebe04de9225e7f14c8504539869c7e3ff0    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 11 Aug 2012 12:51:30 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 11 Aug 2012 12:51:30 -0400    

This command generated new pg_depend entries linking the index to the  
constraint and the constraint to the table, which match the entries made  
when a unique or primary key constraint is built de novo.  However, it did  
not bother to get rid of the entries linking the index directly to the  
table.  We had considered the issue when the ADD CONSTRAINT USING INDEX  
patch was written, and concluded that we didn't need to get rid of the  
extra entries.  But this is wrong: ALTER COLUMN TYPE wasn't expecting such  
redundant dependencies to exist, as reported by Hubert Depesz Lubaczewski.  
On reflection it seems rather likely to break other things as well, since  
there are many bits of code that crawl pg_depend for one purpose or  
another, and most of them are pretty naive about what relationships they're  
expecting to find.  Fortunately it's not that hard to get rid of the extra  
dependency entries, so let's do that.  
  
Back-patch to 9.1, where ALTER TABLE ADD CONSTRAINT USING INDEX was added.  

commit   : e2af6537b5c81d9354e08896012cdd5c38bea311    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Fri, 10 Aug 2012 17:14:47 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Fri, 10 Aug 2012 17:14:47 -0400    

Backpatch to 9.2.  

commit   : 63e719ec511f99eeb4f237366ef633cd264e40da    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Fri, 10 Aug 2012 14:49:03 +0200    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Fri, 10 Aug 2012 14:49:03 +0200    

Should be limited to the maximum number of connections excluding  
autovacuum workers, not including.  
  
Add similar check for max_wal_senders, which should never be higher than  
max_connections.  

commit   : 86ece4bff648364ece3cf03c0e7bfbe9fb3fc8cd    
  
author   : Simon Riggs <simon@2ndQuadrant.com>    
date     : Thu, 9 Aug 2012 17:06:47 +0100    
  
committer: Simon Riggs <simon@2ndQuadrant.com>    
date     : Thu, 9 Aug 2012 17:06:47 +0100    

commit   : 6a2cbe12358d3e3c356d863c8fc40c5f8daadb2a    
  
author   : Simon Riggs <simon@2ndQuadrant.com>    
date     : Thu, 9 Aug 2012 17:03:10 +0100    
  
committer: Simon Riggs <simon@2ndQuadrant.com>    
date     : Thu, 9 Aug 2012 17:03:10 +0100    

commit   : 6f4b8a4f4f7a2d683ff79ab59d3693714b965e3d    
  
author   : Simon Riggs <simon@2ndQuadrant.com>    
date     : Wed, 8 Aug 2012 23:58:49 +0100    
  
committer: Simon Riggs <simon@2ndQuadrant.com>    
date     : Wed, 8 Aug 2012 23:58:49 +0100    

Fujii Masao, simplified and extended to cover streaming by Simon Riggs  

commit   : 7c055d64a6c541f8480abd5833321e1661e10bce    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 8 Aug 2012 17:34:20 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 8 Aug 2012 17:34:20 -0400    

commit   : cc23119af5c6142a81af07ce7dae339b9869e725    
  
author   : Simon Riggs <simon@2ndQuadrant.com>    
date     : Wed, 8 Aug 2012 22:36:55 +0100    
  
committer: Simon Riggs <simon@2ndQuadrant.com>    
date     : Wed, 8 Aug 2012 22:36:55 +0100    

Noted by Noah Misch, patch by Fujii Masao  

commit   : df09dbbcaa546350a78ce9f096b872fa3a28cafb    
  
author   : Simon Riggs <simon@2ndQuadrant.com>    
date     : Wed, 8 Aug 2012 21:28:41 +0100    
  
committer: Simon Riggs <simon@2ndQuadrant.com>    
date     : Wed, 8 Aug 2012 21:28:41 +0100    

Spotted by Fujii Masao, fix by Fujii Masao and Simon Riggs  

commit   : 4bf70f22296596a1b67eac92aa6a5fc367b37cb3    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 8 Aug 2012 12:02:11 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 8 Aug 2012 12:02:11 -0400    

The directions explaining about running the prepared-transactions test  
were not updated in commit ae55d9fbe3871a5e6309d9b91629f1b0ff2b8cba.  

commit   : 5cf2307c98f6daeac3d42e74f4e2d46ab3bf0a80    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 8 Aug 2012 11:52:06 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 8 Aug 2012 11:52:06 -0400    

This was broken in commit ed0b409d22346b1b027a4c2099ca66984d94b6dd,  
which revised the GlobalTransactionData struct to not include the  
associated PGPROC as its first member, but overlooked one place where  
a cast was used in reliance on that equivalence.  
  
The most effective way of fixing this seems to be to create a new function  
that looks up the GlobalTransactionData struct given the XID, and make  
both TwoPhaseGetDummyBackendId and TwoPhaseGetDummyProc rely on that.  
  
Per report from Robert Ross.  

commit   : 7d947ec82ac8a7d6a6ce8acf08067dd69098d6cd    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 7 Aug 2012 13:10:44 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 7 Aug 2012 13:10:44 -0400    

Backpatch to 9.2.  

commit   : 4d06811ef9ed2593292f859292f61d10b38be352    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 7 Aug 2012 11:02:53 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 7 Aug 2012 11:02:53 -0400    

commit   : 393b07004e2e9bac6d3b7cad2c4d555516237d90    
  
author   : Simon Riggs <simon@2ndQuadrant.com>    
date     : Tue, 7 Aug 2012 16:20:32 +0100    
  
committer: Simon Riggs <simon@2ndQuadrant.com>    
date     : Tue, 7 Aug 2012 16:20:32 +0100    

Dave Kerr  

commit   : 73a7a6460ee47c13c5bea99c16b4e8756fb85dec    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Mon, 6 Aug 2012 16:12:17 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Mon, 6 Aug 2012 16:12:17 -0400    

Noted by Thom Brown.  

commit   : e022ed91d73cf1db1951f417b33a9a15a35bdd9e    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Mon, 6 Aug 2012 15:18:00 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Mon, 6 Aug 2012 15:18:00 -0400    

Craig Ringer, edited fairly heavily by me  

commit   : da003a5ab1197a39c62d304bd0fc5b4e21ec6b0b    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 6 Aug 2012 12:45:08 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 6 Aug 2012 12:45:08 -0400    

commit   : 0b4660b539821ccdef99e43e79deb023a68db34e    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Mon, 6 Aug 2012 13:53:46 +0200    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Mon, 6 Aug 2012 13:53:46 +0200    

In particular, with a controlled shutdown of the master, pg_basebackup  
with streaming log could terminate without an error message, even though  
the backup is not consistent.  
  
In passing, fix a few cases where walfile wasn't properly set to -1 after  
closing.  
  
Fujii Masao  

commit   : d9c77e249339ec3a49731be55ff22bbdd5a1fcf0    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 6 Aug 2012 13:02:15 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 6 Aug 2012 13:02:15 +0300    

We used to convert the unicode object directly to a string in the server  
encoding by calling Python's PyUnicode_AsEncodedString function. In other  
words, we used Python's routines to do the encoding. However, that has a  
few problems. First of all, it required keeping a mapping table of Python  
encoding names and PostgreSQL encodings. But the real killer was that Python  
doesn't support EUC_TW and MULE_INTERNAL encodings at all.  
  
Instead, convert the Python unicode object to UTF-8, and use PostgreSQL's  
encoding conversion functions to convert from UTF-8 to server encoding. We  
were already doing the same in the other direction in PLyUnicode_FromString,  
so this is more consistent, too.  
  
Note: This makes SQL_ASCII to behave more leniently. We used to map  
SQL_ASCII to Python's 'ascii', which on Python means strict 7-bit ASCII  
only, so you got an error if the python string contained anything but pure  
ASCII. You no longer get an error; you get the UTF-8 representation of the  
string instead.  
  
Backpatch to 9.0, where these conversions were introduced.  
  
Jan Urbański  

commit   : a411f7e770895b34035727bc44866e550cca892f    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Sat, 4 Aug 2012 10:35:37 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Sat, 4 Aug 2012 10:35:37 -0400    

Backpatch to 9.1 and 9.2.  

commit   : 225fe68c19c7baf02aff9b2ea83027091f95ee38    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 3 Aug 2012 17:39:45 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 3 Aug 2012 17:39:45 -0400    

DecodeInterval() failed to honor the "range" parameter (the special SQL  
syntax for indicating which fields appear in the literal string) if the  
time was signed.  This seems inappropriate, so make it work like the  
not-signed case.  The inconsistency was introduced in my commit  
f867339c0148381eb1d01f93ab5c79f9d10211de, which as noted in its log message  
was only really focused on making SQL-compliant literals work per spec.  
Including a sign here is not per spec, but if we're going to allow it  
then it's reasonable to expect it to work like the not-signed case.  
  
Also, remove bogus setting of tmask, which caused subsequent processing to  
think that what had been given was a timezone and not an hh:mm(:ss) field,  
thus confusing checks for redundant fields.  This seems to be an aboriginal  
mistake in Lockhart's commit 2cf1642461536d0d8f3a1cf124ead0eac04eb760.  
  
Add regression test cases to illustrate the changed behaviors.  
  
Back-patch as far as 8.4, where support for spec-compliant interval  
literals was added.  
  
Range problem reported and diagnosed by Amit Kapila, tmask problem by me.  

commit   : bf92fb6c2de488d94ac4ad6ec0f78e7f133efac5    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Fri, 3 Aug 2012 16:33:09 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Fri, 3 Aug 2012 16:33:09 -0400    

Backpatch to 9.2  
  
Erik Rijkers  

commit   : 11de73b25dbeea012ae61e8f1dcf939f6b737286    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 3 Aug 2012 15:41:23 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 3 Aug 2012 15:41:23 -0400    

As noted by Noah Misch, btree_xlog_delete_get_latestRemovedXid is  
critically dependent on the assumption that it's examining a consistent  
state of the database.  This was undocumented though, so the  
seemingly-unrelated check for no active HS sessions might be thought to be  
merely an optional optimization.  Improve comments, and add an explicit  
check of reachedConsistency just to be sure.  
  
This function returns InvalidTransactionId (thereby killing all HS  
transactions) in several cases that are not nearly unlikely enough for my  
taste.  This commit doesn't attempt to fix those deficiencies, just  
document them.  
  
Back-patch to 9.2, not from any real functional need but just to keep the  
branches more closely synced to simplify possible future back-patching.  

commit   : dd6947aae8cd05809f03c9aae1908f5c70f0dd7d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 3 Aug 2012 15:22:47 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 3 Aug 2012 15:22:47 -0400    

In yesterday's commit 962e0cc71e839c58fb9125fa85511b8bbb8bdbee, I added the  
ResolveRecoveryConflictWithSnapshot call in the wrong place.  I correctly  
put it before spgRedoVacuumRedirect itself would modify the index page ---  
but not before RestoreBkpBlocks, so replay of a record with a full-page  
image would modify the page before kicking off any conflicting HS  
transactions.  Oops.  

commit   : e7d9f26a6008c61ea388f1324176cf45b94e2337    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Fri, 3 Aug 2012 15:15:27 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Fri, 3 Aug 2012 15:15:27 -0400    

Backpatch to 9.2.  

commit   : 91668fcc318cac9d980f076dee9258cd76904e9f    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Fri, 3 Aug 2012 14:02:22 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Fri, 3 Aug 2012 14:02:22 -0400    

Backpatch to 9.2 and 9.1.  

commit   : 51ec1d3d486fa4b88d3d9382a7699f980fcaec65    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Fri, 3 Aug 2012 12:43:37 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Fri, 3 Aug 2012 12:43:37 -0400    

Backpatch to 9.2.  

commit   : f30b05b8a468d0240d18251dbf2907793da676ba    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 2 Aug 2012 18:23:20 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 2 Aug 2012 18:23:20 -0400    

commit   : 095bcf93a8cdf71b7809877a14f94c9cbf7c47fd    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 2 Aug 2012 23:01:01 +0300    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 2 Aug 2012 23:01:01 +0300    

commit   : 7f7c93f85f5fb7fa86c525e04f3de031f3dde794    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 2 Aug 2012 15:34:21 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 2 Aug 2012 15:34:21 -0400    

The correct test for whether a redirection tuple is removable is whether  
tuple's xid < RecentGlobalXmin, not OldestXmin; the previous coding  
failed to protect index searches being done in concurrent transactions that  
have no XID.  This mirrors the recent fix in btree's page recycling logic  
made in commit d3abbbebe52eb1e59e621c880ad57df9d40d13f2.  
  
Also, WAL-log the newest XID of any removed redirection tuple on an index  
page, and apply ResolveRecoveryConflictWithSnapshot during InHotStandby WAL  
replay.  This protects against concurrent Hot Standby transactions possibly  
needing to see the redirection tuple(s).  
  
Per my query of 2012-03-12 and subsequent discussion.  

commit   : 87a237956860c05c6c0d64a7f443b338d99ee38e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 2 Aug 2012 13:21:24 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 2 Aug 2012 13:21:24 -0400    

commit   : ea56ed9a1e2b5164b02f4a030fb327346612b2d9    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 2 Aug 2012 13:10:36 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 2 Aug 2012 13:10:36 -0400    

After taking awhile to digest the row-processor feature that was added to  
libpq in commit 92785dac2ee7026948962cd61c4cd84a2d052772, we've concluded  
it is over-complicated and too hard to use.  Leave the core infrastructure  
changes in place (that is, there's still a row processor function inside  
libpq), but remove the exposed API pieces, and instead provide a "single  
row" mode switch that causes PQgetResult to return one row at a time in  
separate PGresult objects.  
  
This approach incurs more overhead than proper use of a row processor  
callback would, since construction of a PGresult per row adds extra cycles.  
However, it is far easier to use and harder to break.  The single-row mode  
still affords applications the primary benefit that the row processor API  
was meant to provide, namely not having to accumulate large result sets in  
memory before processing them.  Preliminary testing suggests that we can  
probably buy back most of the extra cycles by micro-optimizing construction  
of the extra results, but that task will be left for another day.  
  
Marko Kreen  

commit   : f6fb9f103ff534193f4132e0c6a47bf441cfad42    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 1 Aug 2012 00:41:45 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 1 Aug 2012 00:41:45 -0400    

Thom Brown  

commit   : 3786b9b4668743b99e837fe276e14be1f1bdfde9    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 31 Jul 2012 17:56:27 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 31 Jul 2012 17:56:27 -0400    

Parse analysis neglected to cover the case of a WITH clause attached to an  
intermediate-level set operation; it only handled WITH at the top level  
or WITH attached to a leaf-level SELECT.  Per report from Adam Mackler.  
  
In HEAD, I rearranged the order of SelectStmt's fields to put withClause  
with the other fields that can appear on non-leaf SelectStmts.  In back  
branches, leave it alone to avoid a possible ABI break for third-party  
code.  
  
Back-patch to 8.4 where WITH support was added.  

commit   : 63aba79c7f1f06422b22e2b44fdcb563bbc3f7a5    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 31 Jul 2012 14:36:58 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 31 Jul 2012 14:36:58 -0400    

In the original coding of the log rotation stuff, we did not bother to make  
the truncation logic work for the very first rotation after postmaster  
start (or after a syslogger crash and restart).  It just always appended  
in that case.  It did not seem terribly important at the time, but we've  
recently had two separate complaints from people who expected it to work  
unsurprisingly.  (Both users tend to restart the postmaster about as often  
as a log rotation is configured to happen, which is maybe not typical use,  
but still...)  Since the initial log file is opened in the postmaster,  
fixing this requires passing down some more state to the syslogger child  
process.  
  
It's always been like this, so back-patch to all supported branches.  

commit   : 65f33352494cccf70ab512c5c6d1637b31a13364    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 31 Jul 2012 10:09:16 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 31 Jul 2012 10:09:16 -0400    

The most user-visible part of this is to change the long options  
--statusint and --noloop to --status-interval and --no-loop,  
respectively, per discussion.  
  
Also, consistently enclose file names in double quotes, per our  
conventions; and consistently use the term "transaction log file" to  
talk about WAL segments.  (Someday we may need to go over this  
terminology and make it consistent across the whole source code.)  
  
Finally, reflow the code to better fit in 80 columns, and have pgindent  
fix it up some more.  

commit   : 776bdc4c5c019a9556a6622a01a406c6c0fec4c9    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 31 Jul 2012 09:00:23 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 31 Jul 2012 09:00:23 -0400    

When the internal loop mode was added, freeing memory and closing  
filedescriptors before returning became important, and a few cases  
in the code missed that.  
  
This is a backpatch of commit 058a050e to the 9.2 branch, which seems to  
have been neglected (in error, because the bugs it fixes were introduced  
in commit 16282ae6 which is present in both master and 9.2).  
  
Fujii Masao  

commit   : 99dd2a390f8b0129092fe62a303b0cd1df547691    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 30 Jul 2012 10:15:57 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 30 Jul 2012 10:15:57 -0400    

Backpatch from 9.0 to current.  

commit   : 62d69045dd1c41bbcd8a7f78c7a4170e8381ca76    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 27 Jul 2012 19:31:19 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 27 Jul 2012 19:31:19 -0400    

This function suppressed any stderr output from the called program, which  
is unnecessary in the normal case and unhelpful in error cases.  It also  
gave a rather opaque message along the lines of "fgets failure: Success"  
in case the called program failed to return anything on stdout.  Since  
we've seen multiple reports of people not understanding what's wrong when  
pg_ctl reports this, improve the message.  
  
Back-patch to all active branches.  

commit   : 9ebe82bd48e63081382641027dd0f16b00bca25f    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Thu, 26 Jul 2012 21:25:26 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Thu, 26 Jul 2012 21:25:26 -0400    

Patch to 9.0 and later, where script is mentioned.  

commit   : 54e3c4af2340bcfbd203e60c05b5e2bb9ad1108d    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Thu, 26 Jul 2012 14:30:07 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Thu, 26 Jul 2012 14:30:07 -0400    

Backpatch to 9.2.  

commit   : 07399f447a6d8851c0b067d691394adf7dcca56c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 26 Jul 2012 14:29:32 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 26 Jul 2012 14:29:32 -0400    

In the original coding of the autovacuum cancel feature, commit  
acac68b2bcae818bc8803b8cb8cbb17eee8d5e2b, an autovacuum process was  
considered a target for cancellation if it was found to hard-block any  
process examined in the deadlock search.  This patch tightens the test so  
that the autovacuum must directly hard-block the current process.  This  
should make the behavior more predictable in general, and in particular  
it ensures that an autovacuum will not be canceled with less than  
deadlock_timeout grace period.  In the old coding, it was possible for an  
autovacuum to be canceled almost instantly, given unfortunate timing of two  
or more other processes' lock attempts.  
  
This also justifies the logging methodology in the recent commit  
d7318d43d891bd63e82dcfc27948113ed7b1db80; without this restriction, that  
patch isn't providing enough information to see the connection of the  
canceling process to the autovacuum.  Like that one, patch all the way  
back.  

commit   : a5bca2487244e48de1ece92d4c6a1ff330d5333c    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Thu, 26 Jul 2012 09:18:32 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Thu, 26 Jul 2012 09:18:32 -0400    

The old message was at DEBUG2, so typically it didn't show up in the  
log at all.  As a result, in most cases where autovacuum was canceled,  
the only information that was logged was the table being vacuumed,  
with no indication as to what problem caused the cancel.  Crank up  
the level to LOG and add some more details to assist with debugging.  
  
Back-patch all the way, per discussion on pgsql-hackers.  

commit   : ba98239dcacb276929e5447473dcaa713e643913    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Thu, 26 Jul 2012 06:22:06 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Thu, 26 Jul 2012 06:22:06 -0400    

Backpatch to 9.2.  

commit   : a4a7eb37d4c067f3d8d76338cda1bb33722e50ec    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 25 Jul 2012 17:40:43 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 25 Jul 2012 17:40:43 -0400    

If a crash occurred immediately after the first nextval() call for a serial  
column, WAL replay would restore the sequence to a state in which it  
appeared that no nextval() had been done, thus allowing the first sequence  
value to be returned again by the next nextval() call; as reported in  
bug #6748 from Xiangming Mei.  
  
More generally, the problem would occur if an ALTER SEQUENCE was executed  
on a freshly created or reset sequence.  (The manifestation with serial  
columns was introduced in 8.2 when we added an ALTER SEQUENCE OWNED BY step  
to serial column creation.)  The cause is that sequence creation attempted  
to save one WAL entry by writing out a WAL record that made it appear that  
the first nextval() had already happened (viz, with is_called = true),  
while marking the sequence's in-database state with log_cnt = 1 to show  
that the first nextval() need not emit a WAL record.  However, ALTER  
SEQUENCE would emit a new WAL entry reflecting the actual in-database state  
(with is_called = false).  Then, nextval would allocate the first sequence  
value and set is_called = true, but it would trust the log_cnt value and  
not emit any WAL record.  A crash at this point would thus restore the  
sequence to its post-ALTER state, causing the next nextval() call to return  
the first sequence value again.  
  
To fix, get rid of the idea of logging an is_called status different from  
reality.  This means that the first nextval-driven WAL record will happen  
at the first nextval call not the second, but the marginal cost of that is  
pretty negligible.  In addition, make sure that ALTER SEQUENCE resets  
log_cnt to zero in any case where it touches sequence parameters that  
affect future nextval results.  This will result in some user-visible  
changes in the contents of a sequence's log_cnt column, as reflected in the  
patch's regression test changes; but no application should be depending on  
that anyway, since it was already true that log_cnt changes rather  
unpredictably depending on checkpoint timing.  
  
In addition, make some basically-cosmetic improvements to get rid of  
sequence.c's undesirable intimacy with page layout details.  It was always  
really trying to WAL-log the contents of the sequence tuple, so we should  
have it do that directly using a HeapTuple's t_data and t_len, rather than  
backing into it with some magic assumptions about where the tuple would be  
on the sequence's page.  
  
Back-patch to all supported branches.  

commit   : 7332aa6c79f857248fb74dc8f982bf4562dfc194    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 25 Jul 2012 22:00:00 +0300    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 25 Jul 2012 22:00:00 +0300    

commit   : 408e82c23479dec38f0ea3f32c24090a9d9aea89    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 25 Jul 2012 00:02:49 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 25 Jul 2012 00:02:49 -0400    

commit   : 68043258ac54b09565e9bebadb16214d9b6df933    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 24 Jul 2012 15:49:54 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 24 Jul 2012 15:49:54 -0400    

The initially implemented syntax, "CHECK NO INHERIT (expr)" was not  
deemed very good, so switch to "CHECK (expr) NO INHERIT" instead.  This  
way it looks similar to SQL-standards compliant constraint attribute.  
  
Backport to 9.2 where the new syntax and feature was introduced.  
  
Per discussion.  

commit   : d86fb72c5c7ebf71e238ac87daa0c1f8043a1717    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 22 Jul 2012 00:01:26 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 22 Jul 2012 00:01:26 -0400    

Commit f5bcd398addcbeb785f0513cf28cba5d1ecd2c8a introduced a test using  
a table named "circles" in inherit.sql.  Unfortunately, the concurrently  
executed constraints test was already using that table name, so the  
parallel regression tests would sometimes fail.  Rename table to dodge  
the problem.  Per buildfarm.  

commit   : 641054ad7882a701cf3ac4c5666f6ee59103d3a7    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 21 Jul 2012 17:45:15 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 21 Jul 2012 17:45:15 -0400    

We made use of the ROWS estimate for set-returning functions used in FROM,  
but not for those used in SELECT targetlists; which is a bit of an  
oversight considering there are common usages that require the latter  
approach.  Improve that.  (I had initially thought it might be worth  
folding this into cost_qual_eval, but after investigation concluded that  
that wouldn't be very helpful, so just do it separately.)  Per complaint  
from David Johnston.  
  
Back-patch to 9.2, but not further, for fear of destabilizing plan choices  
in existing releases.  

commit   : c6c6f2192dfd7d4e77bd00b698feef284ddabfaa    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 20 Jul 2012 16:28:24 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 20 Jul 2012 16:28:24 -0400    

commit   : a8f0f98f9b9332f6dcd5bcbc0491de4410868622    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 20 Jul 2012 16:02:51 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 20 Jul 2012 16:02:51 -0400    

There is no point in running this test when prepared transactions are disabled,  
which is the default. New make targets that include the test are provided. This  
will save some useless waste of cycles on buildfarm machines.  
  
Backpatch to 9.1 where these tests were introduced.  

commit   : 1247ebffba13478184b0f09dfb7c474ff2ae1475    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 20 Jul 2012 22:34:11 +0300    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 20 Jul 2012 22:34:11 +0300    

mkdir() can check for errors itself.  We don't need to code that  
ourselves again.  

commit   : d721f208afeac72a943dc88d072ff3df05f53fef    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 20 Jul 2012 12:33:34 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 20 Jul 2012 12:33:34 -0400    

The code was setting it true for other constraints, which is  
bogus.  Doing so caused bogus catalog entries for such constraints, and  
in particular caused an error to be raised when trying to drop a  
constraint of types other than CHECK from a table that has children,  
such as reported in bug #6712.  
  
In 9.2, additionally ignore connoinherit=true for other constraint  
types, to avoid having to force initdb; existing databases might already  
contain bogus catalog entries.  
  
Includes a catversion bump (in HEAD only).  
  
Bug report from Miroslav Šulc  
Analysis from Amit Kapila and Noah Misch; Amit also contributed the patch.  

commit   : d7991a13d86e2b94b0ca3d087fdad8a840ebf025    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 20 Jul 2012 13:09:10 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 20 Jul 2012 13:09:10 -0400    

When a whole-row Var is reading the result of a subquery, we need it to  
ignore any "resjunk" columns that the subquery might have evaluated for  
GROUP BY or ORDER BY purposes.  We've hacked this area before, in commit  
68e40998d058c1f6662800a648ff1e1ce5d99cba, but that fix only covered  
whole-row Vars of named composite types, not those of RECORD type; and it  
was mighty klugy anyway, since it just assumed without checking that any  
extra columns in the result must be resjunk.  A proper fix requires getting  
hold of the subquery's targetlist so we can actually see which columns are  
resjunk (whereupon we can use a JunkFilter to get rid of them).  So bite  
the bullet and add some infrastructure to make that possible.  
  
Per report from Andrew Dunstan and additional testing by Merlin Moncure.  
Back-patch to all supported branches.  In 8.3, also back-patch commit  
292176a118da6979e5d368a4baf27f26896c99a5, which for some reason I had  
not done at the time, but it's a prerequisite for this change.  

commit   : e3981da37a2f071951e54d74d45ad47733cc74a6    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 19 Jul 2012 19:28:27 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 19 Jul 2012 19:28:27 -0400    

Instead of having one hash table entry per relation/fork/segment, just have  
one per relation, and use bitmapsets to represent which specific segments  
need to be fsync'd.  This eliminates the need to scan the whole hash table  
to implement FORGET_RELATION_FSYNC, which fixes the O(N^2) behavior  
recently demonstrated by Jeff Janes for cases involving lots of TRUNCATE or  
DROP TABLE operations during a single checkpoint cycle.  Per an idea from  
Robert Haas.  
  
(FORGET_DATABASE_FSYNC still sucks, but since dropping a database is a  
pretty expensive operation anyway, we'll live with that.)  
  
In passing, improve the delayed-unlink code: remove the pass over the list  
in mdpreckpt, since it wasn't doing anything for us except supporting a  
useless Assert in mdpostckpt, and fix mdpostckpt so that it will absorb  
fsync requests every so often when clearing a large backlog of deletion  
requests.  

commit   : 2bc30516c728fddf791ec508056a9c92c65025af    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 19 Jul 2012 13:07:41 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 19 Jul 2012 13:07:41 -0400    

We were sending one per fork, but a little bit of refactoring allows us  
to send just one request with forknum == InvalidForkNumber.  This not only  
reduces pressure on the shared-memory request queue, but saves repeated  
traversals of the checkpointer's hash table.  

commit   : 79c49131fa59069c70bda107c082199e9f8bd880    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 18 Jul 2012 22:34:06 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 18 Jul 2012 22:34:06 +0300    

Functions like range_eq, range_before etc. are exposed at the SQL-level, but  
they're also used internally by the GiST consistent support function. The  
code sharing was done by a hack, TrickFunctionCall2, which relied on the  
knowledge that all the functions used fn_extra the same way. This commit  
splits the functions into internal versions that take a TypeCacheEntry as  
argument, and thin wrappers to expose the functions at the SQL-level. The  
internal versions can then be called directly and in a less hacky way from  
the GiST consistent function.  
  
This is just cosmetic, but backpatch to 9.2 anyway, to avoid having a  
different version of this code in the 9.2 branch. That would make  
backpatching fixes in this area more difficult.  
  
Alexander Korotkov  

commit   : 1e9326d6a3efcb5648a85c1653cc263bc787efa0    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 18 Jul 2012 15:40:35 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 18 Jul 2012 15:40:35 -0400    

ForwardFsyncRequest() supposed that it could only be called in regular  
backends, which used to be true; but since the splitup of bgwriter and  
checkpointer, it is also called in the bgwriter.  We do not want to count  
such calls in pg_stat_bgwriter.buffers_backend statistics, so fix things  
so that they aren't.  
  
(It's worth noting here that this implies an alarmingly large increase in  
the expected amount of cross-process fsync request traffic, which may well  
mean that the process splitup was not such a hot idea.)  

commit   : d843589e5ab361dd4738dab5c9016e704faf4153    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 18 Jul 2012 15:28:17 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 18 Jul 2012 15:28:17 -0400    

mdinit() was misusing IsBootstrapProcessingMode() to decide whether to  
create an fsync pending-operations table in the current process.  This led  
to creating a table not only in the startup and checkpointer processes as  
intended, but also in the bgwriter process, not to mention other auxiliary  
processes such as walwriter and walreceiver.  Creation of the table in the  
bgwriter is fatal, because it absorbs fsync requests that should have gone  
to the checkpointer; instead they just sit in bgwriter local memory and are  
never acted on.  So writes performed by the bgwriter were not being fsync'd  
which could result in data loss after an OS crash.  I think there is no  
live bug with respect to walwriter and walreceiver because those never  
perform any writes of shared buffers; but the potential is there for  
future breakage in those processes too.  
  
To fix, make AuxiliaryProcessMain() export the current process's  
AuxProcType as a global variable, and then make mdinit() test directly for  
the types of aux process that should have a pendingOpsTable.  Having done  
that, we might as well also get rid of the random bool flags such as  
am_walreceiver that some of the aux processes had grown.  (Note that we  
could not have fixed the bug by examining those variables in mdinit(),  
because it's called from BaseInit() which is run by AuxiliaryProcessMain()  
before entering any of the process-type-specific code.)  
  
Back-patch to 9.2, where the problem was introduced by the split-up of  
bgwriter and checkpointer processes.  The bogus pendingOpsTable exists  
in walwriter and walreceiver processes in earlier branches, but absent  
any evidence that it causes actual problems there, I'll leave the older  
branches alone.  

commit   : ebd9e26daa3df6518e3d403ef94a86e33168eae3    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 18 Jul 2012 01:23:16 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 18 Jul 2012 01:23:16 -0400    

Since the scandir() emulation was taken out of pg_upgrade, there's  
no longer any need for scandir_file_pattern to exist as a global  
variable.  Replace it with a local in the one remaining function  
that was making use of it.  

commit   : 3d929dc7b8e982f12c62fecba7d5122bb22fa497    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 18 Jul 2012 01:13:25 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 18 Jul 2012 01:13:25 -0400    

Error out on out-of-memory, rather than returning -1, which the sole  
existing caller wasn't checking for anyway.  There doesn't seem to be  
any use-case for making the caller check for failure here.  
  
Detect failure return from readdir().  
  
Use a less platform-dependent method of calculating the entrysize.  
It's possible, but not yet confirmed, that this explains bug #6733,  
in which Mike Wilson reports a pg_upgrade crash that did not occur  
in 9.1.  (Note that load_directory is effectively new code in 9.2,  
at least on platforms that have scandir().)  
  
Fix up comments, avoid uselessly using two counters, reduce the number  
of realloc calls to something sane.  

commit   : 4abcce8cabe3845140f9a7cd8470e27e44f208bb    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 17 Jul 2012 16:55:44 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 17 Jul 2012 16:55:44 -0400    

In all branches back to 8.3, this patch fixes a questionable assumption in  
CompactCheckpointerRequestQueue/CompactBgwriterRequestQueue that there are  
no uninitialized pad bytes in the request queue structs.  This would only  
cause trouble if (a) there were such pad bytes, which could happen in 8.4  
and up if the compiler makes enum ForkNumber narrower than 32 bits, but  
otherwise would require not-currently-planned changes in the widths of  
other typedefs; and (b) the kernel has not uniformly initialized the  
contents of shared memory to zeroes.  Still, it seems a tad risky, and we  
can easily remove any risk by pre-zeroing the request array for ourselves.  
In addition to that, we need to establish a coding rule that struct  
RelFileNode can't contain any padding bytes, since such structs are copied  
into the request array verbatim.  (There are other places that are assuming  
this anyway, it turns out.)  
  
In 9.1 and up, the risk was a bit larger because we were also effectively  
assuming that struct RelFileNodeBackend contained no pad bytes, and with  
fields of different types in there, that would be much easier to break.  
However, there is no good reason to ever transmit fsync or delete requests  
for temp files to the bgwriter/checkpointer, so we can revert the request  
structs to plain RelFileNode, getting rid of the padding risk and saving  
some marginal number of bytes and cycles in fsync queue manipulation while  
we are at it.  The savings might be more than marginal during deletion of  
a temp relation, because the old code transmitted an entirely useless but  
nonetheless expensive-to-process ForgetRelationFsync request to the  
background process, and also had the background process perform the file  
deletion even though that can safely be done immediately.  
  
In addition, make some cleanup of nearby comments and small improvements to  
the code in CompactCheckpointerRequestQueue/CompactBgwriterRequestQueue.  

commit   : 3d03c97a45b6904704e1ed2a4856a55396cb23b0    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 17 Jul 2012 21:34:22 +0300    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 17 Jul 2012 21:34:22 +0300    

The upstream XSLT stylesheets missed that case.  
  
found by Álvaro Herrera  

commit   : 82b7faa3b207193dc98d9dd5a5c8b64710ebc1a4    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 17 Jul 2012 12:31:48 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 17 Jul 2012 12:31:48 -0400    

These only pass cleanly on UTF8 and SQL_ASCII encodings, besides the  
Japanese encoding in which they were originally written, which is clearly  
not good enough.  Since the functionality they test has not ever been  
tested from PL/Perl, the best answer seems to be to remove the new tests  
completely.  
  
Per buildfarm results and ensuing discussion.  

commit   : 3727240d01c4e7980ff9fe754e6524636edeaea7    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 16 Jul 2012 13:25:26 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 16 Jul 2012 13:25:26 -0400    

Formerly, when trying to copy both indexes and comments, CREATE TABLE LIKE  
had to pre-assign names to indexes that had comments, because it made up an  
explicit CommentStmt command to apply the comment and so it had to know the  
name for the index.  This creates bad interactions with other indexes, as  
shown in bug #6734 from Daniele Varrazzo: the preassignment logic couldn't  
take any other indexes into account so it could choose a conflicting name.  
  
To fix, add a field to IndexStmt that allows it to carry a comment to be  
assigned to the new index.  (This isn't a user-exposed feature of CREATE  
INDEX, only an internal option.)  Now we don't need preassignment of index  
names in any situation.  
  
I also took the opportunity to refactor DefineIndex to accept the IndexStmt  
as such, rather than passing all its fields individually in a mile-long  
parameter list.  
  
Back-patch to 9.2, but no further, because it seems too dangerous to change  
IndexStmt or DefineIndex's API in released branches.  The bug exists back  
to 9.0 where CREATE TABLE LIKE grew the ability to copy comments, but given  
the lack of prior complaints we'll just let it go unfixed before 9.2.  

commit   : 1116c9d1e7a5c06636b172bb49bbe1e91edb6076    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 15 Jul 2012 13:28:01 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 15 Jul 2012 13:28:01 -0400    

rfree() failed to cope with the case that pg_regcomp() had initialized the  
regex_t struct but then failed to allocate any memory for re->re_guts (ie,  
the first malloc call in pg_regcomp() failed).  It would try to touch the  
guts struct anyway, and thus dump core.  This is a sufficiently narrow  
corner case that it's not surprising it's never been seen in the field;  
but still a bug is a bug, so patch all active branches.  
  
Noted while investigating whether we need to call pg_regfree after a  
failure return from pg_regcomp.  Other than this bug, it turns out we  
don't, so adjust comments appropriately.  

commit   : eb972f3eca22858683a6b40466f6d561262b268b    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Sat, 14 Jul 2012 13:06:09 +0300    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Sat, 14 Jul 2012 13:06:09 +0300    

commit   : 0bf8eb2a15875bc3f4d5638da73cb34ee9ca868e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 12 Jul 2012 14:29:58 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 12 Jul 2012 14:29:58 -0400    

Walsenders must have working SIGALRM handling during InitPostgres,  
but they set the handler to SIG_IGN so that nothing would happen  
if a timeout was reached.  This could result in two failure modes:  
  
* If a walsender participated in a deadlock during its authentication  
transaction, and was the last to wait in the deadly embrace, the deadlock  
would not get cleared automatically.  This would require somebody to be  
trying to take out AccessExclusiveLock on multiple system catalogs, so  
it's not very probable.  
  
* If a client failed to respond to a walsender's authentication challenge,  
the intended disconnect after AuthenticationTimeout wouldn't happen, and  
the walsender would wait indefinitely for the client.  
  
For the moment, fix in back branches only, since this is fixed in a  
different way in the timeout-infrastructure patch that's awaiting  
application to HEAD.  If we choose not to apply that, then we'll need  
to do this in HEAD as well.  

commit   : 4810ebe1037e5d9847a0e0ee4ec2fae026ef55f6    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 10 Jul 2012 23:08:19 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 10 Jul 2012 23:08:19 -0400    

Backpatch to 9.2.  

commit   : 18c8dc32ce6759a8837f01e3dd0036cd19ee8683    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 10 Jul 2012 18:00:39 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 10 Jul 2012 18:00:39 -0400    

Back-patch of commits 628cbb50ba80c83917b07a7609ddec12cda172d0 and  
c6aae3042be5249e672b731ebeb21875b5343010.  This has been broken since  
7.3, so back-patch to all supported branches.  

commit   : f12960d8c9ce454a37c2082549b7766ce36627d2    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 10 Jul 2012 16:52:36 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 10 Jul 2012 16:52:36 -0400    

Back-patch of commits 72dd6291f216440f6bb61a8733729a37c7e3b2d2,  
f6a05fd973a102f7e66c491d3f854864b8d24844, and  
60e9c224a197aa37abb1aa3aefa3aad42da61f7f.  
  
This is needed to support fixing the regex prefix extraction bug in  
back branches.  

commit   : 7c460f0ba745611f4dadf413daa4ed9059951f92    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 9 Jul 2012 17:36:29 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 9 Jul 2012 17:36:29 -0400    

When in SQL_ASCII encoding, strings passed around are not necessarily  
UTF8-safe.  We had already fixed this in some places, but it looks like  
we missed some.  
  
I had to backpatch Peter Eisentraut's a8b92b60 to 9.1 in order for this  
patch to cherry-pick more cleanly.  
  
Patch from Alex Hunsaker, tweaked by Kyotaro HORIGUCHI and myself.  
  
Some desultory cleanup and comment addition by me, during patch review.  
  
Per bug report from Christoph Berg in  
20120209102116.GA14429@msgid.df7cb.de  

commit   : 8fc7b07b64d4f14b1738ce725f23f4903fce18f7    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Jul 2012 23:23:02 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Jul 2012 23:23:02 -0400    

Previously, pattern_fixed_prefix() was defined to return whatever fixed  
prefix it could extract from the pattern, plus the "rest" of the pattern.  
That definition was sensible for LIKE patterns, but not so much for  
regexes, where reconstituting a valid pattern minus the prefix could be  
quite tricky (certainly the existing code wasn't doing that correctly).  
Since the only thing that callers ever did with the "rest" of the pattern  
was to pass it to like_selectivity() or regex_selectivity(), let's cut out  
the middle-man and just have pattern_fixed_prefix's subroutines do this  
directly.  Then pattern_fixed_prefix can return a simple selectivity  
number, and the question of how to cope with partial patterns is removed  
from its API specification.  
  
While at it, adjust the API spec so that callers who don't actually care  
about the pattern's selectivity (which is a lot of them) can pass NULL for  
the selectivity pointer to skip doing the work of computing a selectivity  
estimate.  
  
This patch is only an API refactoring that doesn't actually change any  
processing, other than allowing a little bit of useless work to be skipped.  
However, it's necessary infrastructure for my upcoming fix to regex prefix  
extraction, because after that change there won't be any simple way to  
identify the "rest" of the regex, not even to the low level of fidelity  
needed by regex_selectivity.  We can cope with that if regex_fixed_prefix  
and regex_selectivity communicate directly, but not if we have to work  
within the old API.  Hence, back-patch to all active branches.  

commit   : eb1b48816ba4e8f8e37bd25cd6e760034c0078fe    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 8 Jul 2012 23:51:13 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 8 Jul 2012 23:51:13 -0400    

We can do this without creating an API break for estimation functions  
by passing the collation using the existing fmgr functionality for  
passing an input collation as a hidden parameter.  
  
The need for this was foreseen at the outset, but we didn't get around to  
making it happen in 9.1 because of the decision to sort all pg_statistic  
histograms according to the database's default collation.  That meant that  
selectivity estimators generally need to use the default collation too,  
even if they're estimating for an operator that will do something  
different.  The reason it's suddenly become more interesting is that  
regexp interpretation also uses a collation (for its LC_TYPE not LC_COLLATE  
property), and we no longer want to use the wrong collation when examining  
regexps during planning.  It's not that the selectivity estimate is likely  
to change much from this; rather that we are thinking of caching compiled  
regexps during planner estimation, and we won't get the intended benefit  
if we cache them with a different collation than the executor will use.  
  
Back-patch to 9.1, both because the regexp change is likely to get  
back-patched and because we might as well get this right in all  
collation-supporting branches, in case any third-party code wants to  
rely on getting the collation.  The patch turns out to be minuscule  
now that I've done it ...  

commit   : 3295387b1a63646736dae6bc1bb51293cdaf0309    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 6 Jul 2012 16:23:30 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 6 Jul 2012 16:23:30 -0400    

Commit 2b443063 changed wording for some of the error messages, but  
neglected updating the regress output to match.  

commit   : 81aa2a5d1ca84fd56d17bb3dfd36ae1faaa666d5    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Fri, 6 Jul 2012 12:28:18 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Fri, 6 Jul 2012 12:28:18 -0400    

Backpatch to 9.2.  

commit   : c99882a2857daab32b402a815ab8df4870f7e79e    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Fri, 6 Jul 2012 12:21:43 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Fri, 6 Jul 2012 12:21:43 -0400    

Backpatch to 9.2.  

commit   : efd07bd1364267c7e223d9e8bdcad1a201809ed8    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Fri, 6 Jul 2012 11:58:55 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Fri, 6 Jul 2012 11:58:55 -0400    

Backpatch to 9.2.  

commit   : 59076b2c7651c1c5f2f61d4af0e33403ccacf1df    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Fri, 6 Jul 2012 11:43:59 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Fri, 6 Jul 2012 11:43:59 -0400    

commit   : 06850473fb7f8ef0b8be31ec4602fcc161ad0b36    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Fri, 6 Jul 2012 10:57:08 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Fri, 6 Jul 2012 10:57:08 -0400    

Backpatch to 9.2.  

commit   : 75d5e54f78e9a230855e018b2b38a22a65341511    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Fri, 6 Jul 2012 09:39:21 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Fri, 6 Jul 2012 09:39:21 -0400    

commit   : 11da73ad9e2ab9b70fbc245f1830058c08cc2a60    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Thu, 5 Jul 2012 23:36:30 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Thu, 5 Jul 2012 23:36:30 -0400    

Backpatch to 9.2.  

commit   : f882084dea25a64769006e7c991723a4bdcf9a6b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 5 Jul 2012 17:15:11 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 5 Jul 2012 17:15:11 -0400    

join_path_components() tried to remove leading ".." components from its  
tail argument, but it was not nearly bright enough to do so correctly  
unless the head argument was (a) absolute and (b) canonicalized.  
Rather than try to fix that logic, let's just get rid of it: there is no  
correctness reason to remove "..", and cosmetic concerns can be taken  
care of by a subsequent canonicalize_path() call.  Per bug #6715 from  
Greg Davidson.  
  
Back-patch to all supported branches.  It appears that pre-9.2, this  
function is only used with absolute paths as head arguments, which is why  
we'd not noticed the breakage before.  However, third-party code might be  
expecting this function to work in more general cases, so it seems wise  
to back-patch.  
  
In HEAD and 9.2, also make some minor cosmetic improvements to callers.  

commit   : 7c58a5f246dfab299e6c73c5ed9b04e7dc8d1745    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 5 Jul 2012 23:40:25 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 5 Jul 2012 23:40:25 +0300    

That caused the plpython_unicode regression test to fail on SQL_ASCII  
encoding, as evidenced by the buildfarm. The reason is that with the patch,  
you don't get the detail in the error message that you got before. That  
detail is actually very informative, so rather than just adjust the expected  
output, let's revert that part of the patch for now to make the buildfarm  
green again, and figure out some other way to avoid the recursion of  
PLy_elog() that doesn't lose the detail.  

commit   : 773288016d00bd72e8e2bcb5b1eec67abb2d9e00    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 5 Jul 2012 21:45:24 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 5 Jul 2012 21:45:24 +0300    

Windows encodings, "win1252" and so forth, are named differently in Python,  
like "cp1252". Also, if the PyUnicode_AsEncodedString() function call fails  
for some reason, use a plain ereport(), not a PLy_elog(), to report that  
error. That avoids recursion and crash, if PLy_elog() tries to call  
PLyUnicode_Bytes() again.  
  
This fixes bug reported by Asif Naeem. Backpatch down to 9.0, before that  
plpython didn't even try these conversions.  
  
Jan Urbański, with minor comment improvements by me.  

commit   : 071589cb3f6b4e259d3b87f228fd1c69b8189037    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 4 Jul 2012 21:58:48 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 4 Jul 2012 21:58:48 -0400    

Backpatch to 9.2.  

commit   : 2bc09ff4994fbeecef9601b8654f3f94b55bc81a    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 4 Jul 2012 21:47:48 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 4 Jul 2012 21:47:48 -0400    

Run on HEAD and 9.2.  

commit   : 9c6f8be2b14c170b589fdbd48e3db42c45efb2cc    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 4 Jul 2012 17:36:50 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 4 Jul 2012 17:36:50 -0400    

Backpatch to 9.2.  

commit   : d3341d4121305fe1b6d666471d4cf040bb103083    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Wed, 4 Jul 2012 15:13:09 +0200    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Wed, 4 Jul 2012 15:13:09 +0200    

This makes it possible for the master to track how much data has  
actually been written my pg_receivexlog - and not just how much  
has been sent towards it.  

commit   : 8c8adf4aa43d6c0da2243aea65d3dc508c79a933    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Wed, 4 Jul 2012 15:10:46 +0200    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Wed, 4 Jul 2012 15:10:46 +0200    

This ensures that a standby such as pg_receivexlog will not be selected  
as sync standby - which would cause the master to block waiting for  
a location that could never happen.  
  
Fujii Masao  

commit   : 5c5d54870f5ea7d9254e46a2497f6fa6f2309517    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Wed, 4 Jul 2012 09:22:21 +0200    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Wed, 4 Jul 2012 09:22:21 +0200    

This hasn't been true since 9.1, when the default was changed to -1.  
Remove the reference completely, keeping the discussion of the parameter  
and it's shared memory effects on the config page.  

commit   : a963e06c0c046a3408c4c11e794d39b2a9046ab4    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Wed, 4 Jul 2012 08:58:31 +0200    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Wed, 4 Jul 2012 08:58:31 +0200    

Also remove special references to downloads off pgfoundry since they are  
not correct - downloads are done through the main website.  

commit   : ed4cd4b6644cfc9e0d952b85449f04437d0387e8    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Wed, 4 Jul 2012 09:06:02 +0200    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Wed, 4 Jul 2012 09:06:02 +0200    

gabrielle  

commit   : 5f2fa7f5616fac9ca5570d033e2b66ed5c8da595    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Wed, 4 Jul 2012 08:59:35 +0200    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Wed, 4 Jul 2012 08:59:35 +0200    

pgfoundry is deprectaed and no longer accepting new projects,  
so we really shouldn't be directing people there.  

commit   : c602b42982537409c9120ec38158878e238b3594    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 3 Jul 2012 16:40:15 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 3 Jul 2012 16:40:15 -0400    

commit   : 6416895cc6b95636138338da7854fc1b27930726    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 3 Jul 2012 15:18:40 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 3 Jul 2012 15:18:40 -0400    

Per bug #6593, REASSIGN OWNED fails when the affected role has created  
an extension.  Even though the user related to the extension is not  
nominally the owner, its OID appears on pg_shdepend and thus causes  
problems when the user is to be dropped.  
  
This commit adds code to change the "ownership" of the extension itself,  
not of the contained objects.  This is fine because it's currently only  
called from REASSIGN OWNED, which would also modify the ownership of the  
contained objects.  However, this is not sufficient for a working ALTER  
OWNER implementation extension.  
  
Back-patch to 9.1, where extensions were introduced.  
  
Bug #6593 reported by Emiliano Leporati.  

commit   : 5e59e6a6483ea9ec8149f3ca2a37959115216852    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 2 Jul 2012 21:12:46 +0300    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 2 Jul 2012 21:12:46 +0300    

commit   : 2a15249956b741afafb9f7b581a752bd236db40c    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 2 Jul 2012 21:02:05 +0300    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 2 Jul 2012 21:02:05 +0300    

This has apparently been wrong since event_source was added.  
  
Alexander Lakhin  

commit   : 8400d313290d293c02eb1bc4eb4422de3077aa34    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 2 Jul 2012 11:35:24 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 2 Jul 2012 11:35:24 -0400    

A thinko in commit 029dfdf1157b6d837a7b7211cd35b00c6bcd767c caused the year  
519 to be handled differently from either adjacent year, which was not the  
intention AFAICS.  Report and diagnosis by Marc Cousin.  
  
In passing, remove redundant re-tests of year value.  

commit   : 972e066638dff29cf9288fed8f983a43ec942e77    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 1 Jul 2012 17:12:54 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 1 Jul 2012 17:12:54 -0400    

When (re) loading the typcache comparison cache for an enum type's values,  
use an up-to-date MVCC snapshot, not the transaction's existing snapshot.  
This avoids problems if we encounter an enum OID that was created since our  
transaction started.  Per report from Andres Freund and diagnosis by Robert  
Haas.  
  
To ensure this is safe even if enum comparison manages to get invoked  
before we've set a transaction snapshot, tweak GetLatestSnapshot to  
redirect to GetTransactionSnapshot instead of throwing error when  
FirstSnapshotSet is false.  The existing uses of GetLatestSnapshot (in  
ri_triggers.c) don't care since they couldn't be invoked except in a  
transaction that's already done some work --- but it seems just conceivable  
that this might not be true of enums, especially if we ever choose to use  
enums in system catalogs.  
  
Note that the comparable coding in enum_endpoint and enum_range_internal  
remains GetTransactionSnapshot; this is perhaps debatable, but if we  
changed it those functions would have to be marked volatile, which doesn't  
seem attractive.  
  
Back-patch to 9.1 where ALTER TYPE ADD VALUE was added.  

commit   : 4f1e0e402018c92030f33f2b48974c3a8ab212d1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 30 Jun 2012 17:29:45 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 30 Jun 2012 17:29:45 -0400    

Solaris Studio warns about this, and some compilers might think it's an  
outright syntax error.  

commit   : 52336a47024e8212be619fcfe28d384777ed7b72    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 30 Jun 2012 16:43:58 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 30 Jun 2012 16:43:58 -0400    

If a CHECK constraint or index definition contained a whole-row Var (that  
is, "table.*"), an attempt to copy that definition via CREATE TABLE LIKE or  
table inheritance produced incorrect results: the copied Var still claimed  
to have the rowtype of the source table, rather than the created table.  
  
For the LIKE case, it seems reasonable to just throw error for this  
situation, since the point of LIKE is that the new table is not permanently  
coupled to the old, so there's no reason to assume its rowtype will stay  
compatible.  In the inheritance case, we should ideally allow such  
constraints, but doing so will require nontrivial refactoring of CREATE  
TABLE processing (because we'd need to know the OID of the new table's  
rowtype before we adjust inherited CHECK constraints).  In view of the lack  
of previous complaints, that doesn't seem worth the risk in a back-patched  
bug fix, so just make it throw error for the inheritance case as well.  
  
Along the way, replace change_varattnos_of_a_node() with a more robust  
function map_variable_attnos(), which is capable of being extended to  
handle insertion of ConvertRowtypeExpr whenever we get around to fixing  
the inheritance case nicely, and in the meantime it returns a failure  
indication to the caller so that a helpful message with some context can be  
thrown.  Also, this code will do the right thing with subselects (if we  
ever allow them in CHECK or indexes), and it range-checks varattnos before  
using them to index into the map array.  
  
Per report from Sergey Konoplev.  Back-patch to all supported branches.  

commit   : 31fff64ef522abeda9c26c0be7ffee32d27a1b3c    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Sat, 30 Jun 2012 15:39:16 +0300    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Sat, 30 Jun 2012 15:39:16 +0300    

Change things so that something like initdb --auth-local=peer  
--auth-host=md5 does not cause a "must specify a password" error,  
like initdb -A md5 does.  

commit   : 214fa27e9296fa74955a0682a8bea4d6d42c4b13    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 29 Jun 2012 19:19:29 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 29 Jun 2012 19:19:29 +0300    

This bug was introduced by commit 20d98ab6e4110087d1816cd105a40fcc8ce0a307,  
so backpatch this to 9.0-9.2 like that one.  
  
This fixes bug #6710, reported by Tarvi Pillessaar  

commit   : 90c85e473bd807171b5b5da4032bbf9c0abe1103    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 28 Jun 2012 23:27:00 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 28 Jun 2012 23:27:00 -0400    

Now the log file not only contains the output from commands executed by  
system(), but also what command it was in the first place.  This  
arrangement makes debugging a lot simpler.  

commit   : fe9912270dfe06cdce4d20bfdd3685b3cb8f23fb    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 18 Jun 2012 16:37:49 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 18 Jun 2012 16:37:49 -0400    

In passing, reword another instance of the same message that was  
gratuitously different.  
  
Author: Josh Kupershmidt  
after a bug report by Bosco Rama  

commit   : f374098e8c5f58b95e03b923c8a808cdeeea93e7    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 29 Jun 2012 00:51:40 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 29 Jun 2012 00:51:40 -0400    

The LISTEN/NOTIFY subsystem got confused if SimpleLruZeroPage failed,  
which would typically happen as a result of a write() failure while  
attempting to dump a dirty pg_notify page out of memory.  Subsequently,  
all attempts to send more NOTIFY messages would fail with messages like  
"Could not read from file "pg_notify/nnnn" at offset nnnnn: Success".  
Only restarting the server would clear this condition.  Per reports from  
Kevin Grittner and Christoph Berg.  
  
Back-patch to 9.0, where the problem was introduced during the  
LISTEN/NOTIFY rewrite.  

commit   : c8967e38a65e4afac7027d570136ca6dac5cacc1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 27 Jun 2012 23:18:37 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 27 Jun 2012 23:18:37 -0400    

The callers of UtilityContainsQuery want it to return a non-utility Query  
if it returns anything at all.  However, since we made CREATE TABLE  
AS/SELECT INTO into a utility command instead of a variant of SELECT,  
a command like "EXPLAIN SELECT INTO" results in two nested utility  
statements.  So what we need UtilityContainsQuery to do is drill down  
to the bottom non-utility Query.  
  
I had thought of this possibility in setrefs.c, and fixed it there by  
looping around the UtilityContainsQuery call; but overlooked that the call  
sites in plancache.c have a similar issue.  In those cases it's  
notationally inconvenient to provide an external loop, so let's redefine  
UtilityContainsQuery as recursing down to a non-utility Query instead.  
  
Noted by Rushabh Lathia.  This is a somewhat cleaned-up version of his  
proposed patch.  

commit   : 5ff9ad664745b5cb2c6562ff2691b9418cd59c88    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Wed, 27 Jun 2012 08:44:50 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Wed, 27 Jun 2012 08:44:50 -0400    

commit   : eee5088e538be24f6c42e758ef27cecc2b2579f1    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Tue, 26 Jun 2012 16:16:52 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Tue, 26 Jun 2012 16:16:52 -0400    

A similar change was made previously for pg_cancel_backend, so now it  
all matches again.  
  
Dan Farina, reviewed by Fujii Masao, Noah Misch, and Jeff Davis,  
with slight kibitzing on the doc changes by me.  

commit   : 00e5844592a8c51ceee1682013b94ac50031a9ac    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 26 Jun 2012 14:36:29 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 26 Jun 2012 14:36:29 -0400    

The original coding failed miserably for BLCKSZ of 4K or less, as reported  
by Josh Kupershmidt.  With the present design for text indexes, a given  
inner tuple could have up to 256 labels (requiring either 3K or 4K bytes  
depending on MAXALIGN), which means that we can't positively guarantee no  
failures for smaller blocksizes.  But we can at least make it behave sanely  
so long as there are few enough labels to fit on a page.  Considering that  
btree is also more prone to "index tuple too large" failures when BLCKSZ is  
small, it's not clear that we should expend more work than this on this  
case.  

commit   : 2b79c6ffcfd586667c60d04b5df69695915c4ee2    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 25 Jun 2012 21:20:31 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 25 Jun 2012 21:20:31 -0400    

While pg_dump has included dependency information in archive-format output  
ever since 7.3, it never made any large effort to ensure that that  
information was actually useful.  In particular, in common situations where  
dependency chains include objects that aren't separately emitted in the  
dump, the dependencies shown for objects that were emitted would reference  
the dump IDs of these un-dumped objects, leaving no clue about which other  
objects the visible objects indirectly depend on.  So far, parallel  
pg_restore has managed to avoid tripping over this misfeature, but only  
by dint of some crude hacks like not trusting dependency information in  
the pre-data section of the archive.  
  
It seems prudent to do something about this before it rises up to bite us,  
so instead of emitting the "raw" dependencies of each dumped object,  
recursively search for its actual dependencies among the subset of objects  
that are being dumped.  
  
Back-patch to 9.2, since that code hasn't yet diverged materially from  
HEAD.  At some point we might need to back-patch further, but right now  
there are no known cases where this is actively necessary.  (The one known  
case, bug #6699, is fixed in a different way by my previous patch.)  Since  
this patch depends on 9.2 changes that made TOC entries be marked before  
output commences as to whether they'll be dumped, back-patching further  
would require additional surgery; and as of now there's no evidence that  
it's worth the risk.  

commit   : 835a251b00e8f8c66586f0308db71299ee73dc05    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 25 Jun 2012 21:19:19 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 25 Jun 2012 21:19:19 -0400    

As of 9.2, with the --section option, it is very important that the concept  
of "pre data", "data", and "post data" sections of the output be honored  
strictly; else a dump divided into separate sectional files might be  
unrestorable.  However, the dependency-sorting logic knew nothing of  
sections and would happily select output orderings that didn't fit that  
structure.  Doing so was mostly harmless before 9.2, but now we need to be  
sure it doesn't do that.  To fix, create dummy objects representing the  
section boundaries and add dependencies between them and all the normal  
objects.  (This might sound expensive but it seems to only add a percent or  
two to pg_dump's runtime.)  
  
This also fixes a problem introduced in 9.1 by the feature that allows  
incomplete GROUP BY lists when a primary key is given in GROUP BY.  
That means that views can depend on primary key constraints.  Previously,  
pg_dump would deal with that by simply emitting the primary key constraint  
before the view definition (and hence before the data section of the  
output).  That's bad enough for simple serial restores, where creating an  
index before the data is loaded works, but is undesirable for speed  
reasons.  But it could lead to outright failure of parallel restores, as  
seen in bug #6699 from Joe Van Dyk.  That happened because pg_restore would  
switch into parallel mode as soon as it reached the constraint, and then  
very possibly would try to emit the view definition before the primary key  
was committed (as a consequence of another bug that causes the view not to  
be correctly marked as depending on the constraint).  Adding the section  
boundary constraints forces the dependency-sorting code to break the view  
into separate table and rule declarations, allowing the rule, and hence the  
primary key constraint it depends on, to revert to their intended location  
in the post-data section.  This also somewhat accidentally works around the  
bogus-dependency-marking problem, because the rule will be correctly shown  
as depending on the constraint, so parallel pg_restore will now do the  
right thing.  (We will fix the bogus-dependency problem for real in a  
separate patch, but that patch is not easily back-portable to 9.1, so the  
fact that this patch is enough to dodge the only known symptom is  
fortunate.)  
  
Back-patch to 9.1, except for the hunk that adds verification that the  
finished archive TOC list is in correct section order; the place where  
it was convenient to add that doesn't exist in 9.1.  

commit   : 1178fdfb80aef3332ba9e9653e84de07dd7f029b    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 22 Jun 2012 01:06:14 +0300    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 22 Jun 2012 01:06:14 +0300    

To avoid divergent names on related pages, avoid ambiguities, and  
reduce translation work a little.  

commit   : 66567ab2c674b958ac7fec47f0c830018245e04a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 21 Jun 2012 17:26:13 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 21 Jun 2012 17:26:13 -0400    

Repeated execution of an uncorrelated ARRAY_SUBLINK sub-select (which  
I think can only happen if the sub-select is embedded in a larger,  
correlated subquery) would leak memory for the duration of the query,  
due to not reclaiming the array generated in the previous execution.  
Per bug #6698 from Armando Miraglia.  Diagnosis and fix idea by Heikki,  
patch itself by me.  
  
This has been like this all along, so back-patch to all supported versions.  

commit   : e1a1e6e19840576e563c5c92bb4cbad621e23170    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 20 Jun 2012 00:07:58 +0300    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 20 Jun 2012 00:07:58 +0300    

pointed out by Stefan Kaltenbrunner  

commit   : 2610cb3f7cb3227a520b60de37c74e1f99259c3c    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 18 Jun 2012 23:57:00 +0300    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 18 Jun 2012 23:57:00 +0300    

commit   : 03132da3b65eb44e65fe26267b73c101d6a2113a    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 18 Jun 2012 02:44:00 +0300    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 18 Jun 2012 02:44:00 +0300    

Before, some places didn't document the short options (-? and -V),  
some documented both, some documented nothing, and they were listed in  
various orders.  Now this is hopefully more consistent and complete.  

commit   : 3cdd19b0a66fc8845282d4012b0fcf3e94515e7b    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Sun, 17 Jun 2012 21:18:02 +0800    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Sun, 17 Jun 2012 21:18:02 +0800    

Since this is the easy way of doing it, it should be listed first. All  
the old information is retained for those who want the more advanced way.  
  
Also adds a subheading for compressing logs, that seems to have been missing  

commit   : a22cba0e6cd0b26124184b0c71b87d85acbd0e84    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Sat, 16 Jun 2012 10:12:50 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Sat, 16 Jun 2012 10:12:50 -0400    

Backpatch to 9.2.  
  
Per suggestion from Noah Misch  

commit   : 8f466a28da28235fe2b3e919ae8267f8eef1db64    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Fri, 15 Jun 2012 22:50:02 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Fri, 15 Jun 2012 22:50:02 -0400    

commit   : baac19bdddaf6d0b8a0e6ff693d87404b2a69832    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Fri, 15 Jun 2012 22:43:22 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Fri, 15 Jun 2012 22:43:22 -0400    

Backpatch to 9.2.