PostgreSQL 9.0.17 commit log

Stamp 9.0.17.

  
commit   : 192856b1b9a5abe99bcd8b417d5ef39f09ae2c9d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 17 Mar 2014 15:38:14 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 17 Mar 2014 15:38:14 -0400    

Click here for diff

  
  

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

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

Click here for diff

  
  

Translation updates

  
commit   : 52326d38192c5ad27750f8efaa11e97f9177461b    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Sun, 16 Mar 2014 21:34:28 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Sun, 16 Mar 2014 21:34:28 -0400    

Click here for diff

  
  

Fix advertised dispsize for libpq’s sslmode connection parameter.

  
commit   : fecc9e23a34b8d99dbecdc28acb25eeb622faeed    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 16 Mar 2014 21:43:52 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 16 Mar 2014 21:43:52 -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.  
  

Disable RandomizeBaseAddress on MSVC builds

  
commit   : 665515539f6a6ea05e73cf565eab671afbc3c02d    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Sun, 16 Mar 2014 11:46:20 +0100    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Sun, 16 Mar 2014 11:46:20 +0100    

Click here for diff

  
This is a backpatch of 7f3e17b4827b61ad84e0774e3e43da4c57c4487f  
to 9.0 and 9.1.  
  
Patch by MauMau  
  

Update time zone data files to tzdata release 2014a.

  
commit   : 0033f5324cbf7bcb5e9e559b3997af341b34e9ab    
  
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.  
  

Add missing #include.

  
commit   : f080e493503285d86ad51007a29311c5afc39b71    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 14 Mar 2014 11:46:59 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 14 Mar 2014 11:46:59 -0400    

Click here for diff

  
Commit 31400a673 and siblings added a check_stack_depth() call in  
contrib/intarray/_int_bool.c, but neglected to note that in our oldest  
branches that file didn't have the #include that defines that function.  
This results in a fortunately-harmless compiler warning.  Per buildfarm.  
  

Prevent interrupts while reporting non-ERROR elog messages.

  
commit   : dad55e1e99dcc0c6b2a75722b3f1106bc68c8960    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 13 Mar 2014 20:59:55 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 13 Mar 2014 20:59:55 -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   : 7aea1050ebdf21cb0714bfec46d5bba6d85cf3bf    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 13 Mar 2014 12:03:07 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 13 Mar 2014 12:03:07 -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   : 9954e1f03804b4d7b77fab6f349f7af596f2c903    
  
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 dangling smgr_owner pointer when a fake relcache entry is freed.

  
commit   : 0f714c602cd260cace1f8c2d61896d7851990021    
  
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   : d8f2858b884c4b9c77a14a9e9e6ea5f16a48faf3    
  
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   : 762c1436822304e8acbe79f32e05f852d653431f    
  
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  
  

Avoid getting more than AccessShareLock when deparsing a query.

  
commit   : bed1259e52002ae2fb77a60b0f182dd93941ec60    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 6 Mar 2014 19:31:19 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 6 Mar 2014 19:31:19 -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.  
  

Fix lastReplayedEndRecPtr calculation when starting from shutdown checkpoint.

  
commit   : 4521cc85075ca98b7337ae524c3e88ce723e61e9    
  
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.  
  

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

  
commit   : 43af0e8c6c1a455d038730f3ec33a5f23a560fe2    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 1 Mar 2014 15:21:11 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 1 Mar 2014 15:21:11 -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.  
  

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

  
commit   : 1e0fb6a2c69541e2def2d4364513fbef02c0dbd2    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 25 Feb 2014 16:04:20 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 25 Feb 2014 16:04:20 -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).  
  

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

  
commit   : 19d66ab05ec752dcb4073352be94609fbc1768fb    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 18 Feb 2014 12:44:33 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 18 Feb 2014 12:44:33 -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.  
  

Translation updates

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

Click here for diff