PostgreSQL 9.0.15 commit log

Stamp 9.0.15.

  
commit   : ad670a5d7344b81633ab6ac9efd150f5caac97c2    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 2 Dec 2013 16:04:20 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 2 Dec 2013 16:04:20 -0500    

Click here for diff

  
  

Update release notes for 9.3.2, 9.2.6, 9.1.11, 9.0.15, 8.4.19.

  
commit   : 81fb8ff617df7a474a6a9dee9c7edf088fcaf06a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 2 Dec 2013 15:54:08 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 2 Dec 2013 15:54:08 -0500    

Click here for diff

  
  

Fix incomplete backpatch of pg_multixact truncation changes to <= 9.2

  
commit   : 3d974e303da29ff97822212ab8722d6e366c5119    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 2 Dec 2013 13:28:10 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 2 Dec 2013 13:28:10 -0300    

Click here for diff

  
The backpatch of a95335b544d9c8377e9dc7a399d8e9a155895f82 to 9.2, 9.1  
and 9.0 was incomplete, missing changes to xlog.c, primarily the call  
to TrimMultiXact(). Testing presumably didn't show a problem without  
these changes because TrimMultiXact() performs defense-in-depth work,  
which is not strictly necessary.  
  
It also missed moving StartupMultiXact() which would have been  
problematic if a restartpoing happened in exactly the wrong moment,  
causing a transient error.  
  
Andres Freund  
  

Translation updates

  
commit   : 8269e4091c45f05d92a7b22a3d5bf96e197bf45b    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 2 Dec 2013 00:05:18 -0500    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 2 Dec 2013 00:05:18 -0500    

Click here for diff

  
  

Update time zone data files to tzdata release 2013h.

  
commit   : 47430452ab6d4e591c50186119d0de8d3d0f45e6    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 1 Dec 2013 14:11:44 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 1 Dec 2013 14:11:44 -0500    

Click here for diff

  
DST law changes in Argentina, Brazil, Jordan, Libya, Liechtenstein,  
Morocco, Palestine.  New timezone abbreviations WIB, WIT, WITA for  
Indonesia.  
  

Back-patch src/timezone/known_abbrevs.txt into all active branches.

  
commit   : 126453d4734c30049e6d8d7fcb57eacd9ac5b142    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 1 Dec 2013 14:09:31 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 1 Dec 2013 14:09:31 -0500    

Click here for diff

  
Needed so that timezone data update patches can be cherry-picked  
into older branches conveniently.  
  

Fix pg_dumpall to work for databases flagged as read-only.

  
commit   : 52898e005f06b1529299b4b14510de3ab259a2f1    
  
author   : Kevin Grittner <kgrittn@postgresql.org>    
date     : Sat, 30 Nov 2013 12:07:05 -0600    
  
committer: Kevin Grittner <kgrittn@postgresql.org>    
date     : Sat, 30 Nov 2013 12:07:05 -0600    

Click here for diff

  
pg_dumpall's charter is to be able to recreate a database cluster's  
contents in a virgin installation, but it was failing to honor that  
contract if the cluster had any ALTER DATABASE SET  
default_transaction_read_only settings.  By including a SET command  
for the connection for each connection opened by pg_dumpall output,  
errors are avoided and the source cluster is successfully  
recreated.  
  
There was discussion of whether to also set this for the connection  
applying pg_dump output, but it was felt that it was both less  
appropriate in that context, and far easier to work around.  
  
Backpatch to all supported branches.  
  

Prevent possible compiler warnings.

  
commit   : a74f50a3f627ac2ef73c77dc1b6ea67d0d44da50    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 30 Nov 2013 11:12:16 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 30 Nov 2013 11:12:16 -0500    

Click here for diff

  
Back-patch commit a3e8486dffc413506b14eae9dc5d423f6ae8324a into the 9.0  
branch.  This is the only warning I'm seeing in the live branches with  
gcc 4.4.7 (other than the known "unused variable 'yyg'" flex lossage),  
which makes it just annoying enough to want to clean up.  
  

Truncate pg_multixact/’s contents during crash recovery

  
commit   : 6d0b8cd2f35257a3f16d70df59aa6a12c89f17ff    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 29 Nov 2013 11:26:41 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 29 Nov 2013 11:26:41 -0300    

Click here for diff

  
Commit 9dc842f08 of 8.2 era prevented MultiXact truncation during crash  
recovery, because there was no guarantee that enough state had been  
setup, and because it wasn't deemed to be a good idea to remove data  
during crash recovery anyway.  Since then, due to Hot-Standby, streaming  
replication and PITR, the amount of time a cluster can spend doing crash  
recovery has increased significantly, to the point that a cluster may  
even never come out of it.  This has made not truncating the content of  
pg_multixact/ not defensible anymore.  
  
To fix, take care to setup enough state for multixact truncation before  
crash recovery starts (easy since checkpoints contain the required  
information), and move the current end-of-recovery actions to a new  
TrimMultiXact() function, analogous to TrimCLOG().  
  
At some later point, this should probably done similarly to the way  
clog.c is doing it, which is to just WAL log truncations, but we can't  
do that for the back branches.  
  
Back-patch to 9.0.  8.4 also has the problem, but since there's no hot  
standby there, it's much less pressing.  In 9.2 and earlier, this patch  
is simpler than in newer branches, because multixact access during  
recovery isn't required.  Add appropriate checks to make sure that's not  
happening.  
  
Andres Freund  
  

Fix assorted issues in pg_ctl’s pgwin32_CommandLine().

  
commit   : 4ab4e5c6bb04dc1fc747baed3d42d5aa2ea44dfa    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 29 Nov 2013 18:34:22 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 29 Nov 2013 18:34:22 -0500    

Click here for diff

  
Ensure that the invocation command for postgres or pg_ctl runservice  
double-quotes the executable's pathname; failure to do this leads to  
trouble when the path contains spaces.  
  
Also, ensure that the path ends in ".exe" in both cases and uses  
backslashes rather than slashes as directory separators.  The latter issue  
is reported to confuse some third-party tools such as Symantec Backup Exec.  
  
Also, rewrite the function to avoid buffer overrun issues by using a  
PQExpBuffer instead of a fixed-size static buffer.  Combinations of  
very long executable pathnames and very long data directory pathnames  
could have caused trouble before, for example.  
  
Back-patch to all active branches, since this code has been like this  
for a long while.  
  
Naoya Anzai and Tom Lane, reviewed by Rajeev Rastogi  
  

Don’t update relfrozenxid if any pages were skipped.

  
commit   : ba63799598f134bad6f5a850dbca2549fa8b5146    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 27 Nov 2013 13:10:16 +0200    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 27 Nov 2013 13:10:16 +0200    

Click here for diff

  
Vacuum recognizes that it can update relfrozenxid by checking whether it has  
processed all pages of a relation. Unfortunately it performed that check  
after truncating the dead pages at the end of the relation, and used the new  
number of pages to decide whether all pages have been scanned. If the new  
number of pages happened to be smaller or equal to the number of pages  
scanned, it incorrectly decided that all pages were scanned.  
  
This can lead to relfrozenxid being updated, even though some pages were  
skipped that still contain old XIDs. That can lead to data loss due to xid  
wraparounds with some rows suddenly missing. This likely has escaped notice  
so far because it takes a large number (~2^31) of xids being used to see the  
effect, while a full-table vacuum before that would fix the issue.  
  
The incorrect logic was introduced by commit  
b4b6923e03f4d29636a94f6f4cc2f5cf6298b8c8. Backpatch this fix down to 8.4,  
like that commit.  
  
Andres Freund, with some modifications by me.  
  

ECPG: Fix offset to NULL/size indicator array.

  
commit   : ddd8416e40408da052cb630e1abea12909ca4d5e    
  
author   : Michael Meskes <meskes@postgresql.org>    
date     : Tue, 26 Nov 2013 17:16:39 +0100    
  
committer: Michael Meskes <meskes@postgresql.org>    
date     : Tue, 26 Nov 2013 17:16:39 +0100    

Click here for diff

  
Patch by Boszormenyi Zoltan <zb@cybertec.at>  
  

ECPG: Make the preprocessor emit ‘;’ if the variable type for a list of variables is varchar. This fixes this test case:

  
commit   : 7bee2e3e55f4503eec65783bd6d16f8291537c25    
  
author   : Michael Meskes <meskes@postgresql.org>    
date     : Tue, 26 Nov 2013 17:12:39 +0100    
  
committer: Michael Meskes <meskes@postgresql.org>    
date     : Tue, 26 Nov 2013 17:12:39 +0100    

Click here for diff

  
int main(void)  
{  
    exec sql begin declare section;  
    varchar a[50], b[50];  
    exec sql end declare section;  
  
    return 0;  
}  
  
Since varchars are internally turned into custom structs and  
the type name is emitted for these variable declarations,  
the preprocessed code previously had:  
  
struct varchar_1  { ... }  a _,_  struct varchar_2  { ... }  b ;  
  
The comma in the generated C file was a syntax error.  
  
There are no regression test changes since it's not exercised.  
  
Patch by Boszormenyi Zoltan <zb@cybertec.at>  
  
Conflicts:  
	src/interfaces/ecpg/preproc/ecpg.trailer  
  

Defend against bad trigger definitions in contrib/lo’s lo_manage() trigger.

  
commit   : cd5316f67d5f6e110205d47d27b11eb644720e4b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 23 Nov 2013 22:45:46 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 23 Nov 2013 22:45:46 -0500    

Click here for diff

  
This function formerly crashed if called as a statement-level trigger,  
or if a column-name argument wasn't given.  
  
In passing, add the trigger name to all error messages from the function.  
(None of them are expected cases, so this shouldn't pose any compatibility  
risk.)  
  
Marc Cousin, reviewed by Sawada Masahiko  
  

Fix array slicing of int2vector and oidvector values.

  
commit   : 747dd9724c189cabf2d846102fbf7cdf8bc57e65    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 23 Nov 2013 20:04:10 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 23 Nov 2013 20:04:10 -0500    

Click here for diff

  
The previous coding labeled expressions such as pg_index.indkey[1:3] as  
being of int2vector type; which is not right because the subscript bounds  
of such a result don't, in general, satisfy the restrictions of int2vector.  
To fix, implicitly promote the result of slicing int2vector to int2[],  
or oidvector to oid[].  This is similar to what we've done with domains  
over arrays, which is a good analogy because these types are very much  
like restricted domains of the corresponding regular-array types.  
  
A side-effect is that we now also forbid array-element updates on such  
columns, eg while "update pg_index set indkey[4] = 42" would have worked  
before if you were superuser (and corrupted your catalogs irretrievably,  
no doubt) it's now disallowed.  This seems like a good thing since, again,  
some choices of subscripting would've led to results not satisfying the  
restrictions of int2vector.  The case of an array-slice update was  
rejected before, though with a different error message than you get now.  
We could make these cases work in future if we added a cast from int2[]  
to int2vector (with a cast function checking the subscript restrictions)  
but it seems unlikely that there's any value in that.  
  
Per report from Ronan Dunklau.  Back-patch to all supported branches  
because of the crash risks involved.  
  

Ensure _dosmaperr() actually sets errno correctly.

  
commit   : ec6a6a268a634a3eae3add9088392c77627dfb26    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 23 Nov 2013 18:24:26 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 23 Nov 2013 18:24:26 -0500    

Click here for diff

  
If logging is enabled, either ereport() or fprintf() might stomp on errno  
internally, causing this function to return the wrong result.  That might  
only end in a misleading error report, but in any code that's examining  
errno to decide what to do next, the consequences could be far graver.  
  
This has been broken since the very first version of this file in 2006  
... it's a bit astonishing that we didn't identify this long ago.  
  
Reported by Amit Kapila, though this isn't his proposed fix.  
  

Avoid potential buffer overflow crash

  
commit   : 44032290dd23ccc0c227ee2af4f9e8c0e58077e8    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Sat, 23 Nov 2013 07:25:37 -0500    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Sat, 23 Nov 2013 07:25:37 -0500    

Click here for diff

  
A pointer to a C string was treated as a pointer to a "name" datum and  
passed to SPI_execute_plan().  This pointer would then end up being  
passed through datumCopy(), which would try to copy the entire 64 bytes  
of name data, thus running past the end of the C string.  Fix by  
converting the string to a proper name structure.  
  
Found by LLVM AddressSanitizer.  
  

Flatten join alias Vars before pulling up targetlist items from a subquery.

  
commit   : 612f953c7c3e8f5eed50607b56d461c88196c3a7    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 22 Nov 2013 14:37:35 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 22 Nov 2013 14:37:35 -0500    

Click here for diff

  
pullup_replace_vars()'s decisions about whether a pulled-up replacement  
expression needs to be wrapped in a PlaceHolderVar depend on the assumption  
that what looks like a Var behaves like a Var.  However, if the Var is a  
join alias reference, later flattening of join aliases might replace the  
Var with something that's not a Var at all, and should have been wrapped.  
  
To fix, do a forcible pass of flatten_join_alias_vars() on the subquery  
targetlist before we start to copy items out of it.  We'll re-run that  
processing on the pulled-up expressions later, but that's harmless.  
  
Per report from Ken Tanzer; the added regression test case is based on his  
example.  This bug has been there since the PlaceHolderVar mechanism was  
invented, but has escaped detection because the circumstances that trigger  
it are fairly narrow.  You need a flattenable query underneath an outer  
join, which contains another flattenable query inside a join of its own,  
with a dangerous expression (a constant or something else non-strict)  
in that one's targetlist.  
  
Having seen this, I'm wondering if it wouldn't be prudent to do all  
alias-variable flattening earlier, perhaps even in the rewriter.  
But that would probably not be a back-patchable change.  
  

Fix Hot-Standby initialization of clog and subtrans.

  
commit   : b4f697f8ebfa2fdc36bf98c50550b21eb8e82c7d    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 22 Nov 2013 14:38:59 +0200    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 22 Nov 2013 14:38:59 +0200    

Click here for diff

  
These bugs can cause data loss on standbys started with hot_standby=on at  
the moment they start to accept read only queries, by marking committed  
transactions as uncommited. The likelihood of such corruptions is small  
unless the primary has a high transaction rate.  
  
5a031a5556ff83b8a9646892715d7fef415b83c3 fixed bugs in HS's startup logic  
by maintaining less state until at least STANDBY_SNAPSHOT_PENDING state  
was reached, missing the fact that both clog and subtrans are written to  
before that. This only failed to fail in common cases because the usage  
of ExtendCLOG in procarray.c was superflous since clog extensions are  
actually WAL logged.  
  
f44eedc3f0f347a856eea8590730769125964597/I then tried to fix the missing  
extensions of pg_subtrans due to the former commit's changes - which are  
not WAL logged - by performing the extensions when switching to a state  
> STANDBY_INITIALIZED and not performing xid assignments before that -  
again missing the fact that ExtendCLOG is unneccessary - but screwed up  
twice: Once because latestObservedXid wasn't updated anymore in that  
state due to the earlier commit and once by having an off-by-one error in  
the loop performing extensions. This means that whenever a  
CLOG_XACTS_PER_PAGE (32768 with default settings) boundary was crossed  
between the start of the checkpoint recovery started from and the first  
xl_running_xact record old transactions commit bits in pg_clog could be  
overwritten if they started and committed in that window.  
  
Fix this mess by not performing ExtendCLOG() in HS at all anymore since  
it's unneeded and evidently dangerous and by performing subtrans  
extensions even before reaching STANDBY_SNAPSHOT_PENDING.  
  
Analysis and patch by Andres Freund. Reported by Christophe Pettus.  
Backpatch down to 9.0, like the previous commit that caused this.  
  

Fix incorrect loop counts in tidbitmap.c.

  
commit   : 32b32845e05c4dfe0862c89d12e0cacef4e018bb    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 15 Nov 2013 18:34:14 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 15 Nov 2013 18:34:14 -0500    

Click here for diff

  
A couple of places that should have been iterating over WORDS_PER_CHUNK  
words were iterating over WORDS_PER_PAGE words instead.  This thinko  
accidentally failed to fail, because (at least on common architectures  
with default BLCKSZ) WORDS_PER_CHUNK is a bit less than WORDS_PER_PAGE,  
and the extra words being looked at were always zero so nothing happened.  
Still, it's a bug waiting to happen if anybody ever fools with the  
parameters affecting TIDBitmap sizes, and it's a small waste of cycles  
too.  So back-patch to all active branches.  
  
Etsuro Fujita  
  

Clarify CREATE FUNCTION documentation about handling of typmods.

  
commit   : 1821ef15bd063fdfd0073dff7b18fa7f0d639554    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 13 Nov 2013 13:26:33 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 13 Nov 2013 13:26:33 -0500    

Click here for diff

  
The previous text was a bit misleading, as well as unnecessarily vague  
about what information would be discarded.  Per gripe from Craig Skinner.  
  

  
commit   : 0b336fb96371f353f95a7a0de2650fecdc37947e    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Tue, 12 Nov 2013 12:53:32 +0100    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Tue, 12 Nov 2013 12:53:32 +0100    

Click here for diff

  
Per report from Colin 't Hart  
  

Fix race condition in GIN posting tree page deletion.

  
commit   : 4b099e1bff528a149129732e4d5a1bf020f842ea    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 8 Nov 2013 22:21:42 +0200    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 8 Nov 2013 22:21:42 +0200    

Click here for diff

  
If a page is deleted, and reused for something else, just as a search is  
following a rightlink to it from its left sibling, the search would continue  
scanning whatever the new contents of the page are. That could lead to  
incorrect query results, or even something more curious if the page is  
reused for a different kind of a page.  
  
To fix, modify the search algorithm to lock the next page before releasing  
the previous one, and refrain from deleting pages from the leftmost branch  
of the tree.  
  
Add a new Concurrency section to the README, explaining why this works.  
There is a lot more one could say about concurrency in GIN, but that's for  
another patch.  
  
Backpatch to all supported versions.  
  

  
commit   : 987f05e162dd16aaf395ce1cf346f616a21a0a2c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 8 Nov 2013 11:37:12 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 8 Nov 2013 11:37:12 -0500    

Click here for diff

  
This change prevents us from doing inappropriate subquery flattening in  
cases such as dangerous functions hidden inside a sub-SELECT in the  
targetlist of another sub-SELECT.  That could result in unexpected behavior  
due to multiple evaluations of a volatile function, as in a recent  
complaint from Etienne Dube.  It's been questionable from the very  
beginning whether these functions should look into subqueries (as noted in  
their comments), and this case seems to provide proof that they should.  
  
Because the new code only descends into SubLinks, not SubPlans or  
InitPlans, the change only affects the planner's behavior during  
prepjointree processing and not later on --- for example, you can still get  
it to use a volatile function in an indexqual if you wrap the function in  
(SELECT ...).  That's a historical behavior, for sure, but it's reasonable  
given that the executor's evaluation rules for subplans don't depend on  
whether there are volatile functions inside them.  In any case, we need to  
constrain the behavioral change as narrowly as we can to make this  
reasonable to back-patch.  
  

Be more robust when strerror() doesn’t give a useful result.

  
commit   : 8103f49c1f3374bd71b49c128f1d7c7145e5c0ac    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 7 Nov 2013 16:33:34 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 7 Nov 2013 16:33:34 -0500    

Click here for diff

  
Back-patch commits 8e68816cc2567642c6fcca4eaac66c25e0ae5ced and  
8dace66e0735ca39b779922d02c24ea2686e6521 into the stable branches.  
Buildfarm testing revealed no great portability surprises, and it  
seems useful to have this robustness improvement in all branches.  
  

Prevent creating window functions with default arguments.

  
commit   : 352ab596fa5a8a4ceec6d308ebae34176cc09c13    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 6 Nov 2013 13:32:30 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 6 Nov 2013 13:32:30 -0500    

Click here for diff

  
Insertion of default arguments doesn't work for window functions, which is  
likely to cause a crash at runtime if the implementation code doesn't check  
the number of actual arguments carefully.  It doesn't seem worth working  
harder than this for pre-9.2 branches.  
  

Improve the error message given for modifying a window with frame clause.

  
commit   : 3dd13108ac5f16723d87288c8633f8d347823304    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 5 Nov 2013 21:58:23 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 5 Nov 2013 21:58:23 -0500    

Click here for diff

  
For rather inscrutable reasons, SQL:2008 disallows copying-and-modifying a  
window definition that has any explicit framing clause.  The error message  
we gave for this only made sense if the referencing window definition  
itself contains an explicit framing clause, which it might well not.  
Moreover, in the context of an OVER clause it's not exactly obvious that  
"OVER (windowname)" implies copy-and-modify while "OVER windowname" does  
not.  This has led to multiple complaints, eg bug #5199 from Iliya  
Krapchatov.  Change to a hopefully more intelligible error message, and  
in the case where we have just "OVER (windowname)", add a HINT suggesting  
that omitting the parentheses will fix it.  Also improve the related  
documentation.  Back-patch to all supported branches.  
  

Changed test case slightly so it doesn’t have an unused typedef.

  
commit   : da174fb0390e9827d7a76d43a7f3cab632d52dc0    
  
author   : Michael Meskes <meskes@postgresql.org>    
date     : Sun, 3 Nov 2013 15:37:34 +0100    
  
committer: Michael Meskes <meskes@postgresql.org>    
date     : Sun, 3 Nov 2013 15:37:34 +0100    

Click here for diff

  
  

Ensure all files created for a single BufFile have the same resource owner.

  
commit   : 0c8462fd5325170fda533ecd59e6f986dcb3da6e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 1 Nov 2013 16:10:03 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 1 Nov 2013 16:10:03 -0400    

Click here for diff

  
Callers expect that they only have to set the right resource owner when  
creating a BufFile, not during subsequent operations on it.  While we could  
insist this be fixed at the caller level, it seems more sensible for the  
BufFile to take care of it.  Without this, some temp files belonging to  
a BufFile can go away too soon, eg at the end of a subtransaction,  
leading to errors or crashes.  
  
Reported and fixed by Andres Freund.  Back-patch to all active branches.  
  

Fix some odd behaviors when using a SQL-style simple GMT offset timezone.

  
commit   : d81cd0430f486f1f1c22ebd9733114b944af4d0c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 1 Nov 2013 12:13:33 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 1 Nov 2013 12:13:33 -0400    

Click here for diff

  
Formerly, when using a SQL-spec timezone setting with a fixed GMT offset  
(called a "brute force" timezone in the code), the session_timezone  
variable was not updated to match the nominal timezone; rather, all code  
was expected to ignore session_timezone if HasCTZSet was true.  This is  
of course obviously fragile, though a search of the code finds only  
timeofday() failing to honor the rule.  A bigger problem was that  
DetermineTimeZoneOffset() supposed that if its pg_tz parameter was  
pointer-equal to session_timezone, then HasCTZSet should override the  
parameter.  This would cause datetime input containing an explicit zone  
name to be treated as referencing the brute-force zone instead, if the  
zone name happened to match the session timezone that had prevailed  
before installing the brute-force zone setting (as reported in bug #8572).  
The same malady could affect AT TIME ZONE operators.  
  
To fix, set up session_timezone so that it matches the brute-force zone  
specification, which we can do using the POSIX timezone definition syntax  
"<abbrev>offset", and get rid of the bogus lookaside check in  
DetermineTimeZoneOffset().  Aside from fixing the erroneous behavior in  
datetime parsing and AT TIME ZONE, this will cause the timeofday() function  
to print its result in the user-requested time zone rather than some  
previously-set zone.  It might also affect results in third-party  
extensions, if there are any that make use of session_timezone without  
considering HasCTZSet, but in all cases the new behavior should be saner  
than before.  
  
Back-patch to all supported branches.  
  

Prevent using strncpy with src == dest in TupleDescInitEntry.

  
commit   : aad45bd54b098c14bd5670ec0043a332ee4c7020    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 28 Oct 2013 20:49:38 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 28 Oct 2013 20:49:38 -0400    

Click here for diff

  
The C and POSIX standards state that strncpy's behavior is undefined when  
source and destination areas overlap.  While it remains dubious whether any  
implementations really misbehave when the pointers are exactly equal, some  
platforms are now starting to force the issue by complaining when an  
undefined call occurs.  (In particular OS X 10.9 has been seen to dump core  
here, though the exact set of circumstances needed to trigger that remain  
elusive.  Similar behavior can be expected to be optional on Linux and  
other platforms in the near future.)  So tweak the code to explicitly do  
nothing when nothing need be done.  
  
Back-patch to all active branches.  In HEAD, this also lets us get rid of  
an exception in valgrind.supp.  
  
Per discussion of a report from Matthias Schmitt.  
  

  
commit   : 42ef7c87bfba63988049735e8e74eafd53d7a03e    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 2 Jul 2013 20:32:09 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 2 Jul 2013 20:32:09 -0400    

Click here for diff

  
The web site is dead, and the Wayback Machine shows that it didn't have  
much useful content before.  
  

doc: fix typo in release notes

  
commit   : ca4967903dff9e7ac86d4a146a4aebc9046009b0    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 9 Oct 2013 08:44:52 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 9 Oct 2013 08:44:52 -0400    

Click here for diff

  
Backpatch through 8.4  
  
Per suggestion by Amit Langote