PostgreSQL 9.3.5 commit log

commit   : f7ba173cb3548ddccaab68fcaeae3dd5efdcfbf1    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 21 Jul 2014 15:10:42 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 21 Jul 2014 15:10:42 -0400    

commit   : 0cb0c778283fceec58cf1d73ba3204b67a890980    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 21 Jul 2014 14:59:29 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 21 Jul 2014 14:59:29 -0400    

commit   : 4ee95870de343cd027c7727a175fe1c27c75a389    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 21 Jul 2014 12:58:49 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 21 Jul 2014 12:58:49 -0400    

Per recommendation from Andres.  

commit   : e7984cca069f2064f5b9d8dc2a5f841f63d56156    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 21 Jul 2014 11:41:36 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 21 Jul 2014 11:41:36 -0400    

In commit a61daa14d56867e90dc011bbba52ef771cea6770, we fixed pg_upgrade so  
that it would install sane relminmxid and datminmxid values, but that does  
not cure the problem for installations that were already pg_upgraded to  
9.3; they'll initially have "1" in those fields.  This is not a big problem  
so long as 1 is "in the past" compared to the current nextMultiXact  
counter.  But if an installation were more than halfway to the MXID wrap  
point at the time of upgrade, 1 would appear to be "in the future" and  
that would effectively disable tracking of oldest MXIDs in those  
tables/databases, until such time as the counter wrapped around.  
  
While in itself this isn't worse than the situation pre-9.3, where we did  
not manage MXID wraparound risk at all, the consequences of premature  
truncation of pg_multixact are worse now; so we ought to make some effort  
to cope with this.  We discussed advising users to fix the tracking values  
manually, but that seems both very tedious and very error-prone.  
  
Instead, this patch adopts two amelioration rules.  First, a relminmxid  
value that is "in the future" is allowed to be overwritten with a  
full-table VACUUM's actual freeze cutoff, ignoring the normal rule that  
relminmxid should never go backwards.  (This essentially assumes that we  
have enough defenses in place that wraparound can never occur anymore,  
and thus that a value "in the future" must be corrupt.)  Second, if we see  
any "in the future" values then we refrain from truncating pg_clog and  
pg_multixact.  This prevents loss of clog data until we have cleaned up  
all the broken tracking data.  In the worst case that could result in  
considerable clog bloat, but in practice we expect that relfrozenxid-driven  
freezing will happen soon enough to fix the problem before clog bloat  
becomes intolerable.  (Users could do manual VACUUM FREEZEs if not.)  
  
Note that this mechanism cannot save us if there are already-wrapped or  
already-truncated-away MXIDs in the table; it's only capable of dealing  
with corrupt tracking values.  But that's the situation we have with the  
pg_upgrade bug.  
  
For consistency, apply the same rules to relfrozenxid/datfrozenxid.  There  
are not known mechanisms for these to get messed up, but if they were, the  
same tactics seem appropriate for fixing them.  

commit   : 0016f8e311c5d9f7822057adbcdf09b768d936bc    
  
author   : Peter Eisentraut <[email protected]>    
date     : Mon, 21 Jul 2014 01:04:46 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Mon, 21 Jul 2014 01:04:46 -0400    

commit   : c8fe4990383dc3d09fa1db12f87432f592283ac8    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 19 Jul 2014 22:20:42 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 19 Jul 2014 22:20:42 -0400    

Rather remarkable that this has been wrong since 9.1 and nobody noticed.  

commit   : bd5458f520c486e44a1ce576bedd3e7ea666f3f1    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 19 Jul 2014 15:00:50 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 19 Jul 2014 15:00:50 -0400    

DST law changes in Crimea, Egypt, Morocco.  New zone Antarctica/Troll  
for Norwegian base in Queen Maud Land.  

commit   : b978ab5f6545bad950089a2db0e0ffc6443de350    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 19 Jul 2014 14:28:30 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 19 Jul 2014 14:28:30 -0400    

When a view has a function-returning-composite in FROM, and there are  
some dropped columns in the underlying composite type, ruleutils.c  
printed junk in the column alias list for the reconstructed FROM entry.  
Before 9.3, this was prevented by doing get_rte_attribute_is_dropped  
tests while printing the column alias list; but that solution is not  
currently available to us for reasons I'll explain below.  Instead,  
check for empty-string entries in the alias list, which can only exist  
if that column position had been dropped at the time the view was made.  
(The parser fills in empty strings to preserve the invariant that the  
aliases correspond to physical column positions.)  
  
While this is sufficient to handle the case of columns dropped before  
the view was made, we have still got issues with columns dropped after  
the view was made.  In particular, the view could contain Vars that  
explicitly reference such columns!  The dependency machinery really  
ought to refuse the column drop attempt in such cases, as it would do  
when trying to drop a table column that's explicitly referenced in  
views.  However, we currently neglect to store dependencies on columns  
of composite types, and fixing that is likely to be too big to be  
back-patchable (not to mention that existing views in existing databases  
would not have the needed pg_depend entries anyway).  So I'll leave that  
for a separate patch.  
  
Pre-9.3, ruleutils would print such Vars normally (with their original  
column names) even though it suppressed their entries in the RTE's  
column alias list.  This is certainly bogus, since the printed view  
definition would fail to reload, but at least it didn't crash.  However,  
as of 9.3 the printed column alias list is tightly tied to the names  
printed for Vars; so we can't treat columns as dropped for one purpose  
and not dropped for the other.  This is why we can't just put back the  
get_rte_attribute_is_dropped test: it results in an assertion failure  
if the view in fact contains any Vars referencing the dropped column.  
Once we've got dependencies preventing such cases, we'll probably want  
to do it that way instead of relying on the empty-string test used here.  
  
This fix turned up a very ancient bug in outfuncs/readfuncs, namely  
that T_String nodes containing empty strings were not dumped/reloaded  
correctly: the node was printed as "<>" which is read as a string  
value of <>.  Since (per SQL) we disallow empty-string identifiers,  
such nodes don't occur normally, which is why we'd not noticed.  
(Such nodes aren't used for literal constants, just identifiers.)  
  
Per report from Marc Schablewski.  Back-patch to 9.3 which is where  
the rule printing behavior changed.  The dangling-variable case is  
broken all the way back, but that's not what his complaint is about.  

commit   : 7b55a983e2390c5d4a98bd48b9ddf4565e9f24fd    
  
author   : Noah Misch <[email protected]>    
date     : Fri, 18 Jul 2014 16:05:17 -0400    
  
committer: Noah Misch <[email protected]>    
date     : Fri, 18 Jul 2014 16:05:17 -0400    

~/.pgpass is a sound choice everywhere, and "peer" authentication is  
safe on every platform it supports.  Cease to recommend "trust"  
authentication, the safety of which is deeply configuration-specific.  
Back-patch to 9.0, where pg_upgrade was introduced.  

commit   : 5ef588b22bbc3766c1c77c283579a6b732188524    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 18 Jul 2014 13:00:27 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 18 Jul 2014 13:00:27 -0400    

If pg_regcomp failed after having invoked markst/cleanst, it would leak any  
"struct subre" nodes it had created.  (We've already detected all regex  
syntax errors at that point, so the only likely causes of later failure  
would be query cancel or out-of-memory.)  To fix, make sure freesrnode  
knows the difference between the pre-cleanst and post-cleanst cleanup  
procedures.  Add some documentation of this less-than-obvious point.  
  
Also, newlacon did the wrong thing with an out-of-memory failure from  
realloc(), so that the previously allocated array would be leaked.  
  
Both of these are pretty low-probability scenarios, but a bug is a bug,  
so patch all the way back.  
  
Per bug #10976 from Arthur O'Dwyer.  

commit   : a4867d041eff3f3217d39a3909b6f6790fa731d7    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Wed, 16 Jul 2014 09:10:54 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Wed, 16 Jul 2014 09:10:54 +0300    

The consistent function contained several bugs:  
  
* The "if (which2) { ... }"  block was broken. It compared the  argument's  
lower bound against centroid's upper bound, while it was supposed to compare  
the argument's upper bound against the centroid's lower bound (the comment  
was correct, code was wrong). Also, it cleared bits in the "which1"  
variable, while it was supposed to clear bits in "which2".  
  
* If the argument's upper bound was equal to the centroid's lower bound, we  
descended to both halves (= all quadrants). That's unnecessary, searching  
the right quadrants is sufficient. This didn't lead to incorrect query  
results, but was clearly wrong, and slowed down queries unnecessarily.  
  
* In the case that argument's lower bound is adjacent to the centroid's  
upper bound, we also don't need to visit all quadrants. Per similar  
reasoning as previous point.  
  
* The code where we compare the previous centroid with the current centroid  
should match the code where we compare the current centroid with the  
argument. The point of that code is to redo the calculation done in the  
previous level, to see if we were supposed to traverse left or right (or up  
or down), and if we actually did. If we moved in the different direction,  
then we know there are no matches for bound.  
  
Refactor the code and adds comments to make it more readable and easier to  
reason about.  
  
Backpatch to 9.3 where SP-GiST support for range types was introduced.  

commit   : 12c5bbdcbaa292b2a4b09d298786f7784979fdec    
  
author   : Alvaro Herrera <[email protected]>    
date     : Tue, 15 Jul 2014 13:24:07 -0400    
  
committer: Alvaro Herrera <[email protected]>    
date     : Tue, 15 Jul 2014 13:24:07 -0400    

Trying to reassign objects owned by a user that had text search  
dictionaries or configurations used to fail with:  
ERROR:  unexpected classid 3600  
or  
ERROR:  unexpected classid 3602  
  
Fix by adding cases for those object types in a switch in pg_shdepend.c.  
  
Both REASSIGN OWNED and text search objects go back all the way to 8.1,  
so backpatch to all supported branches.  In 9.3 the alter-owner code was  
made generic, so the required change in recent branches is pretty  
simple; however, for 9.2 and older ones we need some additional  
reshuffling to enable specifying objects by OID rather than name.  
  
Text search templates and parsers are not owned objects, so there's no  
change required for them.  
  
Per bug #9749 reported by Michal Novotný  

commit   : f7dd97fbae69a041cbbbd32196bb24b25f8f7ac5    
  
author   : Peter Eisentraut <[email protected]>    
date     : Mon, 14 Jul 2014 20:37:00 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Mon, 14 Jul 2014 20:37:00 -0400    

From: Josh Kupershmidt <[email protected]>  

commit   : 93c3eca9531dfa649d1bf67d727af42a4444312d    
  
author   : Magnus Hagander <[email protected]>    
date     : Sat, 12 Jul 2014 14:19:57 +0200    
  
committer: Magnus Hagander <[email protected]>    
date     : Sat, 12 Jul 2014 14:19:57 +0200    

Adds support for autocomplete of LC_COLLATE and LC_CTYPE to  
the CREATE DATABASE command in psql.  

commit   : b77e6b959663f022c31167396f2b56275c792833    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 11 Jul 2014 19:12:42 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 11 Jul 2014 19:12:42 -0400    

ExecEvalWholeRowVar incorrectly supposed that it could "bless" the source  
TupleTableSlot just once per query.  But if the input is coming from an  
Append (or, perhaps, other cases?) more than one slot might be returned  
over the query run.  This led to "record type has not been registered"  
errors when a composite datum was extracted from a non-blessed slot.  
  
This bug has been there a long time; I guess it escaped notice because when  
dealing with subqueries the planner tends to expand whole-row Vars into  
RowExprs, which don't have the same problem.  It is possible to trigger  
the problem in all active branches, though, as illustrated by the added  
regression test.  

commit   : 6d36aee5b718524f718436d0973822bc2cb30bdd    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 8 Jul 2014 14:03:19 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 8 Jul 2014 14:03:19 -0400    

While the x output of "select x from t group by x" can be presumed unique,  
this does not hold for "select x, generate_series(1,10) from t group by x",  
because we may expand the set-returning function after the grouping step.  
(Perhaps that should be re-thought; but considering all the other oddities  
involved with SRFs in targetlists, it seems unlikely we'll change it.)  
Put a check in query_is_distinct_for() so it's not fooled by such cases.  
  
Back-patch to all supported branches.  
  
David Rowley  

commit   : f1d7ff5bb8a7beef9afaa311c6f61a37ed4e000e    
  
author   : Bruce Momjian <[email protected]>    
date     : Mon, 7 Jul 2014 13:24:08 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Mon, 7 Jul 2014 13:24:08 -0400    

Previously, when calculations on the need for toast tables changed,  
pg_upgrade could not handle cases where the new cluster needed a TOAST  
table and the old cluster did not.  (It already handled the opposite  
case.)  This fixes the "OID mismatch" error typically generated in this  
case.  
  
Backpatch through 9.2  

commit   : 3d2e1851096752c3ca4dee5c16b552332de09946    
  
author   : Bruce Momjian <[email protected]>    
date     : Wed, 2 Jul 2014 15:29:38 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Wed, 2 Jul 2014 15:29:38 -0400    

Also set these values for pre-9.3 old clusters that don't have values to  
preserve.  
  
Analysis by Alvaro  
  
Backpatch through 9.3  

commit   : 110d293a68708b7c0fa3460fd38a028bc3324101    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 2 Jul 2014 14:20:34 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 2 Jul 2014 14:20:34 -0400    

This function wasn't originally thought to be really user-facing,  
because converting a table to a view isn't something we expect people  
to do manually.  So not all that much effort was spent on the error  
messages; in particular, while the code will complain that you got  
the column types wrong it won't say exactly what they are.  But since  
we repurposed the code to also check compatibility of rule RETURNING  
lists, it's definitely user-facing.  It now seems worthwhile to add  
errdetail messages showing exactly what the conflict is when there's  
a mismatch of column names or types.  This is prompted by bug #10836  
from Matthias Raffelsieper, which might have been forestalled if the  
error message had reported the wrong column type as being "record".  
  
Per Alvaro's advice, back-patch to branches before 9.4, but resist  
the temptation to rephrase any existing strings there.  Adding new  
strings is not really a translation degradation; anyway having the  
info presented in English is better than not having it at all.  

commit   : 174421bd1c2c5c10fbf015fd570354d8e27fe259    
  
author   : Bruce Momjian <[email protected]>    
date     : Wed, 2 Jul 2014 13:11:04 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Wed, 2 Jul 2014 13:11:04 -0400    

Per analysis by Alvaro  
  
Backpatch through 9.3  

commit   : 59e61167686fd4ff5aebca73b1d89f404552c506    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 1 Jul 2014 11:22:50 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 1 Jul 2014 11:22:50 -0400    

The output buffer size in unaccent_lexize() was calculated as input string  
length times pg_database_encoding_max_length(), which effectively assumes  
that replacement strings aren't more than one character.  While that was  
all that we previously documented it to support, the code actually has  
always allowed replacement strings of arbitrary length; so if you tried  
to make use of longer strings, you were at risk of buffer overrun.  To fix,  
use an expansible StringInfo buffer instead of trying to determine the  
maximum space needed a-priori.  
  
This would be a security issue if unaccent rules files could be installed  
by unprivileged users; but fortunately they can't, so in the back branches  
the problem can be labeled as improper configuration by a superuser.  
Nonetheless, a memory stomp isn't a nice way of reacting to improper  
configuration, so let's back-patch the fix.  

commit   : f14e4085215b6d71a54f10932f680ae60d8619b3    
  
author   : Noah Misch <[email protected]>    
date     : Mon, 30 Jun 2014 16:59:19 -0400    
  
committer: Noah Misch <[email protected]>    
date     : Mon, 30 Jun 2014 16:59:19 -0400    

This function continued to use it after heap_endscan() freed it.  In  
passing, don't explicit create a strategy here.  Instead, use the one  
created by heap_beginscan_strat(), if any.  Back-patch to 9.2, where use  
of a BufferAccessStrategy here was introduced.  

commit   : 9a28c3752c89ec01fb8b28bb5904c6d547507fda    
  
author   : Alvaro Herrera <[email protected]>    
date     : Fri, 27 Jun 2014 14:43:52 -0400    
  
committer: Alvaro Herrera <[email protected]>    
date     : Fri, 27 Jun 2014 14:43:52 -0400    

Instead of truncating pg_multixact at vacuum time, do it only at  
checkpoint time.  The reason for doing it this way is twofold: first, we  
want it to delete only segments that we're certain will not be required  
if there's a crash immediately after the removal; and second, we want to  
do it relatively often so that older files are not left behind if  
there's an untimely crash.  
  
Per my proposal in  
http://www.postgresql.org/message-id/[email protected]  
we now execute the truncation in the checkpointer process rather than as  
part of vacuum.  Vacuum is in only charge of maintaining in shared  
memory the value to which it's possible to truncate the files; that  
value is stored as part of checkpoints also, and so upon recovery we can  
reuse the same value to re-execute truncate and reset the  
oldest-value-still-safe-to-use to one known to remain after truncation.  
  
Per bug reported by Jeff Janes in the course of his tests involving  
bug #8673.  
  
While at it, update some comments that hadn't been updated since  
multixacts were changed.  
  
Backpatch to 9.3, where persistency of pg_multixact files was  
introduced by commit 0ac5ad5134f2.  

commit   : e86cfc4bbe198f8c7367e8b23efadae97da64d7c    
  
author   : Alvaro Herrera <[email protected]>    
date     : Fri, 27 Jun 2014 14:43:45 -0400    
  
committer: Alvaro Herrera <[email protected]>    
date     : Fri, 27 Jun 2014 14:43:45 -0400    

We were allowing a table's pg_class.relminmxid value to move backwards  
when heaps were swapped by VACUUM FULL or CLUSTER.  There is a  
similar protection against relfrozenxid going backwards, which we  
neglected to clone when the multixact stuff was rejiggered by commit  
0ac5ad5134f276.  
  
Backpatch to 9.3, where relminmxid was introduced.  
  
As reported by Heikki in  
http://www.postgresql.org/message-id/[email protected]  

commit   : 5c538442a0a73b9d4f3fa11ecac6d5b93a982aca    
  
author   : Alvaro Herrera <[email protected]>    
date     : Fri, 27 Jun 2014 14:43:38 -0400    
  
committer: Alvaro Herrera <[email protected]>    
date     : Fri, 27 Jun 2014 14:43:38 -0400    

Don't assert MultiXactIdIsRunning if the multi came from a tuple that  
had been share-locked and later copied over to the new cluster by  
pg_upgrade.  Doing that causes an error to be raised unnecessarily:  
MultiXactIdIsRunning is not open to the possibility that its argument  
came from a pg_upgraded tuple, and all its other callers are already  
checking; but such multis cannot, obviously, have transactions still  
running, so the assert is pointless.  
  
Noticed while investigating the bogus pg_multixact/offsets/0000 file  
left over by pg_upgrade, as reported by Andres Freund in  
http://www.postgresql.org/message-id/[email protected]  
  
Backpatch to 9.3, as the commit that introduced the buglet.  

commit   : a2db7b7d0135c4068ebc3806931e60d5edd8f5cf    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 26 Jun 2014 10:41:01 -0700    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 26 Jun 2014 10:41:01 -0700    

When we committed a87c729153e372f3731689a7be007bc2b53f1410, we somehow  
failed to notice that it didn't merely improve plan quality for expression  
indexes; there were very closely related cases that failed outright with  
"could not find pathkey item to sort".  The failing cases seem to be those  
where the planner was already capable of selecting a MergeAppend plan,  
and there was inheritance involved: the lack of appropriate eclass child  
members would prevent prepare_sort_from_pathkeys() from succeeding on the  
MergeAppend's child plan nodes for inheritance child tables.  
  
Accordingly, back-patch into 9.1 through 9.3, along with an extra  
regression test case covering the problem.  
  
Per trouble report from Michael Glaesemann.  

commit   : 131ec00c0dc45e03aea86728b3645cca51616ada    
  
author   : Fujii Masao <[email protected]>    
date     : Thu, 26 Jun 2014 14:27:27 +0900    
  
committer: Fujii Masao <[email protected]>    
date     : Thu, 26 Jun 2014 14:27:27 +0900    

7380b63 changed log_filename so that epoch was not appended to it  
when no format specifier is given. But the example of CSV log file name  
with epoch still left in log_filename document. This commit removes  
such obsolete example.  
  
This commit also documents the defaults of log_directory and  
log_filename.  
  
Backpatch to all supported versions.  
  
Christoph Berg  

commit   : a1fc36495f00b250e915fc5ca579449723b3129a    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 24 Jun 2014 21:22:47 -0700    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 24 Jun 2014 21:22:47 -0700    

populate_recordset_object_start() improperly created a new hash table  
(overwriting the link to the existing one) if called at nest levels  
greater than one.  This resulted in previous fields not appearing in  
the final output, as reported by Matti Hameister in bug #10728.  
In 9.4 the problem also affects json_to_recordset.  
  
This perhaps missed detection earlier because the default behavior is to  
throw an error for nested objects: you have to pass use_json_as_text = true  
to see the problem.  
  
In addition, fix query-lifespan leakage of the hashtable created by  
json_populate_record().  This is pretty much the same problem recently  
fixed in dblink: creating an intended-to-be-temporary context underneath  
the executor's per-tuple context isn't enough to make it go away at the  
end of the tuple cycle, because MemoryContextReset is not  
MemoryContextResetAndDeleteChildren.  
  
Michael Paquier and Tom Lane  

commit   : cc584180967490f7084b4d2328970fecdd7bc179    
  
author   : Bruce Momjian <[email protected]>    
date     : Tue, 24 Jun 2014 16:11:06 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Tue, 24 Jun 2014 16:11:06 -0400    

This fixes a bug that caused vacuum to fail when the '0000' files left  
by initdb were accessed as part of vacuum's cleanup of old pg_multixact  
files.  
  
Backpatch through 9.3  

commit   : 2a7512bc7fd01b311f967e85024fa695a6061e4f    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Tue, 24 Jun 2014 12:31:36 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Tue, 24 Jun 2014 12:31:36 +0300    

The syntax doesn't let you specify "WITH OIDS" for foreign tables, but it  
was still possible with default_with_oids=true. But the rest of the system,  
including pg_dump, isn't prepared to handle foreign tables with OIDs  
properly.  
  
Backpatch down to 9.1, where foreign tables were introduced. It's possible  
that there are databases out there that already have foreign tables with  
OIDs. There isn't much we can do about that, but at least we can prevent  
them from being created in the future.  
  
Patch by Etsuro Fujita, reviewed by Hadi Moshayedi.  

commit   : 33b05485301f0f649fa30ba32c7b8b253f78ca8e    
  
author   : Kevin Grittner <[email protected]>    
date     : Sat, 21 Jun 2014 09:17:24 -0500    
  
committer: Kevin Grittner <[email protected]>    
date     : Sat, 21 Jun 2014 09:17:24 -0500    

By using curly braces, the template had specified that one of  
"NOT DEFERRABLE", "INITIALLY IMMEDIATE", or "INITIALLY DEFERRED"  
was required on any CREATE TRIGGER statement, which is not  
accurate.  Change to square brackets makes that optional.  
  
Backpatch to 9.1, where the error was introduced.  

commit   : b3a3f3d2f437922258371aee78c587b3f774b992    
  
author   : Joe Conway <[email protected]>    
date     : Fri, 20 Jun 2014 12:22:50 -0700    
  
committer: Joe Conway <[email protected]>    
date     : Fri, 20 Jun 2014 12:22:50 -0700    

dblink uses a short-lived data conversion memory context. However it  
was not deleted when no longer needed, leading to a noticeable memory  
leak under some circumstances. Plug the hole, along with minor  
refactoring. Backpatch to 9.2 where the leak was introduced.  
  
Report and initial patch by MauMau. Reviewed/modified slightly by  
Tom Lane and me.  

commit   : 46c450c0b04471fc52602520c0a436bda42a3c0d    
  
author   : Andres Freund <[email protected]>    
date     : Fri, 20 Jun 2014 11:06:53 +0200    
  
committer: Andres Freund <[email protected]>    
date     : Fri, 20 Jun 2014 11:06:53 +0200    

Since fdf9e21196a lazy_vacuum_page() rechecks the all-visible status  
of pages in the second pass over the heap. It does so inside a  
critical section, but both visibilitymap_test() and  
heap_page_is_all_visible() perform operations that should not happen  
inside one. The former potentially performs IO and both potentially do  
memory allocations.  
  
To fix, simply move all the all-visible handling outside the critical  
section. Doing so means that the PD_ALL_VISIBLE on the page won't be  
included in the full page image of the HEAP2_CLEAN record anymore. But  
that's fine, the flag will be set by the HEAP2_VISIBLE logged later.  
  
Backpatch to 9.3 where the problem was introduced. The bug only came  
to light due to the assertion added in 4a170ee9 and isn't likely to  
cause problems in production scenarios. The worst outcome is a  
avoidable PANIC restart.  
  
This also gets rid of the difference in the order of operations  
between master and standby mentioned in 2a8e1ac5.  
  
Per reports from David Leverton and Keith Fiske in bug #10533.  

commit   : c1f8fb9bfb0d2a89f646b3186a004d6e4ebdecb4    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 19 Jun 2014 22:13:47 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 19 Jun 2014 22:13:47 -0400    

ExecMakeTableFunctionResult evaluated the arguments for a function-in-FROM  
in the query-lifespan memory context.  This is insignificant in simple  
cases where the function relation is scanned only once; but if the function  
is in a sub-SELECT or is on the inside of a nested loop, any memory  
consumed during argument evaluation can add up quickly.  (The potential for  
trouble here had been foreseen long ago, per existing comments; but we'd  
not previously seen a complaint from the field about it.)  To fix, create  
an additional temporary context just for this purpose.  
  
Per an example from MauMau.  Back-patch to all active branches.  

commit   : 1442b426e5d724c90070f890fed36332f4b17884    
  
author   : Noah Misch <[email protected]>    
date     : Sat, 14 Jun 2014 09:41:13 -0400    
  
committer: Noah Misch <[email protected]>    
date     : Sat, 14 Jun 2014 09:41:13 -0400    

Any OS user able to access the socket can connect as the bootstrap  
superuser and proceed to execute arbitrary code as the OS user running  
the test.  Protect against that by placing the socket in a temporary,  
mode-0700 subdirectory of /tmp.  The pg_regress-based test suites and  
the pg_upgrade test suite were vulnerable; the $(prove_check)-based test  
suites were already secure.  Back-patch to 8.4 (all supported versions).  
The hazard remains wherever the temporary cluster accepts TCP  
connections, notably on Windows.  
  
As a convenient side effect, this lets testing proceed smoothly in  
builds that override DEFAULT_PGSOCKET_DIR.  Popular non-default values  
like /var/run/postgresql are often unwritable to the build user.  
  
Security: CVE-2014-0067  

commit   : 841baf28f8e86b67c0b036fb921446a310e5c60b    
  
author   : Noah Misch <[email protected]>    
date     : Sat, 14 Jun 2014 09:41:13 -0400    
  
committer: Noah Misch <[email protected]>    
date     : Sat, 14 Jun 2014 09:41:13 -0400    

This function is pervasive on free software operating systems; import  
NetBSD's implementation.  Back-patch to 8.4, like the commit that will  
harness it.  

commit   : a11577f47e5ed1d6271188ec5830fecf1036ce4d    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 12 Jun 2014 20:14:39 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 12 Jun 2014 20:14:39 -0400    

Prior to 9.0, pg_dump handled comments on large objects by dumping a bunch  
of COMMENT commands into a single BLOB COMMENTS archive object.  With  
sufficiently many such comments, some of the commands would likely get  
split across bufferloads when restoring, causing failures in  
direct-to-database restores (though no problem would be evident in text  
output).  This is the same type of issue we have with table data dumped as  
INSERT commands, and it can be fixed in the same way, by using a mini SQL  
lexer to figure out where the command boundaries are.  Fortunately, the  
COMMENT commands are no more complex to lex than INSERTs, so we can just  
re-use the existing lexer for INSERTs.  
  
Per bug #10611 from Jacek Zalewski.  Back-patch to all active branches.  

commit   : 71ffbe5e60c1a8de2cde41dfcd2ec5668bacc1a9    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 12 Jun 2014 16:51:08 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 12 Jun 2014 16:51:08 -0400    

Robert Frost is no longer with us, but his copyrights still are, so  
let's stop using "Stopping by Woods on a Snowy Evening" as test data  
before somebody decides to sue us.  Wordsworth is more safely dead.  

commit   : 87db9534a19382af3345ed319d14fcd66211fe63    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 10 Jun 2014 22:48:16 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 10 Jun 2014 22:48:16 -0400    

When we grabbed this file off the Snowball project's website, we mistakenly  
supposed that it was in LATIN1 encoding, but evidently it was actually in  
LATIN2.  This resulted in ő (o-double-acute, U+0151, which is code 0xF5 in  
LATIN2) being misconverted into õ (o-tilde, U+00F5), as complained of in  
bug #10589 from Zoltán Sörös.  We'd have messed up u-double-acute too,  
but there aren't any of those in the file.  Other characters used in the  
file have the same codes in LATIN1 and LATIN2, which no doubt helped hide  
the problem for so long.  
  
The error is not only ours: the Snowball project also was confused about  
which encoding is required for Hungarian.  But dealing with that will  
require source-code changes that I'm not at all sure we'll wish to  
back-patch.  Fixing the stopword file seems reasonably safe to back-patch  
however.  

commit   : 04b598b230953c9b1495b1efdce0bad5cbd28eb0    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 9 Jun 2014 21:37:20 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 9 Jun 2014 21:37:20 -0400    

Although this bug is already fixed in post-9.2 branches, the case  
triggering it is quite different from what was under consideration  
at the time.  It seems worth memorializing this example in HEAD  
just to make sure it doesn't get broken again in future.  
  
Extracted from commit 187ae17300776f48b2bd9d0737923b1bf70f606e.  

commit   : 717c116f1dd995921787243e5c58f49877af6ca0    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 9 Jun 2014 16:30:43 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 9 Jun 2014 16:30:43 -0400    

Previously, the code used a node label of zero both for strings that  
contain no bytes beyond the inner tuple's prefix, and for cases where an  
"allTheSame" inner tuple has to be split to allow a string with a different  
next byte to be inserted into it.  Failing to distinguish these cases meant  
that if a string ending with the current prefix needed to be inserted into  
an allTheSame tuple, we got into an infinite loop, because after splitting  
the tuple we'd descend into the child allTheSame tuple and then find we  
need to split again.  
  
To fix, instead use -1 and -2 as the node labels for these two cases.  
This requires widening the node label type from "char" to int2, but  
fortunately SPGiST stores all pass-by-value node label types in their  
Datum representation, which means that this change is transparently upward  
compatible so far as the on-disk representation goes.  We continue to  
recognize zero as a dummy node label for reading purposes, but will not  
attempt to push new index entries down into such a label, so that the loop  
won't occur even when dealing with an existing index.  
  
Per report from Teodor Sigaev.  Back-patch to 9.2 where the faulty  
code was introduced.  

commit   : 167a2535f8e73f792d87e3dfef094cbe4655ca23    
  
author   : Alvaro Herrera <[email protected]>    
date     : Mon, 9 Jun 2014 15:17:23 -0400    
  
committer: Alvaro Herrera <[email protected]>    
date     : Mon, 9 Jun 2014 15:17:23 -0400    

In a50d97625497b7 I already changed this, but got it wrong for the case  
where the number of members is larger than the number of entries that  
fit in the last page of the last segment.  
  
As reported by Serge Negodyuck in a followup to bug #8673.  

commit   : e2f02ed64e5e953d60315b19509f697b073f840d    
  
author   : Fujii Masao <[email protected]>    
date     : Fri, 6 Jun 2014 18:46:32 +0900    
  
committer: Fujii Masao <[email protected]>    
date     : Fri, 6 Jun 2014 18:46:32 +0900    

This commit changes HS regression test so that it uses  
REPEATABLE READ transaction instead of SERIALIZABLE one  
because SERIALIZABLE transaction isolation level is not  
available in HS. Also this commit fixes VACUUM/ANALYZE  
label mixup.  
  
This was fixed in HEAD (commit 2985e16), but it should  
have been back-patched to 9.1 which had introduced SSI  
and forbidden SERIALIZABLE transaction in HS.  
  
Amit Langote  

commit   : 780852ef00506414c8c471e042bfa8b9bca182ef    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 5 Jun 2014 11:31:09 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 5 Jun 2014 11:31:09 -0400    

It's critical that the backend's idea of LOBLKSIZE match the way data has  
actually been divided up in pg_largeobject.  While we don't provide any  
direct way to adjust that value, doing so is a one-line source code change  
and various people have expressed interest recently in changing it.  So,  
just as with TOAST_MAX_CHUNK_SIZE, it seems prudent to record the value in  
pg_control and cross-check that the backend's compiled-in setting matches  
the on-disk data.  
  
Also tweak the code in inv_api.c so that fetches from pg_largeobject  
explicitly verify that the length of the data field is not more than  
LOBLKSIZE.  Formerly we just had Asserts() for that, which is no protection  
at all in production builds.  In some of the call sites an overlength data  
value would translate directly to a security-relevant stack clobber, so it  
seems worth one extra runtime comparison to be sure.  
  
In the back branches, we can't change the contents of pg_control; but we  
can still make the extra checks in inv_api.c, which will offer some amount  
of protection against running with the wrong value of LOBLKSIZE.  

commit   : edde59db1339397ec389d45e4c0d0f86064dad1a    
  
author   : Andres Freund <[email protected]>    
date     : Wed, 4 Jun 2014 23:26:08 +0200    
  
committer: Andres Freund <[email protected]>    
date     : Wed, 4 Jun 2014 23:26:08 +0200    

HeapTupleSatisfiesVacuum() didn't properly discern between  
DELETE_IN_PROGRESS and INSERT_IN_PROGRESS for rows that have been  
inserted in the current transaction and deleted in a aborted  
subtransaction of the current backend. At the very least that caused  
problems for CLUSTER and CREATE INDEX in transactions that had  
aborting subtransactions producing rows, leading to warnings like:  
WARNING:  concurrent delete in progress within table "..."  
possibly in an endless, uninterruptible, loop.  
  
Instead of treating *InProgress xmins the same as *IsCurrent ones,  
treat them as being distinct like the other visibility routines. As  
implemented this separatation can cause a behaviour change for rows  
that have been inserted and deleted in another, still running,  
transaction. HTSV will now return INSERT_IN_PROGRESS instead of  
DELETE_IN_PROGRESS for those. That's both, more in line with the other  
visibility routines and arguably more correct. The latter because a  
INSERT_IN_PROGRESS will make callers look at/wait for xmin, instead of  
xmax.  
The only current caller where that's possibly worse than the old  
behaviour is heap_prune_chain() which now won't mark the page as  
prunable if a row has concurrently been inserted and deleted. That's  
harmless enough.  
  
As a cautionary measure also insert a interrupt check before the gotos  
in IndexBuildHeapScan() that lead to the uninterruptible loop. There  
are other possible causes, like a row that several sessions try to  
update and all fail, for repeated loops and the cost of doing so in  
the retry case is low.  
  
As this bug goes back all the way to the introduction of  
subtransactions in 573a71a5da backpatch to all supported releases.  
  
Reported-By: Sandro Santilli  

commit   : 8dc90b9c4c45fa30a8f59313e21d294529ef7182    
  
author   : Fujii Masao <[email protected]>    
date     : Thu, 5 Jun 2014 01:46:31 +0900    
  
committer: Fujii Masao <[email protected]>    
date     : Thu, 5 Jun 2014 01:46:31 +0900    

Back-patch to 9.3 where pg_stat directory was introduced.  

commit   : 9dee1e4b3832c1cdb1b052a58dca0cf33929438a    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 3 Jun 2014 12:01:30 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 3 Jun 2014 12:01:30 -0400    

This test previously used a data value containing U+0080, and would  
therefore fail if the database encoding didn't have an equivalent to  
that; which only about half of our supported server encodings do.  
We could fall back to using some plain-ASCII character, but that seems  
like it's losing most of the point of the test.  Instead switch to using  
U+00A0 (no-break space), which translates into all our supported encodings  
except the four in the EUC_xx family.  
  
Per buildfarm testing.  Back-patch to 9.1, which is as far back as this  
test is expected to succeed everywhere.  (9.0 has the test, but without  
back-patching some 9.1 code changes we could not expect to get consistent  
results across platforms anyway.)  

commit   : ee6c5f10d53f9dd73007535ff4cba752e7e70f5e    
  
author   : Andres Freund <[email protected]>    
date     : Tue, 3 Jun 2014 14:02:54 +0200    
  
committer: Andres Freund <[email protected]>    
date     : Tue, 3 Jun 2014 14:02:54 +0200    

Because RecoveryConflictInterrupt() didn't set the process latch  
anything using the latter to wait for events didn't get notified about  
recovery conflicts. Most latch users are never the target of recovery  
conflicts, which explains the lack of reports about this until  
now.  
Since 9.3 two possible affected users exist though: The sql callable  
pg_sleep() now uses latches to wait and background workers are  
expected to use latches in their main loop. Both would currently wait  
until the end of WaitLatch's timeout.  
  
Fix by adding a SetLatch() to RecoveryConflictInterrupt(). It'd also  
be possible to fix the issue by having each latch user set  
set_latch_on_sigusr1. That seems failure prone and though, as most of  
these callsites won't often receive recovery conflicts and thus will  
likely only be tested against normal query cancels et al. It'd also be  
unnecessarily verbose.  
  
Backpatch to 9.1 where latches were introduced. Arguably 9.3 would be  
sufficient, because that's where pg_sleep() was converted to waiting  
on the latch and background workers got introduced; but there could be  
user level code making use of the latch pre 9.3.  

commit   : c102c32e9ad3066eaa0e13492a5d03dc511811c8    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 1 Jun 2014 15:03:15 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 1 Jun 2014 15:03:15 -0400    

Back-patch commit d0765d50f429472d00554701ac6531c84d324811 into 9.3  
and 9.2, which is as far back as we previously bothered to adjust the  
regression tests for Python 3.3.  Per gripe from Honza Horak.  

commit   : 4f5f4da79ee805681f1f23a107bc905d647f12bc    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 30 May 2014 18:18:14 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 30 May 2014 18:18:14 -0400    

As of Xcode 5.0, Apple isn't including the Python framework as part of the  
SDK-level files, which means that linking to it might fail depending on  
whether Xcode thinks you've selected a specific SDK version.  According to  
their Tech Note 2328, they've basically deprecated the framework method of  
linking to libpython and are telling people to link to the shared library  
normally.  (I'm pretty sure this is in direct contradiction to the advice  
they were giving a few years ago, but whatever.)  Testing says that this  
approach works fine at least as far back as OS X 10.4.11, so let's just  
rip out the framework special case entirely.  We do still need a special  
case to decide that OS X provides a shared library at all, unfortunately  
(I wonder why the distutils check doesn't work ...).  But this is still  
less of a special case than before, so it's fine.  
  
Back-patch to all supported branches, since we'll doubtless be hearing  
about this more as more people update to recent Xcode.  

commit   : 6f11869d13a7163a97c90a0452a465b6b3f03d82    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Fri, 30 May 2014 10:27:40 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Fri, 30 May 2014 10:27:40 +0300    

Michael Paquier  

commit   : 961dd203a2503ada9c458b79e9dbf43bb478864e    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 29 May 2014 13:51:05 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 29 May 2014 13:51:05 -0400    

The original coding in contrib/uuid-ossp created and destroyed a uuid_t  
object (or, in some cases, even two of them) each time it was called.  
This is not the intended usage: you're supposed to keep the uuid_t object  
around so that the library can cache its state across uses.  (Other UUID  
libraries seem to keep equivalent state behind-the-scenes in static  
variables, but OSSP chose differently.)  Aside from being quite inefficient,  
creating a new uuid_t loses knowledge of the previously generated UUID,  
which in theory could result in duplicate V1-style UUIDs being created  
on sufficiently fast machines.  
  
On at least some platforms, creating a new uuid_t also draws some entropy  
from /dev/urandom, leaving less for the rest of the system.  This seems  
sufficiently unpleasant to justify back-patching this change.  

commit   : 2677bace522cae86fae899c58b58c11d7b45fd56    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 28 May 2014 19:28:37 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 28 May 2014 19:28:37 -0400    

This reverts commit ece7aa8b0f57d92577055a88579555df895eb929.  
  
It turns out that the %name-prefix syntax without "=" does not work  
at all in pre-2.4 Bison.  We are not prepared to make such a large  
jump in minimum required Bison version just to suppress a warning  
message in a version hardly any developers are using yet.  
When 3.0 gets more popular, we'll figure out a way to deal with this.  
In the meantime, BISONFLAGS=-Wno-deprecated is recommendable for  
anyone using 3.0 who doesn't want to see the warning.  

commit   : ece7aa8b0f57d92577055a88579555df895eb929    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 28 May 2014 15:41:55 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 28 May 2014 15:41:55 -0400    

%name-prefix doesn't use an "=" sign according to the Bison docs, but it  
silently accepted one anyway, until Bison 3.0.  This was originally a  
typo of mine in commit 012abebab1bc72043f3f670bf32e91ae4ee04bd2, and we  
seem to have slavishly copied the error into all the other grammar files.  
  
Per report from Vik Fearing; analysis by Peter Eisentraut.  
  
Back-patch to all active branches, since somebody might try to build  
a back branch with up-to-date tools.  

commit   : 433cacfc0f1bf245a13df60da4bded02c5b61165    
  
author   : Magnus Hagander <[email protected]>    
date     : Wed, 28 May 2014 13:00:09 +0200    
  
committer: Magnus Hagander <[email protected]>    
date     : Wed, 28 May 2014 13:00:09 +0200    

Move the code that sends the initial status information as well as the  
calculation of paths inside the ENSURE_ERROR_CLEANUP block. If this code  
failed, we would "leak" a counter of number of concurrent backups, thereby  
making the system always believe it was in backup mode. This could happen  
if the sending failed (which it probably never did given that the small  
amount of data to send would never cause a flush). It is very low risk, but  
all operations after do_pg_start_backup should be protected.  

commit   : b8cf89c041d0789d9353a2875a1041c77429037c    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 26 May 2014 22:23:33 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 26 May 2014 22:23:33 -0400    

On Mingw, it seems that scanf() doesn't necessarily accept the same format  
codes that printf() does, and in particular it may fail to recognize %llu  
even though printf() does.  Since configure only probes printf() behavior  
while setting up the INT64_FORMAT macros, this means it's unsafe to use  
those macros with scanf().  We had only one instance of such a coding  
pattern, in contrib/pg_stat_statements, so change that code to avoid  
the problem.  
  
Per buildfarm warnings.  Back-patch to 9.0 where the troublesome code  
was introduced.  
  
Michael Paquier  

commit   : 0266a9c78139d0f0d64dc1c440e60b8f30172046    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 20 May 2014 12:20:52 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 20 May 2014 12:20:52 -0400    

Commit af7914c6627bcf0b0ca614e9ce95d3f8056602bf, which introduced the  
EXPLAIN (TIMING) option, for some reason coded explain.c to look at  
planstate->instrument->need_timer rather than es->timing to decide  
whether to print timing info.  However, the former flag might get set  
as a result of contrib/auto_explain wanting timing information.  We  
certainly don't want activation of auto_explain to change user-visible  
statement behavior, so fix that.  
  
Also fix an independent bug introduced in the same patch: in the code  
path for a never-executed node with a machine-friendly output format,  
if timing was selected, it would fail to print the Actual Rows and Actual  
Loops items.  
  
Per bug #10404 from Tomonari Katsumata.  Back-patch to 9.2 where the  
faulty code was introduced.  

commit   : e0c04b7c3833c3874bf8ca91eb3a8ef45ac00ae4    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Mon, 19 May 2014 13:21:59 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Mon, 19 May 2014 13:21:59 +0300    

The macros and functions that work with backup blocks in the redo function  
use 0-based numbering, so let's use that consistently in the function that  
generates the records too. Makes it so much easier to compare the  
generation and replay functions.  
  
Backpatch to 9.0, where we switched from 1-based to 0-based numbering.  

commit   : 777d07d7a34f6af2a977297846a9ae133e727d9c    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 19 May 2014 00:06:28 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 19 May 2014 00:06:28 -0400    

C89 says that compound initializers may only contain constant expressions;  
a restriction violated by commit 89d00cbe.  While we've had no actual field  
complaints about this, C89 is still the project standard, and it's not  
saving all that much code to break compatibility here.  So let's adhere to  
the old restriction.  
  
In passing, replace a bunch of hardwired constants "256" with  
sizeof(target-variable), just because the latter is more readable and  
less breakable.  And const-ify where possible.  
  
Back-patch to 9.3 where the nonportable code was added.  
  
Andres Freund and Tom Lane  

commit   : d6a9767404cfee7f037a58e445b601af5837e4a5    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Fri, 16 May 2014 09:47:50 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Fri, 16 May 2014 09:47:50 +0300    

Commit dd428c79 added dbId and tsId to the xl_xact_commit struct but missed  
that prepared transaction commits reuse that struct. Fix that.  
  
Because those fields were left unitialized, replaying a commit prepared WAL  
record in a hot standby node would fail to remove the relcache init file.  
That can lead to "could not open file" errors on the standby. Relcache init  
file only needs to be removed when a system table/index is rewritten in the  
transaction using two phase commit, so that should be rare in practice. In  
HEAD, the incorrect dbId/tsId values are also used for filtering in logical  
replication code, causing the transaction to always be filtered out.  
  
Analysis and fix by Andres Freund. Backpatch to 9.0 where hot standby was  
introduced.  

commit   : 8960b2db5151575099da7cadff10e3316af8c16b    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 15 May 2014 15:57:57 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 15 May 2014 15:57:57 -0400    

In yesterday's commit 2dc4f011fd61501cce507be78c39a2677690d44b, I tried  
to force buffering of stdout/stderr in initdb to be what it is by  
default when the program is run interactively on Unix (since that's how  
most manual testing is done).  This tripped over the fact that Windows  
doesn't support _IOLBF mode.  We dealt with that a long time ago in  
syslogger.c by falling back to unbuffered mode on Windows.  Export that  
solution in port.h and use it in initdb.  
  
Back-patch to 8.4, like the previous commit.  

commit   : 19d7e8f07abf6b3a2e3d7c0c9c51041dfaac0ad6    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Thu, 15 May 2014 18:29:20 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Thu, 15 May 2014 18:29:20 +0300    

The proc array can contain duplicate XIDs, when a transaction is just being  
prepared for two-phase commit. To cope, remove any duplicates in  
txid_current_snapshot(). Also ignore duplicates in the input functions, so  
that if e.g. you have an old pg_dump file that already contains duplicates,  
it will be accepted.  
  
Report and fix by Jan Wieck. Backpatch to all supported versions.  

commit   : 48fc8962f9f1ec456735500795ba894c5da9e89a    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Thu, 15 May 2014 16:37:50 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Thu, 15 May 2014 16:37:50 +0300    

To lock a prepared transaction's shared memory entry, we used to mark it  
with the XID of the backend. When the XID was no longer active according  
to the proc array, the entry was implicitly considered as not locked  
anymore. However, when preparing a transaction, the backend's proc array  
entry was cleared before transfering the locks (and some other state) to  
the prepared transaction's dummy PGPROC entry, so there was a window where  
another backend could finish the transaction before it was in fact fully  
prepared.  
  
To fix, rewrite the locking mechanism of global transaction entries. Instead  
of an XID, just have simple locked-or-not flag in each entry (we store the  
locking backend's backend id rather than a simple boolean, but that's just  
for debugging purposes). The backend is responsible for explicitly unlocking  
the entry, and to make sure that that happens, install a callback to unlock  
it on abort or process exit.  
  
Backpatch to all supported versions.  

commit   : 4511e6c831e3d16303d6df183a00d33f5d6ba3e8    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 14 May 2014 21:13:56 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 14 May 2014 21:13:56 -0400    

Since this program may print to either stdout or stderr, the relative  
ordering of its messages depends on the buffering behavior of those files.  
Force stdout to be line-buffered and stderr to be unbuffered, ensuring  
that the behavior will match standard Unix interactive behavior, even  
when stdout and stderr are rerouted to a file.  
  
Per complaint from Tomas Vondra.  The particular case he pointed out is  
new in HEAD, but issues of the same sort could arise in any branch with  
other error messages, so back-patch to all branches.  
  
I'm unsure whether we might not want to do this in other client programs  
as well.  For the moment, just fix initdb.  

commit   : e7a9020939c9f09eddf6cf2f5477f82a1efcbf09    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 14 May 2014 14:55:50 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 14 May 2014 14:55:50 -0400    

rd_replidindex should be managed the same as rd_oidindex, and rd_keyattr  
and rd_idattr should be managed like rd_indexattr.  Omissions in this area  
meant that the bitmapsets computed for rd_keyattr and rd_idattr would be  
leaked during any relcache flush, resulting in a slow but permanent leak in  
CacheMemoryContext.  There was also a tiny probability of relcache entry  
corruption if we ran out of memory at just the wrong point in  
RelationGetIndexAttrBitmap.  Otherwise, the fields were not zeroed where  
expected, which would not bother the code any AFAICS but could greatly  
confuse anyone examining the relcache entry while debugging.  
  
Also, create an API function RelationGetReplicaIndex rather than letting  
non-relcache code be intimate with the mechanisms underlying caching of  
that value (we won't even mention the memory leak there).  
  
Also, fix a relcache flush hazard identified by Andres Freund:  
RelationGetIndexAttrBitmap must not assume that rd_replidindex stays valid  
across index_open.  
  
The aspects of this involving rd_keyattr date back to 9.3, so back-patch  
those changes.  

commit   : d5b912c905efd531a6228d08c98cd92d49cdd94c    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Tue, 13 May 2014 14:16:28 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Tue, 13 May 2014 14:16:28 +0300    

The code expands a varbit gist leaf key to a node key by copying the bit  
data twice in a varlen datum, as both the lower and upper key. The lower key  
was expanded to INTALIGN size, but the padding bytes were not initialized.  
That's a problem because when the lower/upper keys are compared, the padding  
bytes are used compared too, when the values are otherwise equal. That could  
lead to incorrect query results.  
  
REINDEX is advised for any btree_gist indexes on bit or bit varying data  
type, to fix any garbage padding bytes on disk.  
  
Per Valgrind, reported by Andres Freund. Backpatch to all supported  
versions.  

commit   : b65a258a512049eba567283d93bd63b22b77916a    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 12 May 2014 14:24:18 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 12 May 2014 14:24:18 -0400    

config.pl and buildenv.pl can be used to customize build settings when  
using MSVC.  They should never get committed into the common source tree.  
  
Back-patch to 9.0; it looks like the rules were different in 8.4.  
  
Michael Paquier  

commit   : 0ad78306be6bd3db0575b0d046e4cbe7f50635b8    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Mon, 12 May 2014 10:17:40 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Mon, 12 May 2014 10:17:40 +0300    

The leak is fairly small and rare, but a leak nevertheless.  
  
Per Coverity report. Backpatch to 9.2, where pg_receivexlog was added.  
pg_basebackup shares the code, but it always exits on error, so there is  
no real leak.  

commit   : c6d048c97864daa1a5011c5b11484e7d426139ba    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 10 May 2014 10:48:04 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 10 May 2014 10:48:04 -0400    

Usually the search would find plain "tclsh" without any trouble,  
but some installations might only have the version-numbered flavor  
of that program.  
  
No compatibility problems have been reported with 8.6, so we might  
as well back-patch this to all active branches.  
  
Christoph Berg  

commit   : 13c6799958f82b3f3ad1123c0be58d8420973a63    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 9 May 2014 12:55:03 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 9 May 2014 12:55:03 -0400    

These functions were relying on typcategory to identify arrays and  
composites, which is not reliable and not the normal way to do it.  
Using typcategory to identify boolean, numeric types, and json itself is  
also pretty questionable, though the code in those cases didn't seem to be  
at risk of anything worse than wrong output.  Instead, use the standard  
lsyscache functions to identify arrays and composites, and rely on a direct  
check of the type OID for the other cases.  
  
In HEAD, also be sure to look through domains so that a domain is treated  
the same as its base type for conversions to JSON.  However, this is a  
small behavioral change; given the lack of field complaints, we won't  
back-patch it.  
  
In passing, refactor so that there's only one copy of the code that decides  
which conversion strategy to apply, not multiple copies that could (and  
have) gotten out of sync.  

commit   : 5c6d3e405ff533a9d52ae3c24eddda09e0ae1a68    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 8 May 2014 21:45:02 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 8 May 2014 21:45:02 -0400    

Back in 8.3, we installed permissions checks in these functions (see  
commits 8bc225e7990a and cc26599b7206).  But we forgot to document that  
anywhere in the user-facing docs; it did get mentioned in the 8.3 release  
notes, but nobody's looking at that any more.  Per gripe from Suya Huang.  

commit   : 40d6f6a30f7fbb13e3709c0bbe443ffa1db0241f    
  
author   : Noah Misch <[email protected]>    
date     : Thu, 8 May 2014 19:29:02 -0400    
  
committer: Noah Misch <[email protected]>    
date     : Thu, 8 May 2014 19:29:02 -0400    

Commit 4318daecc959886d001a6e79c6ea853e8b1dfb4b broke it.  The change in  
sub-second precision at extreme dates is normal.  The inconsistent  
truncation vs. rounding is essentially a bug, albeit a longstanding one.  
Back-patch to 8.4, like the causative commit.  

commit   : 34572920c92680b8c29779060632d7f40168cae2    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Thu, 8 May 2014 14:43:04 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Thu, 8 May 2014 14:43:04 +0300    

To-be-deleted list pages contain no useful information, as they are being  
deleted, but we must still protect the writes from being torn by a crash  
after a partial write. To do that, re-initialize the pages on WAL replay.  
  
Jeff Janes caught this with a test program to test partial writes.  
Backpatch to all supported versions.  

commit   : cd7df1060b405c15353e61dfab2404e97c3482c1    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Thu, 8 May 2014 10:56:57 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Thu, 8 May 2014 10:56:57 +0300    

Michael Paquier  

commit   : b4f9c93ce0556e3afe371566b96e093f8228bf8f    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 7 May 2014 21:38:38 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 7 May 2014 21:38:38 -0400    

If the server sends a long stream of data, and the server + network are  
consistently fast enough to force the recv() loop in pqReadData() to  
iterate until libpq's input buffer is full, then upon processing the last  
incomplete message in each bufferload we'd usually double the buffer size,  
due to supposing that we didn't have enough room in the buffer to finish  
collecting that message.  After filling the newly-enlarged buffer, the  
cycle repeats, eventually resulting in an out-of-memory situation (which  
would be reported misleadingly as "lost synchronization with server").  
Of course, we should not enlarge the buffer unless we still need room  
after discarding already-processed messages.  
  
This bug dates back quite a long time: pqParseInput3 has had the behavior  
since perhaps 2003, getCopyDataMessage at least since commit 70066eb1a1ad  
in 2008.  Probably the reason it's not been isolated before is that in  
common environments the recv() loop would always be faster than the server  
(if on the same machine) or faster than the network (if not); or at least  
it wouldn't be slower consistently enough to let the buffer ramp up to a  
problematic size.  The reported cases involve Windows, which perhaps has  
different timing behavior than other platforms.  
  
Per bug #7914 from Shin-ichi Morita, though this is different from his  
proposed solution.  Back-patch to all supported branches.  

commit   : fc58c39d468587467c7c55b349c28167794eadaf    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 7 May 2014 14:25:13 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 7 May 2014 14:25:13 -0400    

ActiveSnapshot needs to be set when we call ExecutorRewind because some  
plan node types may execute user-defined functions during their ReScan  
calls (nodeLimit.c does so, at least).  The wisdom of that is somewhat  
debatable, perhaps, but for now the simplest fix is to make sure the  
required context is valid.  Failure to do this typically led to a  
null-pointer-dereference core dump, though it's possible that in more  
complex cases a function could be executed with the wrong snapshot  
leading to very subtle misbehavior.  
  
Per report from Leif Jensen.  It's been broken for a long time, so  
back-patch to all active branches.  

commit   : b671061e1452ce27dbb9ffe6d56a87874c8bd347    
  
author   : Jeff Davis <[email protected]>    
date     : Tue, 6 May 2014 19:35:24 -0700    
  
committer: Jeff Davis <[email protected]>    
date     : Tue, 6 May 2014 19:35:24 -0700    

Commit 4318daecc959886d001a6e79c6ea853e8b1dfb4b introduced a test that  
couldn't be made consistent between integer and floating-point  
timestamps.  
  
It was designed to test the longest possible interval output length,  
so removing four zeros from the number of hours, as this patch does,  
is not ideal. But the test still has some utility for its original  
purpose, and there aren't a lot of other good options.  
  
Noah Misch suggested a different approach where we test that the  
output either matches what we expect from integer timestamps or what  
we expect from floating-point timestamps. That seemed to obscure an  
otherwise simple test, however.  
  
Reviewed by Tom Lane and Noah Misch.  

commit   : 04e15c69d2176849aad40dc8df55761ba0ad0491    
  
author   : Bruce Momjian <[email protected]>    
date     : Tue, 6 May 2014 11:26:28 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Tue, 6 May 2014 11:26:28 -0400    

This was not changed in HEAD, but will be done later as part of a  
pgindent run.  Future pgindent runs will also do this.  
  
Report by Tom Lane  
  
Backpatch through all supported branches, but not HEAD  

commit   : 41fdcf71d2b424104e08ce229104b8e8e2840d1b    
  
author   : Simon Riggs <[email protected]>    
date     : Tue, 6 May 2014 14:45:05 +0100    
  
committer: Simon Riggs <[email protected]>    
date     : Tue, 6 May 2014 14:45:05 +0100    

Logic is correct, matching handling of LP_DEAD elsewhere.  

commit   : a7a3e71c8592a530f9a605aea4f08af7ad8e0ab3    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Tue, 6 May 2014 15:14:51 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Tue, 6 May 2014 15:14:51 +0300    

Found via valgrind. The bug exists since the introduction of the walsender,  
so backpatch to 9.0.  
  
Andres Freund  

commit   : b4eeb9d58ec9237a3f2a9d6c5b1d4374beb2e675    
  
author   : Michael Meskes <[email protected]>    
date     : Tue, 6 May 2014 13:04:30 +0200    
  
committer: Michael Meskes <[email protected]>    
date     : Tue, 6 May 2014 13:04:30 +0200    

When array of char * was used as target for a FETCH statement returning more  
than one row, it tried to store all the result in the first element. Instead it  
should dump array of char pointers with right offset, use the address instead  
of the value of the C variable while reading the array and treat such variable  
as char **, instead of char * for pointer arithmetic.  
  
Patch by Ashutosh Bapat <[email protected]>  

commit   : 4f4ef042fddb9698fe4147ca15d92992206d3fbb    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 5 May 2014 14:43:42 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 5 May 2014 14:43:42 -0400    

Commit fad153ec45299bd4d4f29dec8d9e04e2f1c08148 modified sinval.c to reduce  
the number of calls into sinvaladt.c (which require taking a shared lock)  
by keeping a local buffer of collected-but-not-yet-processed messages.  
However, if processing of the last message in a batch resulted in a  
recursive call to ReceiveSharedInvalidMessages, we could overwrite that  
message with a new one while the outer invalidation function was still  
working on it.  This would be likely to lead to invalidation of the wrong  
cache entry, allowing subsequent processing to use stale cache data.  
The fix is just to make a local copy of each message while we're processing  
it.  
  
Spotted by Andres Freund.  Back-patch to 8.4 where the bug was introduced.  

commit   : 693a82dddf9657eb4cda2293acc219ca79066ab5    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 2 May 2014 15:30:29 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 2 May 2014 15:30:29 -0400    

This test used to just define an unused static inline function and check  
whether that causes a warning.  But newer clang versions warn about  
unused static inline functions when defined inside a .c file, but not  
when defined in an included header, which is the case we care about.  
Change the test to cope.  
  
Andres Freund  

commit   : e31193d495f668b2e2e98db290f36af83b6c70e8    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 1 May 2014 20:22:39 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 1 May 2014 20:22:39 -0400    

ruleutils.c tries to cope with additions/deletions/renamings of columns in  
tables referenced by views, by means of adding machine-generated aliases to  
the printed form of a view when needed to preserve the original semantics.  
A recent blog post by Marko Tiikkaja pointed out a case I'd missed though:  
if one input of a join with USING is itself a join, there is nothing to  
stop the user from adding a column of the same name as the USING column to  
whichever side of the sub-join didn't provide the USING column.  And then  
there'll be an error when the view is re-parsed, since now the sub-join  
exposes two columns matching the USING specification.  We were catching a  
lot of related cases, but not this one, so add some logic to cope with it.  
  
Back-patch to 9.3, which is the first release that makes any serious  
attempt to cope with such cases (cf commit 2ffa740be and follow-ons).  

commit   : b72e90bc3117a03f8964a2a5e74f92ecef0328af    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 1 May 2014 15:19:10 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 1 May 2014 15:19:10 -0400    

If we have an array of records stored on disk, the individual record fields  
cannot contain out-of-line TOAST pointers: the tuptoaster.c mechanisms are  
only prepared to deal with TOAST pointers appearing in top-level fields of  
a stored row.  The same applies for ranges over composite types, nested  
composites, etc.  However, the existing code only took care of expanding  
sub-field TOAST pointers for the case of nested composites, not for other  
structured types containing composites.  For example, given a command such  
as  
  
UPDATE tab SET arraycol = ARRAY[(ROW(x,42)::mycompositetype] ...  
  
where x is a direct reference to a field of an on-disk tuple, if that field  
is long enough to be toasted out-of-line then the TOAST pointer would be  
inserted as-is into the array column.  If the source record for x is later  
deleted, the array field value would become a dangling pointer, leading  
to errors along the line of "missing chunk number 0 for toast value ..."  
when the value is referenced.  A reproducible test case for this was  
provided by Jan Pecek, but it seems likely that some of the "missing chunk  
number" reports we've heard in the past were caused by similar issues.  
  
Code-wise, the problem is that PG_DETOAST_DATUM() is not adequate to  
produce a self-contained Datum value if the Datum is of composite type.  
Seen in this light, the problem is not just confined to arrays and ranges,  
but could also affect some other places where detoasting is done in that  
way, for example form_index_tuple().  
  
I tried teaching the array code to apply toast_flatten_tuple_attribute()  
along with PG_DETOAST_DATUM() when the array element type is composite,  
but this was messy and imposed extra cache lookup costs whether or not any  
TOAST pointers were present, indeed sometimes when the array element type  
isn't even composite (since sometimes it takes a typcache lookup to find  
that out).  The idea of extending that approach to all the places that  
currently use PG_DETOAST_DATUM() wasn't attractive at all.  
  
This patch instead solves the problem by decreeing that composite Datum  
values must not contain any out-of-line TOAST pointers in the first place;  
that is, we expand out-of-line fields at the point of constructing a  
composite Datum, not at the point where we're about to insert it into a  
larger tuple.  This rule is applied only to true composite Datums, not  
to tuples that are being passed around the system as tuples, so it's not  
as invasive as it might sound at first.  With this approach, the amount  
of code that has to be touched for a full solution is greatly reduced,  
and added cache lookup costs are avoided except when there actually is  
a TOAST pointer that needs to be inlined.  
  
The main drawback of this approach is that we might sometimes dereference  
a TOAST pointer that will never actually be used by the query, imposing a  
rather large cost that wasn't there before.  On the other side of the coin,  
if the field value is used multiple times then we'll come out ahead by  
avoiding repeat detoastings.  Experimentation suggests that common SQL  
coding patterns are unaffected either way, though.  Applications that are  
very negatively affected could be advised to modify their code to not fetch  
columns they won't be using.  
  
In future, we might consider reverting this solution in favor of detoasting  
only at the point where data is about to be stored to disk, using some  
method that can drill down into multiple levels of nested structured types.  
That will require defining new APIs for structured types, though, so it  
doesn't seem feasible as a back-patchable fix.  
  
Note that this patch changes HeapTupleGetDatum() from a macro to a function  
call; this means that any third-party code using that macro will not get  
protection against creating TOAST-pointer-containing Datums until it's  
recompiled.  The same applies to any uses of PG_RETURN_HEAPTUPLEHEADER().  
It seems likely that this is not a big problem in practice: most of the  
tuple-returning functions in core and contrib produce outputs that could  
not possibly be toasted anyway, and the same probably holds for third-party  
extensions.  
  
This bug has existed since TOAST was invented, so back-patch to all  
supported branches.  

commit   : 0140bee43d55324a066a43bce63fc6ed70c305de    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 30 Apr 2014 13:46:16 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 30 Apr 2014 13:46:16 -0400    

Since ruleutils.c recurses, it could be driven to stack overflow by  
deeply nested constructs.  Very large queries might also take long  
enough to deparse that a check for interrupts seems like a good idea.  
Stick appropriate tests into a couple of key places.  
  
Noted by Greg Stark.  Back-patch to all supported branches.  

commit   : 0652d77fb067137be22dc3e42aa60bffa26726ac    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 30 Apr 2014 13:26:29 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 30 Apr 2014 13:26:29 -0400    

A query such as "SELECT x UNION SELECT y UNION SELECT z UNION ..."  
produces a left-deep nested parse tree, which we formerly showed in its  
full nested glory and with all the possible parentheses.  This does little  
for readability, though, and long UNION lists resulting in excessive  
indentation are common.  Instead, let's omit parentheses and indent all  
the subqueries at the same level in such cases.  
  
This patch skips indentation/parenthesization whenever the lefthand input  
of a SetOperationStmt is another SetOperationStmt of the same kind and  
ALL/DISTINCT property.  We could teach the code the exact syntactic  
precedence of set operations and thereby avoid parenthesization in some  
more cases, but it's not clear that that'd be a readability win: it seems  
better to parenthesize if the set operation changes.  (As an example,  
if there's one UNION in a long list of UNION ALL, it now stands out like  
a sore thumb, which seems like a good thing.)  
  
Back-patch to 9.3.  This completes our response to a complaint from Greg  
Stark that since commit 62e666400d there's a performance problem in pg_dump  
for views containing long UNION sequences (or other types of deeply nested  
constructs).  The previous commit 0601cb54dac14d979d726ab2ebeda251ae36e857  
handles the general problem, but this one makes the specific case of UNION  
lists look a lot nicer.  

commit   : de6c439dc880ffa3536be7415a77ee65f56750e7    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 30 Apr 2014 12:48:15 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 30 Apr 2014 12:48:15 -0400    

Continuing to indent no matter how deeply nested we get doesn't really  
do anything for readability; what's worse, it results in O(N^2) total  
whitespace, which can become a performance and memory-consumption issue.  
  
To address this, once we get past 40 characters of indentation, reduce  
the indentation step distance 4x, and also limit the maximum indentation  
by reducing it modulo 40.  This latter choice is a bit weird at first  
glance, but it seems to preserve readability better than a simple cap  
would do.  
  
Back-patch to 9.3, because since commit 62e666400d the performance issue  
is a hazard for pg_dump.  
  
Greg Stark and Tom Lane  

commit   : 164acbe33c0951221b1ae2e5285c793f404a75a1    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 30 Apr 2014 12:01:21 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 30 Apr 2014 12:01:21 -0400    

The code attempted to outdent JOIN clauses further left than the parent  
FROM keyword, which was odd in any case, and led to inconsistent formatting  
since in simple cases the clauses couldn't be moved any further left than  
that.  And it left a permanent decrement of the indentation level, causing  
subsequent lines to be much further left than they should be (again, this  
couldn't be seen in simple cases for lack of indentation to give up).  
  
After a little experimentation I chose to make it indent JOIN keywords  
two spaces from the parent FROM, which is one space more than the join's  
lefthand input in cases where that appears on a different line from FROM.  
  
Back-patch to 9.3.  This is a purely cosmetic change, and the bug is quite  
old, so that may seem arbitrary; but we are going to be making some other  
changes to the indentation behavior in both HEAD and 9.3, so it seems  
reasonable to include this in 9.3 too.  I committed this one first because  
its effects are more visible in the regression test results as they  
currently stand than they will be later.  

commit   : 8a90a39b4e033881dda0dcacfc69a0b66e244624    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Wed, 30 Apr 2014 10:34:15 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Wed, 30 Apr 2014 10:34:15 +0300    

Some popen() calls were missing SYSTEMQUOTEs, which caused initdb and  
pg_upgrade to fail on Windows, if the installation path contained both  
spaces and @ signs.  
  
Patch by Nikhil Deshpande. Backpatch to all supported versions.  

commit   : 150a44e83d7559000aa9578d60c8906cae097f78    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 29 Apr 2014 13:12:29 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 29 Apr 2014 13:12:29 -0400    

In general we can't discard constant-NULL inputs, since they could change  
the result of the AND/OR to be NULL.  But at top level of WHERE, we do not  
need to distinguish a NULL result from a FALSE result, so it's okay to  
treat NULL as FALSE and then simplify AND/OR accordingly.  
  
This is a very ancient oversight, but in 9.2 and later it can lead to  
failure to optimize queries that previous releases did optimize, as a  
result of more aggressive parameter substitution rules making it possible  
to reduce more subexpressions to NULL constants.  This is the root cause of  
bug #10171 from Arnold Scheffler.  We could alternatively have fixed that  
by teaching orclauses.c to ignore constant-NULL OR arms, but it seems  
better to get rid of them globally.  
  
I resisted the temptation to back-patch this change into all active  
branches, but it seems appropriate to back-patch as far as 9.2 so that  
there will not be performance regressions of the kind shown in this bug.  

commit   : f6590f6a8e51ec9c81fd27cc0c900282bd57487b    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Mon, 28 Apr 2014 16:12:45 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Mon, 28 Apr 2014 16:12:45 +0300    

In writeListPage, never take a full-page image of the page, because we  
have all the information required to re-initialize in the WAL record  
anyway. Before this fix, a full-page image was always generated, unless  
full_page_writes=off, because when the page is initialized its LSN is  
always 0. In stable-branches, keep the code to restore the backup blocks  
if they exist, in case that the WAL is generated with an older minor  
version, but in master Assert that there are no full-page images.  
  
In the redo routine, add missing "off++". Otherwise the tuples are added  
to the page in reverse order. That happens to be harmless because we  
always scan and remove all the tuples together, but it was clearly wrong.  
Also, it was masked by the first bug unless full_page_writes=off, because  
the page was always restored from a full-page image.  
  
Backpatch to all supported versions.  

commit   : 36825f38dd44d8630b07be843dfc1619fe9f8d5c    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 27 Apr 2014 21:24:19 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 27 Apr 2014 21:24:19 -0400    

pg_controldata includes postgres.h not postgres_fe.h, so utils/palloc.h  
must be able to compile in a "#define FRONTEND" context.  It appears that  
Solaris Studio is smart enough to persuade us to define PG_USE_INLINE,  
but not smart enough to not make a copy of unreferenced static functions;  
which leads to an unsatisfied reference to CurrentMemoryContext.  So we  
need an #ifndef FRONTEND around that declaration.  Per buildfarm.  

commit   : e4c1a496f2320f65c27c7a08288c434d8b12876a    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 26 Apr 2014 14:14:30 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 26 Apr 2014 14:14:30 -0400    

This breaks the principle that common/ ought not depend on anything in the  
server, not only code-wise but in the headers.  The only arguable advantage  
is avoidance of duplication of half a dozen extern declarations, and even  
that is rather dubious, considering that the previous coding was wrong  
about which declarations to duplicate: it exposed pnstrdup() to frontend  
code even though no such function is provided in fe_memutils.c.  
  
On the same principle, don't #include utils/memutils.h in the frontend  
build of psprintf.c.  This requires duplicating the definition of  
MaxAllocSize, but that seems fine to me: there's no a-priori reason why  
frontend code should use the same size limit as the backend anyway.  
  
In passing, clean up some rather odd layout and ordering choices that  
were imposed on palloc.h to reduce the number of #ifdefs required by  
the previous approach.  
  
Per gripe from Christoph Berg.  There's still more work to do to make  
include/common/ clean, but this part seems reasonably noncontroversial.  

commit   : c0bd128c81c2b23a1cbc53305180fca51b3b61c3    
  
author   : Alvaro Herrera <[email protected]>    
date     : Thu, 24 Apr 2014 15:41:55 -0300    
  
committer: Alvaro Herrera <[email protected]>    
date     : Thu, 24 Apr 2014 15:41:55 -0300    

If a tuple is locked, and this lock is later upgraded either to an  
update or to a stronger lock, and in the meantime some other process  
tries to lock, update or delete the same tuple, it (the tuple) could end  
up being updated twice, or having conflicting locks held.  
  
The reason for this is that the second updater checks for a change in  
Xmax value, or in the HEAP_XMAX_IS_MULTI infomask bit, after noticing  
the first lock; and if there's a change, it restarts and re-evaluates  
its ability to update the tuple.  But it neglected to check for changes  
in lock strength or in lock-vs-update status when those two properties  
stayed the same.  This would lead it to take the wrong decision and  
continue with its own update, when in reality it shouldn't do so but  
instead restart from the top.  
  
This could lead to either an assertion failure much later (when a  
multixact containing multiple updates is detected), or duplicate copies  
of tuples.  
  
To fix, make sure to compare the other relevant infomask bits alongside  
the Xmax value and HEAP_XMAX_IS_MULTI bit, and restart from the top if  
necessary.  
  
Also, in the belt-and-suspenders spirit, add a check to  
MultiXactCreateFromMembers that a multixact being created does not have  
two or more members that are claimed to be updates.  This should protect  
against other bugs that might cause similar bogus situations.  
  
Backpatch to 9.3, where the possibility of multixacts containing updates  
was introduced.  (In prior versions it was possible to have the tuple  
lock upgraded from shared to exclusive, and an update would not restart  
from the top; yet we're protected against a bug there because there's  
always a sleep to wait for the locking transaction to complete before  
continuing to do anything.  Really, the fact that tuple locks always  
conflicted with concurrent updates is what protected against bugs here.)  
  
Per report from Andrew Dunstan and Josh Berkus in thread at  
http://www.postgresql.org/message-id/[email protected]  
  
Bug analysis by Andres Freund.  

commit   : 12e41a5d70d5a96ed5859e7f0cd6047329b3d8d7    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 24 Apr 2014 13:29:48 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 24 Apr 2014 13:29:48 -0400    

Once we've completed a PREPARE, our session is not running a transaction,  
so its entry in pg_stat_activity should show xact_start as null, rather  
than leaving the value as the start time of the now-prepared transaction.  
  
I think possibly this oversight was triggered by faulty extrapolation  
from the adjacent comment that says PrepareTransaction should not call  
AtEOXact_PgStat, so tweak the wording of that comment.  
  
Noted by Andres Freund while considering bug #10123 from Maxim Boguk,  
although this error doesn't seem to explain that report.  
  
Back-patch to all active branches.  

commit   : cb651b624dabb6d0617ea861aa80c6ec7b76eb34    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 23 Apr 2014 21:21:08 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 23 Apr 2014 21:21:08 -0400    

pg_sequence_parameters() and pg_identify_object() have had incorrect  
proallargtypes entries since 9.1 and 9.3 respectively.  This was mostly  
masked by the correct information in proargtypes, but a few operations  
such as pg_get_function_arguments() (and thus psql's \df display) would  
show the wrong data types for these functions' input parameters.  
  
In HEAD, fix the wrong info, bump catversion, and add an opr_sanity  
regression test to catch future mistakes of this sort.  
  
In the back branches, just fix the wrong info so that installations  
initdb'd with future minor releases will have the right data.  We  
can't force an initdb, and it doesn't seem like a good idea to add  
a regression test that will fail on existing installations.  
  
Andres Freund  

commit   : f468c64cb68fddcdf169c0b4fd8c88aa425d3116    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Wed, 23 Apr 2014 14:39:12 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Wed, 23 Apr 2014 14:39:12 +0300    

We no longer have a TLI field in the page header.  

commit   : b60162402606608dfc2fb5e2aca85caf7adc1e42    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Wed, 23 Apr 2014 12:56:41 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Wed, 23 Apr 2014 12:56:41 +0300    

commit   : 053959397bd1f5e10d16d68bb91b7beffcb673e7    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 21 Apr 2014 13:28:10 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 21 Apr 2014 13:28:10 -0400    

pgss_post_parse_analyze() neglected to pass the call on to any earlier  
occupant of the post_parse_analyze_hook.  There are no other users of that  
hook in contrib/, and most likely none in the wild either, so this is  
probably just a latent bug.  But it's a bug nonetheless, so back-patch  
to 9.2 where this code was introduced.  

commit   : 98876f0ff18e617d6366989d40ab74c07580fb0a    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 17 Apr 2014 16:12:24 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 17 Apr 2014 16:12:24 -0400    

Introduced in 585bca39: msgid is not used in the Windows code path.  
  
Also adjust comments a tad (mostly to keep pgindent from messing it up).  
  
David Rowley  

commit   : fc72e94a13026b86a06c7f5c670f4c16420d3d77    
  
author   : Bruce Momjian <[email protected]>    
date     : Thu, 17 Apr 2014 12:37:53 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Thu, 17 Apr 2014 12:37:53 -0400    

Specifically, on-stack memset() might be removed, so:  
  
	* Replace memset() with px_memset()  
	* Add px_memset to copy_crlf()  
	* Add px_memset to pgp-s2k.c  
  
Patch by Marko Kreen  
  
Report by PVS-Studio  
  
Backpatch through 8.4.  

commit   : 071d9f085089f3fbae1b472debd38c555cd4a436    
  
author   : Bruce Momjian <[email protected]>    
date     : Thu, 17 Apr 2014 11:42:21 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Thu, 17 Apr 2014 11:42:21 -0400    

Non-existent tablespace directory references can occur if user  
tablespaces are created inside data directories and the data directory  
is renamed in preparation for running pg_upgrade, and the symbolic links  
are not updated.  
  
Backpatch to 9.3.  

commit   : 95aa823eb611a1280c1ab80c651c1ae62719b3e2    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Thu, 17 Apr 2014 17:47:50 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Thu, 17 Apr 2014 17:47:50 +0300    

If we set the all-visible flag after writing WAL record, and XLogInsert  
takes a full-page image of the page, the image would not include the flag.  
We will then proceed to set the VM bit, which would then be set without the  
corresponding all-visible flag on the heap page.  
  
Found by comparing page images on master and standby, after writing/replaying  
each WAL record. (There is still a discrepancy: the all-visible flag won't  
be set after replaying the HEAP_CLEAN record, even though it is set in the  
master. However, it will be set when replaying the HEAP2_VISIBLE record and  
setting the VM bit, so the all-visible flag and VM bit are always consistent  
on the standby, even though they are momentarily out-of-sync with master)  
  
Backpatch to 9.3 where this code was introduced.  

commit   : aa0a5198baba5bbf04081393e77d07ac3febc153    
  
author   : Bruce Momjian <[email protected]>    
date     : Wed, 16 Apr 2014 19:53:42 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Wed, 16 Apr 2014 19:53:42 -0400    

In psql, both stdin and stdout must be terminals to get a client  
encoding of 'auto'.  
  
Patch by Albe Laurenz  
  
Backpatch to 9.3.  

commit   : 0bf52bd990f324440c1cb9cc88e69ba7b9688410    
  
author   : Alvaro Herrera <[email protected]>    
date     : Wed, 16 Apr 2014 18:25:44 -0300    
  
committer: Alvaro Herrera <[email protected]>    
date     : Wed, 16 Apr 2014 18:25:44 -0300    

We were neglecting to schema-qualify them.  
  
Backpatch to 9.3, where object identities were introduced as a concept  
by commit f8348ea32ec8.  

commit   : 9612b982b8c9a8fd2c07e3c03e6a1878e4e41d9b    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 16 Apr 2014 17:22:00 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 16 Apr 2014 17:22:00 -0400    

We were emitting "(SELECT null::typename)", which is usually interpreted  
as a scalar subselect, but not so much in the context "x = ANY(...)".  
This led to remote-side parsing failures when remote_estimate is enabled.  
A quick and ugly fix is to stick in an extra cast step,  
"((SELECT null::typename)::typename)".  The cast will be thrown away as  
redundant by parse analysis, but not before it's done its job of making  
sure the grammar sees the ANY argument as an a_expr rather than a  
select_with_parens.  Per an example from Hannu Krosing.  

commit   : c4dcdd0c259bef380146eadbb55a48d4f3257639    
  
author   : Andrew Dunstan <[email protected]>    
date     : Wed, 16 Apr 2014 13:35:46 -0400    
  
committer: Andrew Dunstan <[email protected]>    
date     : Wed, 16 Apr 2014 13:35:46 -0400    

This has probably been broken for quite a long time. Buildfarm member  
currawong's current results suggest that it's been broken since 9.1, so  
backpatch this to that branch.  
  
This only supports Python 2 - I will handle Python 3 separately, but  
this is a fairly simple fix.  

commit   : 31a469ce37045123640c5487e2adc07722330224    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 16 Apr 2014 13:20:58 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 16 Apr 2014 13:20:58 -0400    

According to the Single Unix Spec and assorted man pages, you're supposed  
to use the constants named AF_xxx when setting ai_family for a getaddrinfo  
call.  In a few places we were using PF_xxx instead.  Use of PF_xxx  
appears to be an ancient BSD convention that was not adopted by later  
standardization.  On BSD and most later Unixen, it doesn't matter much  
because those constants have equivalent values anyway; but nonetheless  
this code is not per spec.  
  
In the same vein, replace PF_INET by AF_INET in one socket() call, which  
wasn't even consistent with the other socket() call in the same function  
let alone the remainder of our code.  
  
Per investigation of a Cygwin trouble report from Marco Atzeri.  It's  
probably a long shot that this will fix his issue, but it's wrong in  
any case.  

commit   : cc269272c488d5e9ff0ffc20fa50983dc9f07efe    
  
author   : Magnus Hagander <[email protected]>    
date     : Wed, 16 Apr 2014 17:18:02 +0200    
  
committer: Magnus Hagander <[email protected]>    
date     : Wed, 16 Apr 2014 17:18:02 +0200    

Bind attempts to an LDAP server should time out after two seconds,  
allowing additional lines in the service control file to be parsed  
(which provide a fall back to a secondary LDAP server or default options).  
The existing code failed to enforce that timeout during TCP connect,  
resulting in a hang far longer than two seconds if the LDAP server  
does not respond.  
  
Laurenz Albe  

commit   : f716c3250adeed22f1ea1b1cb93e4782a202856a    
  
author   : Bruce Momjian <[email protected]>    
date     : Wed, 16 Apr 2014 10:45:48 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Wed, 16 Apr 2014 10:45:48 -0400    

Previously, in some places, socket creation errors were checked for  
negative values, which is not true for Windows because sockets are  
unsigned.  This masked socket creation errors on Windows.  
  
Backpatch through 9.0.  8.4 doesn't have the infrastructure to fix this.  

commit   : c03a6ae220630c6d03dddf20789df62131ea6e9e    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Wed, 16 Apr 2014 10:21:09 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Wed, 16 Apr 2014 10:21:09 +0300    

I mixed up BLCKSZ and XLOG_BLCKSZ when I changed the way the buffer is  
allocated a couple of weeks ago. With the default settings, they are both  
8k, but they can be changed at compile-time.  

commit   : 3b8fda6763ceccac0fc5ae0e921568235608252c    
  
author   : Michael Meskes <[email protected]>    
date     : Wed, 9 Apr 2014 11:21:46 +0200    
  
committer: Michael Meskes <[email protected]>    
date     : Wed, 9 Apr 2014 11:21:46 +0200    

Patches by Ashutosh Bapat <[email protected]>  

commit   : 601c01e08ded65225c0a94878a9e5b6d90cd1206    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Tue, 8 Apr 2014 14:47:24 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Tue, 8 Apr 2014 14:47:24 +0300    

Don't reset the rightlink of a page when replaying a page update record.  
This was a leftover from pre-hot standby days, when it was not possible to  
have scans concurrent with WAL replay. Resetting the right-link was not  
necessary back then either, but it was done for the sake of tidiness. But  
with hot standby, it's wrong, because a concurrent scan might still need it.  
  
Backpatch all versions with hot standby, 9.0 and above.  

commit   : e118822e72486aec32bbbecd3cf7543dbb756c58    
  
author   : Robert Haas <[email protected]>    
date     : Mon, 7 Apr 2014 10:59:42 -0400    
  
committer: Robert Haas <[email protected]>    
date     : Mon, 7 Apr 2014 10:59:42 -0400    

The one existing assertion of this type has tripped a few times in the  
buildfarm lately, but it's not clear whether the problem is really  
originating there or whether it's leftovers from a trip through one  
of the other two paths that lack a matching assertion.  So add one.  
  
Since the same bug(s) most likely exist(s) in the back-branches also,  
back-patch to 9.2, where the fast-path lock mechanism was added.  

commit   : 21aa47d0175c583db5fc1361d9482efd37a393fd    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 5 Apr 2014 18:16:11 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 5 Apr 2014 18:16:11 -0400    

Formerly, we set up the postmaster's signal handling only when we were  
about to start launching subprocesses.  This is a bad idea though, as  
it means that for example a SIGINT arriving before that will kill the  
postmaster instantly, perhaps leaving lockfiles, socket files, shared  
memory, etc laying about.  We'd rather that such a signal caused orderly  
postmaster termination including releasing of those resources.  A simple  
fix is to move the PostmasterMain stanza that initializes signal handling  
to an earlier point, before we've created any such resources.  Then, an  
early-arriving signal will be blocked until we're ready to deal with it  
in the usual way.  (The only part that really needs to be moved up is  
blocking of signals, but it seems best to keep the signal handler  
installation calls together with that; for one thing this ensures the  
kernel won't drop any signals we wished to get.  The handlers won't get  
invoked in any case until we unblock signals in ServerLoop.)  
  
Per a report from MauMau.  He proposed changing the way "pg_ctl stop"  
works to deal with this, but that'd just be masking one symptom not  
fixing the core issue.  
  
It's been like this since forever, so back-patch to all supported branches.  

commit   : 18db2150cee092a0b85baf41c27b800bafa1b480    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 5 Apr 2014 12:41:28 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 5 Apr 2014 12:41:28 -0400    

EXEC_BACKEND builds (i.e., Windows) failed to absorb values of PGC_BACKEND  
parameters if they'd been changed post-startup via the config file.  This  
for example prevented log_connections from working if it were turned on  
post-startup.  The mechanism for handling this case has always been a bit  
of a kluge, and it wasn't revisited when we implemented EXEC_BACKEND.  
While in a normal forking environment new backends will inherit the  
postmaster's value of such settings, EXEC_BACKEND backends have to read  
the settings from the CONFIG_EXEC_PARAMS file, and they were mistakenly  
rejecting them.  So this case has always been broken in the Windows port;  
so back-patch to all supported branches.  
  
Amit Kapila  

commit   : 84520f91ccec4d204ffae92af039544eb3541c39    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 4 Apr 2014 23:09:38 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 4 Apr 2014 23:09:38 -0400    

The code segment that removes the old symlink (if present) wasn't clued  
into the fact that on Windows, symlinks are junction points which have  
to be removed with rmdir().  
  
Backpatch to 9.0, where the failing code was introduced.  
  
MauMau, reviewed by Muhammad Asif Naeem and Amit Kapila  

commit   : 7d1a0f585c233e0e316d99667f97f7af80069837    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 4 Apr 2014 22:03:38 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 4 Apr 2014 22:03:38 -0400    

There's no really compelling reason to refuse to do these read-only,  
non-server-starting options as root, and there's at least one good  
reason to allow -C: pg_ctl uses -C to find out the true data directory  
location when pointed at a config-only directory.  On Windows, this is  
done before dropping administrator privileges, which means that pg_ctl  
fails for administrators if and only if a config-only layout is used.  
  
Since the root-privilege check is done so early in startup, it's a bit  
awkward to check for these switches.  Make the somewhat arbitrary  
decision that we'll only skip the root check if -C is the first switch.  
This is not just to make the code a bit simpler: it also guarantees that  
we can't misinterpret a --boot mode switch.  (While AuxiliaryProcessMain  
doesn't currently recognize any such switch, it might have one in the  
future.)  This is no particular problem for pg_ctl, and since the whole  
behavior is undocumented anyhow, it's not a documentation issue either.  
(--describe-config only works as the first switch anyway, so this is  
no restriction for that case either.)  
  
Back-patch to 9.2 where pg_ctl first began to use -C.  
  
MauMau, heavily edited by me  

commit   : 598f3033f3b887b67acd7310175278732b4c27f9    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 4 Apr 2014 11:43:38 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 4 Apr 2014 11:43:38 -0400    

The displayed sendtime and receipttime were always exactly equal, because  
somebody forgot that timestamptz_to_str returns a static buffer (thereby  
simplifying life for most callers, at the cost of complicating it for those  
who need two results concurrently).  Apply the same pstrdup solution used  
by the other call sites with this issue.  Back-patch to 9.2 where the  
faulty code was introduced.  Per bug #9849 from Haruka Takatsuka, though  
this is not exactly his patch.  
  
Possibly we should change timestamptz_to_str's API, but I wouldn't want  
to do so in the back branches.  

commit   : a2f9572ca507bfcb71bcf1b81b563e5094fd6904    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Fri, 4 Apr 2014 18:20:22 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Fri, 4 Apr 2014 18:20:22 +0300    

It can fail if you run out of memory.  
  
This call was added in 9.3, so backpatch to 9.3 only.  

commit   : 1891a4b6b8ad2bcdd290380a89cbb4dc160adbb8    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Fri, 4 Apr 2014 13:12:38 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Fri, 4 Apr 2014 13:12:38 +0300    

If a palloc in a critical section fails, it becomes a PANIC.  

commit   : d359f71ac069c88c4760739308e23cfc3e0a8d60    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 3 Apr 2014 22:02:27 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 3 Apr 2014 22:02:27 -0400    

For variadic functions (other than VARIADIC ANY), the syntaxes foo(x,y,...)  
and foo(VARIADIC ARRAY[x,y,...]) should be considered equivalent, since the  
former is converted to the latter at parse time.  They have indeed been  
equivalent, in all releases before 9.3.  However, commit 75b39e790 made an  
ill-considered decision to record which syntax had been used in FuncExpr  
nodes, and then to make equal() test that in checking node equality ---  
which caused the syntaxes to not be seen as equivalent by the planner.  
This is the underlying cause of bug #9817 from Dmitry Ryabov.  
  
It might seem that a quick fix would be to make equal() disregard  
FuncExpr.funcvariadic, but the same commit made that untenable, because  
the field actually *is* semantically significant for some VARIADIC ANY  
functions.  This patch instead adopts the approach of redefining  
funcvariadic (and aggvariadic, in HEAD) as meaning that the last argument  
is a variadic array, whether it got that way by parser intervention or was  
supplied explicitly by the user.  Therefore the value will always be true  
for non-ANY variadic functions, restoring the principle of equivalence.  
(However, the planner will continue to consider use of VARIADIC as a  
meaningful difference for VARIADIC ANY functions, even though some such  
functions might disregard it.)  
  
In HEAD, this change lets us simplify the decompilation logic in  
ruleutils.c, since the funcvariadic/aggvariadic flag tells directly whether  
to print VARIADIC.  However, in 9.3 we have to continue to cope with  
existing stored rules/views that might contain the previous definition.  
Fortunately, this just means no change in ruleutils.c, since its existing  
behavior effectively ignores funcvariadic for all cases other than VARIADIC  
ANY functions.  
  
In HEAD, bump catversion to reflect the fact that FuncExpr.funcvariadic  
changed meanings; this is sort of pro forma, since I don't believe any  
built-in views are affected.  
  
Unfortunately, this patch doesn't magically fix everything for affected  
9.3 users.  After installing 9.3.5, they might need to recreate their  
rules/views/indexes containing variadic function calls in order to get  
everything consistent with the new definition.  As in the cited bug,  
the symptom of a problem would be failure to use a nominally matching  
index that has a variadic function call in its definition.  We'll need  
to mention this in the 9.3.5 release notes.  

commit   : 2186533911ccf71a1ac0ac5b90420a0b76456631    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 3 Apr 2014 14:18:28 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 3 Apr 2014 14:18:28 -0400    

The advice to join to pg_prepared_xacts via the transaction column was not  
updated when the transaction column was replaced by virtualtransaction.  
Since it's not quite obvious how to do that join, give an explicit example.  
For consistency also give an example for the adjacent case of joining to  
pg_stat_activity.  And link-ify the view references too, just because we  
can.  Per bug #9840 from Alexey Bashtanov.  
  
Michael Paquier and Tom Lane  

commit   : 64e381a163f04b89bc75721cd3a86d93be5fee68    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 3 Apr 2014 11:05:55 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 3 Apr 2014 11:05:55 -0400    

It's been 16 bytes, not 12, for ages.  This was fixed in passing in HEAD  
(commit 146604ec), but as a factual error it should have been back-patched.  
Per gripe from Tatsuhito Kasahara.  

commit   : 767fc1c520a19f353006a5926cfea63bc4a4a57b    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Thu, 3 Apr 2014 15:09:37 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Thu, 3 Apr 2014 15:09:37 +0300    

Memory allocation can fail if you run out of memory, and inside a critical  
section that will lead to a PANIC. Use conservatively-sized arrays in stack  
instead.  
  
There was previously no explicit limit on the number of pages a GiST split  
can produce, it was only limited by the number of LWLocks that can be held  
simultaneously (100 at the moment). This patch adds an explicit limit of 75  
pages. That should be plenty, a typical split shouldn't produce more than  
2-3 page halves.  
  
The bug has been there forever, but only backpatch down to 9.1. The code  
was changed significantly in 9.1, and it doesn't seem worth the risk or  
trouble to adapt this for 9.0 and 8.4.  

commit   : 65183fb78f1a31b6f333fde3293e047898bd6931    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 2 Apr 2014 17:11:27 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 2 Apr 2014 17:11:27 -0400    

The code for matching clients to pg_hba.conf lines that specify host names  
(instead of IP address ranges) failed to complain if reverse DNS lookup  
failed; instead it silently didn't match, so that you might end up getting  
a surprising "no pg_hba.conf entry for ..." error, as seen in bug #9518  
from Mike Blackwell.  Since we don't want to make this a fatal error in  
situations where pg_hba.conf contains a mixture of host names and IP  
addresses (clients matching one of the numeric entries should not have to  
have rDNS data), remember the lookup failure and mention it as DETAIL if  
we get to "no pg_hba.conf entry".  Apply the same approach to forward-DNS  
lookup failures, too, rather than treating them as immediate hard errors.  
  
Along the way, fix a couple of bugs that prevented us from detecting an  
rDNS lookup error reliably, and make sure that we make only one rDNS lookup  
attempt; formerly, if the lookup attempt failed, the code would try again  
for each host name entry in pg_hba.conf.  Since more or less the whole  
point of this design is to ensure there's only one lookup attempt not one  
per entry, the latter point represents a performance bug that seems  
sufficient justification for back-patching.  
  
Also, adjust src/port/getaddrinfo.c so that it plays as well as it can  
with this code.  Which is not all that well, since it does not have actual  
support for rDNS lookup, but at least it should return the expected (and  
required by spec) error codes so that the main code correctly perceives the  
lack of functionality as a lookup failure.  It's unlikely that PG is still  
being used in production on any machines that require our getaddrinfo.c,  
so I'm not excited about working harder than this.  
  
To keep the code in the various branches similar, this includes  
back-patching commits c424d0d1052cb4053c8712ac44123f9b9a9aa3f2 and  
1997f34db4687e671690ed054c8f30bb501b1168 into 9.2 and earlier.  
  
Back-patch to 9.1 where the facility for hostnames in pg_hba.conf was  
introduced.  

commit   : 6cb229d5ad77112156946c42cc91b8cba204072e    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 1 Apr 2014 21:30:11 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 1 Apr 2014 21:30:11 -0400    

Initialization of this field was not being done according to the  
st_changecount protocol (it has to be done within the changecount increment  
range, not outside).  And the test to see if the value should be reported  
as null was wrong.  Noted while perusing uses of Port.remote_hostname.  
  
This was wrong from the introduction of this code (commit 4a25bc145),  
so back-patch to 9.1.  

commit   : d747c6da6aedbbf141870136d1782f23c837029c    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Tue, 1 Apr 2014 09:27:37 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Tue, 1 Apr 2014 09:27:37 +0300    

Amit Langote  

commit   : e452019d8e29eb52dd755ba307b96a42f89da550    
  
author   : Robert Haas <[email protected]>    
date     : Mon, 31 Mar 2014 14:32:12 -0400    
  
committer: Robert Haas <[email protected]>    
date     : Mon, 31 Mar 2014 14:32:12 -0400    

Otherwise, the compiler might decide to move modifications to data  
within this structure outside the enclosing SpinLockAcquire /  
SpinLockRelease pair, leading to shared memory corruption.  
  
This may or may not explain a recent lmgr-related buildfarm failure  
on prairiedog, but it needs to be fixed either way.  

commit   : ac2063ade566deb03e72e3da52cf472e125708b7    
  
author   : Robert Haas <[email protected]>    
date     : Mon, 31 Mar 2014 13:06:26 -0400    
  
committer: Robert Haas <[email protected]>    
date     : Mon, 31 Mar 2014 13:06:26 -0400    

Previously, such buffers weren't counted, with the possible result that  
EXPLAIN (BUFFERS) and pg_stat_statements would understate the true  
number of blocks dirtied by an SQL statement.  
  
Back-patch to 9.2, where this counter was introduced.  
  
Amit Kapila  

commit   : 3080bbaa919143e19dbe65fd0d81a1b4457c845d    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 29 Mar 2014 17:34:03 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 29 Mar 2014 17:34:03 -0400    

It is possible for a view or materialized view to depend on a table's  
primary key, if the view query relies on functional dependency to  
abbreviate a GROUP BY list.  This is problematic for pg_dump since we  
ordinarily want to dump view definitions in the pre-data section but  
indexes in post-data.  pg_dump knows how to deal with this situation for  
regular views, by breaking the view's ON SELECT rule apart from the view  
proper.  But it had not been taught what to do about materialized views,  
and in fact mistakenly dumped them as regular views in such cases, as  
seen in bug #9616 from Jesse Denardo.  
  
If we had CREATE OR REPLACE MATERIALIZED VIEW, we could fix this in a  
manner analogous to what's done for regular views; but we don't yet,  
and we'd not back-patch such a thing into 9.3 anyway.  As a hopefully-  
temporary workaround, break the circularity by postponing the matview  
into post-data altogether when this case occurs.  

commit   : 244590ebfb0c2856a5b349fb50836d28722c893d    
  
author   : Noah Misch <[email protected]>    
date     : Sat, 29 Mar 2014 03:12:00 -0400    
  
committer: Noah Misch <[email protected]>    
date     : Sat, 29 Mar 2014 03:12:00 -0400    

About half of the buildfarm members use too-long directory names,  
strongly suggesting that this approach is a dead end.  

commit   : 95a3ca3be9f66d7222e4f8188318125992b381d9    
  
author   : Noah Misch <[email protected]>    
date     : Sat, 29 Mar 2014 00:52:56 -0400    
  
committer: Noah Misch <[email protected]>    
date     : Sat, 29 Mar 2014 00:52:56 -0400    

Any OS user able to access the socket can connect as the bootstrap  
superuser and in turn execute arbitrary code as the OS user running the  
test.  Protect against that by placing the socket in the temporary data  
directory, which has mode 0700 thanks to initdb.  Back-patch to 8.4 (all  
supported versions).  The hazard remains wherever the temporary cluster  
accepts TCP connections, notably on Windows.  
  
Attempts to run "make check" from a directory with a long name will now  
fail.  An alternative not sharing that problem was to place the socket  
in a subdirectory of /tmp, but that is only secure if /tmp is sticky.  
The PG_REGRESS_SOCK_DIR environment variable is available as a  
workaround when testing from long directory paths.  
  
As a convenient side effect, this lets testing proceed smoothly in  
builds that override DEFAULT_PGSOCKET_DIR.  Popular non-default values  
like /var/run/postgresql are often unwritable to the build user.  
  
Security: CVE-2014-0067  

commit   : afd0d3ff576ee91072a92430fe1d34ddf4bb3f3d    
  
author   : Noah Misch <[email protected]>    
date     : Sat, 29 Mar 2014 00:52:31 -0400    
  
committer: Noah Misch <[email protected]>    
date     : Sat, 29 Mar 2014 00:52:31 -0400    

Back-patch to 8.4 (all supported versions).  

commit   : 611fc913f400113506815c9b58797b25be126725    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 27 Mar 2014 17:05:59 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 27 Mar 2014 17:05:59 -0400    

This reverts commit 2a33b796ee27732c1854f41594329afbb9ffba3d.  
The change requiring cdecimal is new in 9.4 (see 7919398bac),  
so we should not claim previous branches need it.  

commit   : 2a33b796ee27732c1854f41594329afbb9ffba3d    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 26 Mar 2014 22:43:24 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 26 Mar 2014 22:43:24 -0400    

This has been true for some time, but we were leaving users to discover it  
the hard way.  
  
Back-patch to 9.2.  It might've been true before that, but we were claiming  
Python 2.2 compatibility before that, so I won't guess at the exact  
requirements back then.  

commit   : 742cc408f1ad8ef8d104663938f9910064607253    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 26 Mar 2014 16:41:35 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 26 Mar 2014 16:41:35 -0400    

We must increment the refcount on "plntup" as soon as we have the  
reference, not sometime later.  Otherwise, if an error is thrown in  
between, the Py_XDECREF(plntup) call in the PG_CATCH block removes a  
refcount we didn't add, allowing the object to be freed even though  
it's still part of the plpython function's parsetree.  
  
This appears to be the cause of crashes seen on buildfarm member  
prairiedog.  It's a bit surprising that we've not seen it fail repeatably  
before, considering that the regression tests have been exercising the  
faulty code path since 2009.  
  
The real-world impact is probably minimal, since it's unlikely anyone would  
be provoking the "TD["new"] is not a dictionary" error in production, and  
that's the only case that is actually wrong.  Still, it's a bug affecting  
the regression tests, so patch all supported branches.  
  
In passing, remove dead variable "plstr", and demote "platt" to a local  
variable inside the PG_TRY block, since we don't need to clean it up  
in the PG_CATCH path.  

commit   : b12f99478757b3db180396fc2ab5a9f1520d196b    
  
author   : Fujii Masao <[email protected]>    
date     : Wed, 26 Mar 2014 02:12:39 +0900    
  
committer: Fujii Masao <[email protected]>    
date     : Wed, 26 Mar 2014 02:12:39 +0900    

Backpatch to 9.0 where XLOG_PARAMETER_CHANGE record was instroduced.  

commit   : a2e3df7b6f102d3ae1790ba53afdd525ac3100f6    
  
author   : Magnus Hagander <[email protected]>    
date     : Tue, 25 Mar 2014 11:16:57 +0100    
  
committer: Magnus Hagander <[email protected]>    
date     : Tue, 25 Mar 2014 11:16:57 +0100    

Joshua Tolley  

commit   : 08ca107425cb21b8f6b029c4919479dc04241a7d    
  
author   : Fujii Masao <[email protected]>    
date     : Mon, 24 Mar 2014 19:47:35 +0900    
  
committer: Fujii Masao <[email protected]>    
date     : Mon, 24 Mar 2014 19:47:35 +0900    

Enclose "TIMELINE tli" part with brackets because it's optional.  
  
Backport to 9.3 where TIMELINE option was introduced.  
  
Noted by Marko Tiikkaja  

commit   : e4a7c03febe94b0469641b469b29aef2a21ad12c    
  
author   : Noah Misch <[email protected]>    
date     : Sun, 23 Mar 2014 02:13:43 -0400    
  
committer: Noah Misch <[email protected]>    
date     : Sun, 23 Mar 2014 02:13:43 -0400    

equalTupleDescs() neglected both of these ConstrCheck fields, and  
CreateTupleDescCopyConstr() neglected ccnoinherit.  At this time, the  
only known behavior defect resulting from these omissions is constraint  
exclusion disregarding a CHECK constraint validated by an ALTER TABLE  
VALIDATE CONSTRAINT statement issued earlier in the same transaction.  
Back-patch to 9.2, where these fields were introduced.  

commit   : fb918740f307cdde41cca5368e96edea22e9614a    
  
author   : Bruce Momjian <[email protected]>    
date     : Fri, 21 Mar 2014 13:45:11 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Fri, 21 Mar 2014 13:45:11 -0400    

Clear errno before calling readdir() and handle old MinGW errno bug  
while adding full test coverage for readdir/closedir failures.  
  
Backpatch through 8.4.  

commit   : 7f857a511f84410631dea6590d4036c43170afc8    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 19 Mar 2014 11:09:24 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 19 Mar 2014 11:09:24 -0400    

For a regex containing backrefs, pg_regexec() might fail to free all the  
sub-DFAs that were created during execution, resulting in a permanent  
(session lifespan) memory leak.  Problem was introduced by me in commit  
587359479acbbdc95c8e37da40707e37097423f5.  Per report from Sandro Santilli;  
diagnosis by Greg Stark.  

commit   : 63817f86b57fc3d29b57787bca9d786218b7ee25    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 18 Mar 2014 10:38:25 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 18 Mar 2014 10:38:25 -0400    

This used to work properly, but got fat-fingered in commit  
3dee636e0404885d07885d41c0d70e50c784f324.  Per bug #9620 from  
Nicolas Payart.