PostgreSQL 9.6.23 (upcoming) commit log

Further refinement of stuck_on_old_timeline recovery test

commit   : e46f6a078c1a4a2293839c9c5560517b2c4e1d12    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Tue, 15 Jun 2021 15:30:11 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Tue, 15 Jun 2021 15:30:11 -0400    

Click here for diff

TestLib::perl2host can take a file argument as well as a directory  
argument, so that code becomes substantially simpler. Also add comments  
on why we're using forward slashes, and why we're setting  
PERL_BADLANG=0.  
  
Discussion: https://postgr.es/m/e9947bcd-20ee-027c-f0fe-01f736b7e345@dunslane.net  

M src/test/recovery/t/025_stuck_on_old_timeline.pl

Fix decoding of speculative aborts.

commit   : 43acadfcebec36f4db2074e125b2af15d3afda1a    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Tue, 15 Jun 2021 09:18:38 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Tue, 15 Jun 2021 09:18:38 +0530    

Click here for diff

During decoding for speculative inserts, we were relying for cleaning  
toast hash on confirmation records or next change records. But that  
could lead to multiple problems (a) memory leak if there is neither a  
confirmation record nor any other record after toast insertion for a  
speculative insert in the transaction, (b) error and assertion failures  
if the next operation is not an insert/update on the same table.  
  
The fix is to start queuing spec abort change and clean up toast hash  
and change record during its processing. Currently, we are queuing the  
spec aborts for both toast and main table even though we perform cleanup  
while processing the main table's spec abort record. Later, if we have a  
way to distinguish between the spec abort record of toast and the main  
table, we can avoid queuing the change for spec aborts of toast tables.  
  
Reported-by: Ashutosh Bapat  
Author: Dilip Kumar  
Reviewed-by: Amit Kapila  
Backpatch-through: 9.6, where it was introduced  
Discussion: https://postgr.es/m/CAExHW5sPKF-Oovx_qZe4p5oM6Dvof7_P+XgsNAViug15Fm99jA@mail.gmail.com  

M src/backend/replication/logical/decode.c
M src/backend/replication/logical/reorderbuffer.c
M src/include/replication/reorderbuffer.h

Work around portability issue with newer versions of mktime().

commit   : dd53b46c78a0ac23e95f5bd1e4fb6cd011505cef    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 13 Jun 2021 14:32:42 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 13 Jun 2021 14:32:42 -0400    

Click here for diff

Recent glibc versions have made mktime() fail if tm_isdst is  
inconsistent with the prevailing timezone; in particular it fails for  
tm_isdst = 1 when the zone is UTC.  (This seems wildly inconsistent  
with the POSIX-mandated treatment of "incorrect" values for the other  
fields of struct tm, so if you ask me it's a bug, but I bet they'll  
say it's intentional.)  This has been observed to cause cosmetic  
problems when pg_restore'ing an archive created in a different  
timezone.  
  
To fix, do mktime() using the field values from the archive, and if  
that fails try again with tm_isdst = -1.  This will give a result  
that's off by the UTC-offset difference from the original zone, but  
that was true before, too.  It's not terribly critical since we don't  
do anything with the result except possibly print it.  (Someday we  
should flush this entire bit of logic and record a standard-format  
timestamp in the archive instead.  That's not okay for a back-patched  
bug fix, though.)  
  
Also, guard our only other use of mktime() by having initdb's  
build_time_t() set tm_isdst = -1 not 0.  This case could only have  
an issue in zones that are DST year-round; but I think some do exist,  
or could in future.  
  
Per report from Wells Oliver.  Back-patch to all supported  
versions, since any of them might need to run with a newer glibc.  
  
Discussion: https://postgr.es/m/CAOC+FBWDhDHO7G-i1_n_hjRzCnUeFO+H-Czi1y10mFhRWpBrew@mail.gmail.com  

M src/bin/initdb/findtimezone.c
M src/bin/pg_dump/pg_backup_archiver.c

Further tweaks to stuck_on_old_timeline recovery test

commit   : 84cb4be719c16f1fdecb6e16945678c379a85c01    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Sun, 13 Jun 2021 07:10:41 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Sun, 13 Jun 2021 07:10:41 -0400    

Click here for diff

Translate path slashes on target directory path. This was confusing old  
branches, but is applied to all branches for the sake of uniformity.  
Perl is perfectly able to understand paths with forward slashes.  
  
Along the way, restore the previous archive_wait query, for the sake of  
uniformity with other tests, per gripe from Tom Lane.  

M src/test/recovery/t/025_stuck_on_old_timeline.pl

Ignore more environment variables in pg_regress.c

commit   : 1df6bee296ed2be0fda11ee7aa42853cf0469f8d    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sun, 13 Jun 2021 20:08:06 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sun, 13 Jun 2021 20:08:06 +0900    

Click here for diff

This is similar to the work done in 8279f68 for TestLib.pm, where  
environment variables set may cause unwanted failures if using a  
temporary installation with pg_regress.  The list of variables reset is  
adjusted in each stable branch depending on what is supported.  
  
Comments are added to remember that the lists in TestLib.pm and  
pg_regress.c had better be kept in sync.  
  
Reviewed-by: Álvaro Herrera  
Discussion: https://postgr.es/m/YMNR9GYDn+fHlMta@paquier.xyz  
Backpatch-through: 9.6  

M src/test/perl/TestLib.pm
M src/test/regress/pg_regress.c

Ensure pg_filenode_relation(0, 0) returns NULL.

commit   : c1ffbbcbca93b3544c0b57b7ab063497794cb8ff    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 12 Jun 2021 13:29:24 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 12 Jun 2021 13:29:24 -0400    

Click here for diff

Previously, a zero value for the relfilenode resulted in  
a confusing error message about "unexpected duplicate".  
This function returns NULL for other invalid relfilenode  
values, so zero should be treated likewise.  
  
It's been like this all along, so back-patch to all supported  
branches.  
  
Justin Pryzby  
  
Discussion: https://postgr.es/m/20210612023324.GT16435@telsasoft.com  

M src/backend/utils/adt/dbsize.c

Fix new recovery test for use under msys

commit   : dee7ad20d018354a75f26c73ba26b8487b98e642    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Sat, 12 Jun 2021 08:37:16 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Sat, 12 Jun 2021 08:37:16 -0400    

Click here for diff

Commit caba8f0d43 wasn't quite right for msys, as demonstrated by  
several buildfarm animals, including jacana and fairywren. We need to  
use the msys perl in the archive command, but call it in such a way that  
Windows will understand the path. Furthermore, inside the copy script we  
need to convert a Windows path to an msys path.  

M src/test/recovery/t/025_stuck_on_old_timeline.pl
M src/test/recovery/t/cp_history_files

Remove PGSSLCRLDIR from the list of variables ignored in TAP tests

commit   : a78edd4b4207627bcbe5d6d6df604aea480d4326    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sat, 12 Jun 2021 10:39:44 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sat, 12 Jun 2021 10:39:44 +0900    

Click here for diff

This variable was present in the list added by 9d660670, but it is not  
supported by this branch.  Issue noticed while diving into a similar  
change for pg_regress.c.  
  
Backpatch-through: 9.6  

M src/test/perl/TestLib.pm

Adjust new test case to set wal_keep_segments.

commit   : 6cd0e55f9ffb3be400e44812fa6163a217e09bf3    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Thu, 10 Jun 2021 09:43:35 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Thu, 10 Jun 2021 09:43:35 -0400    

Click here for diff

Per buildfarm member conchuela and Kyotaro Horiguchi, it's possible  
for the WAL segment that the cascading standby needs to be removed  
too quickly. Hopefully this will prevent that.  
  
Kyotaro Horiguchi  
  
Discussion: http://postgr.es/m/20210610.101240.1270925505780628275.horikyota.ntt@gmail.com  

M src/test/recovery/t/025_stuck_on_old_timeline.pl

Fix corner case failure of new standby to follow new primary.

commit   : 6eb5b9ae39176a7d40003b4c2e9ca22e6b205def    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Wed, 9 Jun 2021 16:21:14 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Wed, 9 Jun 2021 16:21:14 -0400    

Click here for diff

This only happens if (1) the new standby has no WAL available locally,  
(2) the new standby is starting from the old timeline, (3) the promotion  
happened in the WAL segment from which the new standby is starting,  
(4) the timeline history file for the new timeline is available from  
the archive but the WAL files for are not (i.e. this is a race),  
(5) the WAL files for the new timeline are available via streaming,  
and (6) recovery_target_timeline='latest'.  
  
Commit ee994272ca50f70b53074f0febaec97e28f83c4e introduced this  
logic and was an improvement over the previous code, but it mishandled  
this case. If recovery_target_timeline='latest' and restore_command is  
set, validateRecoveryParameters() can change recoveryTargetTLI to be  
different from receiveTLI. If streaming is then tried afterward,  
expectedTLEs gets initialized with the history of the wrong timeline.  
It's supposed to be a list of entries explaining how to get to the  
target timeline, but in this case it ends up with a list of entries  
explaining how to get to the new standby's original timeline, which  
isn't right.  
  
Dilip Kumar and Robert Haas, reviewed by Kyotaro Horiguchi.  
  
Discussion: http://postgr.es/m/CAFiTN-sE-jr=LB8jQuxeqikd-Ux+jHiXyh4YDiZMPedgQKup0g@mail.gmail.com  

M src/backend/access/transam/xlog.c
A src/test/recovery/t/025_stuck_on_old_timeline.pl
A src/test/recovery/t/cp_history_files

Back-port a few PostgresNode.pm methods.

commit   : 75212a854f991689fd6acbd51536a2912bf7461b    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Wed, 9 Jun 2021 16:16:21 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Wed, 9 Jun 2021 16:16:21 -0400    

Click here for diff

The 'lsn' and 'wait_for_catchup' methods only exist in v10 and  
higher, but are needed in order to support a test planned test  
case for a bug that exists all the way back to v9.6. To minimize  
cross-branch differences in the test case, back-port these  
methods.  
  
Discussion: http://postgr.es/m/CA+TgmoaG5dmA_8Xc1WvbvftPjtwx5uzkGEHxE7MiJ+im9jynmw@mail.gmail.com  

M src/test/perl/PostgresNode.pm

Fix inconsistencies in psql --help=commands

commit   : 954ee4b566eebfae535905696887ffd123038fd7    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 9 Jun 2021 16:26:11 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 9 Jun 2021 16:26:11 +0900    

Click here for diff

The set of subcommands supported by \dAp, \do and \dy was described  
incorrectly in psql's --help.  The documentation was already consistent  
with the code.  
  
Reported-by: inoas, from IRC  
Author: Matthijs van der Vleuten  
Reviewed-by: Neil Chen  
Discussion: https://postgr.es/m/6a984e24-2171-4039-9050-92d55e7b23fe@www.fastmail.com  
Backpatch-through: 9.6  

M src/bin/psql/help.c

Fix incautious handling of possibly-miscoded strings in client code.

commit   : ac600c54165631d5266c8aa7c5cb8c96ac589138    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 7 Jun 2021 14:15:25 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 7 Jun 2021 14:15:25 -0400    

Click here for diff

An incorrectly-encoded multibyte character near the end of a string  
could cause various processing loops to run past the string's  
terminating NUL, with results ranging from no detectable issue to  
a program crash, depending on what happens to be in the following  
memory.  
  
This isn't an issue in the server, because we take care to verify  
the encoding of strings before doing any interesting processing  
on them.  However, that lack of care leaked into client-side code  
which shouldn't assume that anyone has validated the encoding of  
its input.  
  
Although this is certainly a bug worth fixing, the PG security team  
elected not to regard it as a security issue, primarily because  
any untrusted text should be sanitized by PQescapeLiteral or  
the like before being incorporated into a SQL or psql command.  
(If an app fails to do so, the same technique can be used to  
cause SQL injection, with probably much more dire consequences  
than a mere client-program crash.)  Those functions were already  
made proof against this class of problem, cf CVE-2006-2313.  
  
To fix, invent PQmblenBounded() which is like PQmblen() except it  
won't return more than the number of bytes remaining in the string.  
In HEAD we can make this a new libpq function, as PQmblen() is.  
It seems imprudent to change libpq's API in stable branches though,  
so in the back branches define PQmblenBounded as a macro in the files  
that need it.  (Note that just changing PQmblen's behavior would not  
be a good idea; notably, it would completely break the escaping  
functions' defense against this exact problem.  So we just want a  
version for those callers that don't have any better way of handling  
this issue.)  
  
Per private report from houjingyi.  Back-patch to all supported branches.  

M src/bin/psql/common.c
M src/bin/psql/psqlscanslash.l
M src/bin/psql/stringutils.c
M src/bin/psql/tab-complete.c
M src/bin/scripts/common.c
M src/fe_utils/print.c
M src/interfaces/libpq/fe-print.c
M src/interfaces/libpq/fe-protocol3.c

Support use of strnlen() in pre-v11 branches.

commit   : 7cdb976324d3a111fcad1901019e27d5e75715be    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 7 Jun 2021 13:12:35 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 7 Jun 2021 13:12:35 -0400    

Click here for diff

Back-patch a minimal subset of commits fffd651e8 and 46912d9b1,  
to support strnlen() on all platforms without adding any callers.  
This will be needed by a following bug fix.  

M configure
M configure.in
M src/include/pg_config.h.in
M src/include/pg_config.h.win32
M src/include/port.h
M src/interfaces/libpq/.gitignore
M src/interfaces/libpq/Makefile
A src/port/strnlen.c

In PostgresNode.pm, don't pass SQL to psql on the command line

commit   : 066535d411af6e77e06542d8a136576603164d5d    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Thu, 3 Jun 2021 16:08:33 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Thu, 3 Jun 2021 16:08:33 -0400    

Click here for diff

The Msys shell mangles certain patterns in its command line, so avoid  
handing arbitrary SQL to psql on the command line and instead use  
IPC::Run's redirection facility for stdin. This pattern is already  
mostly whats used, but query_poll_until() was not doing the right thing.  
  
Problem discovered on the buildfarm when a new TAP test failed on msys.  

M src/test/perl/PostgresNode.pm

Reduce risks of conflicts in internal queries of REFRESH MATVIEW CONCURRENTLY

commit   : d9525c46c89d6a0d85dca0882ced98d12081bc0e    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 3 Jun 2021 15:29:01 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 3 Jun 2021 15:29:01 +0900    

Click here for diff

The internal SQL queries used by REFRESH MATERIALIZED VIEW CONCURRENTLY  
include some aliases for its diff and temporary relations with  
rather-generic names: diff, newdata, newdata2 and mv.  Depending on the  
queries used for the materialized view, using CONCURRENTLY could lead to  
some internal failures if the query and those internal aliases conflict.  
  
Those names have been chosen in 841c29c8.  This commit switches instead  
to a naming pattern which is less likely going to cause conflicts, based  
on an idea from Thomas Munro, by appending _$ to those aliases.  This is  
not perfect as those new names could still conflict, but at least it has  
the advantage to keep the code readable and simple while reducing the  
likelihood of conflicts to be close to zero.  
  
Reported-by: Mathis Rudolf  
Author: Bharath Rupireddy  
Reviewed-by: Bernd Helmle, Thomas Munro, Michael Paquier  
Discussion: https://postgr.es/m/109c267a-10d2-3c53-b60e-720fcf44d9e8@credativ.de  
Backpatch-through: 9.6  

M src/backend/commands/matview.c

Ignore more environment variables in TAP tests

commit   : a886e2ff2413ee6420b84077f6cb991a5d97b45b    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 3 Jun 2021 11:52:03 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 3 Jun 2021 11:52:03 +0900    

Click here for diff

Various environment variables were not getting reset in the TAP tests,  
which would cause failures depending on the tests or the environment  
variables involved.  For example, PGSSL{MAX,MIN}PROTOCOLVERSION could  
cause failures in the SSL tests.  Even worse, a junk value of  
PGCLIENTENCODING makes a server startup fail.  The list of variables  
reset is adjusted in each stable branch depending on what is supported.  
  
While on it, simplify a bit the code per a suggestion from Andrew  
Dunstan, using a list of variables instead of doing single deletions.  
  
Reviewed-by: Andrew Dunstan, Daniel Gustafsson  
Discussion: https://postgr.es/m/YLbjjRpucIeZ78VQ@paquier.xyz  
Backpatch-through: 9.6  

M src/test/perl/TestLib.pm

Reject SELECT ... GROUP BY GROUPING SETS (()) FOR UPDATE.

commit   : 3eca18522e1908f7a61ab2545bb9238fce4d1ba7    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 1 Jun 2021 11:12:56 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 1 Jun 2021 11:12:56 -0400    

Click here for diff

This case should be disallowed, just as FOR UPDATE with a plain  
GROUP BY is disallowed; FOR UPDATE only makes sense when each row  
of the query result can be identified with a single table row.  
However, we missed teaching CheckSelectLocking() to check  
groupingSets as well as groupClause, so that it would allow  
degenerate grouping sets.  That resulted in a bad plan and  
a null-pointer dereference in the executor.  
  
Looking around for other instances of the same bug, the only one  
I found was in examine_simple_variable().  That'd just lead to  
silly estimates, but it should be fixed too.  
  
Per private report from Yaoguang Chen.  
Back-patch to all supported branches.  

M src/backend/parser/analyze.c
M src/backend/utils/adt/selfuncs.c
M src/test/regress/expected/errors.out
M src/test/regress/sql/errors.sql

fix syntax error

commit   : 34a65fc63e0870c7e0118e76f42b9f0996ab4195    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 28 May 2021 09:35:11 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 28 May 2021 09:35:11 -0400    

Click here for diff

M src/tools/msvc/Solution.pm

Report configured port in MSVC built pg_config

commit   : abbd70022c17f541e7d05163b80631aa722fd58e    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 28 May 2021 09:26:30 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 28 May 2021 09:26:30 -0400    

Click here for diff

This is a long standing omission, discovered when trying to write code  
that relied on it.  
  
Backpatch to all live branches.  

M src/tools/msvc/Solution.pm

Fix MSVC scripts when building with GSSAPI/Kerberos

commit   : 7a4f2e158c0e62e26166423c411628958cb5d474    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 27 May 2021 20:11:38 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 27 May 2021 20:11:38 +0900    

Click here for diff

The deliverables of upstream Kerberos on Windows are installed with  
paths that do not match our MSVC scripts.  First, the include folder was  
named "inc/" in our scripts, but the upstream MSIs use "include/".  
Second, the build would fail with 64-bit environments as the libraries  
are named differently.  
  
This commit adjusts the MSVC scripts to be compatible with the latest  
installations of upstream, and I have checked that the compilation was  
able to work with the 32-bit and 64-bit installations.  
  
Special thanks to Kondo Yuta for the help in investigating the situation  
in hamerkop, which had an incorrect configuration for the GSS  
compilation.  
  
Reported-by: Brian Ye  
Discussion: https://postgr.es/m/162128202219.27274.12616756784952017465@wrigleys.postgresql.org  
Backpatch-through: 9.6  

M src/tools/msvc/Solution.pm

doc: Fix description of some GUCs in docs and postgresql.conf.sample

commit   : 521a812f0f5c83298c92638f419970f74af86189    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 27 May 2021 14:58:23 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 27 May 2021 14:58:23 +0900    

Click here for diff

The following parameters have been imprecise, or incorrect, about their  
description (PGC_POSTMASTER or PGC_SIGHUP):  
- autovacuum_work_mem (docs, as of 9.6~)  
- huge_page_size (docs, as of 14~)  
- max_logical_replication_workers (docs, as of 10~)  
- max_sync_workers_per_subscription (docs, as of 10~)  
- min_dynamic_shared_memory (docs, as of 14~)  
- recovery_init_sync_method (postgresql.conf.sample, as of 14~)  
- remove_temp_files_after_crash (docs, as of 14~)  
- restart_after_crash (docs, as of 9.6~)  
- ssl_min_protocol_version (docs, as of 12~)  
- ssl_max_protocol_version (docs, as of 12~)  
  
This commit adjusts the description of all these parameters to be more  
consistent with the practice used for the others.  
  
Revewed-by: Justin Pryzby  
Discussion: https://postgr.es/m/YK2ltuLpe+FbRXzA@paquier.xyz  
Backpatch-through: 9.6  

M doc/src/sgml/config.sgml

Disallow SSL renegotiation

commit   : 7777df34d7a37c40bba6e93da34bb78af48134e1    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 25 May 2021 10:11:33 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 25 May 2021 10:11:33 +0900    

Click here for diff

SSL renegotiation is already disabled as of 48d23c72, however this does  
not prevent the server to comply with a client willing to use  
renegotiation.  In the last couple of years, renegotiation had its set  
of security issues and flaws (like the recent CVE-2021-3449), and it  
could be possible to crash the backend with a client attempting  
renegotiation.  
  
This commit takes one extra step by disabling renegotiation in the  
backend in the same way as SSL compression (f9264d15) or tickets  
(97d3a0b0).  OpenSSL 1.1.0h has added an option named  
SSL_OP_NO_RENEGOTIATION able to achieve that.  In older versions  
there is an option called SSL3_FLAGS_NO_RENEGOTIATE_CIPHERS that  
was undocumented, and could be set within the SSL object created when  
the TLS connection opens, but I have decided not to use it, as it feels  
trickier to rely on, and it is not official.  Note that this option is  
not usable in OpenSSL < 1.1.0h as the internal contents of the *SSL  
object are hidden to applications.  
  
SSL renegotiation concerns protocols up to TLSv1.2.  
  
Per original report from Robert Haas, with a patch based on a suggestion  
by Andres Freund.  
  
Author: Michael Paquier  
Reviewed-by: Daniel Gustafsson  
Discussion: https://postgr.es/m/YKZBXx7RhU74FlTE@paquier.xyz  
Backpatch-through: 9.6  

M src/backend/libpq/be-secure-openssl.c

Clean up cpluspluscheck violation.

commit   : 85c809496d75361aae03d70c68c286f8e2255c68    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 20 May 2021 13:03:09 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 20 May 2021 13:03:09 -0400    

Click here for diff

"typename" is a C++ keyword, so pg_upgrade.h fails to compile in C++.  
Fortunately, there seems no likely reason for somebody to need to  
do that.  Nonetheless, it's project policy that all .h files should  
pass cpluspluscheck, so rename the argument to fix that.  
  
Oversight in 57c081de0; back-patch as that was.  (The policy requiring  
pg_upgrade.h to pass cpluspluscheck only goes back to v12, but it  
seems best to keep this code looking the same in all branches.)  

M src/bin/pg_upgrade/pg_upgrade.h
M src/bin/pg_upgrade/version.c

Fix typo and outdated information in README.barrier

commit   : 943bda157ecad3b08c875716b7def77443ec2151    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Tue, 18 May 2021 09:58:21 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Tue, 18 May 2021 09:58:21 +1200    

Click here for diff

README.barrier didn't seem to get the memo when atomics were added. Fix  
that.  
  
Author: Tatsuo Ishii, David Rowley  
Discussion: https://postgr.es/m/20210516.211133.2159010194908437625.t-ishii%40sraoss.co.jp  
Backpatch-through: 9.6, oldest supported release  

M src/backend/storage/lmgr/README.barrier

Be more careful about barriers when releasing BackgroundWorkerSlots.

commit   : 5d195dc40af07cc822a20fd8a9a9f9de2a1df43d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 15 May 2021 12:21:06 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 15 May 2021 12:21:06 -0400    

Click here for diff

ForgetBackgroundWorker lacked any memory barrier at all, while  
BackgroundWorkerStateChange had one but unaccountably did  
additional manipulation of the slot after the barrier.  AFAICS,  
the rule must be that the barrier is immediately before setting  
or clearing slot->in_use.  
  
It looks like back in 9.6 when ForgetBackgroundWorker was first  
written, there might have been some case for not needing a  
barrier there, but I'm not very convinced of that --- the fact  
that the load of bgw_notify_pid is in the caller doesn't seem  
to guarantee no memory ordering problem.  So patch 9.6 too.  
  
It's likely that this doesn't fix any observable bug on Intel  
hardware, but machines with weaker memory ordering rules could  
have problems here.  
  
Discussion: https://postgr.es/m/4046084.1620244003@sss.pgh.pa.us  

M src/backend/postmaster/bgworker.c

Prevent infinite insertion loops in spgdoinsert().

commit   : 5015d3c35c6bc33924d8c05a71bf238a5bdb39c1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 14 May 2021 15:07:34 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 14 May 2021 15:07:34 -0400    

Click here for diff

Formerly we just relied on operator classes that assert longValuesOK  
to eventually shorten the leaf value enough to fit on an index page.  
That fails since the introduction of INCLUDE-column support (commit  
09c1c6ab4), because the INCLUDE columns might alone take up more  
than a page, meaning no amount of leaf-datum compaction will get  
the job done.  At least with spgtextproc.c, that leads to an infinite  
loop, since spgtextproc.c won't throw an error for not being able  
to shorten the leaf datum anymore.  
  
To fix without breaking cases that would otherwise work, add logic  
to spgdoinsert() to verify that the leaf tuple size is decreasing  
after each "choose" step.  Some opclasses might not decrease the  
size on every single cycle, and in any case, alignment roundoff  
of the tuple size could obscure small gains.  Therefore, allow  
up to 10 cycles without additional savings before throwing an  
error.  (Perhaps this number will need adjustment, but it seems  
quite generous right now.)  
  
As long as we've developed this logic, let's back-patch it.  
The back branches don't have INCLUDE columns to worry about, but  
this seems like a good defense against possible bugs in operator  
classes.  We already know that an infinite loop here is pretty  
unpleasant, so having a defense seems to outweigh the risk of  
breaking things.  (Note that spgtextproc.c is actually the only  
known opclass with longValuesOK support, so that this is all moot  
for known non-core opclasses anyway.)  
  
Per report from Dilip Kumar.  
  
Discussion: https://postgr.es/m/CAFiTN-uxP_soPhVG840tRMQTBmtA_f_Y8N51G7DKYYqDh7XN-A@mail.gmail.com  

M doc/src/sgml/spgist.sgml
M src/backend/access/spgist/spgdoinsert.c

Fix query-cancel handling in spgdoinsert().

commit   : 4c6cfcc377aaa945e3662319787e6767081e0f43    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 14 May 2021 13:26:55 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 14 May 2021 13:26:55 -0400    

Click here for diff

Knowing that a buggy opclass could cause an infinite insertion loop,  
spgdoinsert() intended to allow its loop to be interrupted by query  
cancel.  However, that never actually worked, because in iterations  
after the first, we'd be holding buffer lock(s) which would cause  
InterruptHoldoffCount to be positive, preventing servicing of the  
interrupt.  
  
To fix, check if an interrupt is pending, and if so fall out of  
the insertion loop and service the interrupt after we've released  
the buffers.  If it was indeed a query cancel, that's the end of  
the matter.  If it was a non-canceling interrupt reason, make use  
of the existing provision to retry the whole insertion.  (This isn't  
as wasteful as it might seem, since any upper-level index tuples we  
already created should be usable in the next attempt.)  
  
While there's no known instance of such a bug in existing release  
branches, it still seems like a good idea to back-patch this to  
all supported branches, since the behavior is fairly nasty if a  
loop does happen --- not only is it uncancelable, but it will  
quickly consume memory to the point of an OOM failure.  In any  
case, this code is certainly not working as intended.  
  
Per report from Dilip Kumar.  
  
Discussion: https://postgr.es/m/CAFiTN-uxP_soPhVG840tRMQTBmtA_f_Y8N51G7DKYYqDh7XN-A@mail.gmail.com  

M src/backend/access/spgist/spgdoinsert.c

Refactor CHECK_FOR_INTERRUPTS() to add flexibility.

commit   : 567328989c19d1f9f657f5c1b1eac61b29e89b3a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 14 May 2021 12:54:26 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 14 May 2021 12:54:26 -0400    

Click here for diff

Split up CHECK_FOR_INTERRUPTS() to provide an additional macro  
INTERRUPTS_PENDING_CONDITION(), which just tests whether an  
interrupt is pending without attempting to service it.  This is  
useful in situations where the caller knows that interrupts are  
blocked, and would like to find out if it's worth the trouble  
to unblock them.  
  
Also add INTERRUPTS_CAN_BE_PROCESSED(), which indicates whether  
CHECK_FOR_INTERRUPTS() can be relied on to clear the pending interrupt.  
  
This commit doesn't actually add any uses of the new macros,  
but a follow-on bug fix will do so.  Back-patch to all supported  
branches to provide infrastructure for that fix.  
  
Alvaro Herrera and Tom Lane  
  
Discussion: https://postgr.es/m/20210513155351.GA7848@alvherre.pgsql  

M src/backend/tcop/postgres.c
M src/include/miscadmin.h