PostgreSQL 11.6 commit log

commit   : 34f805c8cf1bc4d54075526d3b023d9194ccd2cd    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 11 Nov 2019 17:05:05 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 11 Nov 2019 17:05:05 -0500    

commit   : b3c762a45a14e119acf371f60eb01c8d3607f714    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 11 Nov 2019 14:39:54 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 11 Nov 2019 14:39:54 -0500    

The example of expansion of multiple views claimed that the resulting  
subquery nest would not get fully flattened because of an aggregate  
function.  There's no aggregate in the example, though, only a user  
defined function confusingly named MIN().  In a modern server, the  
reason for the non-flattening is that MIN() is volatile, but I'm  
unsure whether that was true back when this text was written.  
  
Let's reduce the confusion level by using LEAST() instead (which  
we didn't have at the time this example was created).  And then  
we can just say that the planner will flatten the sub-queries, so  
the rewrite system doesn't have to.  
  
Noted by Paul Jungwirth.  This text is old enough to vote, so  
back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/CA+renyXZFnmp9PcvX1EVR2dR=XG5e6E-AELr8AHCNZ8RYrpnPw@mail.gmail.com  

commit   : e72b6c39f0fb455b48632afa0c6e3bed9ecf941e    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 11 Nov 2019 10:33:00 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 11 Nov 2019 10:33:00 -0500    

Commits 4ea03f3f4 et al arranged to filter out row counts in parallel  
plans, because those are dependent on the number of workers actually  
obtained.  Somehow I missed that the 'Rows Removed by Filter' counts  
can also vary, so fix that too.  Per buildfarm.  
  
This seems worth a last-minute patch because unreliable regression  
tests are a serious pain in the rear for packagers.  
  
Like the previous patch, back-patch to v11 where this test was  
introduced.  

commit   : 5b41fc1e0f57e655281097a633c0917472c3fe4d    
  
author   : Peter Eisentraut <[email protected]>    
date     : Mon, 11 Nov 2019 10:50:22 +0100    
  
committer: Peter Eisentraut <[email protected]>    
date     : Mon, 11 Nov 2019 10:50:22 +0100    

Source-Git-URL: https://git.postgresql.org/git/pgtranslation/messages.git  
Source-Git-Hash: 36cb12a154ee719a594401e7f8763e472f41614a  

commit   : 8cf280f6db75f046ca7de71f3ad0f0adcf63cd41    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 10 Nov 2019 18:31:13 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 10 Nov 2019 18:31:13 -0500    

commit   : aa988457848fc153bfc85b4d240c0a020f9cdfe8    
  
author   : Peter Eisentraut <[email protected]>    
date     : Sat, 9 Nov 2019 13:19:27 +0100    
  
committer: Peter Eisentraut <[email protected]>    
date     : Sat, 9 Nov 2019 13:19:27 +0100    

After altering a subscription, we should wait until the updated table  
sync data has been fetched by the subscriber.  

commit   : f77be47d339898aeab97ba3fb6c649512e34cab7    
  
author   : Peter Eisentraut <[email protected]>    
date     : Sat, 9 Nov 2019 10:13:14 +0100    
  
committer: Peter Eisentraut <[email protected]>    
date     : Sat, 9 Nov 2019 10:13:14 +0100    

The previous statement that using a passphrase disables the ability to  
change the server's SSL configuration without a server restart was no  
longer completely true since the introduction of  
ssl_passphrase_command_supports_reload.  

commit   : 7961da1887afb04184fd9169dec01870d1003d4a    
  
author   : Peter Eisentraut <[email protected]>    
date     : Thu, 7 Nov 2019 13:48:59 +0100    
  
committer: Peter Eisentraut <[email protected]>    
date     : Thu, 7 Nov 2019 13:48:59 +0100    

This happens when we add a replica identity column on a subscriber  
that does not yet exist on the publisher, according to the mapping  
maintained by the subscriber.  Code that checks whether the target  
relation on the subscriber is updatable would check the replica  
identity attribute bitmap with a column number -1, which would result  
in an error.  To fix, skip such columns in the bitmap lookup and  
consider the relation not updatable.  The result is consistent with  
the rule that the replica identity columns on the subscriber must be a  
subset of those on the publisher, since if the column doesn't exist on  
the publisher, the column set on the subscriber can't be a subset.  
  
Reported-by: Tim Clarke <[email protected]>  
Analyzed-by: Jehan-Guillaume de Rorthais <[email protected]>  
Discussion: https://www.postgresql.org/message-id/flat/a9139c29-7ddd-973b-aa7f-71fed9c38d75%40minerva.info  

commit   : c125bc8995dfdf905ba146550a14867a17982425    
  
author   : Peter Eisentraut <[email protected]>    
date     : Fri, 8 Nov 2019 18:12:51 +0100    
  
committer: Peter Eisentraut <[email protected]>    
date     : Fri, 8 Nov 2019 18:12:51 +0100    

commit   : 042e82cef949b3d0acf04431c25e7ee0e1535456    
  
author   : Etsuro Fujita <[email protected]>    
date     : Fri, 8 Nov 2019 17:00:32 +0900    
  
committer: Etsuro Fujita <[email protected]>    
date     : Fri, 8 Nov 2019 17:00:32 +0900    

Currently, postgres_fdw does not support preparing a remote transaction  
for two-phase commit even in the case where the remote transaction is  
read-only, but the old error message appeared to imply that that was not  
supported only if the remote transaction modified remote tables.  Change  
the message so as to include the case where the remote transaction is  
read-only.  
  
Also fix a comment above the message.  
  
Also add a note about the lack of supporting PREPARE TRANSACTION to the  
postgres_fdw documentation.  
  
Reported-by: Gilles Darold  
Author: Gilles Darold and Etsuro Fujita  
Reviewed-by: Michael Paquier and Kyotaro Horiguchi  
Backpatch-through: 9.4  
Discussion: https://postgr.es/m/08600ed3-3084-be70-65ba-279ab19618a5%40darold.net  

commit   : 353647fd93c0ce871e6da3cc785220fcac17985e    
  
author   : Bruce Momjian <[email protected]>    
date     : Thu, 7 Nov 2019 15:49:59 -0500    
  
committer: Bruce Momjian <[email protected]>    
date     : Thu, 7 Nov 2019 15:49:59 -0500    

The point is that DELETE triggers cannot modify any values.  
  
Reported-by: Eugen Konkov  
  
Discussion: https://postgr.es/m/[email protected]  
  
Backpatch-through: 9.4  

commit   : 89f56fc223f94c0e0c0347aa9fc18d1a247bc316    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 7 Nov 2019 14:21:52 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 7 Nov 2019 14:21:52 -0500    

Declaring this in the client-visible header ecpglib.h was a pretty  
poor decision.  It's not meant to be application-callable (and if  
it was, putting it outside the extern "C" { ... } wrapper means  
that C++ clients would fail to call it).  And the declaration would  
not even compile for a client, anyway, since it would not have the  
macro pg_attribute_format_arg().  Fortunately, it seems that no  
clients have tried to include this header with ENABLE_NLS defined,  
or we'd have gotten complaints about that.  But we have no business  
putting such a restriction on client code.  
  
Move the declaration to ecpglib_extern.h, since in fact nothing  
outside src/interfaces/ecpg/ecpglib/ needs to call it.  
  
The practical effect of this is just that clients can now safely  
#include ecpglib.h while having ENABLE_NLS defined, but that seems  
like enough of a reason to back-patch it.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : e4baecf1e1626139a2298395257ec1838c133d79    
  
author   : Alvaro Herrera <[email protected]>    
date     : Thu, 7 Nov 2019 13:59:24 -0300    
  
committer: Alvaro Herrera <[email protected]>    
date     : Thu, 7 Nov 2019 13:59:24 -0300    

SET CONSTRAINTS ... DEFERRED failed on partitioned tables, because of a  
sanity check that ensures that the affected constraints have triggers.  
On partitioned tables, the triggers are in the leaf partitions, not in  
the partitioned relations themselves, so the sanity check fails.  
Removing the sanity check solves the problem, because the code needed to  
support the case is already there.  
  
Backpatch to 11.  
  
Note: deferred unique constraints are not affected by this bug, because  
they do have triggers in the parent partitioned table.  I did not add a  
test for this scenario.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : b49b7f94489a12d0d7d299b2871c4881fa3c5d49    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 7 Nov 2019 11:22:52 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 7 Nov 2019 11:22:52 -0500    

This patch adopts the overflow check logic introduced by commit cbdb8b4c0  
into two more places.  interval_mul() failed to notice if it computed a  
new microseconds value that was one more than INT64_MAX, and pgbench's  
double-to-int64 logic had the same sorts of edge-case problems that  
cbdb8b4c0 fixed in the core code.  
  
To make this easier to get right in future, put the guts of the checks  
into new macros in c.h, and add commentary about how to use the macros  
correctly.  
  
Back-patch to all supported branches, as we did with the previous fix.  
  
Yuya Watari  
  
Discussion: https://postgr.es/m/CAJ2pMkbkkFw2hb9Qb1Zj8d06EhWAQXFLy73St4qWv6aX=vqnjw@mail.gmail.com  

commit   : fb53c4c07fec36846b522213599438176414fec0    
  
author   : Fujii Masao <[email protected]>    
date     : Thu, 7 Nov 2019 16:31:36 +0900    
  
committer: Fujii Masao <[email protected]>    
date     : Thu, 7 Nov 2019 16:31:36 +0900    

If there is the WAL page that the continuation WAL record just fits within  
(i.e., the continuation record ends just at the end of the page) and  
the LSN in such page is specified with -s option, previously pg_waldump  
caused an assertion failure. The cause of this assertion failure was that  
XLogFindNextRecord() that pg_waldump -s calls mistakenly handled  
such special WAL page.  
  
This commit changes XLogFindNextRecord() so that it can handle  
such WAL page correctly.  
  
Back-patch to all supported versions.  
  
Author: Andrey Lepikhov  
Reviewed-by: Fujii Masao, Michael Paquier  
Discussion: https://postgr.es/m/[email protected]  

commit   : d213f3114d9901159b41cc72f9fd41c74bd2b2b6    
  
author   : Peter Eisentraut <[email protected]>    
date     : Wed, 6 Nov 2019 14:20:29 +0100    
  
committer: Peter Eisentraut <[email protected]>    
date     : Wed, 6 Nov 2019 14:20:29 +0100    

The previous code was allocating more memory than necessary because  
the formula used the wrong data type.  
  
Reported-by: Jehan-Guillaume de Rorthais <[email protected]>  
Discussion: https://www.postgresql.org/message-id/20191105172918.3e32a446@firost  

commit   : cb6d7f9855e9902d5a6aab000f79b74c14a5b885    
  
author   : Michael Paquier <[email protected]>    
date     : Wed, 6 Nov 2019 16:12:34 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Wed, 6 Nov 2019 16:12:34 +0900    

When sending data for logical decoding using the streaming replication  
protocol via a WAL sender, the timestamp of the sent write message is  
allocated at the beginning of the message when preparing for the write,  
and actually computed when the write message is ready to be sent.  
  
The timestamp was getting computed after sending the message.  This  
impacts anything using logical decoding, causing for example logical  
replication to report mostly NULL for last_msg_send_time in  
pg_stat_subscription.  
  
This commit makes sure that the timestamp is computed before sending the  
message.  This is wrong since 5a991ef, so backpatch down to 9.4.  
  
Author: Jeff Janes  
Discussion: https://postgr.es/m/CAMkU=1z=WMn8jt7iEdC5sYNaPgAgOASb_OW5JYv-vMdYaJSL-w@mail.gmail.com  
Backpatch-through: 9.4  

commit   : be99485b94e9f4560f0d8c8f1ed4afc258f75b08    
  
author   : Andrew Gierth <[email protected]>    
date     : Wed, 6 Nov 2019 04:13:30 +0000    
  
committer: Andrew Gierth <[email protected]>    
date     : Wed, 6 Nov 2019 04:13:30 +0000    

WindowAgg will potentially store large numbers of input rows into  
tuplestores to allow access to other rows in the frame. If the input  
is coming via an explicit Sort node, then unneeded columns will  
already have been discarded (since Sort requests a small tlist); but  
there are idioms like COUNT(*) OVER () that result in the input not  
being sorted at all, and cases where the input is being sorted by some  
means other than a Sort; if we don't request a small tlist, then  
WindowAgg's storage requirement is inflated by the unneeded columns.  
  
Backpatch back to 9.6, where the current tlist handling was added.  
(Prior to that, WindowAgg would always use a small tlist.)  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 793739180735a062d9eadec9ad03dbd5db11e5c0    
  
author   : Bruce Momjian <[email protected]>    
date     : Tue, 5 Nov 2019 21:29:02 -0500    
  
committer: Bruce Momjian <[email protected]>    
date     : Tue, 5 Nov 2019 21:29:02 -0500    

Reported-by: Justin Pryzby  
  
Discussion: https://postgr.es/m/[email protected]  
  
Backpatch-through: 11, 12  

commit   : 0d8bc874cfed23e4b59c67221a6564dcdefd3efb    
  
author   : Bruce Momjian <[email protected]>    
date     : Tue, 5 Nov 2019 20:54:04 -0500    
  
committer: Bruce Momjian <[email protected]>    
date     : Tue, 5 Nov 2019 20:54:04 -0500    

Reported-by: [email protected]  
  
Discussion: https://postgr.es/m/[email protected]  
  
Backpatch-through: 9.4  

commit   : 97ddc47b9fab3f81493abb5c2b70a2614258cfdd    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 5 Nov 2019 14:27:37 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 5 Nov 2019 14:27:37 -0500    

For a long time (since commit aed378e8d) we have had a policy to log  
nothing about a connection if the client disconnects when challenged  
for a password.  This is because libpq-using clients will typically  
do that, and then come back for a new connection attempt once they've  
collected a password from their user, so that logging the abandoned  
connection attempt will just result in log spam.  However, this did  
not work well for PAM authentication: the bottom-level function  
pam_passwd_conv_proc() was on board with it, but we logged messages  
at higher levels anyway, for lack of any reporting mechanism.  
Add a flag and tweak the logic so that the case is silent, as it is  
for other password-using auth mechanisms.  
  
Per complaint from Yoann La Cancellera.  It's been like this for awhile,  
so back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/CACP=ajbrFFYUrLyJBLV8=q+eNCapa1xDEyvXhMoYrNphs-xqPw@mail.gmail.com  

commit   : 2bfe015b5626be7f9837b0d1b31438fa896da427    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 5 Nov 2019 13:40:37 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 5 Nov 2019 13:40:37 -0500    

get_relkind_objtype, and hence get_object_type, failed when applied to a  
toast table.  This is not a good thing, because it prevents reporting of  
perfectly legitimate permissions errors.  (At present, these functions  
are in fact *only* used to determine the ObjectType argument for  
acl_error() calls.)  It seems best to have them fall back to returning  
OBJECT_TABLE in every case where they can't determine an object type  
for a pg_class entry, so do that.  
  
In passing, make some edits to alter.c to make it more obvious that  
those calls of get_object_type() are used only for error reporting.  
This might save a few cycles in the non-error code path, too.  
  
Back-patch to v11 where this issue originated.  
  
John Hsu, Michael Paquier, Tom Lane  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 3574c0ac0509df2a70fa225f379541ef22c5756d    
  
author   : Alvaro Herrera <[email protected]>    
date     : Mon, 4 Nov 2019 15:50:57 -0300    
  
committer: Alvaro Herrera <[email protected]>    
date     : Mon, 4 Nov 2019 15:50:57 -0300    

Starting with PostgreSQL 12, pg_restore refuses to run when neither -d  
nor -f are specified (c.f. commit 413ccaa74d9a), and it also makes "-f -"  
mean the old implicit behavior of dumping to stdout.  However, older  
branches write to a file called ./- when invoked like that, making it  
impossible to write pg_restore scripts that work across versions.  This  
is a partial backpatch of the aforementioned commit to all older  
supported branches, providing an upgrade path.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 8f8ff09d49affd665dce3b6b8563a96ad9821a99    
  
author   : Michael Paquier <[email protected]>    
date     : Tue, 5 Nov 2019 10:18:01 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Tue, 5 Nov 2019 10:18:01 +0900    

This clarifies more how to use and how to take advantage of constraints  
when attaching a new partition.  
  
Author: Justin Pryzby  
Reviewed-by: Amit Langote, Álvaro Herrera, Michael Paquier  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 10  

commit   : 078f5bc8e307fd13ea256e8c37d22aaddc846211    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 4 Nov 2019 16:25:05 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 4 Nov 2019 16:25:05 -0500    

The code only compared two triggers' names and namespaces (the latter  
being the owning table's schema).  This could result in falling back  
to an OID-based sort of similarly-named triggers on different tables.  
We prefer to avoid that, so add a comparison of the table names too.  
(The sort order is thus table namespace, trigger name, table name,  
which is a bit odd, but it doesn't seem worth contorting the code  
to work around that.)  
  
Likewise for policy objects, in 9.5 and up.  
  
Complaint and fix by Benjie Gillam.  Back-patch to all supported  
branches.  
  
Discussion: https://postgr.es/m/CAMThMzEEt2mvBbPgCaZ1Ap1N-moGn=Edxmadddjq89WG4NpPtQ@mail.gmail.com  

commit   : 0782050bc22d4d428c3cffe0d0a7ecee29d2f5fe    
  
author   : Peter Eisentraut <[email protected]>    
date     : Mon, 4 Nov 2019 08:30:00 +0100    
  
committer: Peter Eisentraut <[email protected]>    
date     : Mon, 4 Nov 2019 08:30:00 +0100    

Rearrange the logic in record_image_cmp() and record_image_eq() to  
error out on unexpected typlens (either not supported there or  
completely invalid due to corruption).  Barring corruption, this is  
not possible today but it seems more future-proof and robust to fix  
this.  
  
Reported-by: Peter Geoghegan <[email protected]>  

commit   : 88d03d73c22440763dbe85378fdda8389db78b0d    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 3 Nov 2019 16:10:23 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 3 Nov 2019 16:10:23 -0500    

Commit 8af1624e3 introduced a warning about possibly returning  
without a value, on compilers that don't realize that ereport(ERROR)  
doesn't return.  Tweak the code to avoid that.  
  
Per buildfarm.  Back-patch to 9.6, like the aforesaid commit.  

commit   : 65cdf8bc1be4857724c3d0d0bfbaedac8231af5f    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 2 Nov 2019 16:45:32 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 2 Nov 2019 16:45:32 -0400    

Using incorrect, or just mismatched, dictionary and affix files  
could result in a crash, due to failure to cross-check offsets  
obtained from the file.  Add necessary validation, as well as  
some Asserts for future-proofing.  
  
Per bug #16050 from Alexander Lakhin.  Back-patch to 9.6 where the  
problem was introduced.  
  
Arthur Zakirov, per initial investigation by Tomas Vondra  
  
Discussion: https://postgr.es/m/[email protected]  
Discussion: https://postgr.es/m/20191013012610.2p2fp3zzpoav7jzf@development  

commit   : f10815c5bf1bcaff1bd51926f493bd073e94ece5    
  
author   : Michael Paquier <[email protected]>    
date     : Sat, 2 Nov 2019 14:17:12 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Sat, 2 Nov 2019 14:17:12 +0900    

When using CREATE TABLE for a new partition, the partitioned indexes of  
the parent are created automatically in a fashion similar to LIKE  
INDEXES.  The new partition and its parent use a mapping for attribute  
numbers for this operation, and while the mapping was correctly built,  
its length was defined as the number of attributes of the newly-created  
child, and not the parent.  If the parent includes dropped columns, this  
could cause failures.  
  
This is wrong since 8b08f7d which has introduced the concept of  
partitioned indexes, so backpatch down to 11.  
  
Reported-by: Wyatt Alt  
Author: Michael Paquier  
Reviewed-by: Amit Langote  
Discussion: https://postgr.es/m/CAGem3qCcRmhbs4jYMkenYNfP2kEusDXvTfw-q+eOhM0zTceG-g@mail.gmail.com  
Backpatch-through: 11  

commit   : 61f23839257d8260664d0af0ff82cc3dd2b46786    
  
author   : Michael Paquier <[email protected]>    
date     : Fri, 1 Nov 2019 22:38:51 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Fri, 1 Nov 2019 22:38:51 +0900    

When a backend exits, it gets deleted from the syncrep queue if present.  
The queue was checked without SyncRepLock taken in exclusive mode, so it  
would have been possible for a backend to remove itself after a WAL  
sender already did the job.  Fix this issue based on a suggestion from  
Fujii Masao, by first checking the queue without the lock.  Then, if the  
backend is present in the queue, take the lock and perform an additional  
lookup check before doing the element deletion.  
  
Author: Dongming Liu  
Reviewed-by: Kyotaro Horiguchi, Fujii Masao, Michael Paquier  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 9.4  

commit   : 3b24cf732e1746f84271f3a4f84288d146203cc3    
  
author   : Andres Freund <[email protected]>    
date     : Tue, 29 Oct 2019 22:46:40 -0700    
  
committer: Andres Freund <[email protected]>    
date     : Tue, 29 Oct 2019 22:46:40 -0700    

The additional newline seems to have accidentally been introduced in  
2c03216d831, in 9.5. The newline is only issued when an FPW is  
present for the block reference.  
  
While there could be an argument that removing the newlines in the  
back branches could cause a problem for somebody parsing the  
pg_waldump output, the likelihood of that seems small enough. It seems  
at least equally likely that the randomness of when newlines are  
issued causes problems.  
  
Author: Andres Freund  
Discussion: https://postgr.es/m/[email protected]  
Backpatch: 9.5, like 2c03216d831.  

commit   : af67aee69189c59bd3076b472f959a16e6193828    
  
author   : Andres Freund <[email protected]>    
date     : Tue, 29 Oct 2019 19:18:07 -0700    
  
committer: Andres Freund <[email protected]>    
date     : Tue, 29 Oct 2019 19:18:07 -0700    

This got broken in 604f7956b94, shortly after rm_identify's  
introduction.  
  
Author: Andres Freund  
Discussion: https://postgr.es/m/[email protected]  
Backpatch: 9.5, where rm_identify was introduced  

commit   : 9f7a664fe35c40cc9b1a4ebec4fc990dc45370f3    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 25 Oct 2019 15:22:40 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 25 Oct 2019 15:22:40 -0400    

It appears that libxml2 doesn't bother to set the "children" field of  
an XML_NAMESPACE_DECL node to null; that field just contains garbage.  
In v10 and v11, this can result in a crash in XMLTABLE().  The rewrite  
done in commit 251cf2e27 fixed this, somewhat accidentally, in v12.  
We're not going to back-patch 251cf2e27, however.  The case apparently  
doesn't have wide use, so rather than risk introducing other problems,  
just add a safety check to throw an error.  
  
Even though no bug manifests in v12/HEAD, add the relevant test case  
there too, to prevent future regressions.  
  
Chapman Flack (per private report)  

commit   : 2930f163f6a5a8b6be62a02f6e88a404ab7fb9e2    
  
author   : Bruce Momjian <[email protected]>    
date     : Wed, 23 Oct 2019 20:29:02 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Wed, 23 Oct 2019 20:29:02 -0400    

Reported-by: Asim / [email protected]  
  
Discussion: https://postgr.es/m/[email protected]  
  
Backpatch-through: 9.4  

commit   : 669feabfb76213046c8bffcfa9630376e770d4de    
  
author   : Michael Paquier <[email protected]>    
date     : Wed, 23 Oct 2019 10:25:50 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Wed, 23 Oct 2019 10:25:50 +0900    

Any callback set would have no meaning in the context of an exception.  
As an autovacuum worker exits quickly in this context, this could be  
only an issue within EmitErrorReport(), where the elog hook is for  
example called.  That's unlikely to going to be a problem, but let's be  
clean and consistent with other code paths handling exceptions.  This is  
present since 2909419, which introduced autovacuum.  
  
Author: Ashwin Agrawal  
Reviewed-by: Tom Lane, Michael Paquier  
Discussion: https://postgr.es/m/CALfoeisM+_+dgmAdAOHAu0k-ZpEHHqSSG=GRf3pKJGm8OqWX0w@mail.gmail.com  
Backpatch-through: 9.4  

commit   : a05a04d0edb45f5c9b014eada9619141314c815f    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 21 Oct 2019 14:18:01 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 21 Oct 2019 14:18:01 -0400    

It emerges that recent versions of Windows (at least 2016 Standard)  
spell this locale name as "Norwegian Bokmål_Norway.1252", defeating  
our mapping code that translates "Norwegian (Bokmål)_Norway" to  
something that's all-ASCII (cf commits db29620d4 and aa1d2fc5e).  
Add another mapping entry to handle this spelling.  
  
Per bug #16068 from Robert Ford.  Like the previous patches,  
back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 4e19bd41d965b3b3fc9b2fc0022a968a71fbceff    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 21 Oct 2019 13:52:25 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 21 Oct 2019 13:52:25 -0400    

On recent Red Hat platforms (at least RHEL 8 and Fedora 30, maybe older),  
configure's probe for libperl failed if the user forces CFLAGS to be -O0.  
This is because some code in perl's inline.h fails to be optimized away  
at -O0, and said code doesn't work if compiled without -fPIC.  
  
To fix, add CFLAGS_SL to the compile flags used during the libperl probe.  
This is a better simulation of the way that plperl is built, anyway,  
so it might forestall other issues in future.  
  
Per gripe from Kyotaro Horiguchi.  Back-patch to all supported branches,  
since people might want to build older branches on these platforms.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 99c51d5ed88c92db7d9b61b3c53c3d1eea32f9ec    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 21 Oct 2019 12:32:36 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 21 Oct 2019 12:32:36 -0400    

Move the platform-dependent logic that sets CFLAGS_SL from  
src/makefiles/Makefile.foo to src/template/foo, so that the value  
is determined at configure time and thus is available while running  
configure's tests.  
  
On a couple of platforms this might save a few microseconds of build  
time by eliminating a test that make otherwise has to do over and over.  
Otherwise it's pretty much a wash for build purposes; in particular,  
this makes no difference to anyone who might be overriding CFLAGS_SL  
via a make option.  
  
This patch in itself does nothing with the value and thus should not  
change any behavior, though you'll probably have to re-run configure  
to get a correctly updated Makefile.global.  We'll use the new  
configure variable in a follow-on patch.  
  
Per gripe from Kyotaro Horiguchi.  Back-patch to all supported branches,  
because the follow-on patch is a portability bug fix.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : af4477b00cf93c8305aebe3b58ea26499664336e    
  
author   : Noah Misch <[email protected]>    
date     : Fri, 18 Oct 2019 20:20:28 -0700    
  
committer: Noah Misch <[email protected]>    
date     : Fri, 18 Oct 2019 20:20:28 -0700    

Without "b", a variant of the tas() code miscompiles on macOS 10.4.  
This may also fix a compilation failure involving macOS 10.1.  Today's  
compilers have been allocating acceptable registers with or without this  
change, but this future-proofs the code by precisely conveying the  
acceptable registers.  Back-patch to 9.4 (all supported versions).  
  
Reviewed by Tom Lane.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : f7b70700bc44d4a7e5de143c6906e2421dd0c709    
  
author   : Fujii Masao <[email protected]>    
date     : Fri, 18 Oct 2019 22:32:18 +0900    
  
committer: Fujii Masao <[email protected]>    
date     : Fri, 18 Oct 2019 22:32:18 +0900    

recovery_min_apply_delay parameter is intended for use with streaming  
replication deployments. However, the document clearly explains that  
the parameter will be honored in all cases if it's specified. So it should  
take effect even if in archive recovery. But, previously, archive recovery  
with recovery_min_apply_delay enabled always failed, and caused assertion  
failure if --enable-caasert is enabled.  
  
The cause of this problem is that; the ownership of recoveryWakeupLatch  
that recovery_min_apply_delay uses was taken only when standby mode  
is requested. So unowned latch could be used in archive recovery, and  
which caused the failure.  
  
This commit changes recovery code so that the ownership of  
recoveryWakeupLatch is taken even in archive recovery. Which prevents  
archive recovery with recovery_min_apply_delay from failing.  
  
Back-patch to v9.4 where recovery_min_apply_delay was added.  
  
Author: Fujii Masao  
Reviewed-by: Michael Paquier  
Discussion: https://postgr.es/m/CAHGQGwEyD6HdZLfdWc+95g=VQFPR4zQL4n+yHxQgGEGjaSVheQ@mail.gmail.com  

commit   : feed5ee4753afa1b53e441271cc3e28345bcae0b    
  
author   : Michael Paquier <[email protected]>    
date     : Fri, 18 Oct 2019 14:27:00 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Fri, 18 Oct 2019 14:27:00 +0900    

The timestamp tracking the last moment a message is received in a  
logical replication worker was initialized in each loop checking if a  
message was received or not, causing wal_receiver_timeout to be ignored  
in basically any logical replication deployments.  This also broke the  
ping sent to the server when reaching half of wal_receiver_timeout.  
  
This simply moves the initialization of the timestamp out of the apply  
loop to the beginning of LogicalRepApplyLoop().  
  
Reported-by: Jehan-Guillaume De Rorthais  
Author: Julien Rouhaud  
Discussion: https://postgr.es/m/CAOBaU_ZHESFcWva8jLjtZdCLspMj7vqaB2k++rjHLY897ZxbYw@mail.gmail.com  
Backpatch-through: 10  

commit   : 45e4067c05b116bf2b22245361e748939778cc0b    
  
author   : Alvaro Herrera <[email protected]>    
date     : Thu, 17 Oct 2019 15:06:05 +0200    
  
committer: Alvaro Herrera <[email protected]>    
date     : Thu, 17 Oct 2019 15:06:05 +0200    

Logical walsender should exit when it catches up with sending WAL during  
shutdown; but there was a rare corner case when it failed to because of  
a race condition that puts it back to wait for more WAL instead -- but  
since there wasn't any, it'd not shut down immediately.  It would only  
continue the shutdown when wal_sender_timeout terminates the sleep,  
which causes annoying waits during shutdown procedure.  Restructure the  
code so that we no longer forget to set WalSndCaughtUp in that case.  
  
This was an oversight in commit c6c333436.  
  
Backpatch all the way down to 9.4.  
  
Author: Craig Ringer, Álvaro Herrera  
Discussion: https://postgr.es/m/CAMsr+YEuz4XwZX_QmnX_-2530XhyAmnK=zCmicEnq1vLr0aZ-g@mail.gmail.com  

commit   : 6737111a7ae1fac6b4781250be7c0719c5a7ed48    
  
author   : Thomas Munro <[email protected]>    
date     : Thu, 17 Oct 2019 13:24:50 +1300    
  
committer: Thomas Munro <[email protected]>    
date     : Thu, 17 Oct 2019 13:24:50 +1300    

Otherwise it can be hard to see where an error is coming from, when  
the parallel worker sets all the GUCs that it received from the  
leader.  Bug #15726.  Back-patch to 9.5, where RestoreGUCState()  
appeared.  
  
Reported-by: Tiago Anastacio  
Reviewed-by: Daniel Gustafsson, Tom Lane  
Discussion: https://postgr.es/m/15726-6d67e4fa14f027b3%40postgresql.org  

commit   : 6f1e336de01003e4005a9c00f6c25c94ccd4dd34    
  
author   : Thomas Munro <[email protected]>    
date     : Thu, 17 Oct 2019 09:59:21 +1300    
  
committer: Thomas Munro <[email protected]>    
date     : Thu, 17 Oct 2019 09:59:21 +1300    

Commits 801c2dc7 and 801c2dc7 made it possible for vacuum to  
try to freeze a multixact that is still running.  That was  
prevented by a check, but raised an error.  Repair.  
  
Back-patch all the way.  
  
Author: Nathan Bossart, Jeremy Schneider  
Reported-by: Jeremy Schneider  
Reviewed-by: Jim Nasby, Thomas Munro  
Discussion: https://postgr.es/m/DAFB8AFF-2F05-4E33-AD7F-FF8B0F760C17%40amazon.com  

commit   : d071a2539ff4e8cc1fe7abb195efe8da16417f43    
  
author   : Tomas Vondra <[email protected]>    
date     : Wed, 16 Oct 2019 13:23:18 +0200    
  
committer: Tomas Vondra <[email protected]>    
date     : Wed, 16 Oct 2019 13:23:18 +0200    

The pg_upgrade check for pg_catalog.unknown type when upgrading from 9.6  
had a couple of issues with domains and composite types - it detected  
even composite types unused in objects with storage. So for example this  
was enough to trigger an unnecessary pg_upgrade failure:  
  
  CREATE TYPE unknown_composite AS (u pg_catalog.unknown)  
  
On the other hand, this only happened with composite types directly on  
the pg_catalog.unknown data type, but not with a domain. So this was not  
detected  
  
  CREATE DOMAIN unknown_domain AS pg_catalog.unknown;  
  CREATE TYPE unknown_composite_2 AS (u unknown_domain);  
  
unlike the first example. These false positives and inconsistencies are  
unfortunate, but what's worse we've failed to detected objects using the  
pg_catalog.unknown type through a domain. So we missed cases like this  
  
  CREATE TABLE t (u unknown_composite_2);  
  
The consequence is clusters broken after a pg_upgrade.  
  
This fixes these false positives and false negatives by using the same  
recursive CTE introduced by eaf900e842 for sql_identifier. Backpatch all  
the way to 10, where the of pg_catalog.unknown data type was restricted.  
  
Author: Tomas Vondra  
Backpatch-to: 10-  
Discussion: https://postgr.es/m/16045-673e8fa6b5ace196%40postgresql.org  

commit   : a970b6cdebd1578eb13e000d0c510c09c7b9e7d3    
  
author   : Tomas Vondra <[email protected]>    
date     : Wed, 16 Oct 2019 13:23:14 +0200    
  
committer: Tomas Vondra <[email protected]>    
date     : Wed, 16 Oct 2019 13:23:14 +0200    

The pg_upgrade check for pg_catalog.line data type when upgrading from  
9.3 had a couple of issues with domains and composite types. Firstly, it  
triggered false positives for composite types unused in objects with  
storage. This was enough to trigger an unnecessary pg_upgrade failure:  
  
  CREATE TYPE line_composite AS (l pg_catalog.line)  
  
On the other hand, this only happened with composite types directly on  
the pg_catalog.line data type, but not with a domain. So this was not  
detected  
  
  CREATE DOMAIN line_domain AS pg_catalog.line;  
  CREATE TYPE line_composite_2 AS (l line_domain);  
  
unlike the first example. These false positives and inconsistencies are  
unfortunate, but what's worse we've failed to detected objects using the  
pg_catalog.line data type through a domain. So we missed cases like this  
  
  CREATE TABLE t (l line_composite_2);  
  
The consequence is clusters broken after a pg_upgrade.  
  
This fixes these false positives and false negatives by using the same  
recursive CTE introduced by eaf900e842 for sql_identifier. 9.3 did not  
support domains on composite types, but we can still have multi-level  
composite types.  
  
Backpatch all the way to 9.4, where the format for pg_catalog.line data  
type changed.  
  
Author: Tomas Vondra  
Backpatch-to: 9.4-  
Discussion: https://postgr.es/m/16045-673e8fa6b5ace196%40postgresql.org  

commit   : b60febc6d771dd706dc3d71d13aaeab826d7330c    
  
author   : Michael Paquier <[email protected]>    
date     : Wed, 16 Oct 2019 13:10:40 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Wed, 16 Oct 2019 13:10:40 +0900    

This fixes multiple areas of the documentation:  
- COPY for its past compatibility section.  
- SET ROLE mentioning INHERITS instead of INHERIT  
- PREPARE referring to stmt_name, that is not present.  
- Extension documentation about format name with upgrade scripts.  
  
Backpatch down to 9.4 for the relevant parts.  
  
Author: Alexander Lakhin  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 9.4  

commit   : e5b4926ef6110ef4f21c197d462097072d38b39d    
  
author   : Noah Misch <[email protected]>    
date     : Sat, 12 Oct 2019 00:21:47 -0700    
  
committer: Noah Misch <[email protected]>    
date     : Sat, 12 Oct 2019 00:21:47 -0700    

With xlc v16.1.0, it causes internal compiler errors.  With xlc versions  
not exhibiting that bug, removing -qsrcmsg merely changes the compiler  
error reporting format.  Back-patch to 9.4 (all supported versions).  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : e34358c436c6bf4e75beb6e9f79f9a207c0b2ed5    
  
author   : Michael Paquier <[email protected]>    
date     : Wed, 9 Oct 2019 13:31:17 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Wed, 9 Oct 2019 13:31:17 +0900    

The file descriptor was opened with read-only to fsync a regular file,  
which would cause EBADFD errors on some platforms.  
  
This is similar to the recent fix done by a586cc4b (which was broken by  
me with 82a5649), except that I noticed this issue while monitoring the  
backend code for similar mistakes.  Backpatch to 9.4, as this has been  
introduced since logical decoding exists as of b89e151.  
  
Author: Michael Paquier  
Reviewed-by: Andres Freund  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 9.4  

commit   : e4ca62b9488393f1f3a7e982daff544fa90959bf    
  
author   : Bruce Momjian <[email protected]>    
date     : Mon, 7 Oct 2019 18:06:08 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Mon, 7 Oct 2019 18:06:08 -0400    

The docs for sync and async multimaster replication were unclear about  
when to use it, and when it has benefits;  this change clarifies that.  
  
Reported-by: [email protected]  
  
Discussion: https://postgr.es/m/[email protected]  
  
Backpatch-through: 9.4  

commit   : f68d5bff5e440319fab9a49cbb99d2339988358f    
  
author   : Bruce Momjian <[email protected]>    
date     : Mon, 7 Oct 2019 17:26:46 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Mon, 7 Oct 2019 17:26:46 -0400    

This should help people clearly know that these days start at midnight.  
  
Reported-by: David Harper  
  
Discussion: https://postgr.es/m/[email protected]  
  
Backpatch-through: 9.4  

commit   : f872f1817348cda2a1db867d2244cce768ff3328    
  
author   : Bruce Momjian <[email protected]>    
date     : Mon, 7 Oct 2019 14:33:31 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Mon, 7 Oct 2019 14:33:31 -0400    

Previously it was mentioned in the lock_timeout docs in a confusing  
location.  
  
Reported-by: [email protected]  
  
Discussion: https://postgr.es/m/[email protected]  
  
Backpatch-through: 9.4  

commit   : 021065aac676c96b703b9c7a02da763469a183c1    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 7 Oct 2019 12:39:09 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 7 Oct 2019 12:39:09 -0400    

The postmaster's code path for spawning a bgworker neglected to check  
whether we already have the max number of live child processes.  That's  
a bit hard to hit, since it would necessarily be a transient condition;  
but if we do, AssignPostmasterChildSlot() fails causing a postmaster  
crash, as seen in a report from Bhargav Kamineni.  
  
To fix, invoke canAcceptConnections() in the bgworker code path, as we  
do in the other code paths that spawn children.  Since we don't want  
the same pmState tests in this case, add a child-process-type parameter  
to canAcceptConnections() so that it can know what to do.  
  
Back-patch to 9.5.  In principle the same hazard exists in 9.4, but the  
code is enough different that this patch wouldn't quite fix it there.  
Given the tiny usage of bgworkers in that branch it doesn't seem worth  
creating a variant patch for it.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : eb74022d242e86c88c7ee19212e5e3fa0d01bfc5    
  
author   : Noah Misch <[email protected]>    
date     : Sat, 5 Oct 2019 10:05:05 -0700    
  
committer: Noah Misch <[email protected]>    
date     : Sat, 5 Oct 2019 10:05:05 -0700    

This prints the unexpected value in more failure cases, and it removes  
forty-eight hand-maintained error messages.  Back-patch to 9.5, which  
introduced these tests.  
  
Reviewed (in an earlier version) by Andres Freund.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 4fd51980ed5a48cb5f8255c0dc2753302fd46fc6    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 5 Oct 2019 12:26:55 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 5 Oct 2019 12:26:55 -0400    

This would be all right, maybe, if it didn't also match a file that  
definitely should not be ignored.  We don't add rmgrs so often that  
manual maintenance of this file list is impractical, so just write  
out the list.  
  
(I find the equivalent wildcard use in the Makefile pretty lazy and  
unsafe as well, but will leave that alone until it actually causes a  
problem.)  
  
Per bug #16042 from Denis Stuchalin.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 77b2d95b1485091c70fc48ed6d3617f61c3727e2    
  
author   : Andres Freund <[email protected]>    
date     : Sat, 5 Oct 2019 08:05:11 -0700    
  
committer: Andres Freund <[email protected]>    
date     : Sat, 5 Oct 2019 08:05:11 -0700    

Discussion: https://postgr.es/m/[email protected]  
Backpatch: 9.6-, just like c8841199509 and 6e61d75f525  

commit   : 5711a1828f1fd1b120d0faa62f47ad5a5fe5632c    
  
author   : Andres Freund <[email protected]>    
date     : Fri, 4 Oct 2019 21:37:54 -0700    
  
committer: Andres Freund <[email protected]>    
date     : Fri, 4 Oct 2019 21:37:54 -0700    

One of the upsert related tests is unstable (sometimes even hanging  
until isolationtester's step timeout is reached). Based on preliminary  
analysis that might be a problem outside of just that test, but not  
really related to EPQ and triggers.  Disable for now, to get the  
buildfarm greener again.  
  
Discussion: https://postgr.es/m/[email protected]  
Backpatch: 9.6-, just like c8841199509.  

commit   : 54b0feaf90d8c00adb5aa9c094b4f70b509ede0f    
  
author   : Andres Freund <[email protected]>    
date     : Fri, 4 Oct 2019 14:01:35 -0700    
  
committer: Andres Freund <[email protected]>    
date     : Fri, 4 Oct 2019 14:01:35 -0700    

As evidenced by bug #16036 this area is woefully under-tested. Add  
fairly extensive tests for the combination.  
  
Backpatch back to 9.6 - before that isolationtester was not capable  
enough. While we don't backpatch tests all the time, future fixes to  
trigger.c would potentially look different enough in 12+ from the  
earlier branches that introducing bugs during backpatching is more  
likely than normal. Also, it's just a crucial and undertested area of  
the code.  
  
Author: Andres Freund  
Discussion: https://postgr.es/m/[email protected]  
Backpatch: 9.6-, the earliest these tests work  

commit   : 3b9c227008a65b0135931e9478cf2b5bb16eca34    
  
author   : Andrew Dunstan <[email protected]>    
date     : Fri, 4 Oct 2019 15:34:40 -0400    
  
committer: Andrew Dunstan <[email protected]>    
date     : Fri, 4 Oct 2019 15:34:40 -0400    

First, make sure that the .exe name is quoted when trying to get the  
version number. Also, don't quote the lib name for using in the project  
files if it's already been quoted. This second change applies to all  
libraries, not just OpenSSL.  
  
This has clearly been broken forever, so backpatch to all live branches.  

commit   : b8ddf0bdf74603fa04aab911afac861efec0a0a3    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 4 Oct 2019 10:34:21 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 4 Oct 2019 10:34:21 -0400    

Commit 5ac0d9360 failed to entirely fix bitshiftright's habit of  
leaving one-bits in the pad space that should be all zeroes,  
because in a moment of sheer brain fade I'd concluded that only  
the code path used for not-a-multiple-of-8 shift distances needed  
to be fixed.  Of course, a multiple-of-8 shift distance can also  
cause the problem, so we need to forcibly zero the extra bits  
in both cases.  
  
Per bug #16037 from Alexander Lakhin.  As before, back-patch to all  
supported branches.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : e5ff9757194bcbf9c5257b89fccec8187e1b7bd7    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 3 Oct 2019 17:34:25 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 3 Oct 2019 17:34:25 -0400    

Encoding conversion uses the very simplistic rule that the output  
can't be more than 4X longer than the input, and palloc's a buffer  
of that size.  This results in failure to convert any string longer  
than 1/4 GB, which is becoming an annoying limitation.  
  
As a band-aid to improve matters, allow the allocated output buffer  
size to exceed 1GB.  We still insist that the final result fit into  
MaxAllocSize (1GB), though.  Perhaps it'd be safe to relax that  
restriction, but it'd require close analysis of all callers, which  
is daunting (not least because external modules might call these  
functions).  For the moment, this should allow a 2X to 4X improvement  
in the longest string we can convert, which is a useful gain in  
return for quite a simple patch.  
  
Also, once we have successfully converted a long string, repalloc  
the output down to the actual string length, returning the excess  
to the malloc pool.  This seems worth doing since we can usually  
expect to give back several MB if we take this path at all.  
  
This still leaves much to be desired, most notably that the assumption  
that MAX_CONVERSION_GROWTH == 4 is very fragile, and yet we have no  
guard code verifying that the output buffer isn't overrun.  Fixing  
that would require significant changes in the encoding conversion  
APIs, so it'll have to wait for some other day.  
  
The present patch seems safely back-patchable, so patch all supported  
branches.  
  
Alvaro Herrera and Tom Lane  
  
Discussion: https://postgr.es/m/[email protected]  
Discussion: https://postgr.es/m/[email protected]  

commit   : 82d0a46ea32d1f666192d197fa993fd9f07adbec    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 3 Oct 2019 13:56:26 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 3 Oct 2019 13:56:26 -0400    

Up to now, if you resized a large (>8K) palloc chunk down to a smaller  
size, aset.c made no attempt to return any space to the malloc pool.  
That's unpleasant if a really large allocation is resized to a  
significantly smaller size.  I think no such cases existed when this  
code was designed, and I'm not sure whether they're common even yet,  
but an upcoming fix to encoding conversion will certainly create such  
cases.  Therefore, fix AllocSetRealloc so that it gives realloc()  
a chance to do something with the block.  This doesn't noticeably  
increase complexity, we mostly just have to change the order in which  
the cases are considered.  
  
Back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/[email protected]  
Discussion: https://postgr.es/m/[email protected]  

commit   : 0a445f27909aedaf4ecc2efcb05c5d588c02e240    
  
author   : Andrew Gierth <[email protected]>    
date     : Thu, 3 Oct 2019 10:54:52 +0100    
  
committer: Andrew Gierth <[email protected]>    
date     : Thu, 3 Oct 2019 10:54:52 +0100    

query_tree_walker and query_tree_mutator were skipping the  
windowClause of the query, without regard for the fact that the  
startOffset and endOffset in a WindowClause node are expression trees  
that need to be processed. This was an oversight in commit ec4be2ee6  
from 2010 which added the expression fields; the main symptom is that  
function parameters in window frame clauses don't work in inlined  
functions.  
  
Fix (as conservatively as possible since this needs to not break  
existing out-of-tree callers) and add tests.  
  
Backpatch all the way, since this has been broken since 9.0.  
  
Per report from Alastair McKinley; fix by me with kibitzing and review  
from Tom Lane.  
  
Discussion: https://postgr.es/m/DB6PR0202MB2904E7FDDA9D81504D1E8C68E3800@DB6PR0202MB2904.eurprd02.prod.outlook.com  

commit   : b978de0eba8582f4a9cde123ca09bc776bde8c83    
  
author   : Michael Paquier <[email protected]>    
date     : Wed, 2 Oct 2019 15:53:56 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Wed, 2 Oct 2019 15:53:56 +0900    

cbc55da has reworked the order of some actions at the end of archive  
recovery.  Unfortunately this overlooked the fact that the startup  
process needs to remove RECOVERYXLOG (for temporary WAL segment newly  
recovered from archives) and RECOVERYHISTORY (for temporary history  
file) at this step, leaving the files around even after recovery ended.  
  
Backpatch to 9.5, like the previous commit.  
  
Author: Sawada Masahiko  
Reviewed-by: Fujii Masao, Michael Paquier  
Discussion: https://postgr.es/m/CAD21AoBO_eDQub6zojFnWtnmutRBWvYf7=cW4Hsqj+U_R26w3Q@mail.gmail.com  
Backpatch-through: 9.5  

commit   : b81a82e395ac2fa322292802a155d28c7a372b21    
  
author   : Andrew Dunstan <[email protected]>    
date     : Mon, 30 Sep 2019 15:48:54 -0400    
  
committer: Andrew Dunstan <[email protected]>    
date     : Mon, 30 Sep 2019 15:48:54 -0400    

This one was exposed by a12c75a10.  
  
Backpatch to release 11 where check_pg_config was introduced.  

commit   : 51ad5b9bd3e317b0f6ffebaedbac23c9913269bf    
  
author   : Andres Freund <[email protected]>    
date     : Sun, 29 Sep 2019 16:27:08 -0700    
  
committer: Andres Freund <[email protected]>    
date     : Sun, 29 Sep 2019 16:27:08 -0700    

In the course of 5567d12ce03, 356687bd8 and 317ffdfeaac, I changed  
BuildTupleHashTable[Ext]'s call to ExecBuildGroupingEqual to not pass  
in the parent node, but NULL. Which in turn prevents the tuple  
equality comparator from being JIT compiled.  While that fixes  
bug #15486, it is not actually necessary after all of the above commits,  
as we don't re-build the comparator when using the new  
BuildTupleHashTableExt() interface (as the content of the hashtable  
are reset, but the TupleHashTable itself is not).  
  
Therefore re-allow jit compilation for callers that use  
BuildTupleHashTableExt with a separate context for "metadata" and  
content.  
  
As in the previous commit, there's ongoing work to make this easier to  
test to prevent such regressions in the future, but that  
infrastructure is not going to be backpatchable.  
  
The performance impact of not JIT compiling hashtable equality  
comparators can be substantial e.g. for aggregation queries that  
aggregate a lot of input rows to few output rows (when there are a lot  
of output groups, there will be fewer comparisons).  
  
Author: Andres Freund  
Discussion: https://postgr.es/m/[email protected]  
Backpatch: 11, just as 5567d12ce03  

commit   : 51e3005a072c3007b32634043c46673dd9decf03    
  
author   : Andrew Dunstan <[email protected]>    
date     : Sun, 29 Sep 2019 17:32:46 -0400    
  
committer: Andrew Dunstan <[email protected]>    
date     : Sun, 29 Sep 2019 17:32:46 -0400    

Windows does not enforce key file permissions checks in libpq, and psql  
can produce CRLF line endings on Windows.  
  
Backpatch to Release 12 (CRLF) and Release 11 (permissions check)  

commit   : 0baa55655e0549cf19fcfdb007c3250f7d4761a9    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 28 Sep 2019 13:33:34 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 28 Sep 2019 13:33:34 -0400    

This test already knew that, to get stable test output, it had to hide  
"loops" counts in EXPLAIN ANALYZE results.  But that's not nearly enough:  
if we get a smaller number of workers than we planned for, then the  
"Workers Launched" number will change, and so will all the rows and loops  
counts up to the Gather node.  This has resulted in repeated failures in  
the buildfarm, so adjust the test to filter out all these counts.  
  
(Really, we wouldn't bother with EXPLAIN ANALYZE at all here, except  
that currently the only way to verify that executor-time pruning has  
happened is to look for '(never executed)' annotations.  Those are  
stable and needn't be filtered out.)  
  
Back-patch to v11 where the test was introduced.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 240c38a48821c2da12815f36a792ab5dfd26c49e    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 27 Sep 2019 11:01:36 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 27 Sep 2019 11:01:36 -0400    

The markup for optional parameters was neither correct nor consistent.  
In passing, fix a spelling mistake.  
  
Per report from Alex Macy.  Some of these mistakes are old, so  
back-patch as appropriate.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 84ced048d18d166d81a994caafa76077ddc41af8    
  
author   : Amit Kapila <[email protected]>    
date     : Wed, 18 Sep 2019 09:14:26 +0530    
  
committer: Amit Kapila <[email protected]>    
date     : Wed, 18 Sep 2019 09:14:26 +0530    

The test name and the following test cases suggest the index created  
should be hash index, but it forgot to add 'using hash' in the test case.  
This in itself won't improve code coverage as there were some other tests  
which were covering the corresponding code.  However, it is better if the  
added tests serve their actual purpose.  
  
Reported-by: Paul A Jungwirth  
Author: Paul A Jungwirth  
Reviewed-by: Mahendra Singh  
Backpatch-through: 9.4  
Discussion: https://postgr.es/m/CA+renyV=Us-5XfMC25bNp-uWSj39XgHHmGE9Rh2cQKMegSj52g@mail.gmail.com  

commit   : d01d4f23742bb7bfedeb47f16445c3478a9cd3d8    
  
author   : Michael Paquier <[email protected]>    
date     : Wed, 25 Sep 2019 10:08:30 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Wed, 25 Sep 2019 10:08:30 +0900    

In-core relation options can use a custom lock mode since 47167b7, that  
has lowered the lock available for some autovacuum parameters.  However  
it forgot to consider custom relation options.  This causes failures  
with ALTER TABLE SET when changing a custom relation option, as its lock  
is not defined.  The existing APIs to define a custom reloption does not  
allow to define a custom lock mode, so enforce its initialization to  
AccessExclusiveMode which should be safe enough in all cases.  An  
upcoming patch will extend the existing APIs to allow a custom lock mode  
to be defined.  
  
The problem can be reproduced with bloom indexes, so add a test there.  
  
Reported-by: Nikolay Sharplov  
Analyzed-by: Thomas Munro, Michael Paquier  
Author: Michael Paquier  
Reviewed-by: Kuntal Ghosh  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 9.6  

commit   : 7cd99d39472e913c0849cfb5f75cd0173ab98735    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 23 Sep 2019 12:37:04 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 23 Sep 2019 12:37:04 -0400    

The array <@ and @> operators do not worry about duplicates: if every  
member of array X matches some element of array Y, then X is contained  
in Y, even if several members of X get matched to the same Y member.  
This was not explicitly stated in the docs though, so improve matters.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 8873c5b2017f87f8f7626782e67f5cd177cc4dff    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 23 Sep 2019 10:58:19 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 23 Sep 2019 10:58:19 -0400    

The entry for commit f24649976 claimed that citext_pattern_ops could be  
used for LIKE index searches, but in fact it cannot.  That patch only  
created the opclass and some related operators, without doing anything  
to teach the planner about how to use it.  The opclass is basically  
useless in this unfinished state, which is why nothing was added to the  
main documentation about it, and really we shouldn't have said anything  
in the release notes either.  So remove the entry.  
  
Discussion: https://postgr.es/m/CAKqncch4eBt2c8ddNVxzcVh3fFhdk54QoDMzpKgpqor4gA-wcQ@mail.gmail.com  

commit   : 7e7abed056df482b3250fb5844e8373c8a4180d6    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 22 Sep 2019 17:46:00 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 22 Sep 2019 17:46:00 -0400    

If the bitstring length is not a multiple of 8, we'd shift the  
rightmost bits into the pad space, which must be zeroes --- bit_cmp,  
for one, depends on that.  This'd lead to the result failing to  
compare equal to what it should compare equal to, as reported in  
bug #16013 from Daryl Waycott.  
  
This is, if memory serves, not the first such bug in the bitstring  
functions.  In hopes of making it the last one, do a bit more work  
than minimally necessary to fix the bug:  
  
* Add assertion checks to bit_out() and varbit_out() to complain if  
they are given incorrectly-padded input.  This will improve the  
odds that manual testing of any new patch finds problems.  
  
* Encapsulate the padding-related logic in macros to make it  
easier to use.  
  
Also, remove unnecessary padding logic from bit_or() and bitxor().  
Somebody had already noted that we need not re-pad the result of  
bit_and() since the inputs are required to be the same length,  
but failed to extrapolate that to the other two.  
  
Also, move a comment block that once was near the head of varbit.c  
(but people kept putting other stuff in front of it), to put it in  
the header block.  
  
Note for the release notes: if anyone has inconsistent data as a  
result of saving the output of bitshiftright() in a table, it's  
possible to fix it with something like  
UPDATE mytab SET bitcol = ~(~bitcol) WHERE bitcol != ~(~bitcol);  
  
This has been broken since day one, so back-patch to all supported  
branches.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 24f64fba0ad8bc0c32d0bd56b1ebd93523b7facf    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 20 Sep 2019 19:53:33 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 20 Sep 2019 19:53:33 -0400    

DST law changes in Fiji and Norfolk Island.  Historical corrections  
for Alberta, Austria, Belgium, British Columbia, Cambodia, Hong Kong,  
Indiana (Perry County), Kaliningrad, Kentucky, Michigan, Norfolk  
Island, South Korea, and Turkey.  

commit   : 2a98eefc1a15dc32e816ced86d1fd768fefb54b0    
  
author   : Amit Kapila <[email protected]>    
date     : Fri, 20 Sep 2019 07:38:06 +0530    
  
committer: Amit Kapila <[email protected]>    
date     : Fri, 20 Sep 2019 07:38:06 +0530    

Reported-By: Kuntal Ghosh (off-list)  
Backpatch-through: 9.4, like 82fa3ff8672  

commit   : 984b9ba1d119ee59babea515b2ecab70b7b11910    
  
author   : Alexander Korotkov <[email protected]>    
date     : Thu, 19 Sep 2019 23:36:01 +0300    
  
committer: Alexander Korotkov <[email protected]>    
date     : Thu, 19 Sep 2019 23:36:01 +0300    

During backpatch of 6cae9d2c10 Float8GetDatum() was accidentally removed.  This  
commit turns it back.  
  
Reported-by: Erik Rijkers  
Discussion: https://postgr.es/m/6d51305e1159241cabee132f7efc7eff%40xs4all.nl  
Author: Tom Lane  
Backpatch-through: from 11 to 9.5  

commit   : d6a90aac563ecb5b32e2a1d902c9a18d8c21671f    
  
author   : Alexander Korotkov <[email protected]>    
date     : Thu, 19 Sep 2019 21:30:19 +0300    
  
committer: Alexander Korotkov <[email protected]>    
date     : Thu, 19 Sep 2019 21:30:19 +0300    

This commit improves subject in two ways:  
  
 * It removes ugliness of 02f90879e7, which stores distance values and null  
   flags in two separate arrays after GISTSearchItem struct.  Instead we pack  
   both distance value and null flag in IndexOrderByDistance struct.  Alignment  
   overhead should be negligible, because we typically deal with at most few  
   "col op const" expressions in ORDER BY clause.  
 * It fixes handling of "col op NULL" expression in KNN-SP-GiST.  Now, these  
   expression are not passed to support functions, which can't deal with them.  
   Instead, NULL result is implicitly assumed.  It future we may decide to  
   teach support functions to deal with NULL arguments, but current solution is  
   bugfix suitable for backpatch.  
  
Reported-by: Nikita Glukhov  
Discussion: https://postgr.es/m/826f57ee-afc7-8977-c44c-6111d18b02ec%40postgrespro.ru  
Author: Nikita Glukhov  
Reviewed-by: Alexander Korotkov  
Backpatch-through: 9.4  

commit   : 3153328fa918e57192bc72fe9dd0da07836da070    
  
author   : Michael Paquier <[email protected]>    
date     : Thu, 19 Sep 2019 13:19:04 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Thu, 19 Sep 2019 13:19:04 +0900    

This fixes an inconsistency with this parameter name not listed in the  
command synopsis, and connection_name is the parameter name more  
commonly used in the docs for ECPG commands.  
  
Reported-by: Yusuke Egashita  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 9.4  

commit   : 1831c6b1841c7237eeb426556c5cae8aaa64c8e1    
  
author   : Amit Kapila <[email protected]>    
date     : Thu, 19 Sep 2019 08:02:12 +0530    
  
committer: Amit Kapila <[email protected]>    
date     : Thu, 19 Sep 2019 08:02:12 +0530    

It's important users be able to know (without looking at the source code)  
that running DDL or DDL-like commands can interrupt autovacuum which can  
lead to a lot of dead tuples and hence slower database operations.  
  
Reported-by: James Coleman  
Author: James Coleman  
Reviewed-by: Amit Kapila  
Backpatch-through: 9.4  
Discussion: https://postgr.es/m/CAAaqYe-XYyNwML1=f=gnd0qWg46PnvD=BDrCZ5-L94B887XVxQ@mail.gmail.com  

commit   : 79b562448cb3b013e93a9d740c59fb438be527a0    
  
author   : Alvaro Herrera <[email protected]>    
date     : Wed, 18 Sep 2019 11:24:12 -0300    
  
committer: Alvaro Herrera <[email protected]>    
date     : Wed, 18 Sep 2019 11:24:12 -0300    

Lack of quotes results in failure to run the test under older Solaris.  
  
Author: Marina Polyakova, Victor Wagner  
Discussion: https://postgr.es/m/[email protected]  

commit   : 5b7d305e8d122c3b5c815015256a132c4dbfc40d    
  
author   : Etsuro Fujita <[email protected]>    
date     : Wed, 18 Sep 2019 18:50:02 +0900    
  
committer: Etsuro Fujita <[email protected]>    
date     : Wed, 18 Sep 2019 18:50:02 +0900    

1. Commit 7086be6e3 should have documented the limitation that the direct  
   modification is disabled when WCO constraints are present, but didn't,  
   which is definitely my fault.  Update the documentation (Postgres 9.6  
   onwards).  
  
2. Commit fc22b6623 should have documented the limitation that the direct  
   modification is disabled when generated columns are defined, but  
   didn't.  Update the documentation (Postgres 12 onwards).  
  
Author: Etsuro Fujita  
Discussion: https://postgr.es/m/CAPmGK14AYCPunLb6TRz1CQsW5Le01Z2ox8LSOKH0P-cOVDcQRA%40mail.gmail.com  

commit   : 40ad4202513c72f5c1beeb03e26dfbc8890770c0    
  
author   : Noah Misch <[email protected]>    
date     : Fri, 13 Sep 2019 19:34:06 -0700    
  
committer: Noah Misch <[email protected]>    
date     : Fri, 13 Sep 2019 19:34:06 -0700    

PostgreSQL has been unusable when built with xlc 13 and newer, which are  
incompatible with our use of __fetch_and_add().  Back-patch to 9.5,  
which introduced pg_atomic_fetch_add_u32().  
  
Reviewed by Tom Lane.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 585fc561f8246fde76cee691607cc43325e16b29    
  
author   : Noah Misch <[email protected]>    
date     : Fri, 13 Sep 2019 19:33:30 -0700    
  
committer: Noah Misch <[email protected]>    
date     : Fri, 13 Sep 2019 19:33:30 -0700    

Back-patch to 9.5, which introduced these functions.  
  
Reviewed by Tom Lane.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 41f3d262693b1d735a3683104e334f1e9b48d7f4    
  
author   : Alvaro Herrera <[email protected]>    
date     : Fri, 13 Sep 2019 16:36:28 -0300    
  
committer: Alvaro Herrera <[email protected]>    
date     : Fri, 13 Sep 2019 16:36:28 -0300    

Most WAL records are ignored in early SnapBuild snapshot build phases.  
But it's critical to process some of them, so that later messages have  
the correct transaction state after the snapshot is completely built; in  
particular, XLOG_XACT_ASSIGNMENT messages are critical in order for  
sub-transactions to be correctly assigned to their parent transactions,  
or at least one assert misbehaves, as reported by Ildar Musin.  
  
Diagnosed-by: Masahiko Sawada  
Author: Masahiko Sawada  
Discussion: https://postgr.es/m/CAONYFtOv+Er1p3WAuwUsy1zsCFrSYvpHLhapC_fMD-zNaRWxYg@mail.gmail.com  

commit   : 82d0ae919ff8e7a9cb9283420a8834c9b9344128    
  
author   : Alvaro Herrera <[email protected]>    
date     : Fri, 13 Sep 2019 16:26:55 -0300    
  
committer: Alvaro Herrera <[email protected]>    
date     : Fri, 13 Sep 2019 16:26:55 -0300    

Lack of parens in the definitions could cause a statement using these  
macros to have unexpected semantics.  In current code no bug is  
apparent, but best to fix the definitions to avoid problems down the  
line.  
  
Reported-by: Tom Lane  
Discussion: https://postgr.es/m/[email protected]  

commit   : e87b00b5f650a3c87db67049842f743d534b1cb1    
  
author   : Peter Geoghegan <[email protected]>    
date     : Thu, 12 Sep 2019 15:45:05 -0700    
  
committer: Peter Geoghegan <[email protected]>    
date     : Thu, 12 Sep 2019 15:45:05 -0700    

Include newitemoff in rmgr desc output for nbtree page split records.  
In passing, correct an obsolete comment that claimed that newitemoff is  
only logged for _L variant nbtree page split WAL records.  
  
Both issues were oversights in commit 2c03216d831, which revamped the  
WAL format.  
  
Author: Peter Geoghegan  
Backpatch: 9.5-, where the WAL format was revamped.  

commit   : 64d926f2b073d6bc7285bf095fea0a639fb3cd53    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 12 Sep 2019 18:29:17 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 12 Sep 2019 18:29:17 -0400    

Since WITH CHECK OPTION was introduced, ExecInitModifyTable has  
initialized WCO expressions with the wrong plan node as parent -- that is,  
it passed its input subplan not the ModifyTable node itself.  Up to now  
we thought this was harmless, but bug #16006 from Vinay Banakar shows it's  
not: if the input node is a SubqueryScan then ExecInitWholeRowVar can get  
confused into doing the wrong thing.  (The fact that ExecInitWholeRowVar  
contains such logic is certainly a horrid kluge that doesn't deserve to  
live, but figuring out another way to do that is a task for some other day.)  
  
Andres had already noticed the wrong-parent mistake and fixed it in commit  
148e632c0, but not being aware of any user-visible consequences, he quite  
reasonably didn't back-patch.  This patch is simply a back-patch of  
148e632c0, plus addition of a test case based on bug #16006.  I also added  
the test case to v12/HEAD, even though the bug is already fixed there.  
  
Back-patch to all supported branches.  9.4 lacks RLS policies so the  
new test case doesn't work there, but I'm pretty sure a test could be  
devised based on using a whole-row Var in a plain WITH CHECK OPTION  
condition.  (I lack the cycles to do so myself, though.)  
  
Andres Freund and Tom Lane  
  
Discussion: https://postgr.es/m/[email protected]  
Discussion: https://postgr.es/m/[email protected]  

commit   : 728c49779ba885d72f298d549fceb89789078b55    
  
author   : Alvaro Herrera <[email protected]>    
date     : Thu, 12 Sep 2019 16:52:03 -0300    
  
committer: Alvaro Herrera <[email protected]>    
date     : Thu, 12 Sep 2019 16:52:03 -0300    

Add a section explaining how our XML features depart from current  
versions of the SQL standard.  Update and clarify the descriptions  
of some XML functions.  
  
This is a backpatch for branches 10 and 11, taken from Tom's commit  
12d46ac392d0 for 12, then edited to correctly describe behaviors that  
are fixed in 12 but still broken in 10 and 11.  
  
Chapman Flack, reviewed by Ryan Lambert  
  
Discussion: https://postgr.es/m/[email protected]  
Discussion: https://postgr.es/m/[email protected]  
Discussion: https://postgr.es/m/CAN-V+g-6JqUQEQZ55Q3toXEN6d5Ez5uvzL4VR+8KtvJKj31taw@mail.gmail.com  

commit   : 1fcb73fe72dc3f2de50ca7e0d2b866a6fc8e8dc2    
  
author   : Amit Kapila <[email protected]>    
date     : Wed, 11 Sep 2019 10:25:49 +0530    
  
committer: Amit Kapila <[email protected]>    
date     : Wed, 11 Sep 2019 10:25:49 +0530    

The example used to explain 'Looping Through Query Results' uses  
pseudo-materialized views.  Replace it with a more up-to-date example  
which does the same thing with actual materialized views, which have  
been available since PostgreSQL 9.3.  
  
In the passing, change '%' as format specifier instead of '%s' as is used  
in other examples in plpgsql.sgml.  
  
Reported-by: Ian Barwick  
Author: Ian Barwick  
Reviewed-by: Amit Kapila  
Backpatch-through: 9.4  
Discussion: https://postgr.es/m/[email protected]  

commit   : 8da17f3f50612300f11c79b2f28e0b5fae9ac0b2    
  
author   : Michael Paquier <[email protected]>    
date     : Wed, 11 Sep 2019 11:07:29 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Wed, 11 Sep 2019 11:07:29 +0900    

Depending on the system used, t/*.pl may not be expanded into a list of  
tests which can be consumed by prove when attempting to run TAP tests on  
a given path.  Fix that by using glob() directly in the script, to make  
sure that a complete list of tests is provided.  This has not proved to  
be an issue with MSVC as the list was properly expanded, but it is on  
Linux with perl's system().  
  
This is extracted from a larger patch.  
  
Author: Tom Lane  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 9.4  

commit   : b5784042ae7a8c15dc44a7d0112b575dfcc101dc    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 10 Sep 2019 12:45:32 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 10 Sep 2019 12:45:32 -0400    

Back-patch relevant parts of these commits:  
30717637c Fix isolationtester race condition for notices sent before blocking  
ebd499282 Don't drop NOTICE messages in isolation tests  
a28e10e82 Indicate session name in isolationtester notices  
  
This ensures that older versions of the isolationtester will handle  
NOTICE/WARNING messages the same way as HEAD and v12 do.  While this  
isn't fixing any critical problem right now, it seems like a prudent  
change to prevent surprises (like we had yesterday...) with  
back-patches of future isolation test changes.  
  
Back-patch as far as 9.6.  Due to the significant changes we made in  
isolationtester in 9.6, back-patching isolation tests further than  
that is going to be risky anyway; besides, this patch doesn't apply  
cleanly before that.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 8459f908c6166e0249c310a03a3d1265ff7b7972    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 9 Sep 2019 14:21:40 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 9 Sep 2019 14:21:40 -0400    

Don't just assume that the next port is free; it might not be, or  
if we're really unlucky it might even be out of the TCP range.  
Do it honestly with two get_free_port() calls instead.  
  
This is surely a pretty low-probability problem, but I think it  
explains a buildfarm failure seen today, so let's fix it.  
  
Back-patch to v11 where this script was added.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : eec51447012a41c88d6d6b6b6bd98153908b1322    
  
author   : Andrew Dunstan <[email protected]>    
date     : Mon, 9 Sep 2019 08:56:33 -0400    
  
committer: Andrew Dunstan <[email protected]>    
date     : Mon, 9 Sep 2019 08:56:33 -0400    

Modern versions of msys2 have changed the treatment of "cmd /c" so that  
the runtime will try to convert the switch to a native file path. This  
patch adds a setting to inhibit that behaviour.  
  
Discussion: https://postgr.es/m/[email protected]  
  
Backpatch to all live branches.  

commit   : b97a345d96919ea65770e2049e2404e7a0891852    
  
author   : Andrew Dunstan <[email protected]>    
date     : Mon, 9 Sep 2019 08:42:06 -0400    
  
committer: Andrew Dunstan <[email protected]>    
date     : Mon, 9 Sep 2019 08:42:06 -0400    

These tests were disabled on git master in commit 8e5ce1c3f8. This does  
the same thing on the back branches.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 69f883fef14a3fc5849126799278abcc43f40f56    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 8 Sep 2019 17:00:29 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 8 Sep 2019 17:00:29 -0400    

Some of these are quite old, but that doesn't make them not bugs.  
We'd rather report a failure via elog than SIGSEGV.  
  
While at it, uniformly spell the error check as !RelationIsValid(rel)  
rather than a bare rel == NULL test.  The machine code is the same  
but it seems better to be consistent.  
  
Coverity complained about this today, not sure why, because the  
mistake is in fact old.  

commit   : d807200b4a73a100cb8f41ee2f3ff1e2507647b8    
  
author   : Alexander Korotkov <[email protected]>    
date     : Sun, 8 Sep 2019 21:13:40 +0300    
  
committer: Alexander Korotkov <[email protected]>    
date     : Sun, 8 Sep 2019 21:13:40 +0300    

In order to implement NULL LAST semantic GiST previously assumed distance to  
the NULL value to be Inf.  However, our distance functions can return Inf and  
NaN for non-null values.  In such cases, NULL LAST semantic appears to be  
broken.  This commit fixes that by introducing separate array of null flags for  
distances.  
  
Backpatch to all supported versions.  
  
Discussion: https://postgr.es/m/CAPpHfdsNvNdA0DBS%2BwMpFrgwT6C3-q50sFVGLSiuWnV3FqOJuQ%40mail.gmail.com  
Author: Alexander Korotkov  
Backpatch-through: 9.4  

commit   : 749b04d1d8b8ad63d365b8f6ad9d70843f3c1239    
  
author   : Alexander Korotkov <[email protected]>    
date     : Sun, 8 Sep 2019 21:07:30 +0300    
  
committer: Alexander Korotkov <[email protected]>    
date     : Sun, 8 Sep 2019 21:07:30 +0300    

Previously plain float comparison was used in GiST pairing heap.  Such  
comparison doesn't provide proper ordering for value sets containing Inf and Nan  
values.  This commit fixes that by usage of float8_cmp_internal().  Note, there  
is remaining problem with NULL distances, which are represented as Inf in  
pairing heap.  It would be fixes in subsequent commit.  
  
Backpatch to all supported versions.  
  
Reported-by: Andrey Borodin  
Discussion: https://postgr.es/m/CAPpHfdsNvNdA0DBS%2BwMpFrgwT6C3-q50sFVGLSiuWnV3FqOJuQ%40mail.gmail.com  
Author: Alexander Korotkov  
Reviewed-by: Heikki Linnakangas  
Backpatch-through: 9.4  

commit   : 7babff18dc26506d4a05f75283ae621d3b8a1950    
  
author   : Peter Eisentraut <[email protected]>    
date     : Fri, 6 Sep 2019 22:19:53 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Fri, 6 Sep 2019 22:19:53 +0200    

commit   : 61c65cce40e683333c43abb12a9c81ed659c8de0    
  
author   : Robert Haas <[email protected]>    
date     : Fri, 6 Sep 2019 08:22:32 -0400    
  
committer: Robert Haas <[email protected]>    
date     : Fri, 6 Sep 2019 08:22:32 -0400    

The old code didn't differentiate between a read error and a  
concurrent truncation. fread reports both of these by returning 0;  
you have to use feof() or ferror() to distinguish between them,  
which this code did not do.  
  
It might be a better idea to use read() rather than fread() here,  
so that we can display a less-generic error message, but I'm not  
sure that would qualify as a back-patchable bug fix, so just do  
this much for now.  
  
Jeevan Chalke, reviewed by Jeevan Ladhe and by me.  
  
Discussion: http://postgr.es/m/CA+TgmobG4ywMzL5oQq2a8YKp8x2p3p1LOMMcGqpS7aekT9+ETA@mail.gmail.com  

commit   : af28744288b1de46615c947be69935c2172374c7    
  
author   : Michael Paquier <[email protected]>    
date     : Wed, 4 Sep 2019 15:46:49 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Wed, 4 Sep 2019 15:46:49 +0900    

The logic ending progress reporting for a backend entry introduced by  
b6fb647 causes callers of pgstat_progress_end_command() to do some extra  
work when track_activities is enabled as the process fields are reset in  
the backend entry even if no command were started for reporting.  
  
This resets the fields only if a command is registered for progress  
reporting, and only if track_activities is enabled.  
  
Author: Masahiho Sawada  
Discussion: https://postgr.es/m/CAD21AoCry_vJ0E-m5oxJXGL3pnos-xYGCzF95rK5Bbi3Uf-rpA@mail.gmail.com  
Backpatch-through: 9.6  

commit   : 996c92b27dfe5e36702f3a5a06c883b76be98705    
  
author   : Michael Paquier <[email protected]>    
date     : Wed, 4 Sep 2019 13:24:06 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Wed, 4 Sep 2019 13:24:06 +0900    

Since the addition of fsync requests in bc34223 to make base backup data  
consistent on disk once pg_basebackup finishes, each tablespace tar file  
is individually flushed once completed, with an additional flush of the  
parent directory when the base backup finishes.  While holding a  
connection to the server, a fsync request taking a long time may cause a  
failure of the base backup, which is annoying for any integration.  A  
recent example of breakage can involve tcp_user_timeout, but  
wal_sender_timeout can cause similar problems.  
  
While reviewing the code, there was a second issue causing too many  
fsync requests to be done for the same WAL data.  As recursive fsyncs  
are done at the end of the backup for both the plain and tar formats  
from the base target directory where everything is written, it is fine  
to disable fsyncs when fetching or streaming WAL.  
  
Reported-by: Ryohei Takahashi  
Author: Michael Paquier  
Reviewed-by: Ryohei Takahashi  
Discussion: https://postgr.es/m/OSBPR01MB4550DAE2F8C9502894A45AAB82BE0@OSBPR01MB4550.jpnprd01.prod.outlook.com  
Backpatch-through: 10  

commit   : f967a1fda89b8b96b363109af21d521ed9d50877    
  
author   : Michael Paquier <[email protected]>    
date     : Tue, 3 Sep 2019 12:31:08 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Tue, 3 Sep 2019 12:31:08 +0900    

The leak happens in str_tolower, str_toupper and str_initcap, which are  
used in several places including their equivalent SQL-level functions,  
and can only be triggered when using an ICU-provided collation when  
converting the input string.  
  
b615920 fixed a similar leak.  Backpatch down 10 where ICU collations  
have been introduced.  
  
Author: Konstantin Knizhnik  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 10  

commit   : 5524ef55818b77068ccbbf53f065dedcc6b50120    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 2 Sep 2019 14:02:46 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 2 Sep 2019 14:02:46 -0400    

After an unexpected connection loss and successful reconnection,  
psql neglected to resynchronize its internal state about the server,  
such as server version.  Ordinarily we'd be reconnecting to the same  
server and so this isn't really necessary, but there are scenarios  
where we do need to update --- one example is where we have a list  
of possible connection targets and they're not all alike.  
  
Define "resynchronize" as including connection_warnings(), so that  
this case acts the same as \connect.  This seems useful; for example,  
if the server version did change, the user might wish to know that.  
An attuned user might also notice that the new connection isn't  
SSL-encrypted, for example, though this approach isn't especially  
in-your-face about such changes.  Although this part is a behavioral  
change, it only affects interactive sessions, so it should not break  
any applications.  
  
Also, in do_connect, make sure that we desynchronize correctly when  
abandoning an old connection in non-interactive mode.  
  
These problems evidently are the result of people patching only one  
of the two places where psql deals with connection changes, so insert  
some cross-referencing comments in hopes of forestalling future bugs  
of the same ilk.  
  
Lastly, in Windows builds, issue codepage mismatch warnings only at  
startup, not during reconnections.  psql's codepage can't change  
during a reconnect, so complaining about it again seems like useless  
noise.  
  
Peter Billen and Tom Lane.  Back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/CAMTXbE8e6U=EBQfNSe01Ej17CBStGiudMAGSOPaw-ALxM-5jXg@mail.gmail.com  

commit   : 232f645ae20ff12285ce475206408e6a7c5dd891    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 31 Aug 2019 14:05:32 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 31 Aug 2019 14:05:32 -0400    

These have been there a long time, but their format was never explained  
in the docs.  Per complaint from Yusuke Egashira.  
  
Discussion: https://postgr.es/m/848B1649C8A6274AA527C4472CA11EDD5FC70CBE@G01JPEXMBYT02  

commit   : 8c88d21ced41b3a8b227235765065158b723e280    
  
author   : Etsuro Fujita <[email protected]>    
date     : Thu, 29 Aug 2019 18:45:02 +0900    
  
committer: Etsuro Fujita <[email protected]>    
date     : Thu, 29 Aug 2019 18:45:02 +0900    

commit   : 1c99acc6ebbfbd8be01b7e118b0f5d938aacf0ed    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Wed, 28 Aug 2019 12:55:33 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Wed, 28 Aug 2019 12:55:33 +0300    

The comment did not match what the code actually did for integers with  
the 43rd bit set. You get an integer like that, if you have a posting  
list with two adjacent TIDs that are more than 2^31 blocks apart.  
According to the comment, we would store that in 6 bytes, with no  
continuation bit on the 6th byte, but in reality, the code encodes it  
using 7 bytes, with a continuation bit on the 6th byte as normal.  
  
The decoding routine also handled these 7-byte integers correctly, except  
for an overflow check that assumed that one integer needs at most 6 bytes.  
Fix the overflow check, and fix the comment to match what the code  
actually does. Also fix the comment that claimed that there are 17 unused  
bits in the 64-bit representation of an item pointer. In reality, there  
are 64-32-11=21.  
  
Fitting any item pointer into max 6 bytes was an important property when  
this was written, because in the old pre-9.4 format, item pointers were  
stored as plain arrays, with 6 bytes for every item pointer. The maximum  
of 6 bytes per integer in the new format guaranteed that we could convert  
any page from the old format to the new format after upgrade, so that the  
new format was never larger than the old format. But we hardly need to  
worry about that anymore, and running into that problem during upgrade,  
where an item pointer is expanded from 6 to 7 bytes such that the data  
doesn't fit on a page anymore, is implausible in practice anyway.  
  
Backpatch to all supported versions.  
  
This also includes a little test module to test these large distances  
between item pointers, without requiring a 16 TB table. It is not  
backpatched, I'm including it more for the benefit of future development  
of new posting list formats.  
  
Discussion: https://www.postgresql.org/message-id/33bfc20a-5c86-f50c-f5a5-58e9925d05ff%40iki.fi  
Reviewed-by: Masahiko Sawada, Alexander Korotkov  

commit   : b9c4ccfefca00dc42db9761a8b6f930a040c82c9    
  
author   : Thomas Munro <[email protected]>    
date     : Wed, 28 Aug 2019 13:37:03 +1200    
  
committer: Thomas Munro <[email protected]>    
date     : Wed, 28 Aug 2019 13:37:03 +1200    

RelationAllowsEarlyPruning() performed a catalog scan, but is used  
in two contexts where that was a bad idea:  
  
1.  In heap_page_prune_opt(), which runs very frequently in some large  
    scans.  This caused major performance problems in a field report  
    that was easy to reproduce.  
  
2.  In TestForOldSnapshot(), which runs while we hold a buffer content  
    lock.  It's not clear if this was guaranteed to be free of buffer  
    deadlock risk.  
  
The check was introduced in commit 2cc41acd8 and defended against a  
real problem: 9.6's hash indexes have no page LSN and so we can't  
allow early pruning (ie the snapshot-too-old feature).  We can remove  
the check from all later releases though: hash indexes are now logged,  
and there is no way to create UNLOGGED indexes on regular logged  
tables.  
  
If a future release allows such a combination, it might need to put  
a similar check in place, but it'll need some more thought.  
  
Back-patch to 10.  
  
Author: Thomas Munro  
Reviewed-by: Tom Lane, who spotted the second problem  
Discussion: https://postgr.es/m/CA%2BhUKGKT8oTkp5jw_U4p0S-7UG9zsvtw_M47Y285bER6a2gD%2Bg%40mail.gmail.com  
Discussion: https://postgr.es/m/CAA4eK1%2BWy%2BN4eE5zPm765h68LrkWc3Biu_8rzzi%2BOYX4j%2BiHRw%40mail.gmail.com  

commit   : f51006ea9657d6fcad89298520f42071fcf2199e    
  
author   : Michael Paquier <[email protected]>    
date     : Wed, 28 Aug 2019 11:48:19 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Wed, 28 Aug 2019 11:48:19 +0900    

In this case, the transfer uses a libpq connection, which is subject to  
the timeout parameters set at system level, and this can make the rewind  
operation suddenly canceled which is not good for automation.  One  
workaround to such issues would be to use PGOPTIONS to enforce the  
wanted timeout parameters, but that's annoying, and for example pg_dump,  
which can run potentially long-running queries disables all types of  
timeouts.  
  
lock_timeout and statement_timeout are the ones which can cause problems  
now.  Note that pg_rewind does not use transactions, so disabling  
idle_in_transaction_session_timeout is optional, but it feels safer to  
do so for the future.  
  
This is back-patched down to 9.5.  idle_in_transaction_session_timeout  
is only present since 9.6.  
  
Author: Alexander Kukushkin  
Discussion: https://postgr.es/m/CAFh8B=krcVXksxiwVQh1SoY+ziJ-JC=6FcuoBL3yce_40Es5_g@mail.gmail.com  
Backpatch-through: 9.5  

commit   : 8635d73e2f2297820751e725c0c8a01e507cf951    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 27 Aug 2019 18:03:09 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 27 Aug 2019 18:03:09 -0400    

Give it an explanatory para like the other default roles have.  
Don't imply that it can send any signal whatever.  
  
In passing, reorder the table entries and explanatory paras  
for the default roles into some semblance of consistency.  
  
Ian Barwick, tweaked a bit by me.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : e352a005bc34d8d1a3b3529688996985001cfc62    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 27 Aug 2019 16:37:22 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 27 Aug 2019 16:37:22 -0400    

Section 4.2.7 says that unless otherwise specified, built-in  
aggregates ignore rows in which any input is null.  This is  
not true of the JSON aggregates, but it wasn't documented.  
Fix that.  
  
Of the other entries in table 9.55, some were explicit about  
ignoring nulls, and some weren't; for consistency and  
self-contained-ness, make them all say it explicitly.  
  
Per bug #15884 from Tim Möhlmann.  Back-patch to all supported  
branches.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : cf86803e8e8ede508b6900b833339f65d0eabd76    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 27 Aug 2019 14:44:26 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 27 Aug 2019 14:44:26 -0400    

An empty file name or subdirectory name leads join_path_components() to  
just produce the parent directory name, which leads to weird failures or  
recursive inclusions.  Let's throw a specific error for that.  It takes  
only slightly more code to detect all-blank names, so do so.  
  
Also, detect direct recursion, ie a file calling itself.  As coded  
this will also detect recursion via "include_dir '.'", which is  
perhaps more likely than explicitly including the file itself.  
  
Detecting indirect recursion would require API changes for guc-file.l  
functions, which seems not worth it since extensions might call them.  
The nesting depth limit will catch such cases eventually, just not  
with such an on-point error message.  
  
In passing, adjust the example usages in postgresql.conf.sample  
to perhaps eliminate the problem at the source: there's no reason  
for the examples to suggest that an empty value is valid.  
  
Per a trouble report from Brent Bates.  Back-patch to 9.5; the  
issue is old, but the code in 9.4 is enough different that the  
patch doesn't apply easily, and it doesn't seem worth the trouble  
to fix there.  
  
Ian Barwick and Tom Lane  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 128e9b2cc9796da5f5b3056ab8baa4652dd68480    
  
author   : Michael Paquier <[email protected]>    
date     : Tue, 27 Aug 2019 09:11:43 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Tue, 27 Aug 2019 09:11:43 +0900    

FD_SETSIZE needs to be declared before winsock2.h, or it is possible to  
run into buffer overflow issues when using --jobs.  This is similar to  
pgbench's solution done in a23c641.  
  
This has been introduced by 71d84ef, and older versions have been using  
the default value of FD_SETSIZE, defined at 64.  While on it, add a  
missing newline to the previously-added error message.  
  
Per buildfarm member jacana, but this impacts all Windows animals  
running the TAP tests.  I have reproduced the failure locally to check  
the patch.  
  
Author: Michael Paquier  
Reviewed-by: Andrew Dunstan  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 9.5  

commit   : ad9b419f7cbe82ef843b74a983e7cad656d96ebf    
  
author   : Andrew Dunstan <[email protected]>    
date     : Mon, 26 Aug 2019 08:11:27 -0400    
  
committer: Andrew Dunstan <[email protected]>    
date     : Mon, 26 Aug 2019 08:11:27 -0400    

Previously 'uname -r' on Msys2 reported a kernele release starting with  
2. The latest version starts with 3. In commit 1638623f we specifically  
looked for one starting with 2. This is now changed to look for any  
digit between 2 and 9.  
  
backpatch to release 10.  

commit   : 3a1417c4265b93d7fdfcdbcb9c9fc18cbbff3b5b    
  
author   : Andrew Dunstan <[email protected]>    
date     : Mon, 26 Aug 2019 07:44:34 -0400    
  
committer: Andrew Dunstan <[email protected]>    
date     : Mon, 26 Aug 2019 07:44:34 -0400    

On msys2, 'uname -s' reports a string starting MSYS instead on MINGW  
as happens on msys1. Treat these both the same way. This reverts  
608a710195a4b in favor of a more general solution.  
  
Backpatch to all live branches.  

commit   : 5d76c8037329bc259bc1633a09a8550c72650a77    
  
author   : Michael Paquier <[email protected]>    
date     : Mon, 26 Aug 2019 11:14:28 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Mon, 26 Aug 2019 11:14:28 +0900    

When trying to use a high number of jobs, vacuumdb has only checked for  
a maximum number of jobs used, causing confusing failures when running  
out of file descriptors when the jobs open connections to Postgres.  
This commit changes the error handling so as we do not check anymore for  
a maximum number of allowed jobs when parsing the option value with  
FD_SETSIZE, but check instead if a file descriptor is within the  
supported range when opening the connections for the jobs so as this is  
detected at the earliest time possible.  
  
Also, improve the error message to give a hint about the number of jobs  
recommended, using a wording given by the reviewers of the patch.  
  
Reported-by: Andres Freund  
Author: Michael Paquier  
Reviewed-by: Andres Freund, Álvaro Herrera, Tom Lane  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 9.5  

commit   : 5fc7b1e939c432439f7c74885b7d053e5c1cab6f    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 25 Aug 2019 15:04:04 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 25 Aug 2019 15:04:04 -0400    

POSIX permits getopt() to advance optind beyond argc when the last  
argv entry is an option that requires an argument and hasn't got one.  
It seems that no major platforms actually do that, but musl does,  
so that something like "psql -f" would crash with that libc.  
Add a check that optind is in range before trying to look at the  
possibly-bogus option.  
  
Report and fix by Quentin Rameau.  Back-patch to all supported  
branches.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : ee18293a4e722e7681e264dfeab9f0af24d4adb1    
  
author   : Thomas Munro <[email protected]>    
date     : Sun, 25 Aug 2019 13:54:48 +1200    
  
committer: Thomas Munro <[email protected]>    
date     : Sun, 25 Aug 2019 13:54:48 +1200    

Bleeding-edge LLVM has stopped supplying replacements for various  
C++14 library features, for people on older C++ versions.  Since we're  
not ready to require C++14 yet, just use plain old new instead of  
make_unique.  As revealed by buildfarm animal seawasp.  
  
Back-patch to 11.  
  
Reviewed-by: Andres Freund  
Discussion: https://postgr.es/m/CA%2BhUKGJWG7unNqmkxg7nC5o3o-0p2XP6co4r%3D9epqYMm8UY4Mw%40mail.gmail.com  

commit   : 6472d7ad5d70690438385bb90460a1e84553c6d9    
  
author   : Michael Paquier <[email protected]>    
date     : Fri, 23 Aug 2019 20:41:18 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Fri, 23 Aug 2019 20:41:18 +0900    

This adds a section for heap-related functions.  These were previously  
mixed with functions having a more general purpose, leading to  
confusion.  While on it, add a query example for fsm_page_contents.  
  
Backpatch down to 10, where b5e3942 introduced the subsections for  
function types in pageinspect documentation.  
  
Author: Masahiko Sawada  
Discussion: https://postgr.es/m/CAD21AoDyM7E1+cK3-aWejxKTGC-wVVP2B+RnJhN6inXyeRmqzw@mail.gmail.com  
Backpatch-through: 10  

commit   : 9d35bc5931f46d950341008d8fd379ab4f4108ff    
  
author   : Michael Paquier <[email protected]>    
date     : Thu, 22 Aug 2019 09:59:27 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Thu, 22 Aug 2019 09:59:27 +0900    

The "Express" flavor of Visual Studio exists up to 2017, and the  
documentation referred to "Express" for Visual Studio 2019.  
  
Author: Takuma Hoshiai  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 9.4  

commit   : dc2a2cfaa82dc94a567794b55aaae969de618191    
  
author   : Alvaro Herrera <[email protected]>    
date     : Wed, 21 Aug 2019 11:12:44 -0400    
  
committer: Alvaro Herrera <[email protected]>    
date     : Wed, 21 Aug 2019 11:12:44 -0400    

In early development patches, "replication origins" were called "identifiers";  
almost everything was renamed, but these references to the old terminology  
went unnoticed.  
  
Reported-by: Craig Ringer  

commit   : 39c2056289e93cb1ec510d40c57afe5703273a40    
  
author   : Alvaro Herrera <[email protected]>    
date     : Tue, 20 Aug 2019 16:04:09 -0400    
  
committer: Alvaro Herrera <[email protected]>    
date     : Tue, 20 Aug 2019 16:04:09 -0400    

Author: Alexander Lakhin  
Discussion: https://postgr.es/m/[email protected]  

commit   : 93dcec96ef32a80a37264e1994b462da9e35ebd4    
  
author   : Michael Paquier <[email protected]>    
date     : Tue, 20 Aug 2019 13:45:58 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Tue, 20 Aug 2019 13:45:58 +0900    

All those fixes are already included on HEAD thanks to for example  
c96581a and 66bde49, and have gone missing on back-branches.  
  
Author: Alexander Lakhin, Liudmila Mantrova  
Discussion: https://postgr.es/m/CAEkD-mDJHV3bhgezu3MUafJLoAKsOOT86+wHukKU8_NeiJYhLQ@mail.gmail.com  
Backpatch-through: 9.4  

commit   : 2b24cf91a8e20873f8c8c5154e4aa6d4986e077d    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 19 Aug 2019 18:00:57 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 19 Aug 2019 18:00:57 -0400    

If the record argument is NULL and has no declared type more concrete  
than RECORD, we can't extract useful information about the desired  
rowtype from it.  In this case, see if we're in FROM with an AS clause,  
and if so extract the needed rowtype info from AS.  
  
It worked like this before v11, but commit 37a795a60 removed the  
behavior, reasoning that it was undocumented, inefficient, and utterly  
not self-consistent.  If you want to take type info from an AS clause,  
you should be using the json_to_record() family of functions not the  
json_populate_record() family.  Also, it was already the case that  
the "populate" functions would fail for a null-valued RECORD input  
(with an unfriendly "record type has not been registered" error)  
when there wasn't an AS clause at hand, and it wasn't obvious that  
that behavior wasn't OK when there was one.  However, it emerges  
that some people were depending on this to work, and indeed the  
rather off-point error message you got if you left off AS encouraged  
slapping on AS without switching to the json_to_record() family.  
  
Hence, put back the fallback behavior of looking for AS.  While at it,  
improve the run-time error you get when there's no place to obtain type  
info; we can do a lot better than "record type has not been registered".  
(We can't, unfortunately, easily improve the parse-time error message  
that leads people down this path in the first place.)  
  
While at it, I refactored the code a bit to avoid duplicating the  
same logic in several different places.  
  
Per bug #15940 from Jaroslav Sivy.  Back-patch to v11 where the  
current coding came in.  (The pre-v11 deficiencies in this area  
aren't regressions, so we'll leave those branches alone.)  
  
Patch by me, based on preliminary analysis by Dmitry Dolgov.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 909efc4498a071df1198677bc73366f0e29492ce    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 18 Aug 2019 17:11:58 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 18 Aug 2019 17:11:58 -0400    

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.  
  
Discussion: https://postgr.es/m/CA+u7OA4qogDv9rz1HAb-ADxttXYPqQdUdPY_yd4kCzywNxRQXA@mail.gmail.com  

commit   : aed967d697de19a78a653926c72604f9b04c3b1e    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 15 Aug 2019 20:04:19 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 15 Aug 2019 20:04:19 -0400    

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.  
  
Discussion: https://postgr.es/m/CAFMLSdP0rd7LqC3j-H6Fh51FYSt5A10DDh-3=W4PPc4LLUQ8YQ@mail.gmail.com  

commit   : 6070ccdd179f34efecc92d6679a141093df0f879    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 15 Aug 2019 15:21:48 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 15 Aug 2019 15:21:48 -0400    

Commit 4b93f5799 rearranged things in plpgsql to make it cope better with  
composite types changing underneath it intra-session.  However, I failed to  
consider the case of a composite type being dropped and recreated entirely.  
In my defense, the previous coding didn't consider that possibility at all  
either --- but it would accidentally work so long as you didn't change the  
type's field list, because the built-at-compile-time list of component  
variables would then still match the type's new definition.  The new  
coding, however, occasionally tries to re-look-up the type by OID, and  
then fails to find the dropped type.  
  
To fix this, we need to save the TypeName struct, and then redo the type  
OID lookup from that.  Of course that's expensive, so we don't want to do  
it every time we need the type OID.  This can be fixed in the same way that  
4b93f5799 dealt with changes to composite types' definitions: keep an eye  
on the type's typcache entry to see if its tupledesc has been invalidated.  
(Perhaps, at some point, this mechanism should be generalized so it can  
work for non-composite types too; but for now, plpgsql only tries to  
cope with intra-session redefinitions of composites.)  
  
I'm slightly hesitant to back-patch this into v11, because it changes  
the contents of struct PLpgSQL_type as well as the signature of  
plpgsql_build_datatype(), so in principle it could break code that is  
poking into the innards of plpgsql.  However, the only popular extension  
of that ilk is pldebugger, and it doesn't seem to be affected.  Since  
this is a regression for people who were relying on the old behavior,  
it seems worth taking the small risk of causing compatibility issues.  
  
Per bug #15913 from Daniel Fiori.  Back-patch to v11 where 4b93f5799  
came in.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 7f77f2aec3d06e580915acf16c4d7c7c5d998f23    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 15 Aug 2019 11:14:26 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 15 Aug 2019 11:14:26 -0400    

Clarify what external tools can do to this file, and add a bit  
of detail about what ALTER SYSTEM itself does.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 32d38f54a369290cd5c5efb939c9f037a7c13e80    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 14 Aug 2019 15:09:20 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 14 Aug 2019 15:09:20 -0400    

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  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 4dea8ad566d3f41102a0ab79c7faefae0af71774    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 13 Aug 2019 16:57:58 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 13 Aug 2019 16:57:58 -0400    

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.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 72f92549b64176e00dad433f8486e302eab8e9bd    
  
author   : Michael Paquier <[email protected]>    
date     : Tue, 13 Aug 2019 10:56:02 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Tue, 13 Aug 2019 10:56:02 +0900    

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  
v10.  
  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 10  

commit   : 4f393793f7d637e4ab8e6460e7bb4cd747f01f85    
  
author   : Peter Geoghegan <[email protected]>    
date     : Mon, 12 Aug 2019 15:21:28 -0700    
  
committer: Peter Geoghegan <[email protected]>    
date     : Mon, 12 Aug 2019 15:21:28 -0700    

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  
Discussion: https://postgr.es/m/[email protected]  
Backpatch: 10-, where amcheck was introduced.  

commit   : c914e74d2dee0ecf372c1d40f87499d94d591935    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 12 Aug 2019 13:15:48 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 12 Aug 2019 13:15:48 -0400    

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.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : ceb850d4a30c06f2f127487acd898847b80dcfc5    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 10 Aug 2019 11:30:12 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 10 Aug 2019 11:30:12 -0400    

This failed with either "tuple already updated by self" or "duplicate  
key value violates unique constraint", depending on whether the table  
had previously been analyzed or not.  The reason is that ANALYZE tried  
to insert or update the same pg_statistic rows twice, and there was no  
CommandCounterIncrement between.  So add one.  The same case works fine  
outside a transaction block, because then there's a whole transaction  
boundary between, as a consequence of the way VACUUM works.  
  
This issue has been latent all along, but the problem was unreachable  
before commit 11d8d72c2 added the ability to specify multiple tables  
in ANALYZE.  We could, perhaps, alternatively fix it by adding code to  
de-duplicate the list of VacuumRelations --- but that would add a  
lot of overhead to work around dumb commands, so it's not attractive.  
  
Per bug #15946 from Yaroslav Schekin.  Back-patch to v11.  
  
(Note: in v11 I also back-patched the test added by commit 23224563d;  
otherwise the problem doesn't manifest in the test I added, because  
"vactst" is empty when the tests for multiple ANALYZE targets are  
reached.  That seems like not a very good thing anyway, so I did this  
rather than rethinking the choice of test case.)  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 2f729d83226705d1149419a2aef7c1678fe641ec    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 9 Aug 2019 13:20:28 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 9 Aug 2019 13:20:28 -0400    

Not much to be said here: commit 9fdb675fc should have checked  
constisnull, didn't.  
  
Per report from Piotr Włodarczyk.  Back-patch to v11 where  
bug was introduced.  
  
Discussion: https://postgr.es/m/CAP-dhMr+vRpwizEYjUjsiZ1vwqpohTm+3Pbdt6Pr7FEgPq9R0Q@mail.gmail.com  

commit   : bf6455d4c557ff9ef42985bb4806b251497bdc60    
  
author   : Alvaro Herrera <[email protected]>    
date     : Thu, 8 Aug 2019 16:03:14 -0400    
  
committer: Alvaro Herrera <[email protected]>    
date     : Thu, 8 Aug 2019 16:03:14 -0400    

Reviewed by Tom Lane and Amit Langote  
Discussion: https://postgr.es/m/[email protected]  

commit   : 273e78715a0f92708f6b7b0c99393666e3281f72    
  
author   : Andrew Dunstan <[email protected]>    
date     : Thu, 8 Aug 2019 14:57:48 -0400    
  
committer: Andrew Dunstan <[email protected]>    
date     : Thu, 8 Aug 2019 14:57:48 -0400    

openssl doesn't like lower case subject attribute names. Error observed  
in buildfarm results.  
  
Backpatch to release 11.  

commit   : ed6df2e0e39ceffef5d3099466bb077371f14443    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 7 Aug 2019 18:09:28 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 7 Aug 2019 18:09:28 -0400    

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.  
  
Discussion: https://postgr.es/m/CAMsGm5fp3oBUs-2iRfii0iEO=fZuJALVyM2zJLhNTjG34gpAVQ@mail.gmail.com  

commit   : 26555cbd6e1443ea783717fd49b2ca1d55e4a015    
  
author   : Etsuro Fujita <[email protected]>    
date     : Wed, 7 Aug 2019 19:05:19 +0900    
  
committer: Etsuro Fujita <[email protected]>    
date     : Wed, 7 Aug 2019 19:05:19 +0900    

commit   : c5b796125299b7a1b37b8b5d6e5f0b316521c33a    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Wed, 7 Aug 2019 12:40:49 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Wed, 7 Aug 2019 12:40:49 +0300    

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  
place.  
  
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).  
  
Discussion: https://www.postgresql.org/message-id/20190731210630.nqhszuktygwftjty%40alap3.anarazel.de  

commit   : d16d241a55557352e09c9ffd6ab20548b066d193    
  
author   : Michael Paquier <[email protected]>    
date     : Wed, 7 Aug 2019 18:17:39 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Wed, 7 Aug 2019 18:17:39 +0900    

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  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 9.4  

commit   : 113b3d903b348a3c8ac92cdb0389d5ca779c197f    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 6 Aug 2019 18:04:51 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 6 Aug 2019 18:04:51 -0400    

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.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : f1c23b00b9b7cee1e86a6740e5be94de163b44d4    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 6 Aug 2019 17:08:07 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 6 Aug 2019 17:08:07 -0400    

src/test/kerberos and src/test/ldap try to run private authentication  
servers, which of course might fail.  The logs from these servers  
were being dropped into the tmp_check/ subdirectory, but they should  
be put in tmp_check/log/, because the buildfarm will only capture  
log files in that subdirectory.  Without the log output there's  
little hope of diagnosing buildfarm failures related to these servers.  
  
Backpatch to v11 where these test suites were added.  
  
Discussion: https://postgr.es/m/[email protected]