PostgreSQL 9.3.4 commit log

Stamp 9.3.4.

  
commit   : d4f8dde3c1c2c90c723ab550e7f449fc75599316    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 17 Mar 2014 15:35:47 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 17 Mar 2014 15:35:47 -0400    

Click here for diff

  
  

Release notes for 9.3.4, 9.2.8, 9.1.13, 9.0.17, 8.4.21.

  
commit   : fc61da7c911e99152907cd74fe6b7e3163cce280    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 17 Mar 2014 15:28:26 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 17 Mar 2014 15:28:26 -0400    

Click here for diff

  
  

During index build, check and elog (not just Assert) for broken HOT chain.

  
commit   : c3701254b58d2323dfa399d3ed62551e2c738c48    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 17 Mar 2014 12:36:13 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 17 Mar 2014 12:36:13 -0400    

Click here for diff

  
The recently-fixed bug in WAL replay could result in not finding a parent  
tuple for a heap-only tuple.  The existing code would either Assert or  
generate an invalid index entry, neither of which is desirable.  Throw a  
regular error instead.  
  

Fix bug in clean shutdown of walsender that pg_receiving is connecting to.

  
commit   : 3857234053fccbea6344cc4a1b632750621d51d8    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Mon, 17 Mar 2014 20:41:12 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Mon, 17 Mar 2014 20:41:12 +0900    

Click here for diff

  
On clean shutdown, walsender waits for all WAL to be replicated to a standby,  
and exits. It determined whether that replication had been completed by  
checking whether its sent location had been equal to a standby's flush  
location. Unfortunately this condition never becomes true when the standby  
such as pg_receivexlog which always returns an invalid flush location is  
connecting to walsender, and then walsender waits forever.  
  
This commit changes walsender so that it just checks a standby's write  
location if a flush location is invalid.  
  
Back-patch to 9.1 where enough infrastructure for this exists.  
  

plperl: Fix memory leak in hek2cstr

  
commit   : 60829079d7eae9ba6a4e9e58807bbe1a70b12b84    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Sun, 16 Mar 2014 23:22:22 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Sun, 16 Mar 2014 23:22:22 -0300    

Click here for diff

  
Backpatch all the way back to 9.1, where it was introduced by commit  
50d89d42.  
  
Reported by Sergey Burladyan in #9223  
Author: Alex Hunsaker  
  

Translation updates

  
commit   : ae7d04a82b823f087731b6b7c650eb2fb5abe968    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Sun, 16 Mar 2014 21:55:58 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Sun, 16 Mar 2014 21:55:58 -0400    

Click here for diff

  
  

Fix unportable shell-script syntax in pg_upgrade’s test.sh.

  
commit   : a98ad4fabc414c821bfb273f334a5bbccf4a451a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 16 Mar 2014 21:55:06 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 16 Mar 2014 21:55:06 -0400    

Click here for diff

  
I discovered the hard way that on some old shells, the locution  
    FOO=""   unset FOO  
does not behave the same as  
    FOO="";  unset FOO  
and in fact leaves FOO set to an empty string.  test.sh was inconsistently  
spelling it different ways on adjacent lines.  
  
This got broken relatively recently, in commit c737a2e56, so the lack of  
field reports to date doesn't represent a lot of evidence that the problem  
is rare.  
  

Make punctuation consistent

  
commit   : 37e5b3d9bd97b1eb898df95c969f064ea3ce729d    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Sun, 16 Mar 2014 21:44:58 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Sun, 16 Mar 2014 21:44:58 -0400    

Click here for diff

  
  

Fix advertised dispsize for libpq’s sslmode connection parameter.

  
commit   : 37cb060e603133fb52d7b8eb8ff9462fc3df5cbb    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 16 Mar 2014 21:43:43 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 16 Mar 2014 21:43:43 -0400    

Click here for diff

  
"8" was correct back when "disable" was the longest allowed value, but  
since "verify-full" was added, it should be "12".  Given the lack of  
complaints, I wouldn't be surprised if nobody is actually using these  
values ... but still, if they're in the API, they should be right.  
  
Noticed while pursuing a different problem.  It's been wrong for quite  
a long time, so back-patch to all supported branches.  
  

Update time zone data files to tzdata release 2014a.

  
commit   : b5de169971e1715dc9029f79142d669311a6d001    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 15 Mar 2014 13:36:07 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 15 Mar 2014 13:36:07 -0400    

Click here for diff

  
DST law changes in Fiji, Turkey; historical changes in Israel, Ukraine.  
  

Prevent interrupts while reporting non-ERROR elog messages.

  
commit   : 41bd2cf55c7ca0d51832afb848da34ebc9a4930e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 13 Mar 2014 20:59:45 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 13 Mar 2014 20:59:45 -0400    

Click here for diff

  
This should eliminate the risk of recursive entry to syslog(3), which  
appears to be the cause of the hang reported in bug #9551 from James  
Morton.  
  
Arguably, the real problem here is auth.c's willingness to turn on  
ImmediateInterruptOK while executing fairly wide swaths of backend code.  
We may well need to work at narrowing the code ranges in which the  
authentication_timeout interrupt is enabled.  For the moment, though,  
this is a cheap and reasonably noninvasive fix for a field-reported  
failure; the other approach would be complex and not necessarily  
bug-free itself.  
  
Back-patch to all supported branches.  
  

Avoid transaction-commit race condition while receiving a NOTIFY message.

  
commit   : 0d11fed8ef3d6e22afa303328f7ecd65b0ac3328    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 13 Mar 2014 12:02:56 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 13 Mar 2014 12:02:56 -0400    

Click here for diff

  
Use TransactionIdIsInProgress, then TransactionIdDidCommit, to distinguish  
whether a NOTIFY message's originating transaction is in progress,  
committed, or aborted.  The previous coding could accept a message from a  
transaction that was still in-progress according to the PGPROC array;  
if the client were fast enough at starting a new transaction, it might fail  
to see table rows added/updated by the message-sending transaction.  Which  
of course would usually be the point of receiving the message.  We noted  
this type of race condition long ago in tqual.c, but async.c overlooked it.  
  
The race condition probably cannot occur unless there are multiple NOTIFY  
senders in action, since an individual backend doesn't send NOTIFY signals  
until well after it's done committing.  But if two senders commit in close  
succession, it's certainly possible that we could see the second sender's  
message within the race condition window while responding to the signal  
from the first one.  
  
Per bug #9557 from Marko Tiikkaja.  This patch is slightly more invasive  
than what he proposed, since it removes the now-redundant  
TransactionIdDidAbort call.  
  
Back-patch to 9.0, where the current NOTIFY implementation was introduced.  
  

In WAL replay, restore GIN metapage unconditionally to avoid torn page.

  
commit   : 4738cc3569470f3df8e999080935355d71708c59    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 12 Mar 2014 09:59:49 +0200    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 12 Mar 2014 09:59:49 +0200    

Click here for diff

  
We don't take a full-page image of the GIN metapage; instead, the WAL record  
contains all the information required to reconstruct it from scratch. But  
to avoid torn page hazards, we must re-initialize it from the WAL record  
every time, even if it already has a greater LSN, similar to how normal full  
page images are restored.  
  
This was highly unlikely to cause any problems in practice, because the GIN  
metapage is small. We rely on an update smaller than a 512 byte disk sector  
to be atomic elsewhere, at least in pg_control. But better safe than sorry,  
and this would be easy to overlook if more fields are added to the metapage  
so that it's no longer small.  
  
Reported by Noah Misch. Backpatch to all supported versions.  
  

Fix tracking of psql script line numbers during \copy from another place.

  
commit   : f64f4c3709069aaecdceaf12eb77041a5ab61390    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Mar 2014 15:47:09 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Mar 2014 15:47:09 -0400    

Click here for diff

  
Commit 08146775acd8bfe0fcc509c71857abb928697171 changed do_copy() to  
temporarily scribble on pset.cur_cmd_source.  That was a mighty ugly bit of  
code in any case, but in particular it broke handleCopyIn's ability to tell  
whether it was reading from the current script source file (in which case  
pset.lineno should be incremented for each line of COPY data), or from  
someplace else (in which case it shouldn't).  The former case still worked,  
the latter not so much.  The visible effect was that line numbers reported  
for errors in a script file would be wrong if there were an earlier \copy  
that was reading anything other than inline-in-the-script-file data.  
  
To fix, introduce another pset field that holds the file do_copy wants the  
COPY code to use.  This is a little bit ugly, but less so than passing the  
file down explicitly through several layers that aren't COPY-specific.  
  
Extracted from a larger patch by Kumar Rajeev Rastogi; that patch also  
changes printing of COPY command tags, which is not a bug fix and shouldn't  
get back-patched.  This particular idea was from a suggestion by Amit  
Khandekar, if I'm reading the thread correctly.  
  
Back-patch to 9.2 where the faulty code was introduced.  
  

Fix contrib/postgres_fdw to handle multiple join conditions properly.

  
commit   : 73f0483fd158aea49ea5b871b8a958adb98ea762    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 7 Mar 2014 16:36:01 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 7 Mar 2014 16:36:01 -0500    

Click here for diff

  
The previous coding supposed that it could consider just a single join  
condition in any one parameterized path for the foreign table.  But in  
reality, the parameterized-path machinery forces all join clauses that are  
"movable to" the foreign table to be evaluated at that node; including  
clauses that we might not consider safe to send across.  Such cases would  
result in an Assert failure in an assert-enabled build, and otherwise in  
sending an unsafe clause to the foreign server, which might result in  
errors or silently-wrong answers.  A lesser problem was that the  
cost/rowcount estimates generated for the parameterized path failed to  
account for any additional join quals that get assigned to the scan.  
  
To fix, rewrite postgresGetForeignPaths so that it correctly collects all  
the movable quals for any one outer relation when generating parameterized  
paths; we'll now generate just one path per outer relation not one per join  
qual.  Also fix bogus assumptions in postgresGetForeignPlan and  
estimate_path_cost_size that only safe-to-send join quals will be  
presented.  
  
Based on complaint from Etsuro Fujita that the path costs were being  
miscalculated, though this is significantly different from his proposed  
patch.  
  

release notes: add item missed in 9.2.5 release

  
commit   : 28d92026f0855061acd89228199db8327d0412f0    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Fri, 7 Mar 2014 13:45:38 -0500    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Fri, 7 Mar 2014 13:45:38 -0500    

Click here for diff

  
Item is "Prevent errors in WAL replay due to references to uninitialized  
empty pages".  
  
Report and text by Andres Freund  
  
Backpatch through 9.2.  
  

Fix dangling smgr_owner pointer when a fake relcache entry is freed.

  
commit   : 4f91af8ca2f567bc9087644b29df8d6a56549994    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 7 Mar 2014 13:25:11 +0200    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 7 Mar 2014 13:25:11 +0200    

Click here for diff

  
A fake relcache entry can "own" a SmgrRelation object, like a regular  
relcache entry. But when it was free'd, the owner field in SmgrRelation  
was not cleared, so it was left pointing to free'd memory.  
  
Amazingly this apparently hasn't caused crashes in practice, or we would've  
heard about it earlier. Andres found this with Valgrind.  
  
Report and fix by Andres Freund, with minor modifications by me. Backpatch  
to all supported versions.  
  

Avoid memcpy() with same source and destination address.

  
commit   : 8332fe76b559dd7d0a689ec66e96c359e67e1f3b    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 7 Mar 2014 13:13:33 +0200    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 7 Mar 2014 13:13:33 +0200    

Click here for diff

  
The behavior of that is undefined, although unlikely to lead to problems in  
practice.  
  
Found by running regression tests with Valgrind.  
  

Fix name of syslog_ident GUC in docs.

  
commit   : 886c4ebfa3d935ff031f668b845a7c2463fd9acd    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 7 Mar 2014 10:35:37 +0200    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 7 Mar 2014 10:35:37 +0200    

Click here for diff

  
Michael Paquier  
  

Fix typo in comment.

  
commit   : ec3cb1ca2a07abb1f26033f124df438ca816be6f    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 7 Mar 2014 10:36:31 +0200    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 7 Mar 2014 10:36:31 +0200    

Click here for diff

  
Forgot to "git add" it earlier.  
  

Avoid getting more than AccessShareLock when deparsing a query.

  
commit   : f557826f8db1015c55473b8a3343faa96b480aed    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 6 Mar 2014 19:31:09 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 6 Mar 2014 19:31:09 -0500    

Click here for diff

  
In make_ruledef and get_query_def, we have long used AcquireRewriteLocks  
to ensure that the querytree we are about to deparse is up-to-date and  
the schemas of the underlying relations aren't changing.  Howwever, that  
function thinks the query is about to be executed, so it acquires locks  
that are stronger than necessary for the purpose of deparsing.  Thus for  
example, if pg_dump asks to deparse a rule that includes "INSERT INTO t",  
we'd acquire RowExclusiveLock on t.  That results in interference with  
concurrent transactions that might for example ask for ShareLock on t.  
Since pg_dump is documented as being purely read-only, this is unexpected.  
(Worse, it used to actually be read-only; this behavior dates back only  
to 8.1, cf commit ba4200246.)  
  
Fix this by adding a parameter to AcquireRewriteLocks to tell it whether  
we want the "real" execution locks or only AccessShareLock.  
  
Report, diagnosis, and patch by Dean Rasheed.  Back-patch to all supported  
branches.  
  

Send keepalives from walsender even when busy sending WAL.

  
commit   : dcd1131c83a3fff824f0fc0a62a61a1e03282da5    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 6 Mar 2014 21:13:38 +0200    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 6 Mar 2014 21:13:38 +0200    

Click here for diff

  
If walsender doesn't hear from the client for the time specified by  
wal_sender_timeout, it will conclude the connection or client is dead, and  
disconnect. When half of wal_sender_timeout has elapsed, it sends a ping  
to the client, leaving it the remainig half of wal_sender_timeout to  
respond. However, it only checked if half of wal_sender_timeout had elapsed  
when it was about to sleep, so if it was busy sending WAL to the client for  
long enough, it would not send the ping request in time. Then the client  
would not know it needs to send a reply, and the walsender will disconnect  
even though the client is still alive. Fix that.  
  
Andres Freund, reviewed by Robert Haas, and some further changes by me.  
Backpatch to 9.3. Earlier versions relied on the client to send the  
keepalives on its own, and hence didn't have this problem.  
  

Don’t reject ROW_MARK_REFERENCE rowmarks for materialized views.

  
commit   : 3973034e6dc599de2203ed812f783a57b63dce5c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 6 Mar 2014 11:37:04 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 6 Mar 2014 11:37:04 -0500    

Click here for diff

  
We should allow this so that matviews can be referenced in UPDATE/DELETE  
statements in READ COMMITTED isolation level.  The requirement for that  
is that a re-fetch by TID will see the same row version the query saw  
earlier, which is true of matviews, so there's no reason for the  
restriction.  Per bug #9398.  
  
Michael Paquier, after a suggestion by me  
  

Remove the correct pgstat file on DROP DATABASE

  
commit   : 13ea43ab83871a8bed5b9cdf7ec18c62bf63df4f    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 5 Mar 2014 13:03:29 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 5 Mar 2014 13:03:29 -0300    

Click here for diff

  
We were unlinking the permanent file, not the non-permanent one.  But  
since the stat collector already unlinks all permanent files on startup,  
there was nothing for it to unlink.  The non-permanent file remained in  
place, and was copied to the permanent directory on shutdown, so in  
effect no file was ever dropped.  
  
Backpatch to 9.3, where the issue was introduced by commit 187492b6c2e8.  
Before that, there were no per-database files and thus no file to drop  
on DROP DATABASE.  
  
Per report from Thom Brown.  
  
Author: Tomáš Vondra  
  

Do wal_level and hot standby checks when doing crash-then-archive recovery.

  
commit   : a5363a696a46d97b94ac63394f3952e9769ee113    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 5 Mar 2014 14:41:55 +0200    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 5 Mar 2014 14:41:55 +0200    

Click here for diff

  
CheckRequiredParameterValues() should perform the checks if archive recovery  
was requested, even if we are going to perform crash recovery first.  
  
Reported by Kyotaro HORIGUCHI. Backpatch to 9.2, like the crash-then-archive  
recovery mode.  
  

Fix lastReplayedEndRecPtr calculation when starting from shutdown checkpoint.

  
commit   : 2cd72ba42d22a1d19cfb9c01e59f82519ab22a9f    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 5 Mar 2014 13:27:18 +0200    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 5 Mar 2014 13:27:18 +0200    

Click here for diff

  
When entering crash recovery followed by archive recovery, and the latest  
checkpoint is a shutdown checkpoint, and there are no more WAL records to  
replay before transitioning from crash to archive recovery, we would not  
immediately allow read-only connections in hot standby mode even if we  
could. That's because when starting from a shutdown checkpoint, we set  
lastReplayedEndRecPtr incorrectly to the record before the checkpoint  
record, instead of the checkpoint record itself. We don't run the redo  
routine of the shutdown checkpoint record, but starting recovery from it  
goes through the same motions, so it should be considered as replayed.  
  
Reported by Kyotaro HORIGUCHI. All versions with hot standby are affected,  
so backpatch to 9.0.  
  

Error out on send failure in walsender loop.

  
commit   : 38587d7d286faeec83bdbb89ff34eeee5eabb23e    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 4 Mar 2014 15:30:52 +0200    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 4 Mar 2014 15:30:52 +0200    

Click here for diff

  
I changed the loop in 9.3 to use "goto send_failure" instead of "break" on  
errors, but I missed this one case. It was a relatively harmless bug: if  
the flush fails once it will most likely fail again as soon as we try to  
flush the output again. But it's a bug nevertheless.  
  
Report and fix by Andres Freund.  
  

Allow regex operations to be terminated early by query cancel requests.

  
commit   : f5f21315d25ffcbfe7c6a3fa6ffaad54d31bcde0    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 1 Mar 2014 15:21:00 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 1 Mar 2014 15:21:00 -0500    

Click here for diff

  
The regex code didn't have any provision for query cancel; which is  
unsurprising given its non-Postgres origin, but still problematic since  
some operations can take a long time.  Introduce a callback function to  
check for a pending query cancel or session termination request, and  
call it in a couple of strategic spots where we can make the regex code  
exit with an error indicator.  
  
If we ever actually split out the regex code as a standalone library,  
some additional work will be needed to let the cancel callback function  
be specified externally to the library.  But that's straightforward  
(certainly so by comparison to putting the locale-dependent character  
classification logic on a similar arms-length basis), and there seems  
no need to do it right now.  
  
A bigger issue is that there may be more places than these two where  
we need to check for cancels.  We can always add more checks later,  
now that the infrastructure is in place.  
  
Since there are known examples of not-terribly-long regexes that can  
lock up a backend for a long time, back-patch to all supported branches.  
I have hopes of fixing the known performance problems later, but adding  
query cancel ability seems like a good idea even if they were all fixed.  
  

Remove bogus while-loop.

  
commit   : 17450cb6809f534283545f629082efcd3ea904ed    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 28 Feb 2014 13:22:25 +0200    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 28 Feb 2014 13:22:25 +0200    

Click here for diff

  
Commit abf5c5c9a4f142b3343614746bb9e99a794f8e7b added a bogus while-  
statement after the for(;;)-loop. It went unnoticed in testing, because  
it was dead code.  
  
Report by KONDO Mitsumasa. Backpatch to 9.3. The commit that introduced  
this was also applied to 9.2, but not the bogus while-loop part, because  
the code in 9.2 looks quite different.  
  

doc: bgw_main takes a Datum argument, not void *.

  
commit   : 9b4bd35aa1f185b3ad5b2e3d51a524f5bb77f577    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 27 Feb 2014 11:41:43 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 27 Feb 2014 11:41:43 -0300    

Click here for diff

  
Per report from James Harper.  
  

Fix WAL replay of locking an updated tuple

  
commit   : 9a57858f1103b89a5674f0d50c5fe1f756411df6    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 27 Feb 2014 11:13:39 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 27 Feb 2014 11:13:39 -0300    

Click here for diff

  
We were resetting the tuple's HEAP_HOT_UPDATED flag as well as t_ctid on  
WAL replay of a tuple-lock operation, which is incorrect when the tuple  
is already updated.  
  
Back-patch to 9.3.  The clearing of both header elements was there  
previously, but since no update could be present on a tuple that was  
being locked, it was harmless.  
  
Bug reported by Peter Geoghegan and Greg Stark in  
CAM3SWZTMQiCi5PV5OWHb+bYkUcnCk=O67w0cSswPvV7XfUcU5g@mail.gmail.com and  
CAM-w4HPTOeMT4KP0OJK+mGgzgcTOtLRTvFZyvD0O4aH-7dxo3Q@mail.gmail.com  
respectively; diagnosis by Andres Freund.  
  

Use SnapshotDirty rather than an active snapshot to probe index endpoints.

  
commit   : 4162a55c77cbb54acb4ac442ef3565b813b9d07a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 25 Feb 2014 16:04:09 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 25 Feb 2014 16:04:09 -0500    

Click here for diff

  
If there are lots of uncommitted tuples at the end of the index range,  
get_actual_variable_range() ends up fetching each one and doing an MVCC  
visibility check on it, until it finally hits a visible tuple.  This is  
bad enough in isolation, considering that we don't need an exact answer  
only an approximate one.  But because the tuples are not yet committed,  
each visibility check does a TransactionIdIsInProgress() test, which  
involves scanning the ProcArray.  When multiple sessions do this  
concurrently, the ensuing contention results in horrid performance loss.  
20X overall throughput loss on not-too-complicated queries is easy to  
demonstrate in the back branches (though someone's made it noticeably  
less bad in HEAD).  
  
We can dodge the problem fairly effectively by using SnapshotDirty rather  
than a normal MVCC snapshot.  This will cause the index probe to take  
uncommitted tuples as good, so that we incur only one tuple fetch and test  
even if there are many such tuples.  The extent to which this degrades the  
estimate is debatable: it's possible the result is actually a more accurate  
prediction than before, if the endmost tuple has become committed by the  
time we actually execute the query being planned.  In any case, it's not  
very likely that it makes the estimate a lot worse.  
  
SnapshotDirty will still reject tuples that are known committed dead, so  
we won't give bogus answers if an invalid outlier has been deleted but not  
yet vacuumed from the index.  (Because btrees know how to mark such tuples  
dead in the index, we shouldn't have a big performance problem in the case  
that there are many of them at the end of the range.)  This consideration  
motivates not using SnapshotAny, which was also considered as a fix.  
  
Note: the back branches were using SnapshotNow instead of an MVCC snapshot,  
but the problem and solution are the same.  
  
Per performance complaints from Bartlomiej Romanski, Josh Berkus, and  
others.  Back-patch to 9.0, where the issue was introduced (by commit  
40608e7f949fb7e4025c0ddd5be01939adc79eec).  
  

Do ScalarArrayOp estimation correctly when array is a stable expression.

  
commit   : e8655a77f327bd3fca0f4aaf14b86b540c64ecdf    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 21 Feb 2014 17:10:49 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 21 Feb 2014 17:10:49 -0500    

Click here for diff

  
Most estimation functions apply estimate_expression_value to see if they  
can reduce an expression to a constant; the key difference is that it  
allows evaluation of stable as well as immutable functions in hopes of  
ending up with a simple Const node.  scalararraysel didn't get the memo  
though, and neither did gincost_opexpr/gincost_scalararrayopexpr.  Fix  
that, and remove a now-unnecessary estimate_expression_value step in the  
subsidiary function scalararraysel_containment.  
  
Per complaint from Alexey Klyukin.  Back-patch to 9.3.  The problem  
goes back further, but I'm hesitant to change estimation behavior in  
long-stable release branches.  
  

Add a GUC to report whether data page checksums are enabled.

  
commit   : 5a7e75849cb595943fc605c4532716e9dd69f8a0    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 16 Sep 2013 14:36:01 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 16 Sep 2013 14:36:01 +0300    

Click here for diff

  
Backported from master. It was an oversight in the original data checksums  
patch to not have a GUC like this.  
  

Remove broken code that tried to handle OVERLAPS with a single argument.

  
commit   : 0aaa4224108611d2fad80451c69db117eb86217f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 18 Feb 2014 12:44:24 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 18 Feb 2014 12:44:24 -0500    

Click here for diff

  
The SQL standard says that OVERLAPS should have a two-element row  
constructor on each side.  The original coding of OVERLAPS support in  
our grammar attempted to extend that by allowing a single-element row  
constructor, which it internally duplicated ... or tried to, anyway.  
But that code has certainly not worked since our List infrastructure was  
rewritten in 2004, and I'm none too sure it worked before that.  As it  
stands, it ends up building a List that includes itself, leading to  
assorted undesirable behaviors later in the parser.  
  
Even if it worked as intended, it'd be a bit evil because of the  
possibility of duplicate evaluation of a volatile function that the user  
had written only once.  Given the lack of documentation, test cases, or  
complaints, let's just get rid of the idea and only support the standard  
syntax.  
  
While we're at it, improve the error cursor positioning for the  
wrong-number-of-arguments errors, and inline the makeOverlaps() function  
since it's only called in one place anyway.  
  
Per bug #9227 from Joshua Yanovski.  Initial patch by Joshua Yanovski,  
extended a bit by me.  
  

Disable RandomizedBaseAddress on MSVC builds

  
commit   : b88ecb002ef486ff76dd130fb0c6ac01551414dc    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Tue, 18 Feb 2014 14:45:58 +0100    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Tue, 18 Feb 2014 14:45:58 +0100    

Click here for diff

  
The ASLR in Windows 8/Windows 2012 can break PostgreSQL's shared memory. It  
doesn't fail every time (which is explained by the Random part in ASLR), but  
can fail with errors abut failing to reserve shared memory region.  
  
MauMau, reviewed by Craig Ringer  
  

Fix comment; checkpointer, not bgwriter, performs checkpoints since 9.2.

  
commit   : 535b435c217ca8210c25bb59efa01381aaf413c8    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 18 Feb 2014 09:48:18 +0200    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 18 Feb 2014 09:48:18 +0200    

Click here for diff

  
Amit Langote  
  

Translation updates

  
commit   : dc68985c2a8968d3f52c4577f036e785fe31ab31    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 17 Feb 2014 16:54:31 -0500    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 17 Feb 2014 16:54:31 -0500    

Click here for diff