PostgreSQL 10.11 (upcoming) commit log

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

commit   : 451432214f1a9c59e59dbbcdd91e92bb69e6cd03    
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   : 60886965a271242c19e40483c82b41ff726ca24e    
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   : e3ddb112f245041565aa102e20234799e366caab    
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   : f8c9a08520eea2ea7f0197b878515d99861d6221    
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   : f2bdfebb962d117c51b60dcb63de1adcc9ee0380    
author   : Tom Lane <>    
date     : Tue, 13 Aug 2019 16:57:58 -0400    
committer: Tom Lane <>    
date     : Tue, 13 Aug 2019 16:57:58 -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 random regression failure in test case "temp"

commit   : fc8c6ae5fdebb8dc39b3d001aa332b80e0945fc2    
author   : Michael Paquier <>    
date     : Tue, 13 Aug 2019 10:56:07 +0900    
committer: Michael Paquier <>    
date     : Tue, 13 Aug 2019 10:56:07 +0900    

Click here for diff

This test case could fail because of an incorrect result ordering when  
looking up at pg_class entries.  This commit adds an ORDER BY to the  
culprit query.  The cause of the failure was likely caused by a plan  
switch.  By default, the planner would likely choose an index-only scan  
or an index scan, but even a small change in the startup cost could have  
caused a bitmap heap scan to be chosen, causing the failure.  
While on it, switch some filtering quals to a regular expression as per  
an idea of Tom Lane.  As previously shaped, the quals would have  
selected any relations whose name begins with "temp".  And that could  
cause failures if another test running in parallel began to use similar  
relation names.  
Per report from buildfarm member anole, though the failure was very  
rare.  This test has been introduced by 319a810, so backpatch down to  
Backpatch-through: 10  

M src/test/regress/expected/temp.out
M src/test/regress/sql/temp.sql

amcheck: Skip unlogged relations during recovery.

commit   : f8d2cdc12c9407f26b7872bfb0153a899a5ee299    
author   : Peter Geoghegan <>    
date     : Mon, 12 Aug 2019 15:21:27 -0700    
committer: Peter Geoghegan <>    
date     : Mon, 12 Aug 2019 15:21:27 -0700    

Click here for diff

contrib/amcheck failed to consider the possibility that unlogged  
relations will not have any main relation fork files when running in hot  
standby mode.  This led to low-level "can't happen" errors that complain  
about the absence of a relfilenode file.  
To fix, simply skip verification of unlogged index relations during  
recovery.  In passing, add a direct check for the presence of a main  
fork just before verification proper begins, so that we cleanly verify  
the presence of the main relation fork file.  
Author: Andrey Borodin, Peter Geoghegan  
Reported-By: Andrey Borodin  
Diagnosed-By: Andrey Borodin  
Backpatch: 10-, where amcheck was introduced.  

M contrib/amcheck/verify_nbtree.c

Fix compiler warning

commit   : 333a186dc52e32ce250c9d62d9dbaecbd359d651    
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

Fix planner's test for case-foldable characters in ILIKE with ICU.

commit   : 886cf85b52cfdd84c0ff9b24193c7e0e0035b1c7    
author   : Tom Lane <>    
date     : Mon, 12 Aug 2019 13:15:48 -0400    
committer: Tom Lane <>    
date     : Mon, 12 Aug 2019 13:15:48 -0400    

Click here for diff

As coded, the ICU-collation path in pattern_char_isalpha() failed  
to consider regular ASCII letters to be case-varying.  This led to  
like_fixed_prefix treating too much of an ILIKE pattern as being a  
fixed prefix, so that indexscans derived from an ILIKE clause might  
miss entries that they should find.  
Per bug #15892 from James Inform.  This is an oversight in the original  
ICU patch (commit eccfef81e), so back-patch to v10 where that came in.  

M src/backend/utils/adt/selfuncs.c
M src/test/regress/expected/
M src/test/regress/sql/

Doc: document permissions required for ANALYZE.

commit   : b3670f48d8bc83a334a97e7270c5d59f694c4126    
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 typo in comment.

commit   : dcebb3e9c7cf7836779a82fcc202af9b5266a893    
author   : Etsuro Fujita <>    
date     : Wed, 7 Aug 2019 19:05:20 +0900    
committer: Etsuro Fujita <>    
date     : Wed, 7 Aug 2019 19:05:20 +0900    

Click here for diff

M src/backend/catalog/partition.c

Fix predicate-locking of HOT updated rows.

commit   : 65468cc705ea8a329f175de7eed44163ce532482    
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   : 1ba4d0fe463eaf16bc93024d0634cf224f07a0e8    
author   : Michael Paquier <>    
date     : Wed, 7 Aug 2019 18:17:46 +0900    
committer: Michael Paquier <>    
date     : Wed, 7 Aug 2019 18:17:46 +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   : 5b3e6c13f753cb10b476bf7755b5622aef2fbdce    
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