PostgreSQL 12.1 commit log

commit   : 578a551f82f7ad746b36d98c401bdc92c136d664    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 11 Nov 2019 17:03:10 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 11 Nov 2019 17:03:10 -0500    

commit   : 02f7b7ab75680440695a1e205cbb6636551b6013    
  
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   : 95a8394ac79a4177f5e7a6a04dda96a06eaea159    
  
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   : c1646c81ef155ec1c687239610a5e09375e8c75a    
  
author   : Peter Eisentraut <[email protected]>    
date     : Mon, 11 Nov 2019 10:53:15 +0100    
  
committer: Peter Eisentraut <[email protected]>    
date     : Mon, 11 Nov 2019 10:53:15 +0100    

Source-Git-URL: https://git.postgresql.org/git/pgtranslation/messages.git  
Source-Git-Hash: 99bbc57cce0a1024898ac8d38b35fc6df7294e9e  

commit   : 3b0d044469d38177228e11425bb97c951123ba66    
  
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   : f967563045334c3f660805c6ad83068b5f76a00d    
  
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   : 4977a35ea79a4608a2617a06bb73488f199d062f    
  
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   : 175571923c5c6f2ddd0e8f0fae726acda8a9e067    
  
author   : Peter Eisentraut <[email protected]>    
date     : Sat, 9 Nov 2019 09:35:21 +0100    
  
committer: Peter Eisentraut <[email protected]>    
date     : Sat, 9 Nov 2019 09:35:21 +0100    

Remove one sentence that was deemed misleading.  
  
Discussion: https://www.postgresql.org/message-id/flat/E1iEgSp-0004R5-2E%40gemulon.postgresql.org  

commit   : d891d2c897859e86a7728afd151e8c07f2511168    
  
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   : 1add2e09b9a4c2d2c72ce51991fa4efaf577a29f    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 8 Nov 2019 20:12:59 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 8 Nov 2019 20:12:59 -0500    

As usual, the release notes for other branches will be made by cutting  
these down, but put them up for community review first.  Note that a  
fair percentage of the entries apply only to prior branches because  
their issue was already fixed in 12.0.  I'll remove those from the 12.1  
list later.  

commit   : b34946f9a1d2743a485117cc069432d82907e265    
  
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   : 0cc31cc32da0ff6b3569eb73249eb1549b8731d1    
  
author   : Etsuro Fujita <[email protected]>    
date     : Fri, 8 Nov 2019 17:00:31 +0900    
  
committer: Etsuro Fujita <[email protected]>    
date     : Fri, 8 Nov 2019 17:00:31 +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   : 1016549873446934dffd14e59bfa3a6b9dec9b89    
  
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   : b75ccddcd6f747dc386411eeac6bbfdface14a2c    
  
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   : f6e72dc9cc8b8f480ea4a982662c3695ddc5a549    
  
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   : e5cfb8cbbe91e73ee92d9e4ab023ca208f3b748a    
  
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   : f96f14744533e7409876056eeca0229a32fac4dd    
  
author   : Tomas Vondra <[email protected]>    
date     : Mon, 4 Nov 2019 02:00:26 +0100    
  
committer: Tomas Vondra <[email protected]>    
date     : Mon, 4 Nov 2019 02:00:26 +0100    

The docs do say which GUCs can be changed only by superusers, but we  
forgot to mention this for the new log_transaction_sample_rate. This  
GUC was introduced in PostgreSQL 12, so backpatch accordingly.  
  
Author: Adrien Nayrat  
Backpatch-through: 12  

commit   : 9dbc6d25a97d11475fde36c4f71359371bbe240b    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 6 Nov 2019 12:00:17 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 6 Nov 2019 12:00:17 -0500    

Avoid creating transiently-inconsistent slot states where possible,  
by not setting TTS_FLAG_SHOULDFREE until after the slot actually has  
a free'able tuple pointer, and by making sure that we reset tts_nvalid  
and related derived state before we replace the tuple contents.  This  
would only matter if something were to examine the slot after we'd  
suffered some kind of error (e.g. out of memory) while manipulating  
the slot.  We typically don't do that, so these changes might just be  
cosmetic --- but even if so, it seems like good future-proofing.  
  
Also remove some redundant Asserts, and add a couple for consistency.  
  
Back-patch to v12 where all this code was rewritten.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : d4d0cd6ee23e2a111a24cbb7cc0be2b8453c8d4c    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 6 Nov 2019 11:11:40 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 6 Nov 2019 11:11:40 -0500    

Since commit d26a810eb, we've defined bool as being either _Bool from  
<stdbool.h>, or "unsigned char"; but that commit overlooked the fact  
that probes.d has "#define bool char".  For consistency, make it say  
"unsigned char" instead.  This should be strictly a cosmetic change,  
but it seems best to be in sync.  
  
Formally, in the now-normal case where we're using <stdbool.h>, it'd  
be better to write "#define bool _Bool".  However, then we'd need  
some build infrastructure to inject that configuration choice into  
probes.d, and it doesn't seem worth the trouble.  We only use  
<stdbool.h> if sizeof(_Bool) is 1, so having DTrace think that  
bool parameters are "unsigned char" should be close enough.  
  
Back-patch to v12 where d26a810eb came in.  
  
Discussion: https://postgr.es/m/CAA4eK1LmaKO7Du9M9Lo=kxGU8sB6aL8fa3sF6z6d5yYYVe3BuQ@mail.gmail.com  

commit   : 39a6210f9e0fb3f285934f275f6dbffbc7c3fae9    
  
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   : 9ae4bdadf79f68ec85bad38f9393b42fa69fc93a    
  
author   : Michael Paquier <[email protected]>    
date     : Wed, 6 Nov 2019 16:12:28 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Wed, 6 Nov 2019 16:12:28 +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   : f57c63107007f3b9333d270473b9070225c23843    
  
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   : 4d616b112704411ff059321c76f438691f0f2ae8    
  
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   : f71a299c6cb87ac17b51ee1b9e389ae5a31b86fa    
  
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   : f9bd3b6d929aa731ef5b999c9fadfc2acd0b7cfe    
  
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   : 791864193636764b4cbba0acd2b4eab7581eb2c3    
  
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   : a9db37a180e536dc157aebf5bab4286a0494defc    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 5 Nov 2019 11:42:25 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 5 Nov 2019 11:42:25 -0500    

Commit d25ea0127 got rid of what I thought were entirely unnecessary  
derived child expressions in EquivalenceClasses for EC members that  
mention multiple baserels.  But it turns out that some of the child  
expressions that code created are necessary for partitionwise joins,  
else we fail to find matching pathkeys for Sort nodes.  (This happens  
only for certain shapes of the resulting plan; it may be that  
partitionwise aggregation is also necessary to show the failure,  
though I'm not sure of that.)  
  
Reverting that commit entirely would be quite painful performance-wise  
for large partition sets.  So instead, add code that explicitly  
generates child expressions that match only partitionwise child join  
rels we have actually generated.  
  
Per report from Justin Pryzby.  (Amit Langote noticed the problem  
earlier, though it's not clear if he recognized then that it could  
result in a planner error, not merely failure to exploit partitionwise  
join, in the code as-committed.)  Back-patch to v12 where commit  
d25ea0127 came in.  
  
Amit Langote, with lots of kibitzing from me  
  
Discussion: https://postgr.es/m/CA+HiwqG2WVUGmLJqtR0tPFhniO=H=9qQ+Z3L_ZC+Y3-EVQHFGg@mail.gmail.com  
Discussion: https://postgr.es/m/[email protected]  

commit   : 4d04031dd279c4494f4e7b557844f77dec2f5322    
  
author   : Michael Paquier <[email protected]>    
date     : Tue, 5 Nov 2019 10:32:43 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Tue, 5 Nov 2019 10:32:43 +0900    

Since 898e5e32, this command uses partially ShareUpdateExclusiveLock,  
but the docs did not get the call.  
  
Author: Justin Pryzby  
Reviewed-by: Amit Langote, Álvaro Herrera, Michael Paquier  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 12  

commit   : a7207a24d40e887f08cb8ad11659ecb42e85dead    
  
author   : Michael Paquier <[email protected]>    
date     : Tue, 5 Nov 2019 10:17:55 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Tue, 5 Nov 2019 10:17:55 +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   : ca27a84c98f0d071d527bfd17f500a0bd66cb4d2    
  
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   : 5a2967412f63f3b9390aa7b3af95e2fae0965ff8    
  
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 datum_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   : 6dd92138d1efd0da89e90b98bd71b76c3905f9aa    
  
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   : 43753c2cfbdd9870e68671abcc9dd377881071b0    
  
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   : 7963c4c4b7821f286e335c8aed66821c87404ce3    
  
author   : Michael Paquier <[email protected]>    
date     : Sat, 2 Nov 2019 14:16:11 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Sat, 2 Nov 2019 14:16:11 +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   : 7b8c2de64e66659115c1e4075c025d6392d659ef    
  
author   : Michael Paquier <[email protected]>    
date     : Fri, 1 Nov 2019 22:38:45 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Fri, 1 Nov 2019 22:38:45 +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   : 9de37ea65188167b0dc0acb3ce25f031c6cb4d79    
  
author   : Bruce Momjian <[email protected]>    
date     : Wed, 30 Oct 2019 13:43:16 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Wed, 30 Oct 2019 13:43:16 -0400    

Reported-by: [email protected]  
  
Diagnosed-by: Michael Paquier  
  
Discussion: https://postgr.es/m/[email protected]  
  
Author: Michael Paquier  
  
Reviewed-by: me  
  
Backpatch-through: 12 only  

commit   : d4b5206b22374ddf99dbe31370d6d713881fb87c    
  
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   : 4ab353c477e6f585973b171a2652551574cbbc45    
  
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   : eae1ba65fab4790c350264714b5eb7581c5e62be    
  
author   : Michael Paquier <[email protected]>    
date     : Tue, 29 Oct 2019 11:08:16 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Tue, 29 Oct 2019 11:08:16 +0900    

When cancelling REINDEX CONCURRENTLY after swapping the old and new  
indexes (for example interruption at step 5), the old index remains  
around and is marked as invalid.  The old index should also be manually  
droppable to clean up the parent relation from any invalid indexes still  
remaining.  For a partition index reindexed, pg_class.relispartition was  
not getting updated, causing the index to not be droppable as DROP INDEX  
would look for dependencies in a partition tree, which do not exist  
anymore after the swap phase is done.  
  
The fix here is simple: when swapping the old and new indexes, make sure  
that pg_class.relispartition is correctly switched, similarly to what is  
done for the index name.  
  
Reported-by: Justin Pryzby  
Author: Michael Paquier  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 12  

commit   : 43e43771bc4b03a9e33be7261cc84dc7f65ae9ef    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 28 Oct 2019 12:21:13 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 28 Oct 2019 12:21:13 -0400    

Commit 9556aa01c rearranged the innards of text_position() in a way  
that would make it not work for empty search strings.  Which is fine,  
because all callers of that code special-case an empty pattern in  
some way.  However, the primary use-case (text_position itself) got  
special-cased incorrectly: historically it's returned 1 not 0 for  
an empty search string.  Restore the historical behavior.  
  
Per complaint from Austin Drenski (via Shay Rojansky).  
Back-patch to v12 where it got broken.  
  
Discussion: https://postgr.es/m/CADT4RqAz7oN4vkPir86Kg1_mQBmBxCp-L_=9vRpgSNPJf0KRkw@mail.gmail.com  

commit   : b1ad895e12f099f41c8dc1a16f1b3ba2a6e29e06    
  
author   : Michael Paquier <[email protected]>    
date     : Mon, 28 Oct 2019 14:23:48 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Mon, 28 Oct 2019 14:23:48 +0900    

There is a step to track when the new heap is written, but this was  
missing in the documentation.  
  
Author: Noriyoshi Shinoda  
Discussion: https://postgr.es/m/AT5PR8401MB06447FAE88E1592754E958B8EE640@AT5PR8401MB0644.NAMPRD84.PROD.OUTLOOK.COM  
Backpatch-through: 12  

commit   : 5e5f32284d691d0be71d6859c1de9b0367b26584    
  
author   : Michael Paquier <[email protected]>    
date     : Mon, 28 Oct 2019 11:58:29 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Mon, 28 Oct 2019 11:58:29 +0900    

When swapping the dependencies of the old and new indexes, the code has  
been correctly switching all links in pg_depend from the old to the new  
index for both referencing and referenced entries.  However it forgot  
the fact that the new index may itself have existing entries in  
pg_depend, like references to the parent table attributes.  This  
resulted in duplicated entries in pg_depend after running REINDEX  
CONCURRENTLY.  
  
Fix this problem by removing any existing entries in pg_depend for the  
new index before switching the dependencies of the old index to the new  
one.  More regression tests are added to check the consistency of  
entries in pg_depend for indexes, including partitions.  
  
Author: Michael Paquier  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 12  

commit   : 9f0172bba75028a7a5b1a470406adcc2af0f3b86    
  
author   : Michael Paquier <[email protected]>    
date     : Sun, 27 Oct 2019 13:54:20 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Sun, 27 Oct 2019 13:54:20 +0900    

9155580 has changed the value of the first fake LSN for unlogged  
relations from 1 to FirstNormalUnloggedLSN (aka 1000), GiST requiring a  
non-zero LSN on some pages to allow an interlocking logic to work, but  
its value was still initialized to 1 at the beginning of recovery or  
after running pg_resetwal.  This fixes the initialization for both code  
paths.  
  
Author: Takayuki Tsunakawa  
Reviewed-by: Dilip Kumar, Kyotaro Horiguchi, Michael Paquier  
Discussion: https://postgr.es/m/OSBPR01MB2503CE851940C17DE44AE3D9FE6F0@OSBPR01MB2503.jpnprd01.prod.outlook.com  
Backpatch-through: 12  

commit   : 63ebe2009145347680eefd240d2a690fdcdbccdf    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 26 Oct 2019 12:30:41 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 26 Oct 2019 12:30:41 -0400    

When we added the GUC units feature, we didn't make any great effort  
to adjust the documentation of individual GUCs; they tended to still  
say things like "this is the number of milliseconds that ...", even  
though users might prefer to write some other units, and SHOW might  
even show the value in other units.  Commit 6c9fb69f2 made an effort  
to improve this situation, but I thought it made things less readable  
by injecting units information in mid-sentence.  It also wasn't very  
consistent, and did not touch all the GUCs that have units.  
  
To improve matters, standardize on the phrasing "If this value is  
specified without units, it is taken as <units>".  Also, try to  
standardize where this is mentioned, right before the specification  
of the default.  (In a couple of places, doing that would've required  
more rewriting than seemed justified, so I wasn't 100% consistent  
about that.)  I also tried to use the phrases "amount of time",  
"amount of memory", etc rather than describing the contents of GUCs  
in other ways, as those were the majority usage in places that weren't  
overcommitting to a particular unit.  (I left "length of time" alone  
in a couple of places, though.)  
  
I failed to resist the temptation to copy-edit some awkward text, too.  
  
Backpatch to v12, like 6c9fb69f2, mainly because v12 hasn't diverged  
much from HEAD yet.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 2bbdf8e2e827fe80fd39a4a5e2f432f4e8ae6ca3    
  
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   : 4a61aa4a945f5737c65d288077101ed202488e9a    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 25 Oct 2019 12:17:41 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 25 Oct 2019 12:17:41 -0400    

pgtypeslib_extern.h contained fallback definitions of "bool", "FALSE",  
and "TRUE".  The latter two are just plain unused, and have been for  
awhile.  The former came into play only if there wasn't a macro  
definition of "bool", which is true only if we aren't using <stdbool.h>.  
However, it then defined bool as "char"; since commit d26a810eb that  
conflicts with c.h's desire to use "unsigned char".  We'd missed seeing  
any bad effects of that due to accidental header inclusion order choices,  
but dddf4cdc3 exposed that it was problematic.  
  
To fix, let's just get rid of these definitions.  They should not be  
needed because everyplace in Postgres should be relying on c.h to  
provide a definition for type bool.  (Note that despite its name,  
pgtypeslib_extern.h isn't exposed to any outside code; we don't  
install it.)  
  
This doesn't fully resolve the issue, because ecpglib.h is doing  
similar things, but that seems to require more thought to fix.  
  
Back-patch to v12 where d26a810eb came in, to forestall any unpleasant  
surprises from future back-patched bug fixes.  
  
Discussion: https://postgr.es/m/CAA4eK1LmaKO7Du9M9Lo=kxGU8sB6aL8fa3sF6z6d5yYYVe3BuQ@mail.gmail.com  

commit   : 7f84b0ef0bfbb98e4c68d9ef94cd0ff11fc1c2c3    
  
author   : Michael Paquier <[email protected]>    
date     : Fri, 25 Oct 2019 10:20:16 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Fri, 25 Oct 2019 10:20:16 +0900    

Phases 2 (building the new index) and 3 (validating the new index)  
checked for interrupts outside a transaction context, having as  
consequence to not release session-level locks taken on the parent  
relation and the old and new indexes processed.  This could for example  
be triggered with statement_timeout and a bad timing, and would issue  
confusing error messages when shutting down the session still holding  
the locks (note that an assertion failure would be triggered first), on  
top of more issues with concurrent sessions trying to take a lock that  
would interfere with the SHARE UPDATE EXCLUSIVE locks hold here.  
  
This moves all the interruption checks inside a transaction context.  
Note that I have manually tested all interruptions to make sure that  
invalid indexes can be cleaned up properly.  Partition indexes still  
have issues on their own with some missing dependency handling, which  
will be dealt with in a follow-up patch.  
  
Reported-by: Justin Pryzby  
Author: Michael Paquier  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 12  

commit   : 56a459be51931838675b59b6be42ba1f20a8dbf1    
  
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   : 7668d48477edc3bc8d6990ac3d3bd79e327e2719    
  
author   : Michael Paquier <[email protected]>    
date     : Wed, 23 Oct 2019 15:05:09 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Wed, 23 Oct 2019 15:05:09 +0900    

In the first transaction run for REINDEX CONCURRENTLY, a thinko in the  
existing logic caused two session locks to be taken on the old index,  
causing the session lock on the newly-created index to be missed.  This  
made possible concurrent DDL commands (like ALTER INDEX) on the new  
index while REINDEX CONCURRENTLY was processing from the point where the  
first internal transaction committed.  
  
This issue has been discovered while digging into another bug.  
  
Author: Michael Paquier  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 12  

commit   : a6a95d4f382b67bc80b63e4769dfb240bafd9aa7    
  
author   : Michael Paquier <[email protected]>    
date     : Wed, 23 Oct 2019 11:34:42 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Wed, 23 Oct 2019 11:34:42 +0900    

A check was redundant.  While on it, add an assertion to make sure that  
the parsing routine is never called with a NULL input.  All the code  
paths currently calling the parsing routine are careful with NULL inputs  
already, but future callers may forget that.  
  
Reported-by: Peter Eisentraut, Lars Kanis  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 12  

commit   : 399b8d13ca5cda44ed9c4aff10c85351d8e95cff    
  
author   : Michael Paquier <[email protected]>    
date     : Wed, 23 Oct 2019 10:25:46 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Wed, 23 Oct 2019 10:25:46 +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   : 4f2ad52269750c9f04121251a23e7f6ed1fb911c    
  
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   : ca658c91ae724c0a093a039813666705ef0bcfa4    
  
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   : aa5bb828af5387e154a122b1b43ee873d92497a0    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 21 Oct 2019 12:32:35 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 21 Oct 2019 12:32:35 -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   : 48de3bb1a50d3c53f50d827a05deee5adcbb936e    
  
author   : Etsuro Fujita <[email protected]>    
date     : Mon, 21 Oct 2019 17:30:01 +0900    
  
committer: Etsuro Fujita <[email protected]>    
date     : Mon, 21 Oct 2019 17:30:01 +0900    

Commit b52b7dc25, which moved code creating PartitionBoundInfo in  
RelationBuildPartitionDesc() in partcache.c (relocated to partdesc.c  
afterwards) to partbounds.c, should have updated this, but didn't.  
  
Author: Etsuro Fujita  
Reviewed-by: Alvaro Herrera  
Backpatch-through: 12  
Discussion: https://postgr.es/m/CAPmGK16Uxr%3DPatiGyaRwiQVLB7Y-GqbkK3AxRLVYzU0Czv%3DsEw%40mail.gmail.com  

commit   : 62f4dd3796dac30e2230baa4afbb7d2a626d9373    
  
author   : Amit Kapila <[email protected]>    
date     : Thu, 17 Oct 2019 08:45:43 +0530    
  
committer: Amit Kapila <[email protected]>    
date     : Thu, 17 Oct 2019 08:45:43 +0530    

We memorize all internal and empty leaf pages in the 1st vacuum stage for  
gist indexes.  They are used in the 2nd stage, to delete all the empty  
pages.  There was a memory context page_set_context for this purpose, but  
we never used it.  
  
Reported-by: Amit Kapila  
Author: Dilip Kumar  
Reviewed-by: Amit Kapila  
Backpatch-through: 12, where it got introduced  
Discussion: https://postgr.es/m/CAA4eK1LGr+MN0xHZpJ2dfS8QNQ1a_aROKowZB+MPNep8FVtwAA@mail.gmail.com  

commit   : ed5109a616cf98d3b3b2491d043099a6e0a966a2    
  
author   : Michael Paquier <[email protected]>    
date     : Mon, 21 Oct 2019 11:39:28 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Mon, 21 Oct 2019 11:39:28 +0900    

The logic was correctly detecting a parsing failure, but the parsing  
error did not get reported back to the client properly.  
  
Reported-by: Ed Morley  
Author: Lars Kanis  
Reviewed-by: Michael Paquier  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 12  

commit   : 2b0f959b5119cb2bb1d135ac04a8c5272bbcab03    
  
author   : Michael Paquier <[email protected]>    
date     : Mon, 21 Oct 2019 11:17:43 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Mon, 21 Oct 2019 11:17:43 +0900    

Commit e7a2217 has introduced stricter checks for integer values in  
connection parameters for libpq.  However this failed to correctly check  
after trailing whitespaces, while leading whitespaces were discarded per  
the use of strtol(3).  This fixes and refactors the parsing logic to  
handle both cases consistently.  Note that trying to restrict the use of  
trailing whitespaces can easily break connection strings like in ECPG  
regression tests (these have allowed me to catch the parsing bug with  
connect_timeout).  
  
Author: Michael Paquier  
Reviewed-by: Lars Kanis  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 12  

commit   : ef13f914e6c2a66f186f73ec1bba682e56dc621b    
  
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   : 9dfbf9a04398f8b9332d95e49037c530c4dda827    
  
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   : 03666dfa1817ef602ef982a766b983efd43c460f    
  
author   : Fujii Masao <[email protected]>    
date     : Fri, 18 Oct 2019 22:24:18 +0900    
  
committer: Fujii Masao <[email protected]>    
date     : Fri, 18 Oct 2019 22:24:18 +0900    

In v11 or before, this setting could not take effect in crash recovery  
because it's specified in recovery.conf and crash recovery always  
starts without recovery.conf. But commit 2dedf4d9a8 integrated  
recovery.conf into postgresql.conf and which unexpectedly allowed  
this setting to take effect even in crash recovery. This is definitely  
not good behavior.  
  
To fix the issue, this commit makes crash recovery always ignore  
recovery_min_apply_delay setting.  
  
Back-patch to v12 where the issue was added.  
  
Author: Fujii Masao  
Reviewed-by: Michael Paquier  
Discussion: https://postgr.es/m/CAHGQGwEyD6HdZLfdWc+95g=VQFPR4zQL4n+yHxQgGEGjaSVheQ@mail.gmail.com  
Discussion: https://postgr.es/m/[email protected]  

commit   : 954b9c195999d4b891e1ece656e878f2c4f876ce    
  
author   : Alvaro Herrera <[email protected]>    
date     : Fri, 18 Oct 2019 14:49:39 +0200    
  
committer: Alvaro Herrera <[email protected]>    
date     : Fri, 18 Oct 2019 14:49:39 +0200    

Apparently while this code was being developed,  
ReindexRelationConcurrently operated on multiple relations.  The version  
that was ultimately pushed doesn't, so this comment's use of plural is  
inaccurate.  

commit   : 029390a0909f5be74e3dd9bc1ad4dbf1506287d7    
  
author   : Alvaro Herrera <[email protected]>    
date     : Fri, 18 Oct 2019 07:18:50 -0300    
  
committer: Alvaro Herrera <[email protected]>    
date     : Fri, 18 Oct 2019 07:18:50 -0300    

Michaël Paquier complained that index_drop is requesting progress  
reporting for non-obvious reasons, so let's add a comment to explain  
why.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 04510dbe34b9d8eef1754413806c56fcc1d369ed    
  
author   : Michael Paquier <[email protected]>    
date     : Fri, 18 Oct 2019 14:26:53 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Fri, 18 Oct 2019 14:26:53 +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   : 1391c13ce3b898caad07261223bb75f8390c45e2    
  
author   : Alvaro Herrera <[email protected]>    
date     : Thu, 17 Oct 2019 15:06:06 +0200    
  
committer: Alvaro Herrera <[email protected]>    
date     : Thu, 17 Oct 2019 15:06:06 +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   : b304b2b65fde057a35286adf3ea69f5e154d1878    
  
author   : Alvaro Herrera <[email protected]>    
date     : Thu, 17 Oct 2019 09:58:01 +0200    
  
committer: Alvaro Herrera <[email protected]>    
date     : Thu, 17 Oct 2019 09:58:01 +0200    

When an FK constraint is created, it needs the index on the referenced  
table to exist and be valid.  When doing parallel pg_restore and the  
referenced table was partitioned, this condition can sometimes not be  
met, because pg_dump didn't emit sufficient object dependencies to  
ensure so; this means that parallel pg_restore would fail in certain  
conditions.  Fix by having pg_dump make the FK constraint object  
dependent on the partition attachment objects for the constraint's  
referenced index.  
  
This has been broken since f56f8f8da6af, so backpatch to Postgres 12.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 3af7c64fe70c0b9d1072c660ddb1cb87dbe0a9d3    
  
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   : 486a8f152233520b0c841d2e9c32b1ae7949e85c    
  
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   : 1cd5bc3ccf92a511b087629b2c914dffa9151fce    
  
author   : Alvaro Herrera <[email protected]>    
date     : Wed, 16 Oct 2019 14:51:23 +0200    
  
committer: Alvaro Herrera <[email protected]>    
date     : Wed, 16 Oct 2019 14:51:23 +0200    

A race condition can make us try to dereference a NULL pointer to the  
PGPROC struct of a process that's already finished.  That results in  
crashes during REINDEX CONCURRENTLY and CREATE INDEX CONCURRENTLY.  
  
This was introduced in ab0dfc961b6a, so backpatch to pg12.  
  
Reported by: Justin Pryzby  
Reviewed-by: Michaël Paquier  
Discussion: https://postgr.es/m/[email protected]  

commit   : a8e49ae0c38172a288f26ae1590069ecc4a721cd    
  
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   : ebb4caa9120d5bcb047dcb5b8562d929c187174a    
  
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   : 3b25de62099cf954ea0ca1fe5d70dbc3fbb776c5    
  
author   : Andres Freund <[email protected]>    
date     : Wed, 16 Oct 2019 02:37:34 -0700    
  
committer: Andres Freund <[email protected]>    
date     : Wed, 16 Oct 2019 02:37:34 -0700    

The test in 93765bd956b added an event trigger to ensure that the  
tested table rewrites do not get optimized away (as happened in the  
past). But doing so would require running the tests in isolation, as  
otherwise the trigger might also fire in concurrent sessions, causing  
test failures there.  
  
Reported-By: Tom Lane  
Discussion: https://postgr.es/m/[email protected]  
Backpatch: 12, just as 93765bd956b  

commit   : 0cec9baa8816e1a646971de613e74170b2a6d0ee    
  
author   : Michael Paquier <[email protected]>    
date     : Wed, 16 Oct 2019 13:15:11 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Wed, 16 Oct 2019 13:15:11 +0900    

A typo from commit 27b4121 is at the origin of the mistake.  
  
Author: Alexander Lakhin  
Discussion: https://postgr.es/m/[email protected]  

commit   : dbefa96f8ea0e112c34e9317734dd8a303595e6a    
  
author   : Michael Paquier <[email protected]>    
date     : Wed, 16 Oct 2019 13:10:31 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Wed, 16 Oct 2019 13:10:31 +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   : 6d3fe6b6bf05777cb7152b462594a1993af15857    
  
author   : Andres Freund <[email protected]>    
date     : Tue, 15 Oct 2019 10:40:13 -0700    
  
committer: Andres Freund <[email protected]>    
date     : Tue, 15 Oct 2019 10:40:13 -0700    

Since the introduction of different slot types, in 1a0586de3657, we  
create a virtual slot in tuplesort_begin_cluster(). While that looks  
right, it unfortunately doesn't actually work, as ExecStoreHeapTuple()  
is used to store tuples in the slot. Unfortunately no regression tests  
for CLUSTER on expression indexes existed so far.  
  
Fix the slot type, and add bare bones tests for CLUSTER on expression  
indexes.  
  
Reported-By: Justin Pryzby  
Author: Andres Freund  
Discussion: https://postgr.es/m/[email protected]  
Backpatch: 12, like 1a0586de3657  

commit   : 702fd3b717f59b1fada3742f2f0eb529717fc3f9    
  
author   : Tomas Vondra <[email protected]>    
date     : Tue, 15 Oct 2019 00:25:04 +0200    
  
committer: Tomas Vondra <[email protected]>    
date     : Tue, 15 Oct 2019 00:25:04 +0200    

The recursive CTE added in 0ccfc28223 referenced pg_catalog.regtype,  
without the schema part, unlike all other queries in pg_upgrade.  
  
Backpatch-to: 12  

commit   : eaf900e842ab0c8a03f23a2eda6a872eb9fce1c7    
  
author   : Tomas Vondra <[email protected]>    
date     : Mon, 14 Oct 2019 22:31:56 +0200    
  
committer: Tomas Vondra <[email protected]>    
date     : Mon, 14 Oct 2019 22:31:56 +0200    

Commit 7c15cef86d changed sql_identifier data type to be based on name  
instead of varchar.  Unfortunately, this breaks on-disk format for this  
data type.  Luckily, that should be a very rare problem, as this data  
type is used only in information_schema views, so this only affects user  
objects (tables, materialized views and indexes).  One way to end in  
such situation is to do CTAS with a query on those system views.  
  
There are two options to deal with this - we can either abort pg_upgrade  
if there are user objects with sql_identifier columns in pg_upgrade, or  
we could replace the sql_identifier type with varchar.  Considering how  
rare the issue is expected to be, and the complexity of replacing the  
data type (e.g. in matviews), we've decided to go with the simple check.  
  
The query is somewhat complex - the sql_identifier data type may be used  
indirectly - through a domain, a composite type or both, possibly in  
multiple levels.  Detecting this requires a recursive CTE.  
  
Backpatch to 12, where the sql_identifier definition changed.  
  
Reported-by: Hans Buschmann  
Author: Tomas Vondra  
Reviewed-by: Tom Lane  
Backpatch-to: 12  
Discussion: https://postgr.es/m/16045-673e8fa6b5ace196%40postgresql.org  

commit   : 9fd9af97fb7b19a5cf5488358d8535faa0949da4    
  
author   : Michael Paquier <[email protected]>    
date     : Mon, 14 Oct 2019 08:58:47 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Mon, 14 Oct 2019 08:58:47 +0900    

1df5875 has changed the way dependencies are dropped for this command  
with inheritance trees, which impacts sepgsql.  This just updates the  
regression test output to take care of the failures and adapt to the new  
code.  
  
Reported by buildfarm member rhinoceros.  
  
Author: Michael Paquier  
Reviewed-by: Tom Lane  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 12  

commit   : 3a58c5f1464bf5bb5e602477222da88ee201392c    
  
author   : Michael Paquier <[email protected]>    
date     : Sun, 13 Oct 2019 17:53:08 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Sun, 13 Oct 2019 17:53:08 +0900    

When dropping a column on a partitioned table which has one or more  
partitioned indexes, the operation was failing as dependencies with  
partitioned indexes using the column dropped were not getting removed in  
a way consistent with the columns involved across all the relations part  
of an inheritance tree.  
  
This commit refactors the code executing column drop so as all the  
columns from an inheritance tree to remove are gathered first, and  
dropped all at the end.  This way, we let the dependency machinery sort  
out by itself the deletion of all the columns with the partitioned  
indexes across a partition tree.  
  
This issue has been introduced by 1d92a0c, so backpatch down to  
REL_12_STABLE.  
  
Author: Amit Langote, Michael Paquier  
Reviewed-by: Álvaro Herrera, Ashutosh Sharma  
Discussion: https://postgr.es/m/CA+HiwqE9kuBsZ3b5pob2-cvE8ofzPWs-og+g8bKKGnu6b4-yTQ@mail.gmail.com  
Backpatch-through: 12  

commit   : 3fb14cfcbd7999d71a7a5d83ffcbeee08c5228db    
  
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   : fcf7f8d9242da9eb07e8a8de3d0d7fa3fd51ba1a    
  
author   : Fujii Masao <[email protected]>    
date     : Fri, 11 Oct 2019 15:47:59 +0900    
  
committer: Fujii Masao <[email protected]>    
date     : Fri, 11 Oct 2019 15:47:59 +0900    

In v11 or before, those settings could not take effect in crash recovery  
because they are specified in recovery.conf and crash recovery always  
starts without recovery.conf. But commit 2dedf4d9a8 integrated  
recovery.conf into postgresql.conf and which unexpectedly allowed  
those settings to take effect even in crash recovery. This is definitely  
not good behavior.  
  
To fix the issue, this commit makes crash recovery always ignore  
restore_command and recovery_end_command settings.  
  
Back-patch to v12 where the issue was added.  
  
Author: Fujii Masao  
Reviewed-by: Peter Eisentraut  
Discussion: https://postgr.es/m/[email protected]  

commit   : 7ed1bcaed6ecbb0760169ea193cbe70071012576    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 10 Oct 2019 14:24:57 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 10 Oct 2019 14:24:57 -0400    

This reverts commit f7ab80285.  Per discussion, we can't remove an  
exported symbol without a SONAME bump, which we don't want to do.  
In particular that breaks usage of current libpq.so with pre-9.3  
versions of psql etc, which need libpq to export pqsignal().  
  
As noted in that commit message, exporting the symbol from libpgport.a  
won't work reliably; but actually we don't want to export src/port's  
implementation anyway.  Any pre-9.3 client is going to be expecting the  
definition that pqsignal() had before 9.3, which was that it didn't  
set SA_RESTART for SIGALRM.  Hence, put back pqsignal() in a separate  
source file in src/interfaces/libpq, and give it the old semantics.  
  
Back-patch to v12.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : f224c7c11ea7be2751e3342e11317070ffb5622d    
  
author   : Andres Freund <[email protected]>    
date     : Wed, 9 Oct 2019 22:00:50 -0700    
  
committer: Andres Freund <[email protected]>    
date     : Wed, 9 Oct 2019 22:00:50 -0700    

In c2fe139c201c I made ATRewriteTable() use tuple slots. Unfortunately  
I did not notice that columns can be added in a rewrite that do not  
have a default, when another column is added/altered requiring one.  
  
Initialize columns to NULL again, and add tests.  
  
Bug: #16038  
Reported-By: anonymous  
Author: Andres Freund  
Discussion: https://postgr.es/m/[email protected]  
Backpatch: 12, where the bug was introduced in c2fe139c201c  

commit   : 07c314968712a2cb1818f6d884c9818f95dee02e    
  
author   : Michael Paquier <[email protected]>    
date     : Wed, 9 Oct 2019 13:31:13 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Wed, 9 Oct 2019 13:31:13 +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   : 6816497cd78a9b498785fa54af7ba0a41051ad24    
  
author   : Bruce Momjian <[email protected]>    
date     : Tue, 8 Oct 2019 21:49:08 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Tue, 8 Oct 2019 21:49:08 -0400    

Previously, our docs would say "Specifies the number of milliseconds"  
but it wasn't clear that "milliseconds" was merely the default unit.  
New text says "Specifies duration (defaults to milliseconds)", which is  
clearer.  
  
Reported-by: [email protected]  
  
Discussion: https://postgr.es/m/[email protected]  
  
Backpatch-through: 12  

commit   : b569a7146fae23a297ec5e0dceb9dde65b298af5    
  
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   : e61cc3576d16d797e2d34d02ba579d2fbd311f4c    
  
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   : 6fd03a95eb1ef8803b05a612bee304d4b41dd136    
  
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   : 7e8d0eb63fbb3bf01c9b4a68b12a10864ce53b52    
  
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   : e4d050e5f7b2c56ddd7659f843280e2fccb1d3ef    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 6 Oct 2019 14:14:45 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 6 Oct 2019 14:14:45 -0400    

Commit aa087ec64 was a bit over-hasty about the doc changes needed  
while splitting pg_statistic_ext_data off from pg_statistic_ext.  
It duplicated one para and inserted another in what seems to me  
to be the wrong section.  Fix that up, and in passing do some minor  
copy-editing.  
  
Per report from noborusai.  
  
Discussion: https://postgr.es/m/CAAM3qnLXLUz4mOBkqa8jxigpKhKNxzSuvwpjvCRPvO5EqWjxSg@mail.gmail.com  

commit   : 2dbd2cc5a9295f821022e87e20450428ab017608    
  
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   : 4f119e156e65546aec55e06d288e6f6a8e10f958    
  
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   : 9051f62ed7eff9eb01e4fa7a37a6471271d10f5b    
  
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   : bbd26778643f8e353556bce09831f2c3107fb20e    
  
author   : Andres Freund <[email protected]>    
date     : Fri, 4 Oct 2019 21:37:43 -0700    
  
committer: Andres Freund <[email protected]>    
date     : Fri, 4 Oct 2019 21:37:43 -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   : 0cbc72ca72d4d7bdfecea6244bce6d5fb94e2e1a    
  
author   : Andres Freund <[email protected]>    
date     : Fri, 4 Oct 2019 13:56:04 -0700    
  
committer: Andres Freund <[email protected]>    
date     : Fri, 4 Oct 2019 13:56:04 -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   : 60e97d63e5d19098e11fa32431a20eea820e2ae9    
  
author   : Andres Freund <[email protected]>    
date     : Fri, 4 Oct 2019 11:59:34 -0700    
  
committer: Andres Freund <[email protected]>    
date     : Fri, 4 Oct 2019 11:59:34 -0700    

When ExecBRUpdateTriggers()'s GetTupleForTrigger() follows an EPQ  
chain the former needs to run the result tuple through the junkfilter  
again, and update the slot containing the new version of the tuple to  
contain that new version. The input tuple may already be in the  
junkfilter's output slot, which used to be OK - we don't need the  
previous version anymore. Unfortunately ff11e7f4b9ae started to use  
ExecCopySlot() to update newslot, and ExecCopySlot() doesn't support  
copying a slot into itself, leading to a slot in a corrupt  
state, which then can cause crashes or other symptoms.  
  
Fix this by skipping the ExecCopySlot() when copying into itself.  
  
While we could have easily made ExecCopySlot() handle that case, it  
seems better to add an assert forbidding doing so instead. As the goal  
of copying might be to make the contents of one slot independent from  
another, it seems failure prone to handle doing so silently.  
  
A follow-up commit will add tests for the obviously under-covered  
combination of EPQ and triggers. Done as a separate commit as it might  
make sense to backpatch them further than this bug.  
  
Also remove confusion with confusing variable names for slots in  
ExecBRDeleteTriggers() and ExecBRUpdateTriggers().  
  
Bug: #16036  
Reported-By: Антон Власов  
Author: Andres Freund  
Discussion: https://postgr.es/m/[email protected]  
Backpatch: 12-, where ff11e7f4b9ae was merged  

commit   : c025165da9da469ff0136a3eda0070c2b7b6f97e    
  
author   : Andres Freund <[email protected]>    
date     : Fri, 4 Oct 2019 13:08:51 -0700    
  
committer: Andres Freund <[email protected]>    
date     : Fri, 4 Oct 2019 13:08:51 -0700    

Cribbing from dfbaed45975:  
    Some operating systems, including the reporter's windows, return EBADFD  
    or similar when fsync() is invoked on a O_RDONLY file descriptor.  
    Unfortunately RestoreSlotFromDisk() does exactly that; which causes  
    failures after restarts in at least some scenarios.  
  
    If you hit the bug the error message will be something like  
    ERROR: could not fsync file "pg_replslot/$name/state": Bad file descriptor  
  
    Simply use O_RDWR instead of O_RDONLY when opening the relevant file  
    descriptor to fix the bug.  
  
Unfortunately this fix was undone in 82a5649fb9db. Re-apply, and add a  
comment.  
  
Bug: 16039  
Reported-By: Hans Buschmann  
Author: Andres Freund  
Discussion: https://postgr.es/m/[email protected]  
Backpatch: 12-, as 82a5649fb9db  

commit   : ec38d2311124b7e59a1dad20a814f705884bd38a    
  
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   : 6c3b6406db3b132b84d7be6fe838da9d46cd02f8    
  
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   : c2e3b311d9ef85e99b04944e7e6f98e3a336de84    
  
author   : Michael Paquier <[email protected]>    
date     : Fri, 4 Oct 2019 09:16:03 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Fri, 4 Oct 2019 09:16:03 +0900    

Even if --dry-run mode was specified, the control file was getting  
updated, preventing follow-up runs of pg_rewind to work properly on the  
target data folder.  The origin of the problem came from the refactoring  
done by ce6afc6.  
  
Author: Alexey Kondratov  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 12  

commit   : 8381242df587d31c178938d9b125131e2f8064b3    
  
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   : 9a407209a075b53b9ef7141c0f87e91dba41b8b1    
  
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   : 0b11dc01922b0f6376a27f84a34a52451e8f476c    
  
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   : 2a724cdbff0bef4b962255c1e322b4deb74c309e    
  
author   : Michael Paquier <[email protected]>    
date     : Wed, 2 Oct 2019 15:53:51 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Wed, 2 Oct 2019 15:53:51 +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