PostgreSQL 9.1.5 commit log

commit   : 04e96bc69d541dd7b5f4d3b3daf49d291c7fcbb4    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 14 Aug 2012 18:41:04 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 14 Aug 2012 18:41:04 -0400    

commit   : 18ee575df30d3b41444e2309205427cd11a8b30a    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 14 Aug 2012 18:24:14 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 14 Aug 2012 18:24:14 -0400    

commit   : e76e25228600709a1b641341be39bef061a36116    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 14 Aug 2012 18:28:42 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 14 Aug 2012 18:28:42 -0400    

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

commit   : 0df2da9d72b1ab578b1151c33ab434c592e1db4e    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 14 Aug 2012 18:25:44 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 14 Aug 2012 18:25:44 -0400    

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

commit   : b5987c4f8770621067e2dd8f3da840931a28fbde    
  
author   : Peter Eisentraut <[email protected]>    
date     : Tue, 14 Aug 2012 16:34:12 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Tue, 14 Aug 2012 16:34:12 -0400    

commit   : a2c04f189a249bcf4fdbbb3306c01c82e4ad3b87    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 14 Aug 2012 10:54:36 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 14 Aug 2012 10:54:36 -0400    

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

commit   : b2cc6119591cd6428e0235c8cae44cf976783d7c    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 11 Aug 2012 12:51:36 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 11 Aug 2012 12:51:36 -0400    

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

commit   : 64d64a0530a57b4f949fc6d96ebc8d8318b63cdb    
  
author   : Magnus Hagander <[email protected]>    
date     : Fri, 10 Aug 2012 14:49:03 +0200    
  
committer: Magnus Hagander <[email protected]>    
date     : Fri, 10 Aug 2012 14:49:03 +0200    

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

commit   : 2bf6e8cbc0717f4cac8caabea644628fbf5d9563    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 8 Aug 2012 12:02:15 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 8 Aug 2012 12:02:15 -0400    

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

commit   : efed8c0031dbae0adb4ed4cb6197acd57397d2e9    
  
author   : Simon Riggs <[email protected]>    
date     : Tue, 7 Aug 2012 16:21:49 +0100    
  
committer: Simon Riggs <[email protected]>    
date     : Tue, 7 Aug 2012 16:21:49 +0100    

Dave Kerr, backpatched by Simon Riggs  

commit   : 1c638c80747fa605c32193cdbd504a2cce6f0006    
  
author   : Robert Haas <[email protected]>    
date     : Mon, 6 Aug 2012 16:12:17 -0400    
  
committer: Robert Haas <[email protected]>    
date     : Mon, 6 Aug 2012 16:12:17 -0400    

Noted by Thom Brown.  

commit   : 16a69120eb4d2728bc7b988aee9fedf86d15be53    
  
author   : Robert Haas <[email protected]>    
date     : Mon, 6 Aug 2012 15:18:00 -0400    
  
committer: Robert Haas <[email protected]>    
date     : Mon, 6 Aug 2012 15:18:00 -0400    

Craig Ringer, edited fairly heavily by me  

commit   : 31595993901484d24c9ba62428c7abec207dd55e    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Mon, 6 Aug 2012 13:02:15 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Mon, 6 Aug 2012 13:02:15 +0300    

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

commit   : c9c95202b036ea75dec68a4afc1802f35b77a966    
  
author   : Bruce Momjian <[email protected]>    
date     : Sat, 4 Aug 2012 10:35:37 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Sat, 4 Aug 2012 10:35:37 -0400    

Backpatch to 9.1 and 9.2.  

commit   : 805fc21c33f317464e10622d9a443299fb9431a9    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 3 Aug 2012 17:39:50 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 3 Aug 2012 17:39:50 -0400    

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

commit   : d06dfc1b6316582fd337f21d099be84aa6de6405    
  
author   : Bruce Momjian <[email protected]>    
date     : Fri, 3 Aug 2012 14:02:22 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Fri, 3 Aug 2012 14:02:22 -0400    

Backpatch to 9.2 and 9.1.  

commit   : b1c891e90b748a5c5aec3504bfac50f2fe7398db    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 31 Jul 2012 17:56:32 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 31 Jul 2012 17:56:32 -0400    

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

commit   : 118b941614cece1946d7eee31040061397102e05    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 31 Jul 2012 14:37:04 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 31 Jul 2012 14:37:04 -0400    

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

commit   : 27394f76bf9a18a4e0337d3b3fb84a940e3555f5    
  
author   : Bruce Momjian <[email protected]>    
date     : Mon, 30 Jul 2012 10:15:56 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Mon, 30 Jul 2012 10:15:56 -0400    

Backpatch from 9.0 to current.  

commit   : 022e8786da07d2859956d62b71297428a69f04f3    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 27 Jul 2012 19:31:24 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 27 Jul 2012 19:31:24 -0400    

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

commit   : 3d980e15eeeecc4cc240c45dc5abb5567adce4bb    
  
author   : Bruce Momjian <[email protected]>    
date     : Thu, 26 Jul 2012 21:25:25 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Thu, 26 Jul 2012 21:25:25 -0400    

Patch to 9.0 and later, where script is mentioned.  

commit   : 7a7d970b36845310281f6f5c4313bd49a110df44    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 26 Jul 2012 14:29:37 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 26 Jul 2012 14:29:37 -0400    

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

commit   : a1195a5c26c316b46a6c4a8268116b6deeab2d72    
  
author   : Robert Haas <[email protected]>    
date     : Thu, 26 Jul 2012 09:18:32 -0400    
  
committer: Robert Haas <[email protected]>    
date     : Thu, 26 Jul 2012 09:18:32 -0400    

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

commit   : aa7cd144062bef3baf8fd4548c0f54bb108c3270    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 25 Jul 2012 17:40:48 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 25 Jul 2012 17:40:48 -0400    

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

commit   : baf6090f8c3ef1967a71959cf327ac5f82b5b7cb    
  
author   : Andrew Dunstan <[email protected]>    
date     : Fri, 20 Jul 2012 16:29:00 -0400    
  
committer: Andrew Dunstan <[email protected]>    
date     : Fri, 20 Jul 2012 16:29:00 -0400    

commit   : 963bafde8b225a123e31649f44e26ed930b2002c    
  
author   : Andrew Dunstan <[email protected]>    
date     : Fri, 20 Jul 2012 15:56:57 -0400    
  
committer: Andrew Dunstan <[email protected]>    
date     : Fri, 20 Jul 2012 15:56:57 -0400    

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

commit   : 200ff8bf39dff43f708b91949947c12f44557fbb    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 20 Jul 2012 13:09:16 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 20 Jul 2012 13:09:16 -0400    

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

commit   : 2f961b1b5ff2d81892b1ca0fed4d281ed3412fff    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 17 Jul 2012 16:55:51 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 17 Jul 2012 16:55:51 -0400    

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

commit   : 5dd19d10d21b2544128386f5d6bd5fb60c4905af    
  
author   : Alvaro Herrera <[email protected]>    
date     : Tue, 17 Jul 2012 12:31:48 -0400    
  
committer: Alvaro Herrera <[email protected]>    
date     : Tue, 17 Jul 2012 12:31:48 -0400    

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

commit   : d6270e2df9f5fc8803d8171e0aad98a55257f921    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 15 Jul 2012 13:28:09 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 15 Jul 2012 13:28:09 -0400    

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

commit   : d066cc548de7f21e84aeb27bd43388ba82534759    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 12 Jul 2012 14:30:04 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 12 Jul 2012 14:30:04 -0400    

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

commit   : a9287de1760450e7fe3b4309ee1ba7ea2af39217    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 10 Jul 2012 18:00:44 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 10 Jul 2012 18:00:44 -0400    

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

commit   : ed45a5373029f2ff08ce76cf3807499afe3873ee    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 10 Jul 2012 16:52:42 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 10 Jul 2012 16:52:42 -0400    

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

commit   : 892a8d05440deaf0f73b91a98f35d32b9415d497    
  
author   : Alvaro Herrera <[email protected]>    
date     : Tue, 10 Jul 2012 16:46:59 -0400    
  
committer: Alvaro Herrera <[email protected]>    
date     : Tue, 10 Jul 2012 16:46:59 -0400    

Due to a git hook blowing up in my face telling me I could not commit  
Peter Eisentraut's patch on his name, I had to "git reset" to fix the  
previous commit ... and then forgot that I needed to "git add" these  
files :-(  

commit   : fc661f78c6007103604fc43e98622a71400b769f    
  
author   : Alvaro Herrera <[email protected]>    
date     : Mon, 9 Jul 2012 17:36:29 -0400    
  
committer: Alvaro Herrera <[email protected]>    
date     : Mon, 9 Jul 2012 17:36:29 -0400    

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

commit   : 1fbe7d377cb6bf070442794a677499cd2e7531cc    
  
author   : Alvaro Herrera <[email protected]>    
date     : Tue, 10 Jul 2012 15:49:48 -0400    
  
committer: Alvaro Herrera <[email protected]>    
date     : Tue, 10 Jul 2012 15:49:48 -0400    

Use SvREFCNT_inc_simple_void() instead of SvREFCNT_inc() to avoid  
warning about unused return value.  

commit   : 62b9045666616e23c21bb28ede5875f8343fba04    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 9 Jul 2012 23:23:09 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 9 Jul 2012 23:23:09 -0400    

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

commit   : b6108fe59b997aafe6a8003b38a34d91c073618c    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 8 Jul 2012 23:51:19 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 8 Jul 2012 23:51:19 -0400    

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

commit   : 3f35526479f388d1e3ffee7cf6c84e3212a8ec1a    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 5 Jul 2012 17:15:16 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 5 Jul 2012 17:15:16 -0400    

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

commit   : b4234f8fc49fc58ea904f0b9eea0336d5a7930d8    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Thu, 5 Jul 2012 23:40:25 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Thu, 5 Jul 2012 23:40:25 +0300    

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

commit   : 138313ebaa985030d75d429c3b3cb7138e62b10f    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Thu, 5 Jul 2012 22:16:29 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Thu, 5 Jul 2012 22:16:29 +0300    

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

commit   : b8aca12d77612007ebde22db14e3971ef664d553    
  
author   : Magnus Hagander <[email protected]>    
date     : Wed, 4 Jul 2012 15:10:46 +0200    
  
committer: Magnus Hagander <[email protected]>    
date     : Wed, 4 Jul 2012 15:10:46 +0200    

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

commit   : 119027ec8b8d02c8d70e4916df1b41cde78f674d    
  
author   : Magnus Hagander <[email protected]>    
date     : Wed, 4 Jul 2012 09:22:21 +0200    
  
committer: Magnus Hagander <[email protected]>    
date     : Wed, 4 Jul 2012 09:22:21 +0200    

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

commit   : 85189bb930452321d224aa55ccf51f561ba04d5d    
  
author   : Magnus Hagander <[email protected]>    
date     : Wed, 4 Jul 2012 09:06:02 +0200    
  
committer: Magnus Hagander <[email protected]>    
date     : Wed, 4 Jul 2012 09:06:02 +0200    

gabrielle  

commit   : 94c35d5a966ed1112122912ac033e254f5a8d2ae    
  
author   : Magnus Hagander <[email protected]>    
date     : Wed, 4 Jul 2012 08:58:31 +0200    
  
committer: Magnus Hagander <[email protected]>    
date     : Wed, 4 Jul 2012 08:58:31 +0200    

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

commit   : 20060705282a9de7ca61ccdceb3b575ba64f8c13    
  
author   : Magnus Hagander <[email protected]>    
date     : Wed, 4 Jul 2012 08:59:35 +0200    
  
committer: Magnus Hagander <[email protected]>    
date     : Wed, 4 Jul 2012 08:59:35 +0200    

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

commit   : 96ca906ccad72e5d9e8950924ceecf20235ce244    
  
author   : Alvaro Herrera <[email protected]>    
date     : Tue, 3 Jul 2012 16:40:15 -0400    
  
committer: Alvaro Herrera <[email protected]>    
date     : Tue, 3 Jul 2012 16:40:15 -0400    

commit   : ac50404224e5abb74b00bf22139f6ab96b01b2ab    
  
author   : Alvaro Herrera <[email protected]>    
date     : Tue, 3 Jul 2012 15:19:02 -0400    
  
committer: Alvaro Herrera <[email protected]>    
date     : Tue, 3 Jul 2012 15:19:02 -0400    

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

commit   : af4f029675ea2550f12d0b25efb4a673f5c08b08    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 1 Jul 2012 17:12:59 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 1 Jul 2012 17:12:59 -0400    

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

commit   : 81aa9610373ab1bfb0b73f9066319186456d4d01    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 30 Jun 2012 16:44:03 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 30 Jun 2012 16:44:03 -0400    

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

commit   : b6fe2dfda004e28f806c2424fff13063f8532d68    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Fri, 29 Jun 2012 19:19:29 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Fri, 29 Jun 2012 19:19:29 +0300    

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

commit   : 3ac860f6b33ffa0733d4d013718c5f408282fcb6    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 29 Jun 2012 00:51:44 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 29 Jun 2012 00:51:44 -0400    

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

commit   : 8a9bcf7f5c39e4cc30be0478065853619d61fec8    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 25 Jun 2012 21:19:28 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 25 Jun 2012 21:19:28 -0400    

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

commit   : df83f0f61c5e44602fa879626c79751b198237c5    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 21 Jun 2012 17:26:19 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 21 Jun 2012 17:26:19 -0400    

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

commit   : 348f5043173260d438735e3a9e4a8ef1bd099686    
  
author   : Alvaro Herrera <[email protected]>    
date     : Mon, 18 Jun 2012 16:37:49 -0400    
  
committer: Alvaro Herrera <[email protected]>    
date     : Mon, 18 Jun 2012 16:37:49 -0400    

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

commit   : e23e17ffb0ddfc9e9237164e14edb714ba3070e4    
  
author   : Peter Eisentraut <[email protected]>    
date     : Tue, 19 Jun 2012 21:36:08 +0300    
  
committer: Peter Eisentraut <[email protected]>    
date     : Tue, 19 Jun 2012 21:36:08 +0300    

found by Stefan Kaltenbrunner  

commit   : 1643031e5fe02d2de9ae6b8f86ef9ffd09fe7d3f    
  
author   : Magnus Hagander <[email protected]>    
date     : Sun, 17 Jun 2012 21:20:32 +0800    
  
committer: Magnus Hagander <[email protected]>    
date     : Sun, 17 Jun 2012 21:20:32 +0800    

commit   : 0f3326175a951e3ff9e62c310d686a681883899f    
  
author   : Bruce Momjian <[email protected]>    
date     : Wed, 13 Jun 2012 12:34:03 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Wed, 13 Jun 2012 12:34:03 -0400    

Backpatch to 9.1 (already in head)  

commit   : af97980b9a1960145a0737ec15b0e3ea49e2dc01    
  
author   : Bruce Momjian <[email protected]>    
date     : Wed, 13 Jun 2012 12:19:18 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Wed, 13 Jun 2012 12:19:18 -0400    

Backpatch to 9.1.  

commit   : 580b94168e2218a2a32d6792139d51c63104b2c2    
  
author   : Magnus Hagander <[email protected]>    
date     : Mon, 11 Jun 2012 15:07:55 +0200    
  
committer: Magnus Hagander <[email protected]>    
date     : Mon, 11 Jun 2012 15:07:55 +0200    

This prevents a pg_basebackup backup session that just does a base  
backup (no xlog involved at all) from becoming the synchronous slave  
and thus blocking all access while it runs.  
  
Also fixes the problem when a higher priority slave shows up it would  
become the sync standby before it has reached the STREAMING state, by  
making sure we can only switch to a walsender that's actually STREAMING.  
  
Fujii Masao  

commit   : 557433f48ad1e55ce753282f4dfb8ef3606cda8d    
  
author   : Simon Riggs <[email protected]>    
date     : Fri, 8 Jun 2012 17:35:22 +0100    
  
committer: Simon Riggs <[email protected]>    
date     : Fri, 8 Jun 2012 17:35:22 +0100    

Fixes bug #6661 reported by Valentine Gogichashvili.  
  
Analysis and fix by Andres Freund  

commit   : 16222f32ed56d3ebc4136133662d932299188955    
  
author   : Simon Riggs <[email protected]>    
date     : Thu, 7 Jun 2012 19:24:47 +0100    
  
committer: Simon Riggs <[email protected]>    
date     : Thu, 7 Jun 2012 19:24:47 +0100    

Andres Freund and Simon Riggs  

commit   : 5c3532876f8360df10692baf77a0b79c41ee001e    
  
author   : Magnus Hagander <[email protected]>    
date     : Tue, 5 Jun 2012 13:13:53 +0200    
  
committer: Magnus Hagander <[email protected]>    
date     : Tue, 5 Jun 2012 13:13:53 +0200    

Without this, pg_basebackup doesn't tell you why it failed when for example  
there is a file in the data directory that the backend doesn't have  
permissions to read.  

commit   : d9d721472f9900e70124ab734dc00f203d049506    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 4 Jun 2012 20:12:55 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 4 Jun 2012 20:12:55 -0400    

It failed to check for error return from xsltApplyStylesheet(), as reported  
by Peter Gagarinov.  (So far as I can tell, libxslt provides no convenient  
way to get a useful error message in failure cases.  There might be some  
inconvenient way, but considering that this code is deprecated it's hard to  
get enthusiastic about putting lots of work into it.  So I just made it say  
"failed to apply stylesheet", in line with the existing error checks.)  
  
While looking at the code I also noticed that the string returned by  
xsltSaveResultToString was never freed, resulting in a session-lifespan  
memory leak.  
  
Back-patch to all supported versions.  

commit   : 873d1c11ea25f24815861c2e474fc43500d561c8    
  
author   : Simon Riggs <[email protected]>    
date     : Fri, 1 Jun 2012 12:39:08 +0100    
  
committer: Simon Riggs <[email protected]>    
date     : Fri, 1 Jun 2012 12:39:08 +0100    

Noah Misch, reviewed by Simon Riggs