PostgreSQL 9.0.12 commit log

commit   : 3da04a0bb19f8543a9b13becdfeb96624e15288e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 4 Feb 2013 16:12:28 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 4 Feb 2013 16:12:28 -0500    

commit   : 16d10970cb61843b937c84bf1a2d102ed54834c1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 4 Feb 2013 16:25:20 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 4 Feb 2013 16:25:20 -0500    

This function was misdeclared to take cstring when it should take internal.  
This at least allows crashing the server, and in principle an attacker  
might be able to use the function to examine the contents of server memory.  
  
The correct fix is to adjust the system catalog contents (and fix the  
regression tests that should have caught this but failed to).  However,  
asking users to correct the catalog contents in existing installations  
is a pain, so as a band-aid fix for the back branches, install a check  
in enum_recv() to make it throw error if called with a cstring argument.  
We will later revert this in HEAD in favor of correcting the catalogs.  
  
Our thanks to Sumit Soni (via Secunia SVCRP) for reporting this issue.  
  
Security: CVE-2013-0255  

commit   : 0499ff2567475ccd93b07183d4bb44d29ba1c006    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 4 Feb 2013 15:50:53 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 4 Feb 2013 15:50:53 -0500    

commit   : e3729932ebc4ed4ab2a9278fc8bb162c1f25fa73    
  
author   : Simon Riggs <simon@2ndQuadrant.com>    
date     : Mon, 4 Feb 2013 16:44:01 +0000    
  
committer: Simon Riggs <simon@2ndQuadrant.com>    
date     : Mon, 4 Feb 2013 16:44:01 +0000    

commit   : 8e2469a02d59d1c506a20e957da8a02c222a53e8    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Sun, 3 Feb 2013 23:56:29 -0500    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Sun, 3 Feb 2013 23:56:29 -0500    

commit   : 59f800d05866ef447e1337bc8f2c9a54063f6eba    
  
author   : Simon Riggs <simon@2ndQuadrant.com>    
date     : Sat, 2 Feb 2013 18:55:03 +0000    
  
committer: Simon Riggs <simon@2ndQuadrant.com>    
date     : Sat, 2 Feb 2013 18:55:03 +0000    

Following bug analysis of #7819 by Tom Lane  

commit   : 275a86bed8a09d372eb8e02966a847f0321aaa32    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 1 Feb 2013 12:00:40 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 1 Feb 2013 12:00:40 -0300    

The original code used freeze_min_age instead of freeze_table_age.  The  
main consequence of this mistake is that lowering freeze_min_age would  
cause full-table scans to occur much more frequently, which causes  
serious issues because the number of writes required is much larger.  
That feature (freeze_min_age) is supposed to affect only how soon tuples  
are frozen; some pages should still be skipped due to the visibility  
map.  
  
Backpatch to 8.4, where the freeze_table_age feature was introduced.  
  
Report and patch from Andres Freund  

commit   : 7c0e6cc961733189d92b593d9e1588909aae23ec    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Thu, 31 Jan 2013 15:08:05 +0100    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Thu, 31 Jan 2013 15:08:05 +0100    

This ensure the version number increases over time. The first three digits  
in the version number is still set to the actual PostgreSQL version  
number, but the last one is intended to be an ever increasing build number,  
which previosly failed when it changed between 1, 2 and 3 digits long values.  
  
Noted by Deepak  

commit   : 969dc8cce922e58fa5dd6f945678ecd531fdb6a6    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 30 Jan 2013 14:16:44 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 30 Jan 2013 14:16:44 -0500    

Such cases should work, but the grammar failed to accept them because of  
our ancient precedence hacks to convince bison that extra parentheses  
around a sub-SELECT in an expression are unambiguous.  (Formally, they  
*are* ambiguous, but we don't especially care whether they're treated as  
part of the sub-SELECT or part of the expression.  Bison cares, though.)  
Fix by adding a redundant-looking production for this case.  
  
This is a fine example of why fixing shift/reduce conflicts via  
precedence declarations is more dangerous than it looks: you can easily  
cause the parser to reject cases that should work.  
  
This has been wrong since commit 3db4056e22b0c6b2adc92543baf8408d2894fe91  
or maybe before, and apparently some people have been working around it  
by inserting no-op casts.  That method introduces a dump/reload hazard,  
as illustrated in bug #7838 from Jan Mate.  Hence, back-patch to all  
active branches.  

commit   : 8879c3503726534af58e61ce5ab1e26d70877696    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 28 Jan 2013 17:46:47 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 28 Jan 2013 17:46:47 -0300    

My "fix" for bugs #7578 and #6116 on DROP OWNED at fe3b5eb08a1 not only  
misstated that it applied to REASSIGN OWNED (which it did not affect),  
but it also failed to fix the problems fully, because I didn't test the  
case of owned shared objects.  Thus I created a new bug, reported by  
Thomas Kellerer as #7748, which would cause DROP OWNED to fail with a  
not-for-user-consumption error message.  The code would attempt to drop  
the database, which not only fails to work because the underlying code  
does not support that, but is a pretty dangerous and undesirable thing  
to be doing as well.  
  
This patch fixes that bug by having DROP OWNED only attempt to process  
shared objects when grants on them are found, ignoring ownership.  
  
Backpatch to 8.3, which is as far as the previous bug was backpatched.  

commit   : 2dde6751a041efd67bfe59fb957e2b011477156f    
  
author   : Michael Meskes <meskes@postgresql.org>    
date     : Sun, 27 Jan 2013 13:48:12 +0100    
  
committer: Michael Meskes <meskes@postgresql.org>    
date     : Sun, 27 Jan 2013 13:48:12 +0100    

Bug reported and fixed by Chen Huajun <chenhj@cn.fujitsu.com>.  

commit   : ecfbbfc0ef70f2b6b8744e2da3ec54fd7ef8c357    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 25 Jan 2013 11:39:17 -0500    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 25 Jan 2013 11:39:17 -0500    

These were broken by my recent backpatch of  
the simple prompt fix. These older versions  
used DEVTTY, so import the definition from  
psql's command.c.  

commit   : 6121539aca2c797b8a9a78bb642ed060a9209d8e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 24 Jan 2013 18:34:15 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 24 Jan 2013 18:34:15 -0500    

Since 9.0, the count parameter has only limited the number of tuples  
actually returned by the executor.  It doesn't affect the behavior of  
INSERT/UPDATE/DELETE unless RETURNING is specified, because without  
RETURNING, the ModifyTable plan node doesn't return control to execMain.c  
for each tuple.  And we only check the limit at the top level.  
  
While this behavioral change was unintentional at the time, discussion of  
bug #6572 led us to the conclusion that we prefer the new behavior anyway,  
and so we should just adjust the docs to match rather than change the code.  
Accordingly, do that.  Back-patch as far as 9.0 so that the docs match the  
code in each branch.  

commit   : 474cfc390a83964f9e2154ada5d28e6cc7c4a395    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Thu, 24 Jan 2013 16:01:31 -0500    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Thu, 24 Jan 2013 16:01:31 -0500    

This ensures that mapping of non-ascii prompts  
to the correct code page occurs.  
  
Bug report and original patch from Alexander Law,  
reviewed and reworked by Noah Misch.  
  
Backpatch to all live branches.  

commit   : 3a25b2d70c28942cf2c5e4d90d3a643baf845dfc    
  
author   : Simon Riggs <simon@2ndQuadrant.com>    
date     : Thu, 24 Jan 2013 14:25:28 +0000    
  
committer: Simon Riggs <simon@2ndQuadrant.com>    
date     : Thu, 24 Jan 2013 14:25:28 +0000    

Backpatchable fix to 9.0  
  
Detailed bug report and fix by Noah Misch,  
backpatchable version by me.  

commit   : 56d2975c3cae0bc795baf1d2e29e46875f5eaca5    
  
author   : Kevin Grittner <kgrittn@postgresql.org>    
date     : Wed, 23 Jan 2013 13:40:19 -0600    
  
committer: Kevin Grittner <kgrittn@postgresql.org>    
date     : Wed, 23 Jan 2013 13:40:19 -0600    

In situations where there are over 8MB of empty pages at the end of  
a table, the truncation work for trailing empty pages takes longer  
than deadlock_timeout, and there is frequent access to the table by  
processes other than autovacuum, there was a problem with the  
autovacuum worker process being canceled by the deadlock checking  
code. The truncation work done by autovacuum up that point was  
lost, and the attempt tried again by a later autovacuum worker. The  
attempts could continue indefinitely without making progress,  
consuming resources and blocking other processes for up to  
deadlock_timeout each time.  
  
This patch has the autovacuum worker checking whether it is  
blocking any other thread at 20ms intervals. If such a condition  
develops, the autovacuum worker will persist the work it has done  
so far, release its lock on the table, and sleep in 50ms intervals  
for up to 5 seconds, hoping to be able to re-acquire the lock and  
try again. If it is unable to get the lock in that time, it moves  
on and a worker will try to continue later from the point this one  
left off.  
  
While this patch doesn't change the rules about when and what to  
truncate, it does cause the truncation to occur sooner, with less  
blocking, and with the consumption of fewer resources when there is  
contention for the table's lock.  
  
The only user-visible change other than improved performance is  
that the table size during truncation may change incrementally  
instead of just once.  
  
Backpatched to 9.0 from initial master commit at  
b19e4250b45e91c9cbdd18d35ea6391ab5961c8d -- before that the  
differences are too large to be clearly safe.  
  
Jan Wieck  

commit   : e4cfb5f2e6c7ab8921c174ea44e628d3768646a8    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 20 Jan 2013 23:44:01 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 20 Jan 2013 23:44:01 -0500    

This bug goes back to the original Postgres95 sources.  Its significance  
to modern PG versions is marginal, since we have not used PQprintTuples()  
internally in a very long time, and it doesn't seem to have ever been  
documented either.  Still, it *is* exposed to client apps, so somebody  
out there might possibly be using it.  
  
Xi Wang  

commit   : e64a48e69978a78c2a20c467063c382590a9b1af    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Sun, 20 Jan 2013 19:36:30 -0500    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Sun, 20 Jan 2013 19:36:30 -0500    

Leading white space before the "http:" is apparently treated as a  
relative link at least by some browsers.  

commit   : da6c7aff1a0cc14966a3f528e60010e34200451b    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Sat, 19 Jan 2013 14:54:29 -0500    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Sat, 19 Jan 2013 14:54:29 -0500    

Complaint and patch from Zoltán Böszörményi.  
  
When cross-compiling, the native make doesn't know  
about the Windows .exe suffix, so it only builds with  
it when explicitly told to do so.  
  
The native make will not see the link between the target  
name and the built executable, and might this do unnecesary  
work, but that's a bigger problem than this one, if in fact  
we consider it a problem at all.  
  
Back-patch to all live branches.  

commit   : 92c1f917b865c2672a21a3029e2c6f777e6f8641    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 18 Jan 2013 18:06:38 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 18 Jan 2013 18:06:38 -0500    

Use of SnapshotNow is known to expose us to race conditions if the tuple(s)  
being sought could be updated by concurrently-committing transactions.  
CREATE DATABASE and DROP DATABASE are particularly exposed because they do  
heavyweight filesystem operations during their scans of pg_tablespace,  
so that the scans run for a very long time compared to most.  Furthermore,  
the potential consequences of a missed or twice-visited row are nastier  
than average:  
  
* createdb() could fail with a bogus "file already exists" error, or  
  silently fail to copy one or more tablespace's worth of files into the  
  new database.  
  
* remove_dbtablespaces() could miss one or more tablespaces, thus failing  
  to free filesystem space for the dropped database.  
  
* check_db_file_conflict() could likewise miss a tablespace, leading to an  
  OID conflict that could result in data loss either immediately or in  
  future operations.  (This seems of very low probability, though, since a  
  duplicate database OID would be unlikely to start with.)  
  
Hence, it seems worth fixing these three places to use MVCC snapshots, even  
though this will someday be superseded by a generic solution to SnapshotNow  
race conditions.  
  
Back-patch to all active branches.  
  
Stephen Frost and Tom Lane  

commit   : 801babf0d7d5fe3caecbeab0eaf1c4f6bf5eb59e    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 15 Jan 2013 22:09:41 +0200    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 15 Jan 2013 22:09:41 +0200    

"none" could mislead to think that you're connected a database with that  
name. Also, it needs to be translated, which might be hard without some  
context. So in back-branches, use empty string, so that the message is  
(currently ""), which is at least unambiguous and doens't require  
translation. In master, it's no problem to add translatable strings, so use  
a different fix there.  

commit   : bb9a9a9d37f664c2dd7d715b25058e8bc21f99b0    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 15 Jan 2013 18:54:03 +0200    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 15 Jan 2013 18:54:03 +0200    

Backpatch all the way to 8.3. Fixes bug #7811, per report and diagnosis by  
Meng Qingzhong.  

commit   : 78298daa4e4c890cf397f9aaf4598987bb2f6d5b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 14 Jan 2013 15:19:48 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 14 Jan 2013 15:19:48 -0500    

Dates outside the supported range could be entered, but would not print  
reasonably, and operations such as conversion to timestamp wouldn't behave  
sanely either.  Since this has the potential to result in undumpable table  
data, it seems worth back-patching.  
  
Hitoshi Harada  

commit   : ec6de23a0c0d33bb170252bab4ff5e835f9f3bf2    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 14 Jan 2013 14:45:40 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 14 Jan 2013 14:45:40 -0500    

This seems to have been invented in 2011 to represent GMT+3, non daylight  
savings rules, as now used in Europe/Kaliningrad and Europe/Minsk.  
There are no conflicts so might as well add it to the Default list.  
Per bug #7804 from Ruslan Izmaylov.  

commit   : ecf5c1e90e36abcbdb56734535705028c5765a3e    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Wed, 9 Jan 2013 17:34:18 +0100    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Wed, 9 Jan 2013 17:34:18 +0100    

JiangGuiqing  

commit   : 3111af5d1f1a0a66d4e6a2145431ef76127fd3b1    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 1 Jan 2013 17:14:59 -0500    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 1 Jan 2013 17:14:59 -0500    

Fully update git head, and update back branches in ./COPYRIGHT and  
legal.sgml files.  

commit   : 2373ce3ff8c08115157cc40de5383d4ed0e01cca    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Sat, 29 Dec 2012 22:58:07 -0500    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Sat, 29 Dec 2012 22:58:07 -0500    

Parts of the description had claimed incorrect pg_hba.conf option names  
for LDAP authentication.  
  
Albe Laurenz  

commit   : a91c411772fdc9708c535e78d6fec26eacd45b24    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 23 Dec 2012 14:07:42 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 23 Dec 2012 14:07:42 -0500    

transformExpr() is required to cope with already-transformed expression  
trees, for various ugly-but-not-quite-worth-cleaning-up reasons.  However,  
some of its newer subroutines hadn't gotten the memo.  This accounts for  
bug #7763 from Norbert Buchmuller: transformRowExpr() was overwriting the  
previously determined type of a RowExpr during CREATE TABLE LIKE INCLUDING  
INDEXES.  Additional investigation showed that transformXmlExpr had the  
same kind of problem, but all the other cases seem to be safe.  
  
Andres Freund and Tom Lane  

commit   : e5e8ad3df5245cbed7f54674ed2cca596a7f55d6    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 18 Dec 2012 16:22:31 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 18 Dec 2012 16:22:31 -0500    

Some versions of libedit expose bogus definitions of setproctitle(),  
optreset, and perhaps other symbols that we don't want configure to pick up  
on.  There was a previous report of similar problems with strlcpy(), which  
we addressed in commit 59cf88da91bc88978b05275ebd94ac2d980c4047, but the  
problem has evidently grown in scope since then.  In hopes of not having to  
deal with it again in future, rearrange configure's tests for supplied  
functions so that we ignore libedit/libreadline except when probing  
specifically for functions we expect them to provide.  
  
Per report from Christoph Berg, though this is slightly more aggressive  
than his proposed patch.  

commit   : 60f95d0596620ef2493893450e1862bc376ede1a    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 18 Dec 2012 01:21:59 -0500    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 18 Dec 2012 01:21:59 -0500    

commit   : d8caaacc9fad0395d9360481549d9a2c6ffeb1ad    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 11 Dec 2012 22:09:29 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 11 Dec 2012 22:09:29 -0500    

The dynahash code requires the number of buckets in a hash table to fit  
in an int; but since we calculate the desired hash table size dynamically,  
there are various scenarios where we might calculate too large a value.  
The resulting overflow can lead to infinite loops, division-by-zero  
crashes, etc.  I (tgl) had previously installed some defenses against that  
in commit 299d1716525c659f0e02840e31fbe4dea3, but that covered only one  
call path.  Moreover it worked by limiting the request size to work_mem,  
but in a 64-bit machine it's possible to set work_mem high enough that the  
problem appears anyway.  So let's fix the problem at the root by installing  
limits in the dynahash.c functions themselves.  
  
Trouble report and patch by Jeff Davis.  

commit   : 33be41d3adcf8bd272303e0f5dcc4ec41051f141    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 11 Dec 2012 15:09:22 -0500    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 11 Dec 2012 15:09:22 -0500    

All versions of pg_upgrade upgraded invalid indexes caused by CREATE  
INDEX CONCURRENTLY failures and marked them as valid.  The patch adds a  
check to all pg_upgrade versions and throws an error during upgrade or  
--check.  
  
Backpatch to 9.2, 9.1, 9.0.  Patch slightly adjusted.  

commit   : 5840e3181b7e6c784fdb3aff708c4dcc2dfe551d    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 11 Dec 2012 15:57:24 +0200    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 11 Dec 2012 15:57:24 +0200    

EndRecPtr is the last record that we've read, but not necessarily yet  
replayed. CheckRecoveryConsistency should compare minRecoveryPoint with the  
last replayed record instead. This caused recovery to think it's reached  
consistency too early.  
  
Now that we do the check in CheckRecoveryConsistency correctly, we have to  
move the call of that function to after redoing a record. The current place,  
after reading a record but before replaying it, is wrong. In particular, if  
there are no more records after the one ending at minRecoveryPoint, we don't  
enter hot standby until one extra record is generated and read by the  
standby, and CheckRecoveryConsistency is called. These two bugs conspired  
to make the code appear to work correctly, except for the small window  
between reading the last record that reaches minRecoveryPoint, and  
replaying it.  
  
In the passing, rename recoveryLastRecPtr, which is the last record  
replayed, to lastReplayedEndRecPtr. This makes it slightly less confusing  
with replayEndRecPtr, which is the last record read that we're about to  
replay.  
  
Original report from Kyotaro HORIGUCHI, further diagnosis by Fujii Masao.  
Backpatch to 9.0, where Hot Standby subtly changed the test from  
"minRecoveryPoint < EndRecPtr" to "minRecoveryPoint <= EndRecPtr". The  
former works because where the test is performed, we have always read one  
more record than we've replayed.  

commit   : fe20ff0c5646c49c14cd944c284d20bea91fba52    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Tue, 11 Dec 2012 11:48:00 -0500    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Tue, 11 Dec 2012 11:48:00 -0500    

Normally each module is tested in a database named contrib_regression,  
which is dropped and recreated at the beginhning of each pg_regress run.  
This new 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.  
  
Second attempt at this, this time accomodating make versions older  
than 3.82.  
  
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   : 172d067618cc80b515a7ae89fd6a38e29e71a720    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 10 Dec 2012 15:54:42 +0200    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 10 Dec 2012 15:54:42 +0200    

If a file is truncated, we must update minRecoveryPoint. Once a file is  
truncated, there's no going back; it would not be safe to stop recovery  
at a point earlier than that anymore.  
  
Per report from Kyotaro HORIGUCHI. Backpatch to 8.4. Before that,  
minRecoveryPoint was not updated during recovery at all.  

commit   : 0dfbb64a2d7b8caa4ab1d40a99adbdab594397c0    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Sat, 8 Dec 2012 07:36:25 -0500    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Sat, 8 Dec 2012 07:36:25 -0500    

The old one is responding with 404.  

commit   : 2e375ab4b5b1b4308e4c16fc755e45c1ccf1988e    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 4 Dec 2012 12:23:36 -0500    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 4 Dec 2012 12:23:36 -0500    

commit   : f928ffd65e1f48f6d5022e0cda701abd1abd9b0e    
  
author   : Michael Meskes <meskes@postgresql.org>    
date     : Tue, 4 Dec 2012 16:35:18 +0100    
  
committer: Michael Meskes <meskes@postgresql.org>    
date     : Tue, 4 Dec 2012 16:35:18 +0100    

Patch done by Jiang Guiqing <jianggq@cn.fujitsu.com>.