PostgreSQL 9.1.8 commit log

commit   : 69c026512f1141a92dca118768d858e59d76a994    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 4 Feb 2013 16:10:31 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 4 Feb 2013 16:10:31 -0500    

commit   : 1881634820603e8212983ebd4825d4f4b4988789    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 4 Feb 2013 16:25:15 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 4 Feb 2013 16:25:15 -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   : 51d0efe8a2bd6c64f245fcc60a2fba07b9e3b6f6    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 4 Feb 2013 15:50:49 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 4 Feb 2013 15:50:49 -0500    

commit   : 2113574be8467e044a74b7eb4da6841e78384e2e    
  
author   : Simon Riggs <[email protected]>    
date     : Mon, 4 Feb 2013 16:42:12 +0000    
  
committer: Simon Riggs <[email protected]>    
date     : Mon, 4 Feb 2013 16:42:12 +0000    

commit   : 390523596deb3ee772555efc47953cad4b641197    
  
author   : Peter Eisentraut <[email protected]>    
date     : Sun, 3 Feb 2013 23:58:38 -0500    
  
committer: Peter Eisentraut <[email protected]>    
date     : Sun, 3 Feb 2013 23:58:38 -0500    

commit   : ac148a2e9375708170d9c582da4c719832a89f6f    
  
author   : Simon Riggs <[email protected]>    
date     : Sat, 2 Feb 2013 18:51:21 +0000    
  
committer: Simon Riggs <[email protected]>    
date     : Sat, 2 Feb 2013 18:51:21 +0000    

Following bug analysis of #7819 by Tom Lane  

commit   : 3c6e719eac07f64fb6672e0bc20547957a87575a    
  
author   : Alvaro Herrera <[email protected]>    
date     : Fri, 1 Feb 2013 12:00:40 -0300    
  
committer: Alvaro Herrera <[email protected]>    
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   : 1d857a6036fa0e17c6c4f9ee116622956a8fe920    
  
author   : Magnus Hagander <[email protected]>    
date     : Thu, 31 Jan 2013 15:08:05 +0100    
  
committer: Magnus Hagander <[email protected]>    
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   : ec26900f9d44ec06311ea5296d7cd1e3f0776310    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 30 Jan 2013 14:16:34 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 30 Jan 2013 14:16:34 -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   : 3eae7940aeae78432e55ce18efb8ef5ea93f9295    
  
author   : Alvaro Herrera <[email protected]>    
date     : Mon, 28 Jan 2013 17:46:47 -0300    
  
committer: Alvaro Herrera <[email protected]>    
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   : f1a4b15871cc5a5c6c7a791c91cb4552e37dfb4f    
  
author   : Michael Meskes <[email protected]>    
date     : Sun, 27 Jan 2013 13:48:12 +0100    
  
committer: Michael Meskes <[email protected]>    
date     : Sun, 27 Jan 2013 13:48:12 +0100    

Bug reported and fixed by Chen Huajun <[email protected]>.  

commit   : 17dee323e7ff67863582f279e415a8228e0b99cd    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 25 Jan 2013 16:59:05 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 25 Jan 2013 16:59:05 -0500    

plpython tried to use a single cache entry for a trigger function, but it  
needs a separate cache entry for each table the trigger is applied to,  
because there is table-dependent data in there.  This was done correctly  
before 9.1, but commit 46211da1b84bc3537e799ee1126098e71c2428e8 broke it  
by simplifying the lookup key from "function OID and triggered table OID"  
to "function OID and is-trigger boolean".  Go back to using both OIDs  
as the lookup key.  Per bug report from Sandro Santilli.  
  
Andres Freund  

commit   : 812451d1c7a0ad298cdf3a5e04bd3e9d1d700664    
  
author   : Andrew Dunstan <[email protected]>    
date     : Fri, 25 Jan 2013 11:39:45 -0500    
  
committer: Andrew Dunstan <[email protected]>    
date     : Fri, 25 Jan 2013 11:39:45 -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   : a2d44f526ec4b9832b3fff852981652ba9d05e8a    
  
author   : Bruce Momjian <[email protected]>    
date     : Fri, 25 Jan 2013 11:25:56 -0500    
  
committer: Bruce Momjian <[email protected]>    
date     : Fri, 25 Jan 2013 11:25:56 -0500    

Per request from Thom Brown  

commit   : 881104a698b8c5bd686542337218fab9df2a4015    
  
author   : Robert Haas <[email protected]>    
date     : Fri, 25 Jan 2013 08:42:15 -0500    
  
committer: Robert Haas <[email protected]>    
date     : Fri, 25 Jan 2013 08:42:15 -0500    

Hopefully, this will unbreak the buildfarm.  
  
Andres Freund  

commit   : 1cc43979cf44db0b3da77e34493689fe13484fa0    
  
author   : Magnus Hagander <[email protected]>    
date     : Fri, 25 Jan 2013 09:44:14 +0100    
  
committer: Magnus Hagander <[email protected]>    
date     : Fri, 25 Jan 2013 09:44:14 +0100    

Noted by Joe Van Dyk  

commit   : 49e0ea5991bf00a68e753583738a6759b7b29f2d    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 24 Jan 2013 18:34:08 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 24 Jan 2013 18:34:08 -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   : 57d294a18891ef843c9c24f3f9f3076fa2cfcc23    
  
author   : Andrew Dunstan <[email protected]>    
date     : Thu, 24 Jan 2013 16:01:31 -0500    
  
committer: Andrew Dunstan <[email protected]>    
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   : 62b9e3a0ff2d9964e30635ceca825340e71087e1    
  
author   : Simon Riggs <[email protected]>    
date     : Thu, 24 Jan 2013 14:24:48 +0000    
  
committer: Simon Riggs <[email protected]>    
date     : Thu, 24 Jan 2013 14:24:48 +0000    

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

commit   : 5454344b968d6a189219cfd49af609a3e7d6af33    
  
author   : Kevin Grittner <[email protected]>    
date     : Wed, 23 Jan 2013 13:40:06 -0600    
  
committer: Kevin Grittner <[email protected]>    
date     : Wed, 23 Jan 2013 13:40:06 -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   : 2e892a15b966f5183b8aec8f4ba9d4133d2c1941    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 20 Jan 2013 23:43:56 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 20 Jan 2013 23:43:56 -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   : 4a6232cce315f58bb674dd7ce6bd9166aa58fdb3    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 20 Jan 2013 23:09:35 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 20 Jan 2013 23:09:35 -0500    

The code failed to detect an out-of-memory failure.  
  
Xi Wang  

commit   : ebab595579e5b65f479e998dd302d6f5fdd15869    
  
author   : Peter Eisentraut <[email protected]>    
date     : Sun, 20 Jan 2013 19:36:30 -0500    
  
committer: Peter Eisentraut <[email protected]>    
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   : 04edfb10a60cad0a1efa5a0c0bef9b88a2fd5eba    
  
author   : Magnus Hagander <[email protected]>    
date     : Sun, 20 Jan 2013 16:10:12 +0100    
  
committer: Magnus Hagander <[email protected]>    
date     : Sun, 20 Jan 2013 16:10:12 +0100    

Josh Kupershmidt  

commit   : 8c0b2afa38bbdf016c876e74371feee3c00b9f09    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 19 Jan 2013 17:20:32 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 19 Jan 2013 17:20:32 -0500    

Un-double the backslashes in the LIKE patterns, since  
standard_conforming_strings is now the default.  Just to be sure, include  
a command to set standard_conforming_strings to ON in the example.  
  
Back-patch to 9.1, where standard_conforming_strings became the default.  
  
Josh Kupershmidt, reviewed by Jeff Janes  

commit   : aaf5f5942a9f7ed24cf9d6487e5b6629ad0cfe43    
  
author   : Andrew Dunstan <[email protected]>    
date     : Sat, 19 Jan 2013 14:54:29 -0500    
  
committer: Andrew Dunstan <[email protected]>    
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   : c54ebcba5c4c11508dfa72e0d872d3b28e7ef58b    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 18 Jan 2013 18:06:32 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 18 Jan 2013 18:06:32 -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   : 66debecd0c2a507500384a2eb727664f916780f8    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Tue, 15 Jan 2013 22:09:41 +0200    
  
committer: Heikki Linnakangas <[email protected]>    
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   : 14fa9805604e829d96531581e71b45ddfddb4fc8    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Tue, 15 Jan 2013 18:54:03 +0200    
  
committer: Heikki Linnakangas <[email protected]>    
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   : d4c78c1811d14b14f47f3611bf2c2c1a35817988    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 14 Jan 2013 15:19:48 -0500    
  
committer: Tom Lane <[email protected]>    
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   : dc0c987574d89b4f257218e91adac1537a4c2c3e    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 14 Jan 2013 14:45:40 -0500    
  
committer: Tom Lane <[email protected]>    
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   : 2d9a455dba2a0f5e33e903f082f4666363c44ec0    
  
author   : Magnus Hagander <[email protected]>    
date     : Wed, 9 Jan 2013 17:34:18 +0100    
  
committer: Magnus Hagander <[email protected]>    
date     : Wed, 9 Jan 2013 17:34:18 +0100    

JiangGuiqing  

commit   : 93d83938fd452dd7143760ad132aa9d90c5b45e5    
  
author   : Bruce Momjian <[email protected]>    
date     : Tue, 1 Jan 2013 17:15:00 -0500    
  
committer: Bruce Momjian <[email protected]>    
date     : Tue, 1 Jan 2013 17:15:00 -0500    

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

commit   : 7b15bea03d77da3d911fbf4b7c7ab0f407b36d2e    
  
author   : Peter Eisentraut <[email protected]>    
date     : Sat, 29 Dec 2012 22:58:07 -0500    
  
committer: Peter Eisentraut <[email protected]>    
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   : 628ea7ea51e046bade9ce7f15dc9c41118e29f13    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 23 Dec 2012 14:07:36 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 23 Dec 2012 14:07:36 -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   : 14aa55df29ea69e453be4c46f8546d49365fc06b    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Fri, 21 Dec 2012 15:29:49 +0200    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Fri, 21 Dec 2012 15:29:49 +0200    

If a relation file was removed when the server-side counterpart of  
pg_basebackup was just about to open it to send it to the client, you'd  
get a "could not open file" error. Fix that.  
  
Backpatch to 9.1, this goes back to when pg_basebackup was introduced.  

commit   : 17a71067d03edfc7a0eddb5bff42f48fb1855d82    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 20 Dec 2012 16:31:10 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 20 Dec 2012 16:31:10 -0500    

If pg_extension_config_dump() is executed again for a table already listed  
in the extension's extconfig, the code was blindly making a new array entry.  
This does not seem useful.  Fix it to replace the existing array entry  
instead, so that it's possible for extension update scripts to alter the  
filter conditions for configuration tables.  
  
In addition, teach ALTER EXTENSION DROP TABLE to check for an extconfig  
entry for the target table, and remove it if present.  This is not a 100%  
solution because it's allowed for an extension update script to just  
summarily DROP a member table, and that code path doesn't go through  
ExecAlterExtensionContentsStmt.  We could probably make that case clean  
things up if we had to, but it would involve sticking a very ugly wart  
somewhere in the guts of dependency.c.  Since on the whole it seems quite  
unlikely that extension updates would want to remove pre-existing  
configuration tables, making the case possible with an explicit command  
seems sufficient.  
  
Per bug #7756 from Regina Obe.  Back-patch to 9.1 where extensions were  
introduced.  

commit   : 0d0501e80fbbe51a885b4fe2fe3b4f22ef3bed66    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Thu, 20 Dec 2012 21:30:59 +0200    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Thu, 20 Dec 2012 21:30:59 +0200    

After the recovery target timeline is changed, we would still recycle and  
preallocate WAL segments on the old target timeline. Those WAL segments  
created for the old timeline are a waste of space, although otherwise  
harmless.  
  
The problem is that when installing a recycled WAL segment as a future one,  
ThisTimeLineID is used to construct the filename. ThisTimeLineID is  
initialized in the checkpointer process to the recovery target timeline at  
startup, but it was not updated when the startup process chooses a new  
target timeline (recovery_target_timeline='latest'). To fix, always update  
ThisTimeLineID before recycling WAL segments at a restartpoint.  
  
This still leaves a small window where we might install WAL segments under  
wrong timeline ID, if the target timeline is changed just as we're about to  
start recycling. Also, when we're not on the target timeline yet, but still  
replaying some older timeline, we'll install WAL segments to the newer  
timeline anyway and they will still go wasted. We'll just live with the  
waste in that situation.  
  
Commit to 9.2 and 9.1. Older versions didn't change recovery target timeline  
after startup, and for master, I'll commit a slightly different variant of  
this.  

commit   : b487c39dfc0d1799b4ec2c8c711e121d539aac37    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 18 Dec 2012 16:22:24 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 18 Dec 2012 16:22:24 -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   : bd2acc2dc8119ae5657855c6adf19950a6fe18d4    
  
author   : Peter Eisentraut <[email protected]>    
date     : Tue, 18 Dec 2012 01:21:59 -0500    
  
committer: Peter Eisentraut <[email protected]>    
date     : Tue, 18 Dec 2012 01:21:59 -0500    

commit   : ed98b48bf437ae8f8a9dfa53b1f8b9bb235cb089    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 17 Dec 2012 20:15:45 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 17 Dec 2012 20:15:45 -0500    

During crash recovery, we remove disk files belonging to temporary tables,  
but the system catalog entries for such tables are intentionally not  
cleaned up right away.  Instead, the first backend that uses a temp schema  
is expected to clean out any leftover objects therein.  This approach  
requires that we be careful to ignore leftover temp tables (since any  
actual access attempt would fail), *even if their BackendId matches our  
session*, if we have not yet established use of the session's corresponding  
temp schema.  That worked fine in the past, but was broken by commit  
debcec7dc31a992703911a9953e299c8d730c778 which incorrectly removed the  
rd_islocaltemp relcache flag.  Put it back, and undo various changes  
that substituted tests like "rel->rd_backend == MyBackendId" for use  
of a state-aware flag.  Per trouble report from Heikki Linnakangas.  
  
Back-patch to 9.1 where the erroneous change was made.  In the back  
branches, be careful to add rd_islocaltemp in a spot in the struct that  
was alignment padding before, so as not to break existing add-on code.  

commit   : 9d39e9499944b61e0db4e8d2157ba58e8bc52b89    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 16 Dec 2012 15:02:07 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 16 Dec 2012 15:02:07 -0500    

We failed to ever fill the sixth line (LISTEN_ADDR), which caused the  
attempt to fill the seventh line (SHMEM_KEY) to fail, so that the shared  
memory key never got added to the file in standalone mode.  This has been  
broken since we added more content to our lock files in 9.1.  
  
To fix, tweak the logic in CreateLockFile to add an empty LISTEN_ADDR  
line in standalone mode.  This is a tad grotty, but since that function  
already knows almost everything there is to know about the contents of  
lock files, it doesn't seem that it's any better to hack it elsewhere.  
  
It's not clear how significant this bug really is, since a standalone  
backend should never have any children and thus it seems not critical  
to be able to check the nattch count of the shmem segment externally.  
But I'm going to back-patch the fix anyway.  
  
This problem had escaped notice because of an ancient (and in hindsight  
pretty dubious) decision to suppress LOG-level messages by default in  
standalone mode; so that the elog(LOG) complaint in AddToDataDirLockFile  
that should have warned of the problem didn't do anything.  Fixing that  
is material for a separate patch though.  

commit   : f0fc1d4c890135ec879860f7d0c49b34d492d99f    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 11 Dec 2012 22:09:20 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 11 Dec 2012 22:09:20 -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   : 97a60fa5a06bf60c857976e24ef2ed0cb882cd52    
  
author   : Bruce Momjian <[email protected]>    
date     : Tue, 11 Dec 2012 15:09:22 -0500    
  
committer: Bruce Momjian <[email protected]>    
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   : 8b6b374b39d992adea42f703baf28a19909ef747    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Tue, 11 Dec 2012 15:57:24 +0200    
  
committer: Heikki Linnakangas <[email protected]>    
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   : 5dd1c287c2866213a753495551dd75d9c18edbcb    
  
author   : Andrew Dunstan <[email protected]>    
date     : Tue, 11 Dec 2012 11:51:51 -0500    
  
committer: Andrew Dunstan <[email protected]>    
date     : Tue, 11 Dec 2012 11:51:51 -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   : 9ba0361f099e1d9827e9da1df95652d83ac8b973    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Mon, 10 Dec 2012 15:54:42 +0200    
  
committer: Heikki Linnakangas <[email protected]>    
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   : 8bc8f7024fd7ea63a0eff1cc296456b7c7bf7982    
  
author   : Peter Eisentraut <[email protected]>    
date     : Sat, 8 Dec 2012 07:36:25 -0500    
  
committer: Peter Eisentraut <[email protected]>    
date     : Sat, 8 Dec 2012 07:36:25 -0500    

The old one is responding with 404.  

commit   : 9d1a293aba92ac7026f6559e0fe317567987cc19    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 5 Dec 2012 18:28:02 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 5 Dec 2012 18:28:02 -0500    

If we're not in hot standby mode, then there's no way for users to connect  
to reset the recoveryPause flag, so we shouldn't pause.  The code was aware  
of this but the test to see if pausing was safe was seriously inadequate:  
it wasn't paying attention to reachedConsistency, and besides what it was  
testing was that we could legally enter hot standby, not that we have  
done so.  Get rid of that in favor of checking LocalHotStandbyActive,  
which because of the coding in CheckRecoveryConsistency is tantamount to  
checking that we have told the postmaster to enter hot standby.  
  
Also, move the recoveryPausesHere() call that reacts to asynchronous  
recoveryPause requests so that it's not in the middle of application of a  
WAL record.  I put it next to the recoveryStopsHere() call --- in future  
those are going to need to interact significantly, so this seems like a  
good waystation.  
  
Also, don't bother trying to read another WAL record if we've already  
decided not to continue recovery.  This was no big deal when the code was  
written originally, but now that reading a record might entail actions like  
fetching an archive file, it seems a bit silly to do it like that.  
  
Per report from Jeff Janes and subsequent discussion.  The pause feature  
needs quite a lot more work, but this gets rid of some indisputable bugs,  
and seems safe enough to back-patch.  

commit   : 93c041ab100274b07ff6fdaafaf1bf340100465e    
  
author   : Michael Meskes <[email protected]>    
date     : Tue, 4 Dec 2012 16:35:18 +0100    
  
committer: Michael Meskes <[email protected]>    
date     : Tue, 4 Dec 2012 16:35:18 +0100    

Patch done by Jiang Guiqing <[email protected]>.