PostgreSQL 9.6.16 (upcoming) commit log

Disallow changing an inherited column's type if not all parents changed.

commit   : 3442235f2a8d902fb3f8664dd71dfaa258ba656a    
author   : Tom Lane <>    
date     : Sun, 18 Aug 2019 17:11:58 -0400    
committer: Tom Lane <>    
date     : Sun, 18 Aug 2019 17:11:58 -0400    

Click here for diff

If a table inherits from multiple unrelated parents, we must disallow  
changing the type of a column inherited from multiple such parents, else  
it would be out of step with the other parents.  However, it's possible  
for the column to ultimately be inherited from just one common ancestor,  
in which case a change starting from that ancestor should still be  
allowed.  (I would not be excited about preserving that option, were  
it not that we have regression test cases exercising it already ...)  
It's slightly annoying that this patch looks different from the logic  
with the same end goal in renameatt(), and more annoying that it  
requires an extra syscache lookup to make the test.  However, the  
recursion logic is quite different in the two functions, and a  
back-patched bug fix is no place to be trying to unify them.  
Per report from Manuel Rigger.  Back-patch to 9.5.  The bug exists in  
9.4 too (and doubtless much further back); but the way the recursion  
is done in 9.4 is a good bit different, so that substantial refactoring  
would be needed to fix it in 9.4.  I'm disinclined to do that, or risk  
introducing new bugs, for a bug that has escaped notice for this long.  

M src/backend/commands/tablecmds.c
M src/test/regress/expected/inherit.out
M src/test/regress/sql/inherit.sql

Prevent possible double-free when update trigger returns old tuple.

commit   : 1fe8d209ed84c6d5d8e568a836719924deaa9b8b    
author   : Tom Lane <>    
date     : Thu, 15 Aug 2019 20:04:19 -0400    
committer: Tom Lane <>    
date     : Thu, 15 Aug 2019 20:04:19 -0400    

Click here for diff

This is a variant of the problem fixed in commit 25b692568, which  
unfortunately we failed to detect at the time.  If an update trigger  
returns the "old" tuple, as it's entitled to do, then a subsequent  
iteration of the loop in ExecBRUpdateTriggers would have "oldtuple"  
equal to "trigtuple" and would fail to notice that it shouldn't  
free that.  
In addition to fixing the code, extend the test case added by  
25b692568 so that it covers multiple-trigger-iterations cases.  
This problem does not manifest in v12/HEAD, as a result of the  
relevant code having been largely rewritten for slotification.  
However, include the test case into v12/HEAD anyway, since this  
is clearly an area that someone could break again in future.  
Per report from Piotr Gabriel Kosinski.  Back-patch into all  
supported branches, since the bug seems quite old.  
Diagnosis and code fix by Thomas Munro, test case by me.  

M src/backend/commands/trigger.c
M src/test/regress/expected/triggers.out
M src/test/regress/sql/triggers.sql

Doc: improve documentation about

commit   : 0969a7aa3240eaa27f6978da6870f9eef706b356    
author   : Tom Lane <>    
date     : Thu, 15 Aug 2019 11:14:26 -0400    
committer: Tom Lane <>    
date     : Thu, 15 Aug 2019 11:14:26 -0400    

Click here for diff

Clarify what external tools can do to this file, and add a bit  
of detail about what ALTER SYSTEM itself does.  

M doc/src/sgml/config.sgml

Fix ALTER SYSTEM to cope with duplicate entries in

commit   : 4784ad7a370ebdbde7aeaa9faf0f0c00b245f1a4    
author   : Tom Lane <>    
date     : Wed, 14 Aug 2019 15:09:20 -0400    
committer: Tom Lane <>    
date     : Wed, 14 Aug 2019 15:09:20 -0400    

Click here for diff

ALTER SYSTEM itself normally won't make duplicate entries (although  
up till this patch, it was possible to confuse it by writing case  
variants of a GUC's name).  However, if some external tool has appended  
entries to the file, that could result in duplicate entries for a single  
GUC name.  In such a situation, ALTER SYSTEM did exactly the wrong thing,  
because it replaced or removed only the first matching entry, leaving  
the later one(s) still there and hence still determining the active value.  
This patch fixes that by making ALTER SYSTEM sweep through the file and  
remove all matching entries, then (if not ALTER SYSTEM RESET) append the  
new setting to the end.  This means entries will be in order of last  
setting rather than first setting, but that shouldn't hurt anything.  
Also, make the comparisons case-insensitive so that the right things  
happen if you do, say, ALTER SYSTEM SET "TimeZone" = 'whatever'.  
This has been broken since ALTER SYSTEM was invented, so back-patch  
to all supported branches.  
Ian Barwick, with minor mods by me  

M src/backend/utils/misc/guc.c

Un-break pg_dump for pre-8.3 source servers.

commit   : 2b608ba313147553370b233f031f84f0ed77df3f    
author   : Tom Lane <>    
date     : Tue, 13 Aug 2019 16:57:59 -0400    
committer: Tom Lane <>    
date     : Tue, 13 Aug 2019 16:57:59 -0400    

Click here for diff

Commit 07b39083c inserted an unconditional reference to pg_opfamily,  
which of course fails on servers predating that catalog.  Fortunately,  
the case it's trying to solve can't occur on such old servers (AFAIK).  
Hence, just skip the additional code when the source predates 8.3.  
Per bug #15955 from sly.  Back-patch to all supported branches,  
like the previous patch.  

M src/bin/pg_dump/pg_dump.c

Fix compiler warning

commit   : 99493bcbe79dcc0c6efb59af25aca86baf649ab2    
author   : Peter Eisentraut <>    
date     : Mon, 12 Aug 2019 21:20:14 +0200    
committer: Peter Eisentraut <>    
date     : Mon, 12 Aug 2019 21:20:14 +0200    

Click here for diff

With some newer gcc versions (8 and 9) you get a -Wformat-overflow  
warning here.  In PG11 and later this was already fixed.  Since it's  
trivial, backport it to get the older branches building without  

M src/bin/pgbench/pgbench.c

Doc: document permissions required for ANALYZE.

commit   : 5ce3b55520538ff9efeef4f36536e3c893413a30    
author   : Tom Lane <>    
date     : Wed, 7 Aug 2019 18:09:28 -0400    
committer: Tom Lane <>    
date     : Wed, 7 Aug 2019 18:09:28 -0400    

Click here for diff

VACUUM's reference page had this text, but ANALYZE's didn't.  That's  
a clear oversight given that section 5.7 explicitly delegates the  
responsibility to define permissions requirements to the individual  
commands' man pages.  
Per gripe from Isaac Morland.  Back-patch to all supported branches.  

M doc/src/sgml/ref/analyze.sgml

Fix predicate-locking of HOT updated rows.

commit   : 75774cc221e50a408267a1f09af7f09f44999c0b    
author   : Heikki Linnakangas <>    
date     : Wed, 7 Aug 2019 12:40:49 +0300    
committer: Heikki Linnakangas <>    
date     : Wed, 7 Aug 2019 12:40:49 +0300    

Click here for diff

In serializable mode, heap_hot_search_buffer() incorrectly acquired a  
predicate lock on the root tuple, not the returned tuple that satisfied  
the visibility checks. As explained in README-SSI, the predicate lock does  
not need to be copied or extended to other tuple versions, but for that to  
work, the correct, visible, tuple version must be locked in the first  
The original SSI commit had this bug in it, but it was fixed back in 2013,  
in commit 81fbbfe335. But unfortunately, it was reintroduced a few months  
later in commit b89e151054. Wising up from that, add a regression test  
to cover this, so that it doesn't get reintroduced again. Also, move the  
code that sets 't_self', so that it happens at the same time that the  
other HeapTuple fields are set, to make it more clear that all the code in  
the loop operate on the "current" tuple in the chain, not the root tuple.  
Bug spotted by Andres Freund, analysis and original fix by Thomas Munro,  
test case and some additional changes to the fix by Heikki Linnakangas.  
Backpatch to all supported versions (9.4).  

M src/backend/access/heap/heapam.c
A src/test/isolation/expected/predicate-lock-hot-tuple.out
M src/test/isolation/isolation_schedule
A src/test/isolation/specs/predicate-lock-hot-tuple.spec

Fix some incorrect parsing of time with time zone strings

commit   : 7c64a2cd9446629493aadb9620e1ff77597ec27d    
author   : Michael Paquier <>    
date     : Wed, 7 Aug 2019 18:17:52 +0900    
committer: Michael Paquier <>    
date     : Wed, 7 Aug 2019 18:17:52 +0900    

Click here for diff

When parsing a timetz string with a dynamic timezone abbreviation or a  
timezone not specified, it was possible to generate incorrect timestamps  
based on a date which uses some non-initialized variables if the input  
string did not specify fully a date to parse.  This is already checked  
when a full timezone spec is included in the input string, but the two  
other cases mentioned above missed the same checks.  
This gets fixed by generating an error as this input is invalid, or in  
short when a date is not fully specified.  
Valgrind was complaining about this problem.  
Bug: #15910  
Author: Alexander Lakhin  
Backpatch-through: 9.4  

M src/backend/utils/adt/datetime.c
M src/test/regress/expected/timetz.out
M src/test/regress/sql/timetz.sql

Fix intarray's GiST opclasses to not fail for empty arrays with <@.

commit   : e519eded65304be125787908a9343eee66a01860    
author   : Tom Lane <>    
date     : Tue, 6 Aug 2019 18:04:51 -0400    
committer: Tom Lane <>    
date     : Tue, 6 Aug 2019 18:04:51 -0400    

Click here for diff

contrib/intarray considers "arraycol <@ constant-array" to be indexable,  
but its GiST opclass code fails to reliably find index entries for empty  
array values (which of course should trivially match such queries).  
This is because the test condition to see whether we should descend  
through a non-leaf node is wrong.  
Unfortunately, empty array entries could be anywhere in the index,  
as these index opclasses are currently designed.  So there's no way  
to fix this except by lobotomizing <@ indexscans to scan the whole  
index ... which is what this patch does.  That's pretty unfortunate:  
the performance is now actually worse than a seqscan, in most cases.  
We'd be better off to remove <@ from the GiST opclasses entirely,  
and perhaps a future non-back-patchable patch will do so.  
In the meantime, applications whose performance is adversely impacted  
have a couple of options.  They could switch to a GIN index, which  
doesn't have this bug, or they could replace "arraycol <@ constant-array"  
with "arraycol <@ constant-array AND arraycol && constant-array".  
That will provide about the same performance as before, and it will find  
all non-empty subsets of the given constant-array, which is all that  
could reliably be expected of the query before.  
While at it, add some more regression test cases to improve code  
coverage of contrib/intarray.  
In passing, adjust resize_intArrayType so that when it's returning an  
empty array, it uses construct_empty_array for that rather than  
cowboy hacking on the input array.  While the hack produces an array  
that looks valid for most purposes, it isn't bitwise equal to empty  
arrays produced by other code paths, which could have subtle odd  
effects.  I don't think this code path is performance-critical  
enough to justify such shortcuts.  (Back-patch this part only as far  
as v11; before commit 01783ac36 we were not careful about this in  
other intarray code paths either.)  
Back-patch the <@ fixes to all supported versions, since this was  
broken from day one.  
Patch by me; thanks to Alexander Korotkov for review.  

M contrib/intarray/_int_gist.c
M contrib/intarray/_intbig_gist.c
M contrib/intarray/expected/_int.out
M contrib/intarray/sql/_int.sql