PostgreSQL 9.3.1 commit log

commit   : b7f59e6d3e7c10ef0e222ce8ee6d19e8be304e29    
  
author   : Peter Eisentraut <[email protected]>    
date     : Mon, 7 Oct 2013 23:17:38 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Mon, 7 Oct 2013 23:17:38 -0400    

commit   : 4e80950042ff70a8d9825c1d9549692b8124dd40    
  
author   : Peter Eisentraut <[email protected]>    
date     : Mon, 7 Oct 2013 22:42:52 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Mon, 7 Oct 2013 22:42:52 -0400    

This reverts commit 9598134e3030a883ff6eea8a822466ce5143ffeb.  

commit   : 9fba0cbee38bd73b68ed350c31eee3bb102bd422    
  
author   : Peter Eisentraut <[email protected]>    
date     : Mon, 7 Oct 2013 22:32:04 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Mon, 7 Oct 2013 22:32:04 -0400    

This reverts commit f8110c5f66ad079e3dbc0b66bed06207c43643ef.  
  
pending resolution of  
http://www.postgresql.org/message-id/[email protected]  

commit   : 4b414606753498095306132a5b75cb900c6381fe    
  
author   : Peter Eisentraut <[email protected]>    
date     : Mon, 7 Oct 2013 22:31:31 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Mon, 7 Oct 2013 22:31:31 -0400    

This reverts commit 7f165f2587f6dafe7d4d438136dd959ed5610979.  
  
pending resolution of  
http://www.postgresql.org/message-id/[email protected]  

commit   : 2589a5a59b9023b66710227750dab15cec68310f    
  
author   : Bruce Momjian <[email protected]>    
date     : Mon, 7 Oct 2013 21:35:02 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Mon, 7 Oct 2013 21:35:02 -0400    

commit   : cc736ed91f4c04773fcb8f4683542ce105997e5b    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Mon, 7 Oct 2013 23:57:40 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Mon, 7 Oct 2013 23:57:40 +0300    

1. In heap_hot_search_buffer(), the PredicateLockTuple() call is passed  
wrong offset number. heapTuple->t_self is set to the tid of the first  
tuple in the chain that's visited, not the one actually being read.  
  
2. CheckForSerializableConflictIn() uses the tuple's t_ctid field  
instead of t_self to check for exiting predicate locks on the tuple. If  
the tuple was updated, but the updater rolled back, t_ctid points to the  
aborted dead tuple.  
  
Reported by Hannu Krosing. Backpatch to 9.1.  

commit   : 4750eae3504e9d74eec883434cf275657d57bd25    
  
author   : Peter Eisentraut <[email protected]>    
date     : Mon, 7 Oct 2013 16:27:04 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Mon, 7 Oct 2013 16:27:04 -0400    

commit   : ef388b65a8b0aad40146ab9e45fe64b405396c7e    
  
author   : Kevin Grittner <[email protected]>    
date     : Mon, 7 Oct 2013 14:26:54 -0500    
  
committer: Kevin Grittner <[email protected]>    
date     : Mon, 7 Oct 2013 14:26:54 -0500    

If a tuple was frozen while its predicate locks mattered,  
read-write dependencies could be missed, resulting in failure to  
detect conflicts which could lead to anomalies in committed  
serializable transactions.  
  
This field was added to the tag when we still thought that it was  
necessary to carry locks forward to a new version of an updated  
row.  That was later proven to be unnecessary, which allowed  
simplification of the code, but elimination of xmin from the tag  
was missed at the time.  
  
Per report and analysis by Heikki Linnakangas.  
Backpatch to 9.1.  

commit   : 9598134e3030a883ff6eea8a822466ce5143ffeb    
  
author   : Andrew Dunstan <[email protected]>    
date     : Sun, 6 Oct 2013 23:03:57 -0400    
  
committer: Andrew Dunstan <[email protected]>    
date     : Sun, 6 Oct 2013 23:03:57 -0400    

Cédric Villemain and me.  

commit   : 6f85b317d6cc4638dc88175ec4721114dab42153    
  
author   : Bruce Momjian <[email protected]>    
date     : Sat, 5 Oct 2013 10:18:02 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Sat, 5 Oct 2013 10:18:02 -0400    

Mention that link mode uses less disk space, and uses junction points on  
Windows.  
  
Backpatch to 9.3.  

commit   : 3078f2143194c6247a56cf7019c206cde5c2532c    
  
author   : Alvaro Herrera <[email protected]>    
date     : Fri, 4 Oct 2013 14:25:30 -0300    
  
committer: Alvaro Herrera <[email protected]>    
date     : Fri, 4 Oct 2013 14:25:30 -0300    

commit   : 0ac659d4a5a57278cc6c840d4ae64e8e142714e3    
  
author   : Alvaro Herrera <[email protected]>    
date     : Fri, 4 Oct 2013 14:24:46 -0300    
  
committer: Alvaro Herrera <[email protected]>    
date     : Fri, 4 Oct 2013 14:24:46 -0300    

Also, make sure they pass on all transaction isolation levels.  

commit   : eb8a811c5a0d91f53995f0d21ca88adf4eb6d1be    
  
author   : Alvaro Herrera <[email protected]>    
date     : Fri, 4 Oct 2013 10:32:48 -0300    
  
committer: Alvaro Herrera <[email protected]>    
date     : Fri, 4 Oct 2013 10:32:48 -0300    

Previously, isolationtester would forbid returning tuples in  
session-specific teardown (but not global teardown), as well as in  
global setup.  Allow these places to return tuples, too.  

commit   : e632b6b594dfde066ad514e3fcd4ac1b3aa4803f    
  
author   : Peter Eisentraut <[email protected]>    
date     : Wed, 2 Oct 2013 21:33:26 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Wed, 2 Oct 2013 21:33:26 -0400    

commit   : 513251832e0c07f6e174315d8bcf37568c94687c    
  
author   : Magnus Hagander <[email protected]>    
date     : Wed, 2 Oct 2013 16:42:36 +0200    
  
committer: Magnus Hagander <[email protected]>    
date     : Wed, 2 Oct 2013 16:42:36 +0200    

commit   : ecce2618a9c8aba46272d77412dfe02a9224ea69    
  
author   : Alvaro Herrera <[email protected]>    
date     : Tue, 1 Oct 2013 17:36:15 -0300    
  
committer: Alvaro Herrera <[email protected]>    
date     : Tue, 1 Oct 2013 17:36:15 -0300    

With the PGXS boilerplate in place, pg_xlogdump currently fails with an  
ominous error message that certain targets cannot be built because  
certain files do not exist.  Remove that and instead throw a quick error  
message alerting the user of the actual problem, which should be easier  
to diagnose that the statu quo.  
  
Andres Freund  

commit   : d794eae6135b3bb43b54498e95253aa43d776905    
  
author   : Andrew Dunstan <[email protected]>    
date     : Mon, 30 Sep 2013 11:33:54 -0400    
  
committer: Andrew Dunstan <[email protected]>    
date     : Mon, 30 Sep 2013 11:33:54 -0400    

Error noted by Andres Freund.  

commit   : 7f165f2587f6dafe7d4d438136dd959ed5610979    
  
author   : Andrew Dunstan <[email protected]>    
date     : Mon, 30 Sep 2013 10:17:30 -0400    
  
committer: Andrew Dunstan <[email protected]>    
date     : Mon, 30 Sep 2013 10:17:30 -0400    

Push dependency on installdirs down to individual targets.  
  
Christoph Berg  

commit   : f609d074385e87688c93966e57e9229a889d5f95    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Mon, 30 Sep 2013 11:29:09 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Mon, 30 Sep 2013 11:29:09 +0300    

lo_open registers the currently active snapshot, and checks if the  
large object exists after that. Normally, snapshots registered by lo_open  
are unregistered at end of transaction when the lo descriptor is closed, but  
if we error out before the lo descriptor is added to the list of open  
descriptors, it is leaked. Fix by moving the snapshot registration to after  
checking if the large object exists.  
  
Reported by Pavel Stehule. Backpatch to 8.4. The snapshot registration  
system was introduced in 8.4, so prior versions are not affected (and not  
supported, anyway).  

commit   : 311be2aa054725ded78040c63459480c755bef11    
  
author   : Andrew Dunstan <[email protected]>    
date     : Sun, 29 Sep 2013 22:46:30 -0400    
  
committer: Andrew Dunstan <[email protected]>    
date     : Sun, 29 Sep 2013 22:46:30 -0400    

commit   : 83e83aad562ce8a3e44335314a933528824dc521    
  
author   : Andrew Dunstan <[email protected]>    
date     : Sun, 29 Sep 2013 17:41:56 -0400    
  
committer: Andrew Dunstan <[email protected]>    
date     : Sun, 29 Sep 2013 17:41:56 -0400    

This should have been done when the json functionality was added to  
hstore in 9.3.0. To handle this correctly, the upgrade script therefore  
uses conditional logic by using plpgsql in a DO statement to add the two  
new functions and the new cast. If hstore_to_json_loose is detected as  
already present and dependent on the hstore extension nothing is done.  
This will require that the database be loaded with plpgsql.  
  
People who have installed the earlier and spurious 1.1 version of hstore  
will need to do:  
  
	ALTER EXTENSION hstore UPDATE;  
  
to pick up the new functions properly.  

commit   : f8110c5f66ad079e3dbc0b66bed06207c43643ef    
  
author   : Andrew Dunstan <[email protected]>    
date     : Sun, 29 Sep 2013 17:28:16 -0400    
  
committer: Andrew Dunstan <[email protected]>    
date     : Sun, 29 Sep 2013 17:28:16 -0400    

This is a backpatch of commits d942f9d9, 82b01026, and 6697aa2bc, back  
to release 9.1 where we introduced extensions which make heavy use of  
the PGXS infrastructure.  

commit   : 32d860285240df0ecbc2ce32ebaeeaefab4f836c    
  
author   : Andrew Dunstan <[email protected]>    
date     : Thu, 26 Sep 2013 17:46:07 -0400    
  
committer: Andrew Dunstan <[email protected]>    
date     : Thu, 26 Sep 2013 17:46:07 -0400    

The behaviour in json_populate_record() and json_populate_recordset()  
was changed during development but the docs were not.  

commit   : 5bdf02cd2999ddce23340efd1297cc683978816d    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Thu, 26 Sep 2013 11:24:40 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Thu, 26 Sep 2013 11:24:40 +0300    

There is a rare race condition, when a transaction that inserted a tuple  
aborts while vacuum is processing the page containing the inserted tuple.  
Vacuum prunes the page first, which normally removes any dead tuples, but  
if the inserting transaction aborts right after that, the loop after  
pruning will see a dead tuple and remove it instead. That's OK, but if the  
page is on a table with no indexes, and the page becomes completely empty  
after removing the dead tuple (or tuples) on it, it will be immediately  
marked as all-visible. That's OK, but the sanity check in vacuum would  
throw a warning because it thinks that the page contains dead tuples and  
was nevertheless marked as all-visible, even though it just vacuumed away  
the dead tuples and so it doesn't actually contain any.  
  
Spotted this while reading the code. It's difficult to hit the race  
condition otherwise, but can be done by putting a breakpoint after the  
heap_page_prune() call.  
  
Backpatch all the way to 8.4, where this code first appeared.  

commit   : 33936752829e3c6d4c463f3c974968b225304571    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Wed, 25 Sep 2013 16:02:00 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Wed, 25 Sep 2013 16:02:00 +0300    

B-tree operators are not allowed to leak memory into the current memory  
context. Range_cmp leaked detoasted copies of the arguments. That caused  
a quick out-of-memory error when creating an index on a range column.  
  
Reported by Marian Krucina, bug #8468.  

commit   : ea9a2bcea3a3372b7f296b1095aeebf65c27f32a    
  
author   : Alvaro Herrera <[email protected]>    
date     : Tue, 24 Sep 2013 18:19:14 -0300    
  
committer: Alvaro Herrera <[email protected]>    
date     : Tue, 24 Sep 2013 18:19:14 -0300    

commit   : 98a746c1ea7b134d997570adae6bf84da78b7a2a    
  
author   : Noah Misch <[email protected]>    
date     : Mon, 23 Sep 2013 16:00:13 -0400    
  
committer: Noah Misch <[email protected]>    
date     : Mon, 23 Sep 2013 16:00:13 -0400    

Though @libdir@ almost always matches @abs_builddir@ in this context,  
the test could only fail if they differed.  Back-patch to 9.1, where the  
test was introduced.  
  
Hamid Quddus Akhtar  

commit   : faf29715787a6ad835085643b378586d129bd247    
  
author   : Robert Haas <[email protected]>    
date     : Mon, 23 Sep 2013 14:57:01 -0400    
  
committer: Robert Haas <[email protected]>    
date     : Mon, 23 Sep 2013 14:57:01 -0400    

Mike Blackwell and Robert Haas  

commit   : 73c4e527a4d264d632ef29708a13b53883600ff5    
  
author   : Stephen Frost <[email protected]>    
date     : Mon, 23 Sep 2013 08:33:41 -0400    
  
committer: Stephen Frost <[email protected]>    
date     : Mon, 23 Sep 2013 08:33:41 -0400    

In libpq, we set up and pass to OpenSSL callback routines to handle  
locking.  When we run out of SSL connections, we try to clean things  
up by de-registering the hooks.  Unfortunately, we had a few calls  
into the OpenSSL library after these hooks were de-registered during  
SSL cleanup which lead to deadlocking.  This moves the thread callback  
cleanup to be after all SSL-cleanup related OpenSSL library calls.  
I've been unable to reproduce the deadlock with this fix.  
  
In passing, also move the close_SSL call to be after unlocking our  
ssl_config mutex when in a failure state.  While it looks pretty  
unlikely to be an issue, it could have resulted in deadlocks if we  
ended up in this code path due to something other than SSL_new  
failing.  Thanks to Heikki for pointing this out.  
  
Back-patch to all supported versions; note that the close_SSL issue  
only goes back to 9.0, so that hunk isn't included in the 8.4 patch.  
  
Initially found and reported by Vesa-Matti J Kari; many thanks to  
both Heikki and Andres for their help running down the specific  
issue and reviewing the patch.  

commit   : 62ff6556ab588a05259b33bd1a9d663fad96648b    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Mon, 23 Sep 2013 10:17:52 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Mon, 23 Sep 2013 10:17:52 +0300    

When a timeline history file is fetched from server, it is initially created  
with a temporary file name, and renamed to place. However, the temporary  
file name was constructed using an uninitialized buffer. Usually that meant  
that the file was created in current directory instead of the target, which  
usually goes unnoticed, but if the target is on a different filesystem than  
the current dir, the rename() would fail. Fix that.  
  
The second issue is that pg_receivexlog would not take .partial files into  
account when determining when scanning the target directory for existing  
WAL files. If the timeline has switched in the server several times in the  
last WAL segment, and pg_receivexlog is restarted, it would choose a too  
old starting point. That's not a problem as long as the old WAL segment  
exists in the server and can be streamed over, but will cause a failure if  
it's not.  
  
Backpatch to 9.3, where this timeline handling code was written.  
  
Analysed by Andrew Gierth, bug #8453, based on a bug report on IRC.  

commit   : 3451faaec81c8d19acdb243bfc22598c33ab074d    
  
author   : Alvaro Herrera <[email protected]>    
date     : Mon, 16 Sep 2013 15:45:00 -0300    
  
committer: Alvaro Herrera <[email protected]>    
date     : Mon, 16 Sep 2013 15:45:00 -0300    

It seems to make more sense to use "cutoff multixact" terminology  
throughout the backend code; "freeze" is associated with replacing of an  
Xid with FrozenTransactionId, which is not what we do for MultiXactIds.  
  
Andres Freund  
Some adjustments by Álvaro Herrera  

commit   : 374652fb6dc53a12f79586ce0e77f1ec22d58a80    
  
author   : Noah Misch <[email protected]>    
date     : Wed, 11 Sep 2013 20:10:15 -0400    
  
committer: Noah Misch <[email protected]>    
date     : Wed, 11 Sep 2013 20:10:15 -0400    

Once the administrator has called for an immediate shutdown or a backend  
crash has triggered a reinitialization, no mere SIGINT or SIGTERM should  
change that course.  Such derailment remains possible when the signal  
arrives before quickdie() blocks signals.  That being a narrow race  
affecting most PostgreSQL signal handlers in some way, leave it for  
another patch.  Back-patch this to all supported versions.  

commit   : 1eea0ebddcea776ec771f9a3a62feb83a68b54ea    
  
author   : Michael Meskes <[email protected]>    
date     : Sun, 8 Sep 2013 12:59:43 +0200    
  
committer: Michael Meskes <[email protected]>    
date     : Sun, 8 Sep 2013 12:59:43 +0200    

Found by Coverity.  

commit   : 3560dbcaac2f0ccb796512d6daf7ff3ea5bab5f0    
  
author   : Michael Meskes <[email protected]>    
date     : Sun, 8 Sep 2013 12:49:54 +0200    
  
committer: Michael Meskes <[email protected]>    
date     : Sun, 8 Sep 2013 12:49:54 +0200    

commit   : fb843b2679d959a63f48c2f4ad52243053e1a5d4    
  
author   : Jeff Davis <[email protected]>    
date     : Wed, 4 Sep 2013 23:30:27 -0700    
  
committer: Jeff Davis <[email protected]>    
date     : Wed, 4 Sep 2013 23:30:27 -0700    

Make the examples self-contained to avoid confusion. Per bug report  
8367 from KOIZUMI Satoru.  

commit   : dacd258bf14cc78c28b7b773d0f420fd44dd543d    
  
author   : Bruce Momjian <[email protected]>    
date     : Wed, 4 Sep 2013 17:04:12 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Wed, 4 Sep 2013 17:04:12 -0400    

Backpatch to 9.3.  
  
Per suggestion from Gavan Schneider  

commit   : 69876085d69aafed0231abd39f98e2e79cdf2f60    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 3 Sep 2013 18:32:23 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 3 Sep 2013 18:32:23 -0400    

The previous coding attempted to activate all the GUC settings specified  
in SET clauses, so that the function validator could operate in the GUC  
environment expected by the function body.  However, this is problematic  
when restoring a dump, since the SET clauses might refer to database  
objects that don't exist yet.  We already have the parameter  
check_function_bodies that's meant to prevent forward references in  
function definitions from breaking dumps, so let's change CREATE FUNCTION  
to not install the SET values if check_function_bodies is off.  
  
Authors of function validators were already advised not to make any  
"context sensitive" checks when check_function_bodies is off, if indeed  
they're checking anything at all in that mode.  But extend the  
documentation to point out the GUC issue in particular.  
  
(Note that we still check the SET clauses to some extent; the behavior  
with !check_function_bodies is now approximately equivalent to what ALTER  
DATABASE/ROLE have been doing for awhile with context-dependent GUCs.)  
  
This problem can be demonstrated in all active branches, so back-patch  
all the way.  

commit   : 30b5b3b917801ff976f7d0853cc83dd9b601b986    
  
author   : Alvaro Herrera <[email protected]>    
date     : Tue, 3 Sep 2013 16:52:11 -0400    
  
committer: Alvaro Herrera <[email protected]>    
date     : Tue, 3 Sep 2013 16:52:11 -0400    

commit   : 9720164d3426b0a223208b9dc5698264cdb9e2a0    
  
author   : Greg Stark <[email protected]>    
date     : Tue, 3 Sep 2013 13:27:34 +0100    
  
committer: Greg Stark <[email protected]>    
date     : Tue, 3 Sep 2013 13:27:34 +0100    

commit   : 767de7dcd6a2305ae0c2035a43ae133dd0306501    
  
author   : Robert Haas <[email protected]>    
date     : Tue, 3 Sep 2013 11:16:37 -0400    
  
committer: Robert Haas <[email protected]>    
date     : Tue, 3 Sep 2013 11:16:37 -0400    

MauMau