PostgreSQL 9.2.2 commit log

commit   : a20751ef44b47034e8082a14d42b876b169e8713    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 3 Dec 2012 15:16:10 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 3 Dec 2012 15:16:10 -0500    

commit   : decb3bc07e27cf476299842db0ce1c33cfb42f53    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 3 Dec 2012 15:10:05 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 3 Dec 2012 15:10:05 -0500    

commit   : 7f7b49c47acf5194a424c046bb72c8b99f600023    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 3 Dec 2012 15:02:32 -0500    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 3 Dec 2012 15:02:32 -0500    

This reverts commit 30248be9635e844918c2873ae7bb598f8a487e49.  

commit   : 17ee02ea1c87b96a4d687d3319f6f4602450d6cb    
  
author   : Simon Riggs <simon@2ndQuadrant.com>    
date     : Mon, 3 Dec 2012 18:54:52 +0000    
  
committer: Simon Riggs <simon@2ndQuadrant.com>    
date     : Mon, 3 Dec 2012 18:54:52 +0000    

Bug report and suggested fix from Pavan Deolasee  

commit   : 6a8b9987c63bc88b3a4fd56a644d250e7113dd7f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 3 Dec 2012 11:08:54 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 3 Dec 2012 11:08:54 -0500    

Obviously, this returns type "path", but somebody made a copy-and-pasteo  
long ago.  
  
Dagfinn Ilmari Mannsåker  

commit   : 562fca74a164f5edd2922edbc4f655e15ddfcc18    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 3 Dec 2012 08:00:46 -0500    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 3 Dec 2012 08:00:46 -0500    

commit   : 30248be9635e844918c2873ae7bb598f8a487e49    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Sun, 2 Dec 2012 17:28:36 -0500    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Sun, 2 Dec 2012 17:28:36 -0500    

Normally each module is tested in aq database named contrib_regression,  
which is dropped and recreated at the beginhning of each pg_regress run.  
This mode, enabled by adding USE_MODULE_DB=1 to the make command line,  
runs most modules in a database with the module name embedded in it.  
  
This will make testing pg_upgrade on clusters with the contrib modules  
a lot easier.  
  
Still to be done: adapt to the MSVC build system.  
  
Backpatch to 9.0, which is the earliest version it is reasonably  
possible to test upgrading from.  

commit   : 842cb63fd3ca3f5371406b5a1cdffb3a9ec6853a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 2 Dec 2012 16:35:23 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 2 Dec 2012 16:35:23 -0500    

DST law changes in Cuba, Israel, Jordan, Libya, Palestine, Western Samoa,  
and portions of Brazil.  

commit   : f7968554ab20e18a78f8e21bda9ff8445f81773f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 2 Dec 2012 16:17:53 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 2 Dec 2012 16:17:53 -0500    

We've generally recommended use of INSTEAD triggers over rules since that  
feature was added; but this old text in the CREATE VIEW reference page  
didn't get the memo.  Noted by Thomas Kellerer.  

commit   : aaceb0d6acce900144c147fca3d682c11c6adf0c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 2 Dec 2012 15:20:03 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 2 Dec 2012 15:20:03 -0500    

This reverts commit c11130690d6dca64267201a169cfb38c1adec5ef in favor of  
actually fixing the problem: namely, that we should never have been  
modifying the checkpoint record's nextXid at this point to begin with.  
The nextXid should match the state as of the checkpoint's logical WAL  
position (ie the redo point), not the state as of its physical position.  
It's especially bogus to advance it in some wal_levels and not others.  
In any case there is no need for the checkpoint record to carry the  
same nextXid shown in the XLOG_RUNNING_XACTS record just emitted by  
LogStandbySnapshot, as any replay operation will already have adopted  
that value as current.  
  
This fixes bug #7710 from Tarvi Pillessaar, and probably also explains bug  
#6291 from Daniel Farina, in that if a checkpoint were in progress at the  
instant of XID wraparound, the epoch bump would be lost as reported.  
(And, of course, these days there's at least a 50-50 chance of a checkpoint  
being in progress at any given instant.)  
  
Diagnosed by me and independently by Andres Freund.  Back-patch to all  
branches supporting hot standby.  

commit   : c3f64adef829ea41d3761822b8a043aec3d651f2    
  
author   : Simon Riggs <simon@2ndQuadrant.com>    
date     : Sun, 2 Dec 2012 15:00:53 +0000    
  
committer: Simon Riggs <simon@2ndQuadrant.com>    
date     : Sun, 2 Dec 2012 15:00:53 +0000    

Bug reported in #6291 by Daniel Farina and slightly differently in  
  
Cause analysis and recommended fixes from Tom Lane and Andres Freund.  
  
Applied patch is minimal version of Andres Freund's work.  

commit   : 530cbf6b10af156276d45687d14ca05cd4e39d16    
  
author   : Tatsuo Ishii <ishii@postgresql.org>    
date     : Sun, 2 Dec 2012 21:11:15 +0900    
  
committer: Tatsuo Ishii <ishii@postgresql.org>    
date     : Sun, 2 Dec 2012 21:11:15 +0900    

commit   : 19a08ef7d3a8cd8327289c2183f8402d6b7dade9    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 1 Dec 2012 17:23:55 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 1 Dec 2012 17:23:55 -0500    

When we do "make install" to create a temp installation, we don't want  
that instance of make to try to communicate with any instance of make  
that might be calling us.  This is known to cause problems if the  
upper make has a -jN flag, and in principle could cause problems even  
without that.  Unset the relevant environment variables to prevent such  
issues.  
  
Andres Freund  

commit   : 53a1c31237298e4aeedc4f9926678505bf417d94    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 1 Dec 2012 16:04:44 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 1 Dec 2012 16:04:44 -0500    

The previous coding worked as long as MODULEDIR wasn't set explicitly,  
because we create sharedir/$(datamoduledir) and the default value of  
that is "extension".  But if some other value is specified for MODULEDIR  
then the installation directory needed for the control file wasn't made.  
  
Cédric Villemain  

commit   : af09efda128173b2eb273e1882435baba2115aef    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Sat, 1 Dec 2012 01:52:23 -0500    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Sat, 1 Dec 2012 01:52:23 -0500    

commit   : f18c9510dcf9a5a6cbd6d99458be4a519714d665    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 30 Nov 2012 19:20:15 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 30 Nov 2012 19:20:15 -0300    

Commit 81107282a changed it in assert.c, but overlooked this other file.  

commit   : 0adcaeef21d18fc04879a08aeea6cd7efce21296    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 30 Nov 2012 17:02:35 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 30 Nov 2012 17:02:35 -0500    

It's not safe to examine a shared buffer without any lock.  

commit   : 1c316e3a02e7eb8aaf8e04a441fc176aef06e317    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 30 Nov 2012 13:56:00 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 30 Nov 2012 13:56:00 -0500    

If we had not been holding buffer pin continuously since the tuple was  
initially fetched by the UPDATE or DELETE query, it would be possible for  
VACUUM or a page-prune operation to move the tuple while we're trying to  
copy it.  This would result in a garbage "old" tuple value being passed to  
an AFTER ROW UPDATE or AFTER ROW DELETE trigger.  The preconditions for  
this are somewhat improbable, and the timing constraints are very tight;  
so it's not so surprising that this hasn't been reported from the field,  
even though the bug has been there a long time.  
  
Problem found by Andres Freund.  Back-patch to all active branches.  

commit   : 2c55189b2b9e71a14bba1496da6be84614595983    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 30 Nov 2012 10:54:46 -0500    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 30 Nov 2012 10:54:46 -0500    

This removes exisiting PG settings from the environment for  
pg_upgrade tests, just like pg_regress does.  

commit   : a8e60f0b23fa263c9c451cbb6d36f0bc9c196610    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 29 Nov 2012 19:57:10 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 29 Nov 2012 19:57:10 -0500    

The length of a socket path name is constrained by the size of struct  
sockaddr_un, and there's not a lot we can do about it since that is a  
kernel API.  However, it would be a good thing if we produced an  
intelligible error message when the user specifies a socket path that's too  
long --- and getaddrinfo's standard API is too impoverished to do this in  
the natural way.  So insert explicit tests at the places where we construct  
a socket path name.  Now you'll get an error that makes sense and even  
tells you what the limit is, rather than something generic like  
"Non-recoverable failure in name resolution".  
  
Per trouble report from Jeremy Drake and a fix idea from Andrew Dunstan.  

commit   : edfc84b878d667bb074048cccb5f363ea66a82c8    
  
author   : Simon Riggs <simon@2ndQuadrant.com>    
date     : Thu, 29 Nov 2012 22:17:15 +0000    
  
committer: Simon Riggs <simon@2ndQuadrant.com>    
date     : Thu, 29 Nov 2012 22:17:15 +0000    

Resolves bug 7572 reported by Daniele Varrazzo  

commit   : fdac4e2ba2ae75080d9e8c6e34934c9d32fe26ee    
  
author   : Simon Riggs <simon@2ndQuadrant.com>    
date     : Thu, 29 Nov 2012 22:12:44 +0000    
  
committer: Simon Riggs <simon@2ndQuadrant.com>    
date     : Thu, 29 Nov 2012 22:12:44 +0000    

commit   : 44fe8ae9f97cc78f8641c4bffdd8a3e8b55b4690    
  
author   : Michael Meskes <meskes@postgresql.org>    
date     : Thu, 29 Nov 2012 17:12:00 +0100    
  
committer: Michael Meskes <meskes@postgresql.org>    
date     : Thu, 29 Nov 2012 17:12:00 +0100    

Applied patch by Muhammad Usama <m.usama@gmail.com> to fix this.  

commit   : 94c014b53283fc8b5afe7f3c4ac989dda4b652d0    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 29 Nov 2012 10:37:13 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 29 Nov 2012 10:37:13 -0500    

Commit 8cb53654dbdb4c386369eb988062d0bbb6de725e, which introduced DROP  
INDEX CONCURRENTLY, managed to break CREATE INDEX CONCURRENTLY via a poor  
choice of catalog state representation.  The pg_index state for an index  
that's reached the final pre-drop stage was the same as the state for an  
index just created by CREATE INDEX CONCURRENTLY.  This meant that the  
(necessary) change to make RelationGetIndexList ignore about-to-die indexes  
also made it ignore freshly-created indexes; which is catastrophic because  
the latter do need to be considered in HOT-safety decisions.  Failure to  
do so leads to incorrect index entries and subsequently wrong results from  
queries depending on the concurrently-created index.  
  
To fix, make the final state be indisvalid = true and indisready = false,  
which is otherwise nonsensical.  This is pretty ugly but we can't add  
another column without forcing initdb, and it's too late for that in 9.2.  
(There's a cleaner fix in HEAD.)  
  
In addition, change CREATE/DROP INDEX CONCURRENTLY so that the pg_index  
flag changes they make without exclusive lock on the index are made via  
heap_inplace_update() rather than a normal transactional update.  The  
latter is not very safe because moving the pg_index tuple could result in  
concurrent SnapshotNow scans finding it twice or not at all, thus possibly  
resulting in index corruption.  This is a pre-existing bug in CREATE INDEX  
CONCURRENTLY, which was copied into the DROP code.  
  
In addition, fix various places in the code that ought to check to make  
sure that the indexes they are manipulating are valid and/or ready as  
appropriate.  These represent bugs that have existed since 8.2, since  
a failed CREATE INDEX CONCURRENTLY could leave a corrupt or invalid  
index behind, and we ought not try to do anything that might fail with  
such an index.  
  
Also fix RelationReloadIndexInfo to ensure it copies all the pg_index  
columns that are allowed to change after initial creation.  Previously we  
could have been left with stale values of some fields in an index relcache  
entry.  It's not clear whether this actually had any user-visible  
consequences, but it's at least a bug waiting to happen.  
  
In addition, do some code and docs review for DROP INDEX CONCURRENTLY;  
some cosmetic code cleanup but mostly addition and revision of comments.  
  
Portions of this need to be back-patched even further, but I'll work  
on that separately.  
  
Problem reported by Amit Kapila, diagnosis by Pavan Deolasee,  
fix by Tom Lane and Andres Freund.  

commit   : ffc3172e4e3caee0327a7e4126b5e7a3c8a1c8cf    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 28 Nov 2012 11:45:30 +0200    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 28 Nov 2012 11:45:30 +0200    

This was apparently a typo, which caused recovery to think that it  
immediately reached the end of backup, and allowed the database to start  
up too early.  
  
Reported by Jeff Janes. Backpatch to 9.2, where this code was introduced.  

commit   : 786afc1ce53126feecf4d02e96e7455669ccbf5a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 26 Nov 2012 15:55:51 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 26 Nov 2012 15:55:51 -0500    

This reverts commit d573e239f03506920938bf0be56c868d9c3416da, "Take fewer  
snapshots".  While that seemed like a good idea at the time, it caused  
execution to use a snapshot that had been acquired before locking any of  
the tables mentioned in the query.  This created user-visible anomalies  
that were not present in any prior release of Postgres, as reported by  
Tomas Vondra.  While this whole area could do with a redesign (since there  
are related cases that have anomalies anyway), it doesn't seem likely that  
any future patch would be reasonably back-patchable; and we don't want 9.2  
to exhibit a behavior that's subtly unlike either past or future releases.  
Hence, revert to prior code while we rethink the problem.  

commit   : eea6ada926c356087f3d3093dc39a71408ce26ec    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 26 Nov 2012 12:57:24 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 26 Nov 2012 12:57:24 -0500    

In a query such as "SELECT DISTINCT min(x) FROM tab", the DISTINCT is  
pretty useless (there being only one output row), but nonetheless it  
shouldn't fail.  But it could fail if "tab" is an inheritance parent,  
because planagg.c's code for fixing up equivalence classes after making the  
index-optimized MIN/MAX transformation wasn't prepared to find child-table  
versions of the aggregate expression.  The least ugly fix seems to be  
to add an option to mutate_eclass_expressions() to skip child-table  
equivalence class members, which aren't used anymore at this stage of  
planning so it's not really necessary to fix them.  Since child members  
are ignored in many cases already, it seems plausible for  
mutate_eclass_expressions() to have an option to ignore them too.  
  
Per bug #7703 from Maxim Boguk.  
  
Back-patch to 9.1.  Although the same code exists before that, it cannot  
encounter child-table aggregates AFAICS, because the index optimization  
transformation cannot succeed on inheritance trees before 9.1 (for lack  
of MergeAppend).  

commit   : 3f7b04d6f694b447c17999ef0aed406e658de82f    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 23 Nov 2012 18:51:51 +0200    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 23 Nov 2012 18:51:51 +0200    

XLogRecPtrIsInvalid() only checks the xrecoff field, which is correct when  
checking if a WAL record could legally begin at the given position, but WAL  
sending can legally be paused at a page boundary, in which case xrecoff is  
0. Use XLByteEQ(..., InvalidXLogRecPtr) instead, which checks that both  
xlogid and xrecoff are 0.  
  
9.3 doesn't have this problem because XLogRecPtr is now a single 64-bit  
integer, so XLogRecPtrIsInvalid() does the right thing. Apply to 9.2, and  
9.1 where pg_stat_replication view was introduced.  
  
Kyotaro HORIGUCHI, reviewed by Fujii Masao.  

commit   : 430b47f382609c567bd87ff28a81ea5055d173d5    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 22 Nov 2012 11:23:28 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 22 Nov 2012 11:23:28 -0500    

Since we've already chdir'd into the data directory, the file should  
be referenced as just "postmaster.pid", without prefixing the directory  
path.  This is harmless in the normal case where an absolute PGDATA path  
is used, but quite dangerous if a relative path is specified, since the  
program might then fail to notice an active postmaster.  
  
Reported by Hari Babu.  This got broken in my commit  
eb5949d190e80360386113fde0f05854f0c9824d, so patch all active versions.  

commit   : dda8b87b6a470249e9d4e3701849b7bd830bb96c    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 22 Nov 2012 11:23:46 +0200    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 22 Nov 2012 11:23:46 +0200    

When startup process opens a WAL segment after replaying part of it, it  
validates the first page on the WAL segment, even though the page it's  
really interested in later in the file. As part of the validation, it checks  
that the TLI on the page header is >= the TLI it saw on the last page it  
read. If the segment contains a timeline switch, and we have already  
replayed it, and then re-open the WAL segment (because of streaming  
replication got disconnected and reconnected, for example), the TLI check  
will fail when the first page is validated. Fix that by relaxing the TLI  
check when re-opening a WAL segment.  
  
Backpatch to 9.0. Earlier versions had the same code, but before standby  
mode was introduced in 9.0, recovery never tried to re-read a segment after  
partially replaying it.  
  
Reported by Amit Kapila, while testing a new feature.  

commit   : 8af60da9ddab5fa6c27b41ec6413965ee75203c4    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 21 Nov 2012 15:18:43 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 21 Nov 2012 15:18:43 -0500    

Once we've received a shutdown signal (SIGINT or SIGTERM), we should not  
launch any more child processes, even if we get signals requesting such.  
The normal code path for spawning backends has always understood that,  
but the postmaster's infrastructure for hot standby and autovacuum didn't  
get the memo.  As reported by Hari Babu in bug #7643, this could lead to  
failure to shut down at all in some cases, such as when SIGINT is received  
just before the startup process sends PMSIGNAL_RECOVERY_STARTED: we'd  
launch a bgwriter and checkpointer, and then those processes would have no  
idea that they ought to quit.  Similarly, launching a new autovacuum worker  
would result in waiting till it finished before shutting down.  
  
Also, switch the order of the code blocks in reaper() that detect startup  
process crash versus shutdown termination.  Once we've sent it a signal,  
we should not consider that exit(1) is surprising.  This is just a cosmetic  
fix since shutdown occurs correctly anyway, but better not to log a phony  
complaint about startup process crash.  
  
Back-patch to 9.0.  Some parts of this might be applicable before that,  
but given the lack of prior complaints I'm not going to worry too much  
about older branches.  

commit   : 278b60598c648b677dbde1330f9f95676aa82e46    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 19 Nov 2012 21:21:28 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 19 Nov 2012 21:21:28 -0500    

Some platforms throw an exception for this division, rather than returning  
a necessarily-overflowed result.  Since we were testing for overflow after  
the fact, an exception isn't nice.  We can avoid the problem by treating  
division by -1 as negation.  
  
Add some regression tests so that we'll find out if any compilers try to  
optimize away the overflow check conditions.  
  
Back-patch of commit 1f7cb5c30983752ff8de833de30afcaee63536d0.  
  
Per discussion with Xi Wang, though this is different from the patch he  
submitted.  

commit   : 83d48a81f8e25f16a133f56874f1bcdee7838841    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 18 Nov 2012 17:15:11 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 18 Nov 2012 17:15:11 -0500    

The previous definitions of these GUC variables allowed them to range  
up to INT_MAX, but in point of fact the underlying code would suffer  
overflows or other errors with large values.  Reduce the maximum values  
to something that won't misbehave.  There's no apparent value in working  
harder than this, since very large delays aren't sensible for any of  
these.  (Note: the risk with archive_timeout is that if we're late  
checking the state, the timestamp difference it's being compared to  
might overflow.  So we need some amount of slop; the choice of INT_MAX/2  
is arbitrary.)  
  
Per followup investigation of bug #7670.  Although this isn't a very  
significant fix, might as well back-patch.  

commit   : 89067bc16a1d1ea5bf131b3529e01d208f2e34c0    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 18 Nov 2012 16:16:47 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 18 Nov 2012 16:16:47 -0500    

We need to avoid calling WaitLatch with timeouts exceeding INT_MAX.  
Fortunately a simple clamp will do the trick, since no harm is done if  
the wait times out before it's really time to rotate the log file.  
Per bug #7670 (probably bug #7545 is the same thing, too).  
  
In passing, fix bogus definition of log_rotation_age's maximum value in  
guc.c --- it was numerically right, but only because MINS_PER_HOUR and  
SECS_PER_MINUTE have the same value.  
  
Back-patch to 9.2.  Before that, syslogger wasn't using WaitLatch.  

commit   : f0461cd8613830aa2448a38b09569e8c54cead5b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 15 Nov 2012 19:29:12 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 15 Nov 2012 19:29:12 -0500    

Traditionally check_partial_indexes() has only looked at restriction  
clauses while trying to prove partial indexes usable in queries.  However,  
join clauses can also be used in some cases; mainly, that a strict operator  
on "x" proves an "x IS NOT NULL" index predicate, even if the operator is  
in a join clause rather than a restriction clause.  Adding this code fixes  
a regression in 9.2, because previously we would take join clauses into  
account when considering whether a partial index could be used in a  
nestloop inner indexscan path.  9.2 doesn't handle nestloop inner  
indexscans in the same way, and this consideration was overlooked in the  
rewrite.  Moving the work to check_partial_indexes() is a better solution  
anyway, since the proof applies whether or not we actually use the index  
in that particular way, and we don't have to do it over again for each  
possible outer relation.  Per report from Dave Cramer.  

commit   : 3b4db79e3559478212e1231f298e11a22a2b801b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 14 Nov 2012 17:30:04 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 14 Nov 2012 17:30:04 -0500    

The correct answer for this (or any other case with arg2 = -1) is zero,  
but some machines throw a floating-point exception instead of behaving  
sanely.  Commit f9ac414c35ea084ff70c564ab2c32adb06d5296f dealt with this  
in int4mod, but overlooked the fact that it also happens in int8mod  
(at least on my Linux x86_64 machine).  Protect int2mod as well; it's  
not clear whether any machines fail there (mine does not) but since the  
test is so cheap it seems better safe than sorry.  While at it, simplify  
the original guard in int4mod: we need only check for arg2 == -1, we  
don't need to check arg1 explicitly.  
  
Xi Wang, with some editing by me.  

commit   : 5355e39cf53aab9430fc6cd68dd3017b36c9315c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 13 Nov 2012 14:44:35 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 13 Nov 2012 14:44:35 -0500    

record_out() leaks memory: it fails to free the strings returned by the  
per-column output functions, and also is careless about detoasted values.  
This results in a query-lifespan memory leakage when returning composite  
values to the client, because printtup() runs the output functions in the  
query-lifespan memory context.  Fix it to handle these issues the same way  
printtup() does.  Also fix a similar leakage in record_send().  
  
(At some point we might want to try to run output functions in  
shorter-lived memory contexts, so that we don't need a zero-leakage policy  
for them.  But that would be a significantly more invasive patch, which  
doesn't seem like material for back-patching.)  
  
In passing, use appendStringInfoCharMacro instead of appendStringInfoChar  
in the innermost data-copying loop of record_out, to try to shave a few  
cycles from this function's runtime.  
  
Per trouble report from Carlos Henrique Reimer.  Back-patch to all  
supported versions.  

commit   : 31541778b612fd59257a2bf571229f400d35ecf0    
  
author   : Simon Riggs <simon@2ndQuadrant.com>    
date     : Tue, 13 Nov 2012 16:12:20 -0300    
  
committer: Simon Riggs <simon@2ndQuadrant.com>    
date     : Tue, 13 Nov 2012 16:12:20 -0300    

commit   : f66e7ab6db30b7893493c4dfd5d642bef93b350f    
  
author   : Simon Riggs <simon@2ndQuadrant.com>    
date     : Tue, 13 Nov 2012 15:56:28 -0300    
  
committer: Simon Riggs <simon@2ndQuadrant.com>    
date     : Tue, 13 Nov 2012 15:56:28 -0300    

Andres Freund and Simon Riggs  

commit   : 8805ff6580621d0daee350826de5211d6bb36ec3    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 12 Nov 2012 22:05:14 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 12 Nov 2012 22:05:14 -0500    

Most of the replay functions for WAL record types that modify more than  
one page failed to ensure that those pages were locked correctly to ensure  
that concurrent queries could not see inconsistent page states.  This is  
a hangover from coding decisions made long before Hot Standby was added,  
when it was hardly necessary to acquire buffer locks during WAL replay  
at all, let alone hold them for carefully-chosen periods.  
  
The key problem was that RestoreBkpBlocks was written to hold lock on each  
page restored from a full-page image for only as long as it took to update  
that page.  This was guaranteed to break any WAL replay function in which  
there was any update-ordering constraint between pages, because even if the  
nominal order of the pages is the right one, any mixture of full-page and  
non-full-page updates in the same record would result in out-of-order  
updates.  Moreover, it wouldn't work for situations where there's a  
requirement to maintain lock on one page while updating another.  Failure  
to honor an update ordering constraint in this way is thought to be the  
cause of bug #7648 from Daniel Farina: what seems to have happened there  
is that a btree page being split was rewritten from a full-page image  
before the new right sibling page was written, and because lock on the  
original page was not maintained it was possible for hot standby queries to  
try to traverse the page's right-link to the not-yet-existing sibling page.  
  
To fix, get rid of RestoreBkpBlocks as such, and instead create a new  
function RestoreBackupBlock that restores just one full-page image at a  
time.  This function can be invoked by WAL replay functions at the points  
where they would otherwise perform non-full-page updates; in this way, the  
physical order of page updates remains the same no matter which pages are  
replaced by full-page images.  We can then further adjust the logic in  
individual replay functions if it is necessary to hold buffer locks  
for overlapping periods.  A side benefit is that we can simplify the  
handling of concurrency conflict resolution by moving that code into the  
record-type-specfic functions; there's no more need to contort the code  
layout to keep conflict resolution in front of the RestoreBkpBlocks call.  
  
In connection with that, standardize on zero-based numbering rather than  
one-based numbering for referencing the full-page images.  In HEAD, I  
removed the macros XLR_BKP_BLOCK_1 through XLR_BKP_BLOCK_4.  They are  
still there in the header files in previous branches, but are no longer  
used by the code.  
  
In addition, fix some other bugs identified in the course of making these  
changes:  
  
spgRedoAddNode could fail to update the parent downlink at all, if the  
parent tuple is in the same page as either the old or new split tuple and  
we're not doing a full-page image: it would get fooled by the LSN having  
been advanced already.  This would result in permanent index corruption,  
not just transient failure of concurrent queries.  
  
Also, ginHeapTupleFastInsert's "merge lists" case failed to mark the old  
tail page as a candidate for a full-page image; in the worst case this  
could result in torn-page corruption.  
  
heap_xlog_freeze() was inconsistent about using a cleanup lock or plain  
exclusive lock: it did the former in the normal path but the latter for a  
full-page image.  A plain exclusive lock seems sufficient, so change to  
that.  
  
Also, remove gistRedoPageDeleteRecord(), which has been dead code since  
VACUUM FULL was rewritten.  
  
Back-patch to 9.0, where hot standby was introduced.  Note however that 9.0  
had a significantly different WAL-logging scheme for GIST index updates,  
and it doesn't appear possible to make that scheme safe for concurrent hot  
standby queries, because it can leave inconsistent states in the index even  
between WAL records.  Given the lack of complaints from the field, we won't  
work too hard on fixing that branch.  

commit   : 454edf1da9f36615b780b1cb216ae5d9fe8ba42c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 11 Nov 2012 19:56:16 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 11 Nov 2012 19:56:16 -0500    

Since transformSetOperationTree() recurses, it can be driven to stack  
overflow with enough UNION/INTERSECT/EXCEPT clauses in a query.  Add a  
check to ensure it fails cleanly instead of crashing.  Per report from  
Matthew Gerber (though it's not clear whether this is the only thing  
going wrong for him).  
  
Historical note: I think the reasoning behind not putting a check here in  
the beginning was that the check in transformExpr() ought to be sufficient  
to guard the whole parser.  However, because transformSetOperationTree()  
recurses all the way to the bottom of the set-operation tree before doing  
any analysis of the statement's expressions, that check doesn't save it.  

commit   : 9b06d91ac88d2263d185fb12c7f11d9b450326db    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 8 Nov 2012 23:55:36 -0500    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 8 Nov 2012 23:55:36 -0500    

Some versions of the XSLT stylesheets don't handle the missing slash  
correctly (they concatenate directory and file name without the slash).  
This might never have worked correctly.  

commit   : 8354ce92165ee969510e975d30a69f875e3ffcd9    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 8 Nov 2012 20:04:54 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 8 Nov 2012 20:04:54 -0500    

If the sleep is interrupted by a signal, we must recompute the remaining  
time to wait; otherwise, a steady stream of non-wait-terminating interrupts  
could delay return from WaitLatch indefinitely.  This has been shown to be  
a problem for the autovacuum launcher, and there may well be other places  
now or in the future with similar issues.  So we'd better make the function  
robust, even though this'll add at least one gettimeofday call per wait.  
  
Back-patch to 9.2.  We might eventually need to fix 9.1 as well, but the  
code is quite different there, and the usage of WaitLatch in 9.1 is so  
limited that it's not clearly important to do so.  
  
Reported and diagnosed by Jeff Janes, though I rewrote his patch rather  
heavily.  

commit   : 03787f63921e37c123ceff712ed405c5172e765d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 8 Nov 2012 11:34:37 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 8 Nov 2012 11:34:37 -0500    

The trigger and rule cases need to split up the input name list, but  
they mustn't corrupt the passed-in data structure, since it could be part  
of a cached utility-statement parsetree.  Per bug #7641.  

commit   : 9eb80f2ca75a205949df7dc86019d99fe076eb87    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 7 Nov 2012 16:23:39 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 7 Nov 2012 16:23:39 -0300    

Commit 4c9d0901 mistakenly introduced a call to  
TransferPredicateLocksToHeapRelation() on an index relation that had  
been closed a few lines above.  Moving up an index_open() call that's  
below is enough to fix the problem.  
  
Discovered by me while testing an unrelated patch.  

commit   : 663c68f0e94ec6d4d4f75edcbd3d5c3dec4478fd    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 7 Nov 2012 13:36:08 -0500    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 7 Nov 2012 13:36:08 -0500    

Backpatch to 9.2.  

commit   : 3cef201c198c99831d2ee96eaa7de68799abea9a    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 6 Nov 2012 14:28:48 -0500    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 6 Nov 2012 14:28:48 -0500    

Backpatch to 9.2.  

commit   : 329057fd8f967d08190cd355333430c604418d81    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 5 Nov 2012 13:36:21 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 5 Nov 2012 13:36:21 -0500    

This case got broken in 8.4 by the addition of an error check that  
complains if ALTER TABLE ONLY is used on a table that has children.  
We do use ONLY for this situation, but it's okay because the necessary  
recursion occurs at a higher level.  So we need to have a separate  
flag to suppress recursion without making the error check.  
  
Reported and patched by Pavan Deolasee, with some editorial adjustments by  
me.  Back-patch to 8.4, since this is a regression of functionality that  
worked in earlier branches.  

commit   : 2f5390aacc7b7ff297dcfeaeab40dae8bb3943c9    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 1 Nov 2012 19:48:58 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 1 Nov 2012 19:48:58 -0400    

I'm not sure why commit 1eb1dde049ccfffc42c80c2bcec14155c58bcc1f seems  
to have made this start to fail on Cygwin when it never did before ---  
but nonetheless, the coding was pretty bogus, and unlike the way we  
handle $(X) anywhere else.  Per buildfarm.  

commit   : ca2d6a6cef5740b29406980eb8d21d44da32634b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 1 Nov 2012 14:08:48 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 1 Nov 2012 14:08:48 -0400    

In bug #7626, Brian Dunavant exposes a performance problem created by  
commit 3b8968f25232ad09001bf35ab4cc59f5a501193e: that commit attempted to  
consider *all* possible combinations of indexable join clauses, but if said  
clauses join to enough different relations, there's an exponential increase  
in the number of outer-relation sets considered.  
  
In Brian's example, all the clauses come from the same equivalence class,  
which means it's redundant to use more than one of them in an indexscan  
anyway.  So we can prevent the problem in this class of cases (which is  
probably the majority of real examples) by rejecting combinations that  
would only serve to add a known-redundant clause.  
  
But that still leaves us exposed to exponential growth of planning time  
when the query has a lot of non-equivalence join clauses that are usable  
with the same index.  I chose to prevent such cases by setting an upper  
limit on the number of relation sets considered, equal to ten times the  
number of index clauses considered so far.  (This sliding limit still  
allows new relsets to be added on as we move to additional index columns,  
which is probably more important than considering even more combinations of  
clauses for the previous column.)  This should keep the amount of work done  
roughly linear rather than exponential in the apparent query complexity.  
This part of the fix is pretty ad-hoc; but without a clearer idea of  
real-world cases for which this would result in markedly inferior plans,  
it's hard to see how to do better.  

commit   : ec397c90990f5c5c08990a7ab378e32101b2e832    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 31 Oct 2012 14:26:20 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 31 Oct 2012 14:26:20 -0400    

Per bug #7631 from Rob Johnson.  The code is operating as designed, but the  
docs didn't explain it.  

commit   : fb3590dde0fad43c2933afbdce699b9dd7d8ac53    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 31 Oct 2012 10:48:41 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 31 Oct 2012 10:48:41 -0300    

In its original conception, it was leaving some objects into the old  
schema, but without their proper pg_depend entries; this meant that the  
old schema could be dropped, causing future pg_dump calls to fail on the  
affected database.  This was originally reported by Jeff Frost as #6704;  
there have been other complaints elsewhere that can probably be traced  
to this bug.  
  
To fix, be more consistent about altering a table's subsidiary objects  
along the table itself; this requires some restructuring in how tables  
are relocated when altering an extension -- hence the new  
AlterTableNamespaceInternal routine which encapsulates it for both the  
ALTER TABLE and the ALTER EXTENSION cases.  
  
There was another bug lurking here, which was unmasked after fixing the  
previous one: certain objects would be reached twice via the dependency  
graph, and the second attempt to move them would cause the entire  
operation to fail.  Per discussion, it seems the best fix for this is to  
do more careful tracking of objects already moved: we now maintain a  
list of moved objects, to avoid attempting to do it twice for the same  
object.  
  
Authors: Alvaro Herrera, Dimitri Fontaine  
Reviewed by Tom Lane  

commit   : 7e951ba6e1de7bb77aef4ea2d0ef7d2be860f389    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 26 Oct 2012 14:19:39 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 26 Oct 2012 14:19:39 -0400    

generate_base_implied_equalities_const() should prefer plain Consts over  
other em_is_const eclass members when choosing the "pivot" value that  
all the other members will be equated to.  This makes it more likely that  
the generated equalities will be useful in constraint-exclusion proofs.  
Per report from Rushabh Lathia.  

commit   : 725fa25e20248800461b06802f5ee9a203825618    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 26 Oct 2012 12:12:48 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 26 Oct 2012 12:12:48 -0400    

Represent a sequence's current value as a separate TableDataInfo dumpable  
object, so that it can be dumped within the data section of the archive  
rather than in pre-data.  This fixes an undesirable inconsistency between  
the meanings of "--data-only" and "--section=data", and also fixes dumping  
of sequences that are marked as extension configuration tables, as per a  
report from Marko Kreen back in July.  The main cost is that we do one more  
SQL query per sequence, but that's probably not very meaningful in most  
databases.  
  
Back-patch to 9.1, since it has the extension configuration issue even  
though not the --section switch.  

commit   : 1dec7c7c6ccd70318a71d058b7af9da149041b33    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 24 Oct 2012 14:53:49 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 24 Oct 2012 14:53:49 -0400    

Views should not have any pg_attribute entries for system columns.  
However, we forgot to remove such entries when converting a table to a  
view.  This could lead to crashes later on, if someone attempted to  
reference such a column, as reported by Kohei KaiGai.  
  
This problem is corrected properly in HEAD (by removing the pg_attribute  
entries during conversion), but in the back branches we need to defend  
against existing mis-converted views.  This fix costs us an extra syscache  
lookup per system column reference, which is annoying but probably not  
really measurable in the big scheme of things.  

commit   : 523ecaf40436588278701ace3c06dc80d2189068    
  
author   : Kevin Grittner <kgrittn@postgresql.org>    
date     : Sun, 21 Oct 2012 17:26:32 -0500    
  
committer: Kevin Grittner <kgrittn@postgresql.org>    
date     : Sun, 21 Oct 2012 17:26:32 -0500    

For the non-concurrent case there is an AccessExclusiveLock lock  
on both the index and the heap at a time during which no other  
process is using either, before which the index is maintained and  
used for scans, and after which the index is no longer used or  
maintained.  Predicate locks can safely be moved from the index to  
the related heap relation under the protection of these locks.  
This was done prior to the introductin of DROP INDEX CONCURRENTLY  
and continues to be done for non-concurrent index drops.  
  
For concurrent index drops, the predicate locks must be moved when  
there are no index scans in progress on that index and no more can  
subsequently start, and before heap inserts stop maintaining the  
index.  As long as these conditions are guaranteed when the  
TransferPredicateLocksToHeapRelation() function is called,  
stronger locks are not needed for correctness.  
  
Kevin Grittner based on questions by Tom Lane in reviewing the  
DROP INDEX CONCURRENTLY patch and in cooperation with Andres  
Freund and Simon Riggs.  
  
Back-patch of commit 4c9d0901f135d724a9f3cfa4140a5afd44b10f08  

commit   : a4ef1f09bd870048ed91b43c5b584cf90cc59b54    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 20 Oct 2012 16:58:32 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 20 Oct 2012 16:58:32 -0400    

In commit 4317e0246c645f60c39e6572644cff1cb03b4c65, I accidentally broke  
this behavior while rearranging code to ensure that --create wouldn't  
affect whether a DATABASE entry gets put into archive-format output.  
Thus, 9.2 would issue a DROP DATABASE command in --clean mode, which is  
either useless or dangerous depending on the usage scenario.  
It should not do that, and no longer does.  
  
A bright spot is that this refactoring makes it easy to allow the  
combination of --clean and --create to work sensibly, ie, emit DROP  
DATABASE then CREATE DATABASE before reconnecting.  Ordinarily we'd  
consider that a feature addition and not back-patch it, but it seems  
silly to not include the extra couple of lines required in the 9.2  
version of the code.  
  
Per report from Guillaume Lelarge, though this is slightly more extensive  
than his proposed patch.  

commit   : 12b721a7f0e3cb05630f267e0d9b4e63bbba6b0b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 19 Oct 2012 18:33:53 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 19 Oct 2012 18:33:53 -0400    

The code seems to have been written to handle the pre-parse-analysis  
representation, where an ExecuteStmt would appear directly under  
CreateTableAsStmt.  But in reality the function is only run on  
already-parse-analyzed statements, so there will be a Query node in  
between.  We'd not noticed the bug because the function is generally  
not used at all except in extended query protocol.  
  
Per report from Robert Haas and Rushabh Lathia.  

commit   : 8a3249f12447468c4ac5a3b91cfdad5573e2b660    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 19 Oct 2012 15:24:10 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 19 Oct 2012 15:24:10 -0400    

An out-of-memory error during expand_table() on a palloc-based hash table  
would leave a partially-initialized entry in the table.  This would not be  
harmful for transient hash tables, since they'd get thrown away anyway at  
transaction abort.  But for long-lived hash tables, such as the relcache  
hash, this would effectively corrupt the table, leading to crash or other  
misbehavior later.  
  
To fix, rearrange the order of operations so that table enlargement is  
attempted before we insert a new entry, rather than after adding it  
to the hash table.  
  
Problem discovered by Hitoshi Harada, though this is a bit different  
from his proposed patch.  

commit   : 645984e40c6a8c892bca5c27a5b381554ea1d3f1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 19 Oct 2012 13:39:57 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 19 Oct 2012 13:39:57 -0400    

Per bug #7615 from Marko Tiikkaja.  Apparently nobody ever tried this  
case before ...  

commit   : c567535742b5dbd244bbc9f33be794585afac2b7    
  
author   : Simon Riggs <simon@2ndQuadrant.com>    
date     : Fri, 19 Oct 2012 09:57:32 +0100    
  
committer: Simon Riggs <simon@2ndQuadrant.com>    
date     : Fri, 19 Oct 2012 09:57:32 +0100    

Backpatch to 9.2  
  
Andres Freund, tested by Abhijit Menon-Sen  

commit   : f61013a438f255b386c9bf7dcae32f3dcf5d5b2e    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Thu, 18 Oct 2012 16:15:49 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Thu, 18 Oct 2012 16:15:49 -0400    

commit   : e7bab081a9f726fa8cd910bd7e2567423383b44b    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 18 Oct 2012 22:26:26 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 18 Oct 2012 22:26:26 +0300    

Don't leak a file descriptor if the file is empty or we can't read its size.  
  
Expect there to be a newline at the end of the last line, too. If there  
isn't, ignore anything after the last newline. This makes it a tiny bit  
more robust in case the file is appended to concurrently, so that we don't  
return the last line if it hasn't been fully written yet. And this makes  
the code a bit less obscure, anyway. Per Tom Lane's suggestion.  
  
Backpatch to all supported branches.  

commit   : 623e49c0c03a1ff1b0992a20c0e2fdaaa6d13f34    
  
author   : Simon Riggs <simon@2ndQuadrant.com>    
date     : Thu, 18 Oct 2012 19:44:13 +0100    
  
committer: Simon Riggs <simon@2ndQuadrant.com>    
date     : Thu, 18 Oct 2012 19:44:13 +0100    

Abhijit Menon-Sen  

commit   : 5da1c4b7cc46af5d54912447ee51332d1dbd681c    
  
author   : Simon Riggs <simon@2ndQuadrant.com>    
date     : Thu, 18 Oct 2012 19:05:14 +0100    
  
committer: Simon Riggs <simon@2ndQuadrant.com>    
date     : Thu, 18 Oct 2012 19:05:14 +0100    

Backpatch to 9.2  
  
Andres Freund, tweaked by me  

commit   : 0237b39452f7651a976661e20ab90a93d00cbc18    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 18 Oct 2012 12:28:54 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 18 Oct 2012 12:28:54 -0400    

If a potential equivalence clause references a variable from the nullable  
side of an outer join, the planner needs to take care that derived clauses  
are not pushed to below the outer join; else they may use the wrong value  
for the variable.  (The problem arises only with non-strict clauses, since  
if an upper clause can be proven strict then the outer join will get  
simplified to a plain join.)  The planner attempted to prevent this type  
of error by checking that potential equivalence clauses aren't  
outerjoin-delayed as a whole, but actually we have to check each side  
separately, since the two sides of the clause will get moved around  
separately if it's treated as an equivalence.  Bugs of this type can be  
demonstrated as far back as 7.4, even though releases before 8.3 had only  
a very ad-hoc notion of equivalence clauses.  
  
In addition, we neglected to account for the possibility that such clauses  
might have nonempty nullable_relids even when not outerjoin-delayed; so the  
equivalence-class machinery lacked logic to compute correct nullable_relids  
values for clauses it constructs.  This oversight was harmless before 9.2  
because we were only using RestrictInfo.nullable_relids for OR clauses;  
but as of 9.2 it could result in pushing constructed equivalence clauses  
to incorrect places.  (This accounts for bug #7604 from Bill MacArthur.)  
  
Fix the first problem by adding a new test check_equivalence_delay() in  
distribute_qual_to_rels, and fix the second one by adding code in  
equivclass.c and called functions to set correct nullable_relids for  
generated clauses.  Although I believe the second part of this is not  
currently necessary before 9.2, I chose to back-patch it anyway, partly to  
keep the logic similar across branches and partly because it seems possible  
we might find other reasons why we need valid values of nullable_relids in  
the older branches.  
  
Add regression tests illustrating these problems.  In 9.0 and up, also  
add test cases checking that we can push constants through outer joins,  
since we've broken that optimization before and I nearly broke it again  
with an overly simplistic patch for this problem.  

commit   : 126091270396d24ecd9bc2094f7e8dbbc6547e39    
  
author   : Simon Riggs <simon@2ndQuadrant.com>    
date     : Thu, 18 Oct 2012 15:26:02 +0100    
  
committer: Simon Riggs <simon@2ndQuadrant.com>    
date     : Thu, 18 Oct 2012 15:26:02 +0100    

commit   : d4412fa0e543fa1608c3bb9b6651d247ce59983f    
  
author   : Simon Riggs <simon@2ndQuadrant.com>    
date     : Thu, 18 Oct 2012 13:40:10 +0100    
  
committer: Simon Riggs <simon@2ndQuadrant.com>    
date     : Thu, 18 Oct 2012 13:40:10 +0100    

Abhijit Menon-Sen  

commit   : d7598aeea9ffdc0a1443c17e1ea8e58a204c94fe    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 17 Oct 2012 12:38:28 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 17 Oct 2012 12:38:28 -0400    

If an SMgrRelation is not "owned" by a relcache entry, don't allow it to  
live past transaction end.  This design allows the same SMgrRelation to be  
used for blind writes of multiple blocks during a transaction, but ensures  
that we don't hold onto such an SMgrRelation indefinitely.  Because an  
SMgrRelation typically corresponds to open file descriptors at the fd.c  
level, leaving it open when there's no corresponding relcache entry can  
mean that we prevent the kernel from reclaiming deleted disk space.  
(While CacheInvalidateSmgr messages usually fix that, there are cases  
where they're not issued, such as DROP DATABASE.  We might want to add  
some more sinval messaging for that, but I'd be inclined to keep this  
type of logic anyway, since allowing VFDs to accumulate indefinitely  
for blind-written relations doesn't seem like a good idea.)  
  
This code replaces a previous attempt towards the same goal that proved  
to be unreliable.  Back-patch to 9.1 where the previous patch was added.  

commit   : a1f064fc2bd259dc8d75313df1cf9d5c294437f9    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 17 Oct 2012 12:37:15 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 17 Oct 2012 12:37:15 -0400    

This reverts commit fba105b1099f4f5fa7283bb17cba6fed2baa8d0c.  
That approach had problems with the smgr-level state not tracking what  
we really want to happen, and with the VFD-level state not tracking the  
smgr-level state very well either.  In consequence, it was still possible  
to hold kernel file descriptors open for long-gone tables (as in recent  
report from Tore Halset), and yet there were also cases of FDs being closed  
undesirably soon.  A replacement implementation will follow.  

commit   : 4be1d015b8bf1ae43dd7c99fe6039e00b02cfc28    
  
author   : Simon Riggs <simon@2ndQuadrant.com>    
date     : Wed, 17 Oct 2012 09:19:24 +0100    
  
committer: Simon Riggs <simon@2ndQuadrant.com>    
date     : Wed, 17 Oct 2012 09:19:24 +0100    

commit   : 679f2ca25b34df013b57eb8aa8b32d6c3f56721a    
  
author   : Simon Riggs <simon@2ndQuadrant.com>    
date     : Wed, 17 Oct 2012 08:23:05 +0100    
  
committer: Simon Riggs <simon@2ndQuadrant.com>    
date     : Wed, 17 Oct 2012 08:23:05 +0100    

commit   : 540374768d75b8f0b477274dc98c7c52602b2923    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Sat, 13 Oct 2012 12:48:14 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Sat, 13 Oct 2012 12:48:14 +0300    

If postmaster changed postmaster.pid while pg_ctl was reading it, pg_ctl  
could overrun the buffer it allocated for the file. Fix by reading the  
whole file to memory with one read() call.  
  
initdb contains an identical copy of the readfile() function, but the files  
that initdb reads are static, not modified concurrently. Nevertheless, add  
a simple bounds-check there, if only to silence static analysis tools.  
  
Per report from Dave Vitek. Backpatch to all supported branches.  

commit   : 4d4005cb48f5d48d059bf90b849a43299881c3be    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 14 Oct 2012 23:00:01 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 14 Oct 2012 23:00:01 -0400    

In the previous coding, new backend processes would attempt to create their  
self-pipe during the OwnLatch call in InitProcess.  However, pipe creation  
could fail if the kernel is short of resources; and the system does not  
recover gracefully from a FATAL error right there, since we have armed the  
dead-man switch for this process and not yet set up the on_shmem_exit  
callback that would disarm it.  The postmaster then forces an unnecessary  
database-wide crash and restart, as reported by Sean Chittenden.  
  
There are various ways we could rearrange the code to fix this, but the  
simplest and sanest seems to be to split out creation of the self-pipe into  
a new function InitializeLatchSupport, which must be called from a place  
where failure is allowed.  For most processes that gets called in  
InitProcess or InitAuxiliaryProcess, but processes that don't call either  
but still use latches need their own calls.  
  
Back-patch to 9.1, which has only a part of the latch logic that 9.2 and  
HEAD have, but nonetheless includes this bug.  

commit   : 0fbd44387d8658c5f3dae39b78d1a593e7026e09    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 12 Oct 2012 12:10:55 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 12 Oct 2012 12:10:55 -0400    

This change ensures that the planner will see implicit and explicit casts  
as equivalent for all purposes, except in the minority of cases where  
there's actually a semantic difference (as reflected by having a 3-argument  
cast function).  In particular, this fixes cases where the EquivalenceClass  
machinery failed to consider two references to a varchar column as  
equivalent if one was implicitly cast to text but the other was explicitly  
cast to text, as seen in bug #7598 from Vaclav Juza.  We have had similar  
bugs before in other parts of the planner, so I think it's time to fix this  
problem at the core instead of continuing to band-aid around it.  
  
Remove set_coercionform_dontcare(), which represents the band-aid  
previously in use for allowing matching of index and constraint expressions  
with inconsistent cast labeling.  (We can probably get rid of  
COERCE_DONTCARE altogether, but I don't think removing that enum value in  
back branches would be wise; it's possible there's third party code  
referring to it.)  
  
Back-patch to 9.2.  We could go back further, and might want to once this  
has been tested more; but for the moment I won't risk destabilizing plan  
choices in long-since-stable branches.  

commit   : a963c8b85f8f109509d6b1815e42ef6c09e8aa28    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 11 Oct 2012 12:21:02 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 11 Oct 2012 12:21:02 -0400    

When hashing a subplan like "WHERE (a, b) NOT IN (SELECT x, y FROM ...)",  
findPartialMatch() attempted to match rows using the hashtable's internal  
equality operators, which of course are for x and y's datatypes.  What we  
need to use are the potentially cross-type operators for a=x, b=y, etc.  
Failure to do that leads to wrong answers or even crashes.  The scope for  
problems is limited to cases where we have different types with compatible  
hash functions (else we'd not be using a hashed subplan), but for example  
int4 vs int8 can cause the problem.  
  
Per bug #7597 from Bo Jensen.  This has been wrong since the hashed-subplan  
code was written, so patch all the way back.  

commit   : 812d6db94327476f5b6ccd6b68ea1b315cd7f020    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 10 Oct 2012 13:54:43 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 10 Oct 2012 13:54:43 -0400    

Etsuro Fujita, with some wording adjustment by me.  

commit   : c33d6ef57dbaf2c98192b9f5e4b75c7539116e70    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 10 Oct 2012 13:53:26 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 10 Oct 2012 13:53:26 -0400    

Backpatch to 9.2.  

commit   : 1b013f78fbdea47f1029482cedb5b390e672db14    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 9 Oct 2012 21:04:11 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 9 Oct 2012 21:04:11 -0400    

Building a shlib on AIX requires use of the mkldexport.sh script, but we  
failed to install that, preventing its use from non-source-tree contexts.  
Also, Makefile.aix had the wrong idea about where to find the installed  
copy of the postgres.imp symbol file used by AIX.  
  
Per report from John Pierce.  Patch all the way back, since this has been  
broken since the beginning of PGXS.  

commit   : c5b8daa08d9abf7812d58617b834a6589760f8af    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 8 Oct 2012 21:52:42 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 8 Oct 2012 21:52:42 -0400    

I found that these functions tend to return -1 while leaving an empty error  
message string in the PGconn, if they suffer some kind of I/O error on the  
file.  The reason is that lo_close, which thinks it's executed a perfectly  
fine SQL command, clears the errorMessage.  The minimum-change workaround  
is to reorder operations here so that we don't fill the errorMessage until  
after lo_close.  

commit   : cf9d99298cf8b59f8cd0f73f5e74e45c2462eb7e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 8 Oct 2012 21:18:51 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 8 Oct 2012 21:18:51 -0400    

lo_export returns -1, not zero, on failure.  

commit   : 795e10749f1e2e0132cb236b4fe3143cf53b0825    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 8 Oct 2012 14:17:27 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 8 Oct 2012 14:17:27 +0300    

Tomonaru Katsumata  

commit   : 6dea5f4c4e1fcb5b5b0fea9a0e3a06f5f5def41c    
  
author   : Michael Meskes <meskes@postgresql.org>    
date     : Fri, 5 Oct 2012 16:49:27 +0200    
  
committer: Michael Meskes <meskes@postgresql.org>    
date     : Fri, 5 Oct 2012 16:49:27 +0200    

commit   : c413015fd488ae3ce660efeea182faec244bab5d    
  
author   : Michael Meskes <meskes@postgresql.org>    
date     : Fri, 5 Oct 2012 16:37:45 +0200    
  
committer: Michael Meskes <meskes@postgresql.org>    
date     : Fri, 5 Oct 2012 16:37:45 +0200    

Instead of continuing if the next character is not an array boundary get_data()  
used to continue only on finding a boundary so it was not able to read any  
element after the first.  

commit   : cb4083dfbbda97eb2b23111a3093c417d8a7d41a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 4 Oct 2012 13:41:05 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 4 Oct 2012 13:41:05 -0400    

These reference pages still claimed that you have to be superuser to create  
a database or schema owned by a different role.  That was true before 8.1,  
but it was changed in commits aa1110624c08298393dfce996f7b21809d98d3fd and  
f91370cd2faf1fd35a1ac74d84652a85ed841919 to allow assignment of ownership  
to any role you are a member of.  However, at the time we were thinking of  
that primarily as a change to the ALTER OWNER rules, so the need to touch  
these two CREATE ref pages got missed.  

commit   : a846f63aed825e4addbf24bbbb36fc0de9ddf568    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 4 Oct 2012 10:34:40 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 4 Oct 2012 10:34:40 +0300    

commit   : 49bf146b7ad0b1751fb4d15853306dabf1ce83c6    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 3 Oct 2012 13:37:53 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 3 Oct 2012 13:37:53 -0400    

examine_simple_variable supposed that any RTE_SUBQUERY rel it gets pointed  
at must have been planned already.  However, this isn't a safe assumption  
because we must do selectivity estimation while generating indexscan paths,  
and that code might look at join clauses involving a rel that the loop in  
set_base_rel_sizes() hasn't reached yet.  The simplest fix is to play dumb  
in such a situation, that is give up trying to extract any stats for the  
Var.  This could possibly be improved by making a separate pass over the  
RTE list to plan each unflattened subquery before we start the main  
planning work --- but that would be pretty invasive and it doesn't seem  
worth it, for now at least.  (We couldn't just break set_base_rel_sizes()  
into two loops: the prescan would need to handle all subquery rels in the  
query, not only those in the current join subproblem.)  
  
This bug was introduced in commit 1cb108efb0e60d87e4adec38e7636b6e8efbeb57,  
although I think that subsequent changes may have exposed it more than it  
was originally.  Per bug #7580 from Maxim Boguk.  

commit   : da24920ab8ea6b22632103845c3c6126c8833ca6    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 3 Oct 2012 12:22:41 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 3 Oct 2012 12:22:41 -0300    

Apparently this was considered in the original code (see commit  
cec3b0a9) but I failed to notice that such entries would always be  
skipped by the database check at the start of the loop.  
  
Per bugs #7578 by Nikolay, #6116 by tushar.qa@gmail.com.  

commit   : 03dfbce9a2d5f1680438ddb2837b68e6a6624b66    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 2 Oct 2012 21:18:43 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 2 Oct 2012 21:18:43 -0400    

Backpatch to 9.2.  

commit   : 689d99306a1838728075928fcc61ca3ffc112384    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 2 Oct 2012 17:31:49 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 2 Oct 2012 17:31:49 -0400    

On some platforms these functions return NULL, rather than the more common  
practice of returning a pointer to a zero-sized block of memory.  Hack our  
various wrapper functions to hide the difference by substituting a size  
request of 1.  This is probably not so important for the callers, who  
should never touch the block anyway if they asked for size 0 --- but it's  
important for the wrapper functions themselves, which mistakenly treated  
the NULL result as an out-of-memory failure.  This broke at least pg_dump  
for the case of no user-defined aggregates, as per report from  
Matthew Carrington.  
  
Back-patch to 9.2 to fix the pg_dump issue.  Given the lack of previous  
complaints, it seems likely that there is no live bug in previous releases,  
even though some of these functions were in place before that.  

commit   : 87b6a3989fec4a8d10de910671ab702e07aa85cf    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 2 Oct 2012 19:59:00 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 2 Oct 2012 19:59:00 +0300    

Fujii Masao  

commit   : cbf99c7aa46d5be64b7adf8169129d5c1453dcdd    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 2 Oct 2012 11:53:45 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 2 Oct 2012 11:53:45 -0400    

Backpatch to 9.2.  

commit   : 087f41086bcdf428056fccc06b34c96fd5bc143d    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 2 Oct 2012 11:46:08 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 2 Oct 2012 11:46:08 -0400    

Backpatch to 9.2.  

commit   : fe39bf0db64a99d401a2fdb0a219aefcbb406aa2    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 2 Oct 2012 11:42:34 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 2 Oct 2012 11:42:34 -0400    

Backpatch to 9.2.  

commit   : 4e6a910069d6c6f31e72c0891ee8495df61759bb    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 2 Oct 2012 17:37:41 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 2 Oct 2012 17:37:41 +0300    

timeval.t_sec is of type time_t, which is not always compatible with long.  
I'm not sure if this was just harmless warning or a real bug, but this  
fixes it, anyway.  

commit   : a50be771c80446d36771ff6c425a152e0d332315    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Tue, 2 Oct 2012 10:42:42 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Tue, 2 Oct 2012 10:42:42 -0400    

commit   : 23355e6cb9272cde1b695a3c6228e8e8186d59f4    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 2 Oct 2012 10:43:48 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 2 Oct 2012 10:43:48 +0300    

This affects date_in(), and a couple of other funcions that use DecodeDate().  
  
Hitoshi Harada  

commit   : fab2ae0ec9e71227003ae1177ef8c633a80ae4b0    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 29 Sep 2012 17:56:45 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 29 Sep 2012 17:56:45 -0400    

The tar output module did some very ugly and ultimately incorrect hacking  
on COPY commands to try to get them to work in the context of restoring a  
deconstructed tar archive.  In particular, it would fail altogether for  
table names containing any upper-case characters, since it smashed the  
command string to lower-case before modifying it (and, just to add insult  
to injury, did that in a way that would fail in multibyte encodings).  
I don't see any particular value in being flexible about the case of the  
command keywords, since the string will just have been created by  
dumpTableData, so let's get rid of the whole case-folding thing.  
  
Also, it doesn't seem to meet the POLA for the script to restore data only  
in COPY mode, so add \i commands to make it have comparable behavior in  
--inserts mode.  
  
Noted while looking at the tar-output code in connection with Brian  
Weaver's patch.  

commit   : 900d77fa57565ac5881acf464e76a88069605ad2    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 28 Sep 2012 15:35:46 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 28 Sep 2012 15:35:46 -0400    

Back-patch portions of commit 05b555d12bc2ad0d581f48a12b45174db41dc10d.  
There doesn't seem to be any reason not to fix pg_basebackup fully, but  
we can't change pg_dump's "magic" string without breaking older versions  
of pg_restore.  Instead, just patch pg_restore to accept either version  
of the magic string, in hopes of avoiding compatibility problems when  
9.3 comes out.  I also fixed pg_dump to write the correct 2-block EOF  
marker, since that won't create a compatibility problem with pg_restore  
and it could help with some versions of tar.  
  
Brian Weaver and Tom Lane  

commit   : f2366e584aea41b980f23fcf0a2e118efd7fb09b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 27 Sep 2012 17:00:05 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 27 Sep 2012 17:00:05 -0400    

This fixes another error in commit 9e8da0f75731aaa7605cf4656c21ea09e84d2eb1.  
I neglected to make the mark/restore functionality save and restore the  
current set of array key values, which led to strange behavior if an  
IndexScan with ScalarArrayOpExpr quals was used as the inner side of a  
mergejoin.  Per bug #7570 from Melese Tesfaye.  

commit   : 01546402d4cbf88a66e680be5a9c6f018518050a    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 27 Sep 2012 12:15:03 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 27 Sep 2012 12:15:03 -0300    

This worked fine for superusers, but not for ordinary users trying to  
cancel their own processes.  Tweak the order the checks are done in so  
that we correctly return SIGNAL_BACKEND_ERROR (which current callers  
know to ignore without erroring out) so that an ordinary user can loop  
through a resultset without fearing that a process might exit in the  
middle of said looping -- causing the remaining processes to go  
unsignalled.  
  
Incidentally, the last in-core caller of IsBackendPid() is now gone.  
However, the function is exported and must remain in place, because  
there are plenty of callers in external modules.  
  
Author: Josh Kupershmidt  
  
Reviewed by Noah Misch  

commit   : f7b836eb83dce05976dd07f71c92c16a718b89f6    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 25 Sep 2012 13:52:57 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 25 Sep 2012 13:52:57 -0400    

The syntax "su -c 'command' username" is not accepted by all versions of  
su, for example not OpenBSD's.  More portable is "su username -c  
'command'".  So change runtime.sgml to recommend that syntax.  Also,  
add a -D switch to the OpenBSD example script, for consistency with other  
examples.  Per Denis Lapshin and Gábor Hidvégi.  

commit   : d2292f6405670e1fdac13998f87b4348c71fb9e6    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 24 Sep 2012 00:18:17 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 24 Sep 2012 00:18:17 -0400    

Small oversight in commit 0f524ea0cf388a149f362e48a33c01662eeddc04 ...  
per report from Grazvydas Valeika.