PostgreSQL 10.9 (upcoming) commit log

Fix ordering of GRANT commands in pg_dumpall for database creation

commit   : 0c2a5a86263c07ed1ae7a2fa032e0412961e412e    
author   : Michael Paquier <>    
date     : Wed, 22 May 2019 14:48:30 +0900    
committer: Michael Paquier <>    
date     : Wed, 22 May 2019 14:48:30 +0900    

Click here for diff

This uses a method similar to 68a7c24f, which guarantees that GRANT  
commands using the WITH GRANT OPTION are dumped in a way so as cascading  
dependencies are respected.  As databases do not have support for  
initial privileges via pg_init_privs, we need to repeat again the same  
ACL reordering method.  
ACL for databases have been moved from pg_dumpall to pg_dump in v11, so  
this impacts pg_dump for v11 and above, and pg_dumpall for v9.6 and  
Author: Nathan Bossart  
Reviewed-by: Haribabu Kommi  
Backpatch-through: 9.6  

M src/bin/pg_dump/pg_dumpall.c

Fix some grammar in documentation of spgist and pgbench

commit   : 7f920b8f71aa2083ca6eaf0f254e3a68be3f208d    
author   : Michael Paquier <>    
date     : Mon, 20 May 2019 09:48:37 +0900    
committer: Michael Paquier <>    
date     : Mon, 20 May 2019 09:48:37 +0900    

Click here for diff

Author: Liudmila Mantrova  
Reviewed-by: Jonathan Katz, Tom Lane, Michael Paquier  
Backpatch-through: 9.4  

M doc/src/sgml/ref/pgbench.sgml
M doc/src/sgml/spgist.sgml

Revert “In the pg_upgrade test suite, don’t write to src/test/regress.”

commit   : e0a39a1d9a15da5c9a4bdb7d2599ad8499a02b39    
author   : Noah Misch <>    
date     : Sun, 19 May 2019 15:24:42 -0700    
committer: Noah Misch <>    
date     : Sun, 19 May 2019 15:24:42 -0700    

Click here for diff

This reverts commit bd1592e8570282b1650af6b8eede0016496daecd.  It had  
multiple defects.  

M src/bin/pg_upgrade/
M src/test/regress/input/largeobject.source
M src/test/regress/output/largeobject.source
M src/test/regress/output/largeobject_1.source
M src/tools/msvc/

In the pg_upgrade test suite, don’t write to src/test/regress.

commit   : 422584caf32fa0477272447fd3f3851211310a6e    
author   : Noah Misch <>    
date     : Sun, 19 May 2019 14:36:44 -0700    
committer: Noah Misch <>    
date     : Sun, 19 May 2019 14:36:44 -0700    

Click here for diff

When this suite runs installcheck, redirect file creations from  
src/test/regress to src/bin/pg_upgrade/tmp_check/regress.  This closes a  
race condition in "make -j check-world".  If the pg_upgrade suite wrote  
to a given src/test/regress/results file in parallel with the regular  
src/test/regress invocation writing it, a test failed spuriously.  Even  
without parallelism, in "make -k check-world", the suite finishing  
second overwrote the other's regression.diffs.  This revealed test  
"largeobject" assuming @abs_builddir@ is getcwd(), so fix that, too.  
Buildfarm client REL_10, released forty-five days ago, supports saving  
regression.diffs from its new location.  When an older client reports a  
pg_upgradeCheck failure, it will no longer include regression.diffs.  
Back-patch to 9.5, where pg_upgrade moved to src/bin.  
Reviewed by Andrew Dunstan.  

M src/bin/pg_upgrade/
M src/test/regress/input/largeobject.source
M src/test/regress/output/largeobject.source
M src/test/regress/output/largeobject_1.source
M src/tools/msvc/

Add isolation test for INSERT ON CONFLICT speculative insertion failure.

commit   : 04595960a0a7c8844198668186bec2a6115244e0    
author   : Andres Freund <>    
date     : Tue, 14 May 2019 11:45:40 -0700    
committer: Andres Freund <>    
date     : Tue, 14 May 2019 11:45:40 -0700    

Click here for diff

This path previously was not reliably covered. There was some  
heuristic coverage via insert-conflict-toast.spec, but that test is  
not deterministic, and only tested for a somewhat specific bug.  
Backpatch, as this is a complicated and otherwise untested code  
path. Unfortunately 9.5 cannot handle two waiting sessions, and thus  
cannot execute this test.  
Triggered by a conversion with Melanie Plageman.  
Author: Andres Freund  
Backpatch: 9.5-  

A src/test/isolation/expected/insert-conflict-specconflict.out
M src/test/isolation/isolation_schedule
A src/test/isolation/specs/insert-conflict-specconflict.spec

Fix comment on when HOT update is possible.

commit   : d7bf9ad8431700763a135710e2685317c67e25bc    
author   : Heikki Linnakangas <>    
date     : Tue, 14 May 2019 13:09:28 +0300    
committer: Heikki Linnakangas <>    
date     : Tue, 14 May 2019 13:09:28 +0300    

Click here for diff

The conditions listed in this comment have changed several times, and at  
some point the thing that the "if so" referred to was negated.  
The text was OK up to 9.6. It was differently wrong in v10, v11 and  
master, so fix in all those versions.  

M src/backend/access/heap/heapam.c

Doc: Refer to line pointers as item identifiers.

commit   : 0569f047e8d65f1ed08280bc9ad535cfbbe0829a    
author   : Peter Geoghegan <>    
date     : Mon, 13 May 2019 15:39:03 -0700    
committer: Peter Geoghegan <>    
date     : Mon, 13 May 2019 15:39:03 -0700    

Click here for diff

An upcoming HEAD-only patch will standardize the terminology around  
ItemIdData variables/line pointers, ending the practice of referring to  
them as "item pointers".  Make the "Database Page Layout" docs  
consistent with the new policy.  The term "item identifier" is already  
used in the same section, so stick with that.  
Backpatch: All supported branches.  

M doc/src/sgml/storage.sgml

Fix logical replication’s ideas about which type OIDs are built-in.

commit   : 3b505036a129af5bbbf40a00f8997fc15438bb38    
author   : Tom Lane <>    
date     : Mon, 13 May 2019 17:23:00 -0400    
committer: Tom Lane <>    
date     : Mon, 13 May 2019 17:23:00 -0400    

Click here for diff

Only hand-assigned type OIDs should be presumed to match across different  
PG servers; those assigned during or during initdb are likely  
to change due to addition or removal of unrelated objects.  
This means that the cutoff should be FirstGenbkiObjectId (in HEAD)  
or FirstBootstrapObjectId (before that), not FirstNormalObjectId.  
Compare postgres_fdw's is_builtin() test.  
It's likely that this error has no observable consequence in a  
normally-functioning system, since ATM the only affected type OIDs are  
system catalog rowtypes and information_schema types, which would not  
typically be interesting for logical replication.  But you could  
probably break it if you tried hard, so back-patch.  

M src/backend/replication/logical/relation.c
M src/backend/replication/pgoutput/pgoutput.c

Fix misuse of an integer as a bool.

commit   : e3bf3c0f8c9c880ba808bc11c2825ecba720e4ed    
author   : Tom Lane <>    
date     : Mon, 13 May 2019 10:53:19 -0400    
committer: Tom Lane <>    
date     : Mon, 13 May 2019 10:53:19 -0400    

Click here for diff

pgtls_read_pending is declared to return bool, but what the underlying  
SSL_pending function returns is a count of available bytes.  
This is actually somewhat harmless if we're using C99 bools, but in  
the back branches it's a live bug: if the available-bytes count happened  
to be a multiple of 256, it would get converted to a zero char value.  
On machines where char is signed, counts of 128 and up could misbehave  
as well.  The net effect is that when using SSL, libpq might block  
waiting for data even though some has already been received.  
Broken by careless refactoring in commit 4e86f1b16, so back-patch  
to 9.5 where that came in.  
Per bug #15802 from David Binderman.  

M src/interfaces/libpq/fe-misc.c
M src/interfaces/libpq/fe-secure-openssl.c

postgres_fdw: Fix typo in comment.

commit   : 7c16a2bfdcd8d477c8ff39c5eeb7d3b87fe0d60b    
author   : Etsuro Fujita <>    
date     : Mon, 13 May 2019 17:30:38 +0900    
committer: Etsuro Fujita <>    
date     : Mon, 13 May 2019 17:30:38 +0900    

Click here for diff

M contrib/postgres_fdw/postgres_fdw.c

Fix misoptimization of “{1,1}” quantifiers in regular expressions.

commit   : 940f6479257d5ad297d08d9a205d057b108dca92    
author   : Tom Lane <>    
date     : Sun, 12 May 2019 18:53:13 -0400    
committer: Tom Lane <>    
date     : Sun, 12 May 2019 18:53:13 -0400    

Click here for diff

A bounded quantifier with m = n = 1 might be thought a no-op.  But  
according to our documentation (which traces back to Henry Spencer's  
original man page) it still imposes greediness, or non-greediness in the  
case of the non-greedy variant "{1,1}?", on whatever it's attached to.  
This turns out not to work though, because parseqatom() optimizes away  
the m = n = 1 case without regard for whether it's supposed to change  
the greediness of the argument RE.  
We can fix this by just not applying the optimization when the greediness  
needs to change; the subsequent general cases handle it fine.  
The three cases in which we can still apply the optimization are  
(a) no quantifier, or quantifier does not impose a preference;  
(b) atom has no greediness property, implying it cannot match a  
variable amount of text anyway; or  
(c) quantifier's greediness is same as atom's.  
Note that in most cases where one of these applies, we'd have exited  
earlier in the "not a messy case" fast path.  I think it's now only  
possible to get to the optimization when the atom involves capturing  
parentheses or a non-top-level backref.  
Back-patch to all supported branches.  I'd ordinarily be hesitant to  
put a subtle behavioral change into back branches, but in this case  
it's very hard to see a reason why somebody would write "{1,1}?" unless  
they're trying to get the documented change-of-greediness behavior.  

M src/backend/regex/regcomp.c
M src/test/regress/expected/regex.out
M src/test/regress/sql/regex.sql

Fail pgwin32_message_to_UTF16() for SQL_ASCII messages.

commit   : 409f5303ced62246d36cabb8d4c5da5f7ce7f376    
author   : Noah Misch <>    
date     : Sun, 12 May 2019 10:33:05 -0700    
committer: Noah Misch <>    
date     : Sun, 12 May 2019 10:33:05 -0700    

Click here for diff

The function had been interpreting SQL_ASCII messages as UTF8, throwing  
an error when they were invalid UTF8.  The new behavior is consistent  
with pg_do_encoding_conversion().  This affects LOG_DESTINATION_STDERR  
and LOG_DESTINATION_EVENTLOG, which will send untranslated bytes to  
write() and ReportEventA().  On buildfarm member bowerbird, enabling  
log_connections caused an error whenever the role name was not valid  
UTF8.  Back-patch to 9.4 (all supported versions).  

M src/backend/utils/mb/mbutils.c
M src/bin/pg_dump/t/
M src/bin/scripts/t/

Rearrange pgstat_bestart() to avoid failures within its critical section.

commit   : c3d113136bbaa86fbf1edde7aaf70ba06a6166b7    
author   : Tom Lane <>    
date     : Sat, 11 May 2019 21:27:13 -0400    
committer: Tom Lane <>    
date     : Sat, 11 May 2019 21:27:13 -0400    

Click here for diff

We long ago decided to design the shared PgBackendStatus data structure to  
minimize the cost of writing status updates, which means that writers just  
have to increment the st_changecount field twice.  That isn't hooked into  
any sort of resource management mechanism, which means that if something  
were to throw error between the two increments, the st_changecount field  
would be left odd indefinitely.  That would cause readers to lock up.  
Now, since it's also a bad idea to leave the field odd for longer than  
absolutely necessary (because readers will spin while we have it set),  
the expectation was that we'd treat these segments like spinlock critical  
sections, with only short, more or less straight-line, code in them.  
That was fine as originally designed, but commit 9029f4b37 broke it  
by inserting a significant amount of non-straight-line code into  
pgstat_bestart(), code that is very capable of throwing errors, not to  
mention taking a significant amount of time during which readers will spin.  
We have a report from Neeraj Kumar of readers actually locking up, which  
I suspect was due to an encoding conversion error in X509_NAME_to_cstring,  
though conceivably it was just a garden-variety OOM failure.  
Subsequent commits have loaded even more dubious code into pgstat_bestart's  
critical section (and commit fc70a4b0d deserves some kind of booby prize  
for managing to miss the critical section entirely, although the negative  
consequences seem minimal given that the PgBackendStatus entry should be  
seen by readers as inactive at that point).  
The right way to fix this mess seems to be to compute all these values  
into a local copy of the process' PgBackendStatus struct, and then just  
copy the data back within the critical section proper.  This plan can't  
be implemented completely cleanly because of the struct's heavy reliance  
on out-of-line strings, which we must initialize separately within the  
critical section.  But still, the critical section is far smaller and  
safer than it was before.  
In hopes of forestalling future errors of the same ilk, rename the  
macros for st_changecount management to make it more apparent that  
the writer-side macros create a critical section.  And to prevent  
the worst consequences if we nonetheless manage to mess it up anyway,  
adjust those macros so that they really are a critical section, ie  
they now bump CritSectionCount.  That doesn't add much overhead, and  
it guarantees that if we do somehow throw an error while the counter  
is odd, it will lead to PANIC and a database restart to reset shared  
Back-patch to 9.5 where the problem was introduced.  
In HEAD, also fix an oversight in commit b0b39f72b: it failed to teach  
pgstat_read_current_status to copy st_gssstatus data from shared memory to  
local memory.  Hence, subsequent use of that data within the transaction  
would potentially see changing data that it shouldn't see.  

M src/backend/postmaster/pgstat.c
M src/include/pgstat.h

Honor TEMP_CONFIG in TAP suites.

commit   : 7a6a541234fdd929bc4a0f39538a4f05b69bc839    
author   : Noah Misch <>    
date     : Sat, 11 May 2019 00:22:38 -0700    
committer: Noah Misch <>    
date     : Sat, 11 May 2019 00:22:38 -0700    

Click here for diff

The buildfarm client uses TEMP_CONFIG to implement its extra_config  
setting.  Except for stats_temp_directory, extra_config now applies to  
TAP suites; extra_config values seen in the past month are compatible  
with this.  Back-patch to 9.6, where PostgresNode was introduced, so the  
buildfarm can rely on it sooner.  
Reviewed by Andrew Dunstan and Tom Lane.  

M src/bin/pg_ctl/t/
M src/test/perl/

Fix error reporting in reindexdb

commit   : c6354e94304ca64815683042c5c6aa524f27c9f3    
author   : Michael Paquier <>    
date     : Sat, 11 May 2019 13:01:12 +0900    
committer: Michael Paquier <>    
date     : Sat, 11 May 2019 13:01:12 +0900    

Click here for diff

When failing to reindex a table or an index, reindexdb would generate an  
extra error message related to a database failure, which is misleading.  
Backpatch all the way down, as this has been introduced by 85e9a5a0.  
Author: Julien Rouhaud  
Reviewed-by: Daniel Gustafsson, Álvaro Herrera, Tom Lane, Michael  
Backpatch-through: 9.4  

M src/bin/scripts/reindexdb.c

Cope with EINVAL and EIDRM shmat() failures in PGSharedMemoryAttach.

commit   : 3dcf45af560eeeef8d4ed4255a8d13ef16764dc4    
author   : Tom Lane <>    
date     : Fri, 10 May 2019 14:56:41 -0400    
committer: Tom Lane <>    
date     : Fri, 10 May 2019 14:56:41 -0400    

Click here for diff

There's a very old race condition in our code to see whether a pre-existing  
shared memory segment is still in use by a conflicting postmaster: it's  
possible for the other postmaster to remove the segment in between our  
shmctl() and shmat() calls.  It's a narrow window, and there's no risk  
unless both postmasters are using the same port number, but that's possible  
during parallelized "make check" tests.  (Note that while the TAP tests  
take some pains to choose a randomized port number, pg_regress doesn't.)  
If it does happen, we treated that as an unexpected case and errored out.  
To fix, allow EINVAL to be treated as segment-not-present, and the same  
for EIDRM on Linux.  AFAICS, the considerations here are basically  
identical to the checks for acceptable shmctl() failures, so I documented  
and coded it that way.  
While at it, adjust PGSharedMemoryAttach's API to remove its undocumented  
dependency on UsedShmemSegAddr in favor of passing the attach address  
explicitly.  This makes it easier to be sure we're using a null shmaddr  
when probing for segment conflicts (thus avoiding questions about what  
EINVAL means).  I don't think there was a bug there, but it required  
fragile assumptions about the state of UsedShmemSegAddr during  
Commit c09850992 may have made this failure more probable by applying  
the conflicting-segment tests more often.  Hence, back-patch to all  
supported branches, as that was.  

M src/backend/port/sysv_shmem.c

Repair issues with faulty generation of merge-append plans.

commit   : 946cdf9ff771807885f49913b789fdc282b751bc    
author   : Tom Lane <>    
date     : Thu, 9 May 2019 16:52:49 -0400    
committer: Tom Lane <>    
date     : Thu, 9 May 2019 16:52:49 -0400    

Click here for diff

create_merge_append_plan failed to honor the CP_EXACT_TLIST flag:  
it would generate the expected targetlist but then it felt free to  
add resjunk sort targets to it.  This demonstrably leads to assertion  
failures in v11 and HEAD, and it's probably just accidental that we  
don't see the same in older branches.  I've not looked into whether  
there would be any real-world consequences in non-assert builds.  
In HEAD, create_append_plan has sprouted the same problem, so fix  
that too (although we do not have any test cases that seem able to  
reach that bug).  This is an oversight in commit 3fc6e2d7f which  
invented the CP_EXACT_TLIST flag, so back-patch to 9.6 where that  
came in.  
convert_subquery_pathkeys would create pathkeys for subquery output  
values if they match any EquivalenceClass known in the outer query  
and are available in the subquery's syntactic targetlist.  However,  
the second part of that condition is wrong, because such values might  
not appear in the subquery relation's reltarget list, which would  
mean that they couldn't be accessed above the level of the subquery  
scan.  We must check that they appear in the reltarget list, instead.  
This can lead to dropping knowledge about the subquery's sort  
ordering, but I believe it's okay, because any sort key that the  
outer query actually has any interest in would appear in the  
reltarget list.  
This second issue is of very long standing, but right now there's no  
evidence that it causes observable problems before 9.6, so I refrained  
from back-patching further than that.  We can revisit that choice if  
somebody finds a way to make it cause problems in older branches.  
(Developing useful test cases for these issues is really problematic;  
fixing convert_subquery_pathkeys removes the only known way to exhibit  
the create_merge_append_plan bug, and neither of the test cases added  
by this patch causes a problem in all branches, even when considering  
the issues separately.)  
The second issue explains bug #15795 from Suresh Kumar R ("could not  
find pathkey item to sort" with nested DISTINCT queries).  I stumbled  
across the first issue while investigating that.  

M src/backend/optimizer/path/pathkeys.c
M src/backend/optimizer/plan/createplan.c
M src/test/regress/expected/union.out
M src/test/regress/sql/union.sql

Fix error status of vacuumdb when multiple jobs are used

commit   : db8802a99ed75e1f8f5ffab199cea7fb6f63a057    
author   : Michael Paquier <>    
date     : Thu, 9 May 2019 10:29:40 +0900    
committer: Michael Paquier <>    
date     : Thu, 9 May 2019 10:29:40 +0900    

Click here for diff

When running a batch of VACUUM or ANALYZE commands on a given database,  
there were cases where it is possible to have vacuumdb not report an  
error where it actually should, leading to incorrect status results.  
Author: Julien Rouhaud  
Reviewed-by: Amit Kapila, Michael Paquier  
Backpatch-through: 9.5  

M src/bin/scripts/vacuumdb.c

Fix documentation for the privileges required for replication functions.

commit   : 704637d8d935bee52f748641a0620e2e83de07d2    
author   : Fujii Masao <>    
date     : Thu, 9 May 2019 01:35:13 +0900    
committer: Fujii Masao <>    
date     : Thu, 9 May 2019 01:35:13 +0900    

Click here for diff

Previously it's documented that use of replication functions is  
restricted to superusers. This is true for the functions which  
use replication origin, but not for pg_logicl_emit_message() and  
functions which use replication slot. For example, not only  
superusers but also users with REPLICATION privilege is allowed  
to use the functions for replication slot. This commit fixes  
the documentation for the privileges required for those replication  
Back-patch to 9.4 (all supported versions).  
Author: Matsumura Ryo  

M doc/src/sgml/func.sgml

Probe only when looking for ports on Unix.

commit   : 8c7a8e19bb17e0634e21ee8edbb912dc4deb5cb0    
author   : Thomas Munro <>    
date     : Mon, 6 May 2019 15:02:41 +1200    
committer: Thomas Munro <>    
date     : Mon, 6 May 2019 15:02:41 +1200    

Click here for diff

Commit c0985099, later adjusted by commit 4ab02e81, probed  
in addition to, for the benefit of Windows build farm  
animals.  It isn't really useful on Unix systems, and turned out to  
be a bit inconvenient to users of some corporate firewall software.  
Switch back to probing just on non-Windows systems.  
Back-patch to 9.6, like the earlier changes.  

M src/test/perl/

Remove leftover reference to old “flat file” mechanism in a comment.

commit   : 9e078fed21a0d60166896ffc82b5ff4c30b118d2    
author   : Heikki Linnakangas <>    
date     : Wed, 8 May 2019 09:32:34 +0300    
committer: Heikki Linnakangas <>    
date     : Wed, 8 May 2019 09:32:34 +0300    

Click here for diff

The flat file mechanism was removed in PostgreSQL 9.0.  

M src/backend/access/transam/xact.c

commit   : 6bd3203b9e54a39805b531c3ce7e44e444c98541    
author   : Michael Paquier <>    
date     : Tue, 7 May 2019 14:20:01 +0900    
committer: Michael Paquier <>    
date     : Tue, 7 May 2019 14:20:01 +0900    

Click here for diff

This code was broken as of 582edc3, and is most likely not used anymore.  
Note that pg_dump supports servers down to 8.0, and psql has code to  
support servers down to 7.4.  
Author: Julien Rouhaud  
Reviewed-by: Tom Lane  

M src/bin/scripts/common.c