PostgreSQL 9.1.7 commit log

commit   : c47f643c49d1f56c388dd0e7405ed280cfa9d0b2    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 3 Dec 2012 15:19:35 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 3 Dec 2012 15:19:35 -0500    

commit   : 86e006d9ed64db7ceafdc8365208139278c5da60    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 3 Dec 2012 15:10:10 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 3 Dec 2012 15:10:10 -0500    

commit   : 13632b0c14cca224a03c2ed76933d0700579dd8a    
  
author   : Andrew Dunstan <[email protected]>    
date     : Mon, 3 Dec 2012 15:03:15 -0500    
  
committer: Andrew Dunstan <[email protected]>    
date     : Mon, 3 Dec 2012 15:03:15 -0500    

This reverts commit 513e546a6e75b0a79c3102ce22c583ccd1053ac6.  

commit   : 3c4eec4488fef07675db85e73445f410dac732dd    
  
author   : Simon Riggs <[email protected]>    
date     : Mon, 3 Dec 2012 18:55:42 +0000    
  
committer: Simon Riggs <[email protected]>    
date     : Mon, 3 Dec 2012 18:55:42 +0000    

Bug report and suggested fix from Pavan Deolasee  

commit   : e0aad34a6b1afa4fc165849d2743f769e550f022    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 3 Dec 2012 11:08:59 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 3 Dec 2012 11:08:59 -0500    

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

commit   : 04a210b090ee9ff3ff4c148c07dff62eb4c30f92    
  
author   : Peter Eisentraut <[email protected]>    
date     : Mon, 3 Dec 2012 07:53:51 -0500    
  
committer: Peter Eisentraut <[email protected]>    
date     : Mon, 3 Dec 2012 07:53:51 -0500    

commit   : 513e546a6e75b0a79c3102ce22c583ccd1053ac6    
  
author   : Andrew Dunstan <[email protected]>    
date     : Sun, 2 Dec 2012 17:29:30 -0500    
  
committer: Andrew Dunstan <[email protected]>    
date     : Sun, 2 Dec 2012 17:29:30 -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   : 31ab8936c770545d6aaa09d348661ce175f9b33d    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 2 Dec 2012 16:35:23 -0500    
  
committer: Tom Lane <[email protected]>    
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   : 7e487c1b0acbb26a481e64570dcbfe39b3e54abb    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 2 Dec 2012 16:17:53 -0500    
  
committer: Tom Lane <[email protected]>    
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   : d08fd1f849ba7419b79094e6cf863b6c190784b5    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 2 Dec 2012 15:20:08 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 2 Dec 2012 15:20:08 -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   : 973c011639e1aecf7256de07e2aa8520f9b49035    
  
author   : Simon Riggs <[email protected]>    
date     : Sun, 2 Dec 2012 15:01:44 +0000    
  
committer: Simon Riggs <[email protected]>    
date     : Sun, 2 Dec 2012 15:01:44 +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   : a7c53092d88bf9c617713389bc11f0670762b723    
  
author   : Tatsuo Ishii <[email protected]>    
date     : Sun, 2 Dec 2012 21:11:15 +0900    
  
committer: Tatsuo Ishii <[email protected]>    
date     : Sun, 2 Dec 2012 21:11:15 +0900    

commit   : 647b1bcdfd26f786248366e4fb25c0fd62006329    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 1 Dec 2012 17:24:01 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 1 Dec 2012 17:24:01 -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   : 04f91ae5d0caa5faae7100eac3b0ade6f84e1e9e    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 1 Dec 2012 16:04:50 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 1 Dec 2012 16:04:50 -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   : 1b4359b55d8fe32a54460c3ea00567a2fafa6b9c    
  
author   : Peter Eisentraut <[email protected]>    
date     : Sat, 1 Dec 2012 01:52:23 -0500    
  
committer: Peter Eisentraut <[email protected]>    
date     : Sat, 1 Dec 2012 01:52:23 -0500    

commit   : 2b96c32d5361f443b00d17bfbe1fc84dcdd6fbc0    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 30 Nov 2012 17:02:39 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 30 Nov 2012 17:02:39 -0500    

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

commit   : df1aa462852309c6a3c53b81c296de61e7f5504c    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 30 Nov 2012 13:56:04 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 30 Nov 2012 13:56:04 -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   : c6a91c92b51a13f204495851cf7a90e55ec16f0a    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 29 Nov 2012 19:57:17 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 29 Nov 2012 19:57:17 -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   : 6f9a9da85c9015e773d12e8571c469e5a2a6b3fb    
  
author   : Simon Riggs <[email protected]>    
date     : Thu, 29 Nov 2012 23:52:17 +0000    
  
committer: Simon Riggs <[email protected]>    
date     : Thu, 29 Nov 2012 23:52:17 +0000    

commit   : 1da5bef3174170a6768bea6621afcbf72dd02a87    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 29 Nov 2012 14:50:31 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 29 Nov 2012 14:50:31 -0500    

This patch changes CREATE INDEX CONCURRENTLY so that the pg_index  
flag changes it makes 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.  
  
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.  
  
This is a subset of a patch already applied in 9.2 and HEAD.  Back-patch  
into all earlier supported branches.  
  
Tom Lane and Andres Freund  

commit   : 381c3b8f4cba2d7d30d7010c28b06c076093876f    
  
author   : Michael Meskes <[email protected]>    
date     : Thu, 29 Nov 2012 17:12:00 +0100    
  
committer: Michael Meskes <[email protected]>    
date     : Thu, 29 Nov 2012 17:12:00 +0100    

Applied patch by Muhammad Usama <[email protected]> to fix this.  

commit   : bdceb861d7c8034f69ab07a11f2f2603d6d74b3e    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 26 Nov 2012 12:57:30 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 26 Nov 2012 12:57:30 -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   : 38b38fb12244c640230b1fd71d2c55ecc04844fa    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Fri, 23 Nov 2012 18:51:51 +0200    
  
committer: Heikki Linnakangas <[email protected]>    
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   : 806e6d1ddb90fcbc3b59b17434cafeb4af51c126    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 22 Nov 2012 11:23:33 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 22 Nov 2012 11:23:33 -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   : db3658b34faed7e247c9dc61e39a3a054c3cb5d8    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Thu, 22 Nov 2012 11:23:46 +0200    
  
committer: Heikki Linnakangas <[email protected]>    
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   : 866f2dd78414c63a5fcd22ae3a36916e4da164b6    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 21 Nov 2012 15:18:47 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 21 Nov 2012 15:18:47 -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   : 4387cc9ab4ad7e037df32e93c8435e34b5832cc5    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 19 Nov 2012 21:21:40 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 19 Nov 2012 21:21:40 -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   : fe838e5074149058a1101092d3a557e4b86b8ff2    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 18 Nov 2012 17:15:16 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 18 Nov 2012 17:15:16 -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   : e9ad86ce6803faecda721311ff04dde88b38583b    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 14 Nov 2012 17:30:07 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 14 Nov 2012 17:30:07 -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   : 68a8ea6046a0583171a34269688a2bcd8d2f8f08    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 13 Nov 2012 14:44:40 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 13 Nov 2012 14:44:40 -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   : d0d58f7aa94986edbab6c000470707b90ef37d54    
  
author   : Simon Riggs <[email protected]>    
date     : Tue, 13 Nov 2012 15:58:05 -0300    
  
committer: Simon Riggs <[email protected]>    
date     : Tue, 13 Nov 2012 15:58:05 -0300    

Andres Freund and Simon Riggs  

commit   : 634e148dcaa1ec77aba4f5eac883285e8f225268    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 12 Nov 2012 22:05:21 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 12 Nov 2012 22:05:21 -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   : f8ffe6234a09faeaabe034643b619462df897ca9    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 11 Nov 2012 19:56:21 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 11 Nov 2012 19:56:21 -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   : 1458f0f1dab91458bd4f4f731a64a7a52fe028d1    
  
author   : Peter Eisentraut <[email protected]>    
date     : Thu, 8 Nov 2012 23:55:36 -0500    
  
committer: Peter Eisentraut <[email protected]>    
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   : f43ca3c8945fb60ed409b7768b0ce5ee0437161e    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 5 Nov 2012 13:36:26 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 5 Nov 2012 13:36:26 -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   : efa81e3c946654f5d5b0a752def609416d32e056    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 1 Nov 2012 19:49:02 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 1 Nov 2012 19:49:02 -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   : c22acf455842765e08f58ee308a43882cfcc13d4    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 31 Oct 2012 14:26:20 -0400    
  
committer: Tom Lane <[email protected]>    
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   : 65225900de86044948c70e9732d02d99412eb171    
  
author   : Alvaro Herrera <[email protected]>    
date     : Wed, 31 Oct 2012 10:49:14 -0300    
  
committer: Alvaro Herrera <[email protected]>    
date     : Wed, 31 Oct 2012 10:49:14 -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   : ff8f7103b559d8f19731157aca38650a938fedef    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 26 Oct 2012 14:19:47 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 26 Oct 2012 14:19:47 -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   : 5110a96992e508b220a7a6ab303b0501c4237b4a    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 26 Oct 2012 12:12:53 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 26 Oct 2012 12:12:53 -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   : f01936f70b58dec8136399f6258b37d762c3cec3    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 24 Oct 2012 14:53:58 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 24 Oct 2012 14:53:58 -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   : d01a7442190686a981c0a5ce330e962d8083ac4f    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 19 Oct 2012 15:24:15 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 19 Oct 2012 15:24:15 -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   : 823f83d3d53ad2c0e799b1953ed9a1955840f11c    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 19 Oct 2012 13:40:05 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 19 Oct 2012 13:40:05 -0400    

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

commit   : d2a5f326568dfe98559319db6f3b9d08f0c851cc    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Thu, 18 Oct 2012 22:26:26 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
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   : 447dad7193721f757dddf7c409b0b75aa2b5fb98    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 18 Oct 2012 12:29:00 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 18 Oct 2012 12:29:00 -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   : 473320e6c87cc7ffc704b2823c685b3dd13c0342    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 17 Oct 2012 12:38:33 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 17 Oct 2012 12:38:33 -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   : cacb65263b99c3d96aa4b250cdbda05072ade03e    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 17 Oct 2012 12:37:20 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 17 Oct 2012 12:37:20 -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   : f34d1fa0c8bd587a165234e0971bba8dc5e1fd2a    
  
author   : Simon Riggs <[email protected]>    
date     : Wed, 17 Oct 2012 09:20:42 +0100    
  
committer: Simon Riggs <[email protected]>    
date     : Wed, 17 Oct 2012 09:20:42 +0100    

commit   : 3877b1fa17fc9003691d890cec5557c64db05462    
  
author   : Simon Riggs <[email protected]>    
date     : Wed, 17 Oct 2012 08:27:27 +0100    
  
committer: Simon Riggs <[email protected]>    
date     : Wed, 17 Oct 2012 08:27:27 +0100    

commit   : 288367427472f3d300c51ff9941eb486cfc01c6a    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Sat, 13 Oct 2012 12:48:14 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
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   : eb5e0d8488451bcfcf81e26fd82dd9687c99b941    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 14 Oct 2012 23:00:07 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 14 Oct 2012 23:00:07 -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   : de31ea98a2c993cf1517f83112fc595f96f56b8a    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 11 Oct 2012 12:21:09 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 11 Oct 2012 12:21:09 -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   : bd0ef304f8a306522983f3b4b06274fdc45beed8    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 9 Oct 2012 21:04:15 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 9 Oct 2012 21:04:15 -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   : bb3aa7a484a53d80784c367e2ff272b8730e338d    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 8 Oct 2012 21:52:48 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 8 Oct 2012 21:52:48 -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   : a883c02449cf86a657838303213d11ad85939b1d    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 8 Oct 2012 21:18:57 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 8 Oct 2012 21:18:57 -0400    

lo_export returns -1, not zero, on failure.  

commit   : 3c856708e56ceb7025066a800c95b7293e9bd3f5    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Mon, 8 Oct 2012 14:17:27 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Mon, 8 Oct 2012 14:17:27 +0300    

Tomonaru Katsumata  

commit   : 8ebe8889a8c5604b66802508b822cf18b8cd6820    
  
author   : Michael Meskes <[email protected]>    
date     : Fri, 5 Oct 2012 16:49:27 +0200    
  
committer: Michael Meskes <[email protected]>    
date     : Fri, 5 Oct 2012 16:49:27 +0200    

commit   : 856ce0fb563a630ddd07dfad8cb4d8eb1d601b77    
  
author   : Michael Meskes <[email protected]>    
date     : Fri, 5 Oct 2012 16:37:45 +0200    
  
committer: Michael Meskes <[email protected]>    
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   : 6c33084fa2eb1c1cce61def72d8eb7c91a69d525    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 4 Oct 2012 13:41:09 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 4 Oct 2012 13:41:09 -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   : 412a4295b5390cfe4fd5b9fc84a25c6e2d1aa0ad    
  
author   : Alvaro Herrera <[email protected]>    
date     : Wed, 3 Oct 2012 12:22:41 -0300    
  
committer: Alvaro Herrera <[email protected]>    
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 [email protected].  

commit   : 6c00b2bbf7726efdf7d96ad5c9e9ef0450d2a150    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Tue, 2 Oct 2012 10:43:48 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
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   : d617b28c6cc315d1aa1a4855673dd9eb121dcf73    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 29 Sep 2012 17:56:50 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 29 Sep 2012 17:56:50 -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   : dfa6eda5e44f1525aa6b142b8e252f5a79110ee6    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 28 Sep 2012 15:35:51 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 28 Sep 2012 15:35:51 -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   : bc99397563ff88c31078d4bf66b8538c78a08bda    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 25 Sep 2012 13:53:01 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 25 Sep 2012 13:53:01 -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.