PostgreSQL 12.10 commit log

Stamp 12.10.

commit   : ec24521950fb055488e3ab2c652ffbf7fe0180b9    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 7 Feb 2022 16:19:04 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 7 Feb 2022 16:19:04 -0500    

Click here for diff

M configure
M configure.in
M src/include/pg_config.h.win32
M src/interfaces/libpq/libpq.rc.in
M src/port/win32ver.rc

Translation updates

commit   : 3b00428f1f453dd1beba64385c57efd4cb67d57f    
  
author   : Peter Eisentraut <[email protected]>    
date     : Mon, 7 Feb 2022 13:44:07 +0100    
  
committer: Peter Eisentraut <[email protected]>    
date     : Mon, 7 Feb 2022 13:44:07 +0100    

Click here for diff

Source-Git-URL: git://git.postgresql.org/git/pgtranslation/messages.git  
Source-Git-Hash: cc8ba6a1bf30f4ee65149c1596513abcffa2e521  

M src/backend/po/de.po
M src/backend/po/fr.po
M src/backend/po/ru.po
M src/backend/po/sv.po
M src/bin/initdb/po/sv.po
M src/bin/pg_archivecleanup/po/sv.po
M src/bin/pg_basebackup/po/de.po
M src/bin/pg_basebackup/po/fr.po
M src/bin/pg_basebackup/po/ru.po
M src/bin/pg_basebackup/po/sv.po
M src/bin/pg_checksums/po/sv.po
M src/bin/pg_config/po/sv.po
M src/bin/pg_controldata/po/sv.po
M src/bin/pg_ctl/po/sv.po
M src/bin/pg_dump/po/de.po
M src/bin/pg_dump/po/fr.po
M src/bin/pg_dump/po/ru.po
M src/bin/pg_dump/po/sv.po
M src/bin/pg_resetwal/po/sv.po
M src/bin/pg_rewind/po/sv.po
M src/bin/pg_test_fsync/po/sv.po
M src/bin/pg_test_timing/po/sv.po
M src/bin/pg_upgrade/po/ru.po
M src/bin/pg_upgrade/po/sv.po
M src/bin/pg_waldump/po/sv.po
M src/bin/psql/po/de.po
M src/bin/psql/po/fr.po
M src/bin/psql/po/ru.po
M src/bin/psql/po/sv.po
M src/bin/scripts/po/ru.po
M src/bin/scripts/po/sv.po
M src/interfaces/ecpg/ecpglib/po/sv.po
M src/interfaces/ecpg/preproc/po/sv.po
M src/interfaces/libpq/po/de.po
M src/interfaces/libpq/po/fr.po
M src/interfaces/libpq/po/ru.po
M src/interfaces/libpq/po/sv.po
M src/pl/plperl/po/ru.po
M src/pl/plperl/po/sv.po
M src/pl/plpgsql/src/po/sv.po
M src/pl/plpython/po/sv.po
M src/pl/tcl/po/sv.po

Release notes for 14.2, 13.6, 12.10, 11.15, 10.20.

commit   : e0a581229d787d904a0541b9d555f12e331f7f07    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 6 Feb 2022 14:24:55 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 6 Feb 2022 14:24:55 -0500    

Click here for diff

M doc/src/sgml/release-12.sgml

Doc: be clearer that foreign-table partitions need user-added constraints.

commit   : 5d97181335b7a6a4f4554b78a0ee31989891b817    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 5 Feb 2022 12:55:44 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 5 Feb 2022 12:55:44 -0500    

Click here for diff

A very well-informed user might deduce this from what we said already,  
but I'd bet against it.  Lay it out explicitly.  
  
While here, rewrite the comment about tuple routing to be more  
intelligible to an average SQL user.  
  
Per bug #17395 from Alexander Lakhin.  Back-patch to v11.  (The text  
in this area is different in v10 and I'm not sufficiently excited  
about this point to adapt the patch.)  
  
Discussion: https://postgr.es/m/[email protected]  

M doc/src/sgml/ddl.sgml
M doc/src/sgml/ref/create_foreign_table.sgml

Test, don't just Assert, that mergejoin's inputs are in order.

commit   : f469f0678c3042b8bf96080ccf7cd0aa53468a2d    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 5 Feb 2022 11:59:30 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 5 Feb 2022 11:59:30 -0500    

Click here for diff

There are two Asserts in nodeMergejoin.c that are reachable if  
the input data is not in the expected order.  This seems way too  
fragile.  Alexander Lakhin reported a case where the assertions  
could be triggered with misconfigured foreign-table partitions,  
and bitter experience with unstable operating system collation  
definitions suggests another easy route to hitting them.  Neither  
Assert is in a place where we can't afford one more test-and-branch,  
so replace 'em with plain test-and-elog logic.  
  
Per bug #17395.  While the reported symptom is relatively recent,  
collation changes could happen anytime, so back-patch to all  
supported branches.  
  
Discussion: https://postgr.es/m/[email protected]  

M src/backend/executor/nodeMergejoin.c

doc: clarify syntax notation, particularly parentheses

commit   : 0079795ab7809f29190e98efdf8108584f846ced    
  
author   : Bruce Momjian <[email protected]>    
date     : Wed, 2 Feb 2022 21:53:51 -0500    
  
committer: Bruce Momjian <[email protected]>    
date     : Wed, 2 Feb 2022 21:53:51 -0500    

Click here for diff

Also move TCL syntax to the PL/tcl section.  
  
Reported-by: [email protected]  
  
Discussion: https://postgr.es/m/[email protected]  
  
Backpatch-through: 10  

M doc/src/sgml/notation.sgml
M doc/src/sgml/pltcl.sgml

doc: Fix mistake in PL/Python documentation

commit   : f4f97e95043ffeae152324842443b29996c004cd    
  
author   : Peter Eisentraut <[email protected]>    
date     : Wed, 2 Feb 2022 09:14:26 +0100    
  
committer: Peter Eisentraut <[email protected]>    
date     : Wed, 2 Feb 2022 09:14:26 +0100    

Click here for diff

Small thinko introduced by 94aceed317730953476bec490ce0148b2af3c383  
  
Reported-by: [email protected]  

M doc/src/sgml/plpython.sgml

Replace use of deprecated Python module distutils.sysconfig, take 2.

commit   : aa2215d6b8acee3604e16d5f5f2c3f40fc045bb4    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 1 Feb 2022 19:03:41 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 1 Feb 2022 19:03:41 -0500    

Click here for diff

With Python 3.10, configure spits out warnings about the module  
distutils.sysconfig being deprecated and scheduled for removal in  
Python 3.12.  Change the uses in configure to use the module sysconfig  
instead.  The logic stays largely the same, although we have to  
rely on INCLUDEPY instead of the deprecated get_python_inc function.  
  
Note that sysconfig exists since Python 2.7, so this moves the  
minimum required version up from Python 2.6 (or 2.4, before v13).  
Also, sysconfig didn't exist in Python 3.1, so the minimum 3.x  
version is now 3.2.  
  
Back-patch of commit bd233bdd8 into all supported branches.  
  
In v10, this also includes back-patching v11's beff4bb9c, primarily  
because this opinion is clearly out-of-date:  
  
    While at it, get rid of the code's assumption that both the major and  
    minor numbers contain exactly one digit.  That will foreseeably be  
    broken by Python 3.10 in perhaps four or five years.  That's far enough  
    out that we probably don't need to back-patch this.  
  
Peter Eisentraut, Tom Lane, Andres Freund  
  
Discussion: https://postgr.es/m/[email protected]  

M config/python.m4
M configure
M doc/src/sgml/installation.sgml

Revert "plperl: Fix breakage of c89f409749c in back branches."

commit   : a2ff3f6ecd67e39edbb312526b2feb5730e246ed    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 31 Jan 2022 15:07:39 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 31 Jan 2022 15:07:39 -0500    

Click here for diff

This reverts commits d81cac47a et al.  We shouldn't need that  
hack after the preceding commits.  
  
Discussion: https://postgr.es/m/[email protected]  

M src/pl/plperl/plperl.c

plperl: update ppport.h to Perl 5.34.0.

commit   : 0a7ded19b4cdf5fd9c758583461a81fed66c144a    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 31 Jan 2022 15:01:05 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 31 Jan 2022 15:01:05 -0500    

Click here for diff

Also apply the changes suggested by running  
perl ppport.h --compat-version=5.8.0  
  
And remove some no-longer-required NEED_foo declarations.  
  
Dagfinn Ilmari Mannsåker  
  
Back-patch of commit 05798c9f7 into all supported branches.  
At the time we thought this update was mostly cosmetic, but the  
lack of it has caused trouble, while the patch itself hasn't.  
  
Discussion: https://postgr.es/m/[email protected]  
Discussion: https://postgr.es/m/[email protected]  

M src/pl/plperl/plperl.c
M src/pl/plperl/plperl.h
M src/pl/plperl/ppport.h

plperl: Fix breakage of c89f409749c in back branches.

commit   : bb82e8a0bd044cbae1eb608b9a61f0a92efa681a    
  
author   : Andres Freund <[email protected]>    
date     : Sun, 30 Jan 2022 17:53:53 -0800    
  
committer: Andres Freund <[email protected]>    
date     : Sun, 30 Jan 2022 17:53:53 -0800    

Click here for diff

ppport.h was only updated in 05798c9f7f0 (master). Unfortunately my commit  
c89f409749c uses PERL_VERSION_LT which came in with that update. Breaking most  
buildfarm animals.  
  
I should have noticed that...  
  
We might want to backpatch the ppport update instead, but for now lets get the  
buildfarm green again.  
  
Discussion: https://postgr.es/m/[email protected]  
Backpatch: 10-14, master doesn't need it  

M src/pl/plperl/plperl.c

plperl: windows: Use Perl_setlocale on 5.28+, fixing compile failure.

commit   : f173738d56564689569d697f80b3f7ca3f5b236c    
  
author   : Andres Freund <[email protected]>    
date     : Sun, 30 Jan 2022 14:29:04 -0800    
  
committer: Andres Freund <[email protected]>    
date     : Sun, 30 Jan 2022 14:29:04 -0800    

Click here for diff

For older versions we need our own copy of perl's setlocale(), because it was  
not exposed (why we need the setlocale in the first place is explained in  
plperl_init_interp) . The copy stopped working in 5.28, as some of the used  
macros are not public anymore.  But Perl_setlocale is available in 5.28, so  
use that.  
  
Author: Victor Wagner <[email protected]>  
Reviewed-By: Dagfinn Ilmari Mannsåker <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  
Backpatch: all versions  

M src/pl/plperl/plperl.c

Fix ordering of XIDs in ProcArrayApplyRecoveryInfo

commit   : 4b8af2bf8c5c78a69d522bb0513b0b792581d97a    
  
author   : Tomas Vondra <[email protected]>    
date     : Thu, 27 Jan 2022 17:53:53 +0100    
  
committer: Tomas Vondra <[email protected]>    
date     : Thu, 27 Jan 2022 17:53:53 +0100    

Click here for diff

Commit 8431e296ea reworked ProcArrayApplyRecoveryInfo to sort XIDs  
before adding them to KnownAssignedXids. But the XIDs are sorted using  
xidComparator, which compares the XIDs simply as uint32 values, not  
logically. KnownAssignedXidsAdd() however expects XIDs in logical order,  
and calls TransactionIdFollowsOrEquals() to enforce that. If there are  
XIDs for which the two orderings disagree, an error is raised and the  
recovery fails/restarts.  
  
Hitting this issue is fairly easy - you just need two transactions, one  
started before the 4B limit (e.g. XID 4294967290), the other sometime  
after it (e.g. XID 1000). Logically (4294967290 <= 1000) but when  
compared using xidComparator we try to add them in the opposite order.  
Which makes KnownAssignedXidsAdd() fail with an error like this:  
  
  ERROR: out-of-order XID insertion in KnownAssignedXids  
  
This only happens during replica startup, while processing RUNNING_XACTS  
records to build the snapshot. Once we reach STANDBY_SNAPSHOT_READY, we  
skip these records. So this does not affect already running replicas,  
but if you restart (or create) a replica while there are transactions  
with XIDs for which the two orderings disagree, you may hit this.  
  
Long-running transactions and frequent replica restarts increase the  
likelihood of hitting this issue. Once the replica gets into this state,  
it can't be started (even if the old transactions are terminated).  
  
Fixed by sorting the XIDs logically - this is fine because we're dealing  
with normal XIDs (because it's XIDs assigned to backends) and from the  
same wraparound epoch (otherwise the backends could not be running at  
the same time on the primary node). So there are no problems with the  
triangle inequality, which is why xidComparator compares raw values.  
  
Investigation and root cause analysis by Abhijit Menon-Sen. Patch by me.  
  
This issue is present in all releases since 9.4, however releases up to  
9.6 are EOL already so backpatch to 10 only.  
  
Reviewed-by: Abhijit Menon-Sen  
Reviewed-by: Alvaro Herrera  
Backpatch-through: 10  
Discussion: https://postgr.es/m/36b8a501-5d73-277c-4972-f58a4dce088a%40enterprisedb.com  

M src/backend/storage/ipc/procarray.c
M src/backend/utils/adt/xid.c
M src/include/utils/builtins.h

On sparc64+ext4, suppress test failures from known WAL read failure.

commit   : 279956817ff4f8e69a2892d0677e303cb2a8c30b    
  
author   : Noah Misch <[email protected]>    
date     : Wed, 26 Jan 2022 18:06:19 -0800    
  
committer: Noah Misch <[email protected]>    
date     : Wed, 26 Jan 2022 18:06:19 -0800    

Click here for diff

Buildfarm members kittiwake, tadarida and snapper began to fail  
frequently when commits 3cd9c3b921977272e6650a5efbeade4203c4bca2 and  
f47ed79cc8a0cfa154dc7f01faaf59822552363f added tests of concurrency, but  
the problem was reachable before those commits.  Back-patch to v10 (all  
supported versions).  
  
Discussion: https://postgr.es/m/[email protected]  

M contrib/amcheck/t/003_cic_2pc.pl
M src/test/perl/TestLib.pm

Fix pg_hba_file_rules for authentication method cert

commit   : aa58f5c53142782bd6a376a578d85d5ddd13d751    
  
author   : Magnus Hagander <[email protected]>    
date     : Wed, 26 Jan 2022 09:52:41 +0100    
  
committer: Magnus Hagander <[email protected]>    
date     : Wed, 26 Jan 2022 09:52:41 +0100    

Click here for diff

For authentication method cert, clientcert=verify-full is implied. But  
the pg_hba_file_rules entry would incorrectly show clientcert=verify-ca.  
  
Per bug #17354  
  
Reported-By: Feike Steenbergen  
Reviewed-By: Jonathan Katz  
Backpatch-through: 12  

M src/backend/libpq/hba.c

Revert "graceful shutdown" changes for Windows, in back branches only.

commit   : 64b2c6507e5714b5c688b9c5cc551fbedb7b3b58    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 25 Jan 2022 12:17:40 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 25 Jan 2022 12:17:40 -0500    

Click here for diff

This reverts commits 6051857fc and ed52c3707, but only in the back  
branches.  Further testing has shown that while those changes do fix  
some things, they also break others; in particular, it looks like  
walreceivers fail to detect walsender-initiated connection close  
reliably if the walsender shuts down this way.  We'll keep trying to  
improve matters in HEAD, but it now seems unwise to push these changes  
into stable releases.  
  
Discussion: https://postgr.es/m/CA+hUKG+OeoETZQ=Qw5Ub5h3tmwQhBmDA=nuNO3KG=zWfUypFAw@mail.gmail.com  

M src/backend/libpq/pqcomm.c

Consider parallel awareness when removing single-child Appends

commit   : 2ccd8fb29d74f91b291be20df43f9c0194642ae8    
  
author   : David Rowley <[email protected]>    
date     : Tue, 25 Jan 2022 21:15:40 +1300    
  
committer: David Rowley <[email protected]>    
date     : Tue, 25 Jan 2022 21:15:40 +1300    

Click here for diff

8edd0e794 added some code to remove Append and MergeAppend nodes when they  
contained a single child node.  As it turned out, this was unsafe to do  
when the Append/MergeAppend was parallel_aware and the child node was not.  
Removing the Append/MergeAppend, in this case, could lead to the child plan  
being called multiple times by parallel workers when it was unsafe to do  
so.  
  
Here we fix this by just not removing the Append/MergeAppend when the  
parallel_aware flag of the parent and child node don't match.  
  
Reported-by: Yura Sokolov  
Bug: #17335  
Discussion: https://postgr.es/m/b59605fecb20ba9ea94e70ab60098c237c870628.camel%40postgrespro.ru  
Backpatch-through: 12, where 8edd0e794 was first introduced  

M src/backend/optimizer/plan/setrefs.c

doc: Fix some grammar

commit   : fcc434047d09428d48341c6faeb29e9bd9d95a4e    
  
author   : Michael Paquier <[email protected]>    
date     : Tue, 25 Jan 2022 10:49:44 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Tue, 25 Jan 2022 10:49:44 +0900    

Click here for diff

This is an extraction of the user-visible changes done in 410aa24,  
including all the relevant documentation parts.  
  
Author: Justin Pryzby  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 10  

M doc/src/sgml/config.sgml
M doc/src/sgml/ddl.sgml
M doc/src/sgml/perform.sgml
M doc/src/sgml/protocol.sgml
M doc/src/sgml/ref/pg_receivewal.sgml
M doc/src/sgml/ref/select_into.sgml

Fix limitations on what SQL commands can be issued to a walsender.

commit   : 689f75d6eb9a1bc09f5f93b7aaaa40357e8d9195    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 24 Jan 2022 15:33:34 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 24 Jan 2022 15:33:34 -0500    

Click here for diff

In logical replication mode, a WalSender is supposed to be able  
to execute any regular SQL command, as well as the special  
replication commands.  Poor design of the replication-command  
parser caused it to fail in various cases, notably:  
  
* semicolons embedded in a command, or multiple SQL commands  
sent in a single message;  
  
* dollar-quoted literals containing odd numbers of single  
or double quote marks;  
  
* commands starting with a comment.  
  
The basic problem here is that we're trying to run repl_scanner.l  
across the entire input string even when it's not a replication  
command.  Since repl_scanner.l does not understand all of the  
token types known to the core lexer, this is doomed to have  
failure modes.  
  
We certainly don't want to make repl_scanner.l as big as scan.l,  
so instead rejigger stuff so that we only lex the first token of  
a non-replication command.  That will usually look like an IDENT  
to repl_scanner.l, though a comment would end up getting reported  
as a '-' or '/' single-character token.  If the token is a replication  
command keyword, we push it back and proceed normally with repl_gram.y  
parsing.  Otherwise, we can drop out of exec_replication_command()  
without examining the rest of the string.  
  
(It's still theoretically possible for repl_scanner.l to fail on  
the first token; but that could only happen if it's an unterminated  
single- or double-quoted string, in which case you'd have gotten  
largely the same error from the core lexer too.)  
  
In this way, repl_gram.y isn't involved at all in handling general  
SQL commands, so we can get rid of the SQLCmd node type.  (In  
the back branches, we can't remove it because renumbering enum  
NodeTag would be an ABI break; so just leave it sit there unused.)  
  
I failed to resist the temptation to clean up some other sloppy  
coding in repl_scanner.l while at it.  The only externally-visible  
behavior change from that is it now accepts \r and \f as whitespace,  
same as the core lexer.  
  
Per bug #17379 from Greg Rychlewski.  Back-patch to all supported  
branches.  
  
Discussion: https://postgr.es/m/[email protected]  

M src/backend/replication/repl_gram.y
M src/backend/replication/repl_scanner.l
M src/backend/replication/walsender.c
M src/include/replication/walsender_private.h

Remember to reset yy_start state when firing up repl_scanner.l.

commit   : a8ce5c8d788823f9bb79ab5760a396bfe2116529    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 24 Jan 2022 12:09:46 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 24 Jan 2022 12:09:46 -0500    

Click here for diff

Without this, we get odd behavior when the previous cycle of  
lexing exited in a non-default exclusive state.  Every other  
copy of this code is aware that it has to do BEGIN(INITIAL),  
but repl_scanner.l did not get that memo.  
  
The real-world impact of this is probably limited, since most  
replication clients would abandon their connection after getting  
a syntax error.  Still, it's a bug.  
  
This mistake is old, so back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/[email protected]  

M src/backend/replication/repl_scanner.l

Suppress variable-set-but-not-used warning from clang 13.

commit   : 68cc72d4d55cd1d45c24f0f3fccc1f445b6ad0da    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 23 Jan 2022 11:09:00 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 23 Jan 2022 11:09:00 -0500    

Click here for diff

In the normal configuration where GEQO_DEBUG isn't defined,  
recent clang versions have started to complain that geqo_main.c  
accumulates the edge_failures count but never does anything  
with it.  As a minimal back-patchable fix, insert a void cast  
to silence this warning.  (I'd speculated about ripping out the  
GEQO_DEBUG logic altogether, but I don't think we'd wish to  
back-patch that.)  
  
Per recently-established project policy, this is a candidate  
for back-patching into out-of-support branches: it suppresses  
an annoying compiler warning but changes no behavior.  Hence,  
back-patch all the way to 9.2.  
  
Discussion: https://postgr.es/m/CA+hUKGLTSZQwES8VNPmWO9AO0wSeLt36OCPDAZTccT1h7Q7kTQ@mail.gmail.com  

M src/backend/optimizer/geqo/geqo_main.c

Correct type of front_pathkey to PathKey

commit   : 93854d5b1bf340858a46a9696320dac1065b9c32    
  
author   : Tomas Vondra <[email protected]>    
date     : Sun, 23 Jan 2022 03:36:55 +0100    
  
committer: Tomas Vondra <[email protected]>    
date     : Sun, 23 Jan 2022 03:36:55 +0100    

Click here for diff

In sort_inner_and_outer we iterate a list of PathKey elements, but the  
variable is declared as (List *). This mistake is benign, because we  
only pass the pointer to lcons() and never dereference it.  
  
This exists since ~2004, but it's confusing. So fix and backpatch to all  
supported branches.  
  
Backpatch-through: 10  
Discussion: https://postgr.es/m/bf3a6ea1-a7d8-7211-0669-189d5c169374%40enterprisedb.com  

M src/backend/optimizer/path/joinpath.c

Flush table's relcache during ALTER TABLE ADD PRIMARY KEY USING INDEX.

commit   : e2d53c8767da9f98c7c4c8d0b129171848472c93    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 22 Jan 2022 13:32:40 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 22 Jan 2022 13:32:40 -0500    

Click here for diff

Previously, unless we had to add a NOT NULL constraint to the column,  
this command resulted in updating only the index's relcache entry.  
That's problematic when replication behavior is being driven off the  
existence of a primary key: other sessions (and ours too for that  
matter) failed to recalculate their opinion of whether the table can  
be replicated.  Add a relcache invalidation to fix it.  
  
This has been broken since pg_class.relhaspkey was removed in v11.  
Before that, updating the table's relhaspkey value sufficed to cause  
a cache flush.  Hence, backpatch to v11.  
  
Report and patch by Hou Zhijie  
  
Discussion: https://postgr.es/m/OS0PR01MB5716EBE01F112C62F8F9B786947B9@OS0PR01MB5716.jpnprd01.prod.outlook.com  

M src/backend/catalog/index.c
M src/test/regress/expected/publication.out
M src/test/regress/sql/publication.sql

Fix race condition in gettext() initialization in libpq and ecpglib.

commit   : 5521d8139fbdb15f1bf25afae22e7e6d196669e0    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 21 Jan 2022 15:36:12 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 21 Jan 2022 15:36:12 -0500    

Click here for diff

In libpq and ecpglib, multiple threads can concurrently enter the  
initialization logic for message localization.  Since we set the  
its-done flag before actually doing the work, it'd be possible  
for some threads to reach gettext() before anyone has called  
bindtextdomain().  Barring bugs in libintl itself, this would not  
result in anything worse than failure to localize some early  
messages.  Nonetheless, it's a bug, and an easy one to fix.  
  
Noted while investigating bug #17299 from Clemens Zeidler  
(much thanks to Liam Bowen for followup investigation on that).  
It currently appears that that actually *is* a bug in libintl itself,  
but that doesn't let us off the hook for this bit.  
  
Back-patch to all supported versions.  
  
Discussion: https://postgr.es/m/[email protected]  
Discussion: https://postgr.es/m/CAE7q7Eit4Eq2=bxce=Fm8HAStECjaXUE=WBQc-sDDcgJQ7s7eg@mail.gmail.com  

M src/interfaces/ecpg/ecpglib/misc.c
M src/interfaces/libpq/fe-misc.c

fsync pg_logical/mappings in CheckPointLogicalRewriteHeap().

commit   : 1c6d055ba77a5b600496a81bbaafaeb064d1cf2d    
  
author   : Andres Freund <[email protected]>    
date     : Fri, 21 Jan 2022 11:22:55 -0800    
  
committer: Andres Freund <[email protected]>    
date     : Fri, 21 Jan 2022 11:22:55 -0800    

Click here for diff

While individual logical rewrite files were synced to disk, the directory was  
not. On some filesystems that could lead to loosing directory entries after a  
crash.  
  
Reported-By: Tom Lane <[email protected]>  
Author: Nathan Bossart <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  
Backpatch: 10-  

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

Fix one-off bug causing missing commit timestamps for subtransactions

commit   : 1c0452c48ca4e5fcdc56808a2f475bbf6b546b86    
  
author   : Michael Paquier <[email protected]>    
date     : Fri, 21 Jan 2022 14:54:55 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Fri, 21 Jan 2022 14:54:55 +0900    

Click here for diff

The logic in charge of writing commit timestamps (enabled with  
track_commit_timestamp) for subtransactions had a one-bug bug,  
where it would be possible that commit timestamps go missing for the  
last subtransaction committed.  
  
While on it, simplify a bit the iteration logic in the loop writing the  
commit timestamps, as per suggestions from Kyotaro Horiguchi and Tom  
Lane, so as some variable initializations are not part of the loop  
itself.  
  
Issue introduced in 73c986a.  
  
Analyzed-by: Alex Kingsborough  
Author: Alex Kingsborough, Kyotaro Horiguchi  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 10  

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

Tighten TAP tests' tracking of postmaster state some more.

commit   : f0b0b1ddb53a66e57404cd1bfa4aa2944c3e77c6    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 20 Jan 2022 17:28:07 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 20 Jan 2022 17:28:07 -0500    

Click here for diff

Commits 6c4a8903b et al. had a couple of deficiencies:  
  
* The logic I added to Cluster::start to see if a PID file is present  
could be fooled by a stale PID file left over from a previous  
postmaster.  To fix, if we're not sure whether we expect to find a  
running postmaster or not, validate the PID using "kill 0".  
  
* 017_shm.pl has a loop in which it just issues repeated Cluster::start  
calls; this will fail if some invocation fails but leaves self->_pid  
set.  Per buildfarm results, the above fix is not enough to make this  
safe: we might have "validated" a PID for a postmaster that exits  
immediately after we look.  Hence, match each failed start call with  
a stop call that will get us back to the self->_pid == undef state.  
Add a fail_ok option to Cluster::stop to make this work.  
  
Discussion: https://postgr.es/m/CA+hUKGKV6fOHvfiPt8=dOKzvswjAyLoFoJF1iQXMNpi7+hD1JQ@mail.gmail.com  

M src/test/perl/PostgresNode.pm
M src/test/recovery/t/017_shm.pl

Allow clean.bat to be run from anywhere

commit   : 22d8c2570fead4ad00f5fe02af9895e4b1c2e3e9    
  
author   : Andrew Dunstan <[email protected]>    
date     : Thu, 20 Jan 2022 10:13:18 -0500    
  
committer: Andrew Dunstan <[email protected]>    
date     : Thu, 20 Jan 2022 10:13:18 -0500    

Click here for diff

This was omitted from c3879a7b4c which modified the other msvc .bat  
files.  
  
Per request from Juan José Santamaría Flecha  
  
Discussion: https://postgr.es/m/CAC+AXB0_fxYGbQoaYjCA8um7TTbOVP4L9aXnVmHwK8WzaT4gdA@mail.gmail.com  
  
Backpatch to all live branches.  

M src/tools/msvc/clean.bat

Try to stabilize reloptions test, again.

commit   : dbe4ca6f418a14c5750464a3fff9a9aea266aa13    
  
author   : Thomas Munro <[email protected]>    
date     : Thu, 20 Jan 2022 22:11:48 +1300    
  
committer: Thomas Munro <[email protected]>    
date     : Thu, 20 Jan 2022 22:11:48 +1300    

Click here for diff

Since the test requires reproducible behavior from VACUUM, and since  
DISABLE_PAGE_SKIPPING doesn't actually disable all forms of page  
skipping, let's use a temporary table to avoid contention.  
  
Back-patch to 12, like commit 3414099c.  
  
Discussion: https://postgr.es/m/20220120052404.sonrhq3f3qgplpzj%40alap3.anarazel.de  

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

doc: Mention the level of locks taken on objects in COMMENT

commit   : e58345f5d11075fb4fbec894786f61293a4ce738    
  
author   : Michael Paquier <[email protected]>    
date     : Thu, 20 Jan 2022 16:55:05 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Thu, 20 Jan 2022 16:55:05 +0900    

Click here for diff

This information was nowhere to be found.  This adds one note on the  
page of COMMENT, and one note in the section dedicated to explicit  
locking, both telling that a SHARE UPDATE EXCLUSIVE lock is taken on the  
object commented.  
  
Author: Nikolai Berkoff  
Reviewed-by: Laurenz Albe  
Discussion: https://postgr.es/m/_0HDHIGcCdCsUyXn22QwI2FEuNR6Fs71rtgGX6hfyBlUh5rrnE2qMmvIFu9EY4Pijr2gUmJEAXCjuNU2Oxku9TryLp9CdHllpsCfN3gD0-Y=@pm.me  
Backpatch-through: 10  

M doc/src/sgml/mvcc.sgml
M doc/src/sgml/ref/comment.sgml

TAP tests: check for postmaster.pid anyway when "pg_ctl start" fails.

commit   : 5940d1b027d750103daf99af48a4cd93be12e148    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 19 Jan 2022 16:29:09 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 19 Jan 2022 16:29:09 -0500    

Click here for diff

"pg_ctl start" might start a new postmaster and then return failure  
anyway, for example if PGCTLTIMEOUT is exceeded.  If there is a  
postmaster there, it's still incumbent on us to shut it down at  
script end, so check for the PID file even though we are about  
to fail.  
  
This has been broken all along, so back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/[email protected]  

M src/test/perl/PostgresNode.pm

doc: Fix description of pg_replication_origin_oid() in error case

commit   : fdb11ad458a789324edfb18984b7d4f5f4560a70    
  
author   : Michael Paquier <[email protected]>    
date     : Wed, 19 Jan 2022 10:37:58 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Wed, 19 Jan 2022 10:37:58 +0900    

Click here for diff

This function returns NULL if the replication origin given in input  
argument does not exist, contrary to what the docs described  
previously.  
  
Author: Ian Barwick  
Discussion: https://postgr.es/m/CAB8KJ=htJjBL=103URqjOxV2mqb4rjphDpMeKdyKq_QXt6h05w@mail.gmail.com  
Backpatch-through: 10  

M doc/src/sgml/func.sgml

Try to stabilize the reloptions test.

commit   : bef165059268ad8b48b9163c4f62999f203b7782    
  
author   : Thomas Munro <[email protected]>    
date     : Wed, 19 Jan 2022 07:03:01 +1300    
  
committer: Thomas Munro <[email protected]>    
date     : Wed, 19 Jan 2022 07:03:01 +1300    

Click here for diff

Where we test vacuum_truncate's effects, sometimes this is failing to  
truncate as expected on the build farm.  That could be explained by page  
skipping, so disable it explicitly, with the theory that commit fe246d1c  
didn't go far enough.  
  
Back-patch to 12, where the vacuum_truncate tests were added.  
  
Discussion: https://postgr.es/m/CA%2BhUKGLT2UL5_JhmBzUgkdyKfc%3D5J-gJSQJLysMs4rqLUKLAzw%40mail.gmail.com  

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

Avoid calling gettext() in signal handlers.

commit   : 6d1a854c157eb4a139e06f19a8cd1b53bdec7e6f    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 17 Jan 2022 13:30:04 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 17 Jan 2022 13:30:04 -0500    

Click here for diff

It seems highly unlikely that gettext() can be relied on to be  
async-signal-safe.  psql used to understand that, but someone got  
it wrong long ago in the src/bin/scripts/ version of handle_sigint,  
and then the bad idea was perpetuated when those two versions were  
unified into src/fe_utils/cancel.c.  
  
I'm unsure why there have not been field complaints about this  
... maybe gettext() is signal-safe once it's translated at least  
one message?  But we have no business assuming any such thing.  
  
In cancel.c (v13 and up), I preserved our ability to localize  
"Cancel request sent" messages by invoking gettext() before  
the signal handler is set up.  In earlier branches I just made  
src/bin/scripts/ not localize those messages, as psql did then.  
  
(Just for extra unsafety, the src/bin/scripts/ version was  
invoking fprintf() from a signal handler.  Sigh.)  
  
Noted while fixing signal-safety issues in PQcancel() itself.  
Back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/[email protected]  

M src/bin/scripts/common.c

Avoid calling strerror[_r] in PQcancel().

commit   : 38f099ef935b34388af2ae52c1098d2c9773465a    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 17 Jan 2022 12:52:44 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 17 Jan 2022 12:52:44 -0500    

Click here for diff

PQcancel() is supposed to be safe to call from a signal handler,  
and indeed psql uses it that way.  All of the library functions  
it uses are specified to be async-signal-safe by POSIX ...  
except for strerror.  Neither plain strerror nor strerror_r  
are considered safe.  When this code was written, back in the  
dark ages, we probably figured "oh, strerror will just index  
into a constant array of strings" ... but in any locale except C,  
that's unlikely to be true.  Probably the reason we've not heard  
complaints is that (a) this error-handling code is unlikely to be  
reached in normal use, and (b) in many scenarios, localized error  
strings would already have been loaded, after which maybe it's  
safe to call strerror here.  Still, this is clearly unacceptable.  
  
The best we can do without relying on strerror is to print the  
decimal value of errno, so make it do that instead.  (This is  
probably not much loss of user-friendliness, given that it is  
hard to get a failure here.)  
  
Back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/[email protected]  

M src/interfaces/libpq/fe-connect.c

Build inherited extended stats on partitioned tables

commit   : 9d1bcf5dc11a932e0a88710c34815c86dc583fcc    
  
author   : Tomas Vondra <[email protected]>    
date     : Sat, 15 Jan 2022 18:17:20 +0100    
  
committer: Tomas Vondra <[email protected]>    
date     : Sat, 15 Jan 2022 18:17:20 +0100    

Click here for diff

Commit 859b3003de disabled building of extended stats for inheritance  
trees, to prevent updating the same catalog row twice. While that  
resolved the issue, it also means there are no extended stats for  
declaratively partitioned tables, because there are no data in the  
non-leaf relations.  
  
That also means declaratively partitioned tables were not affected by  
the issue 859b3003de addressed, which means this is a regression  
affecting queries that calculate estimates for the whole inheritance  
tree as a whole (which includes e.g. GROUP BY queries).  
  
But because partitioned tables are empty, we can invert the condition  
and build statistics only for the case with inheritance, without losing  
anything. And we can consider them when calculating estimates.  
  
It may be necessary to run ANALYZE on partitioned tables, to collect  
proper statistics. For declarative partitioning there should no prior  
statistics, and it might take time before autoanalyze is triggered. For  
tables partitioned by inheritance the statistics may include data from  
child relations (if built 859b3003de), contradicting the current code.  
  
Report and patch by Justin Pryzby, minor fixes and cleanup by me.  
Backpatch all the way back to PostgreSQL 10, where extended statistics  
were introduced (same as 859b3003de).  
  
Author: Justin Pryzby  
Reported-by: Justin Pryzby  
Backpatch-through: 10  
Discussion: https://postgr.es/m/20210923212624.GI831%40telsasoft.com  

M src/backend/commands/analyze.c
M src/backend/statistics/dependencies.c
M src/backend/statistics/extended_stats.c
M src/backend/utils/adt/selfuncs.c
M src/test/regress/expected/stats_ext.out
M src/test/regress/sql/stats_ext.sql

Ignore extended statistics for inheritance trees

commit   : 76569ad6f423f56f655699f57c39298af2111914    
  
author   : Tomas Vondra <[email protected]>    
date     : Sat, 15 Jan 2022 02:15:23 +0100    
  
committer: Tomas Vondra <[email protected]>    
date     : Sat, 15 Jan 2022 02:15:23 +0100    

Click here for diff

Since commit 859b3003de we only build extended statistics for individual  
relations, ignoring the child relations. This resolved the issue with  
updating catalog tuple twice, but we still tried to use the statistics  
when calculating estimates for the whole inheritance tree. When the  
relations contain very distinct data, it may produce bogus estimates.  
  
This is roughly the same issue 427c6b5b9 addressed ~15 years ago, and we  
fix it the same way - by ignoring extended statistics when calculating  
estimates for the inheritance tree as a whole. We still consider  
extended statistics when calculating estimates for individual child  
relations, of course.  
  
This may result in plan changes due to different estimates, but if the  
old statistics were not describing the inheritance tree particularly  
well it's quite likely the new plans is actually better.  
  
Report and patch by Justin Pryzby, minor fixes and cleanup by me.  
Backpatch all the way back to PostgreSQL 10, where extended statistics  
were introduced (same as 859b3003de).  
  
Author: Justin Pryzby  
Reported-by: Justin Pryzby  
Backpatch-through: 10  
Discussion: https://postgr.es/m/20210923212624.GI831%40telsasoft.com  

M src/backend/statistics/dependencies.c
M src/backend/statistics/extended_stats.c
M src/backend/utils/adt/selfuncs.c
M src/test/regress/expected/stats_ext.out
M src/test/regress/sql/stats_ext.sql

Fix ruleutils.c's dumping of whole-row Vars in more contexts.

commit   : 45a3cefad6380cfc33303b7c294687d4b3ce634e    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 13 Jan 2022 17:49:26 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 13 Jan 2022 17:49:26 -0500    

Click here for diff

Commit 7745bc352 intended to ensure that whole-row Vars would be  
printed with "::type" decoration in all contexts where plain  
"var.*" notation would result in star-expansion, notably in  
ROW() and VALUES() constructs.  However, it missed the case of  
INSERT with a single-row VALUES, as reported by Timur Khanjanov.  
  
Nosing around ruleutils.c, I found a second oversight: the  
code for RowCompareExpr generates ROW() notation without benefit  
of an actual RowExpr, and naturally it wasn't in sync :-(.  
(The code for FieldStore also does this, but we don't expect that  
to generate strictly parsable SQL anyway, so I left it alone.)  
  
Back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/[email protected]  

M src/backend/utils/adt/ruleutils.c
M src/test/regress/expected/create_view.out
M src/test/regress/sql/create_view.sql

Doc: fix bogus example about ambiguous timestamps.

commit   : 850c704c72a2e86c682948a36c65c1bd6618829f    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 10 Jan 2022 11:46:16 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 10 Jan 2022 11:46:16 -0500    

Click here for diff

I had a brain fade in commit d32899157, and used 2:30AM as the  
example timestamp for both spring-forward and fall-back cases.  
But it's not actually ambiguous at all in the fall-back case,  
because that transition is from 2AM to 1AM under USA rules.  
Fix the example to use 1:30AM, which *is* ambiguous.  
  
Noted while answering a question from Aleksander Alekseev.  
Back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/[email protected]  

M doc/src/sgml/datetime.sgml

Avoid warning about uninitialized value in MSVC python3 tests

commit   : 5b2cb9c29e09419bcce2e1be47a78a7e3d0a1156    
  
author   : Andrew Dunstan <[email protected]>    
date     : Mon, 10 Jan 2022 10:08:44 -0500    
  
committer: Andrew Dunstan <[email protected]>    
date     : Mon, 10 Jan 2022 10:08:44 -0500    

Click here for diff

Juan José Santamaría Flecha  
  
Backpatch to all live branches  

M src/tools/msvc/vcregress.pl

Fix results of index-only scans on btree_gist char(N) indexes.

commit   : 3a69d45afcc81fceeb44254f38bc3258fc3a160b    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 8 Jan 2022 14:54:39 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 8 Jan 2022 14:54:39 -0500    

Click here for diff

If contrib/btree_gist is used to make a GIST index on a char(N)  
(bpchar) column, and that column is retrieved via an index-only  
scan, what came out had all trailing spaces removed.  Since  
that doesn't happen in any other kind of table scan, this is  
clearly a bug.  The cause is that gbt_bpchar_compress() strips  
trailing spaces (using rtrim1) before a new index entry is made.  
That was probably a good idea when this code was first written,  
but since we invented index-only scans, it's not so good.  
  
One answer could be to mark this opclass as incapable of index-only  
scans.  But to do so, we'd need an extension module version bump,  
followed by manual action by DBAs to install the updated version  
of btree_gist.  And it's not really a desirable place to end up,  
anyway.  
  
Instead, let's fix the code by removing the unwanted space-stripping  
action and adjusting the opclass's comparison logic to ignore  
trailing spaces as bpchar normally does.  This will not hinder  
cases that work today, since index searches with this logic will  
act the same whether trailing spaces are stored or not.  It will  
not by itself fix the problem of getting space-stripped results  
from index-only scans, of course.  Users who care about that can  
REINDEX affected indexes after installing this update, to immediately  
replace all improperly-truncated index entries.  Otherwise, it can  
be expected that the index's behavior will change incrementally as  
old entries are replaced by new ones.  
  
Per report from Alexander Lakhin.  Back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/[email protected]  

M contrib/btree_gist/btree_text.c
M contrib/btree_gist/expected/char.out
M contrib/btree_gist/expected/char_1.out

commit   : df3f24be2aad1f34ee31e3a75cb5e844e3416505    
  
author   : Bruce Momjian <[email protected]>    
date     : Fri, 7 Jan 2022 19:04:56 -0500    
  
committer: Bruce Momjian <[email protected]>    
date     : Fri, 7 Jan 2022 19:04:56 -0500    

Click here for diff

Backpatch-through: 10  

M COPYRIGHT
M doc/src/sgml/legal.sgml

Allow MSVC .bat wrappers to be called from anywhere

commit   : a4cde9153b6efd9f1649daaa5d0caf8d3807e64d    
  
author   : Andrew Dunstan <[email protected]>    
date     : Fri, 7 Jan 2022 16:07:45 -0500    
  
committer: Andrew Dunstan <[email protected]>    
date     : Fri, 7 Jan 2022 16:07:45 -0500    

Click here for diff

Instead of using a hardcoded or default path to the perl file the .bat  
file is a wrapper for, we use a path that means the file is found in  
the same directory as the .bat file.  
  
Patch by Anton Voloshin, slightly tweaked by me.  
  
Backpatch to all live branches  
  
Discussion: https://postgr.es/m/[email protected]  

M src/tools/msvc/build.bat
M src/tools/msvc/install.bat
M src/tools/msvc/pgbison.bat
M src/tools/msvc/pgflex.bat
M src/tools/msvc/vcregress.bat

Prevent altering partitioned table's rowtype, if it's used elsewhere.

commit   : ccc7c3ad86b67cd85805824d40782fa5b92b1fc5    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 6 Jan 2022 16:46:46 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 6 Jan 2022 16:46:46 -0500    

Click here for diff

We disallow altering a column datatype within a regular table,  
if the table's rowtype is used as a column type elsewhere,  
because we lack code to go around and rewrite the other tables.  
This restriction should apply to partitioned tables as well, but it  
was not checked because ATRewriteTables and ATPrepAlterColumnType  
were not on the same page about who should do it for which relkinds.  
  
Per bug #17351 from Alexander Lakhin.  Back-patch to all supported  
branches.  
  
Discussion: https://postgr.es/m/[email protected]  

M src/backend/commands/tablecmds.c
M src/test/regress/expected/alter_table.out
M src/test/regress/sql/alter_table.sql

commit   : ada0e91f9d435b8c1c185107f3ba4e80966b7d82    
  
author   : Michael Paquier <[email protected]>    
date     : Thu, 6 Jan 2022 11:41:47 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Thu, 6 Jan 2022 11:41:47 +0900    

Click here for diff

The link used in the documentation is dead, and the only options to have  
an access to this part of the SQL specification are not free.  Like any  
other books referred, just remove the link to keep some neutrality but  
keep its reference.  
  
Reported-by: Erik Rijkers  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 12  

M doc/src/sgml/biblio.sgml

Fix silly mistake in Assert

commit   : 397b43948861155893da0f04b4de8e7ff021636f    
  
author   : Alvaro Herrera <[email protected]>    
date     : Tue, 4 Jan 2022 13:21:23 -0300    
  
committer: Alvaro Herrera <[email protected]>    
date     : Tue, 4 Jan 2022 13:21:23 -0300    

Click here for diff

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

Allow special SKIP LOCKED condition in Assert()

commit   : 6b681cd056bb8c821f8853463938070ce0dade8f    
  
author   : Alvaro Herrera <[email protected]>    
date     : Tue, 4 Jan 2022 13:01:05 -0300    
  
committer: Alvaro Herrera <[email protected]>    
date     : Tue, 4 Jan 2022 13:01:05 -0300    

Click here for diff

Under concurrency, it is possible for two sessions to be merrily locking  
and releasing a tuple and marking it again as HEAP_XMAX_INVALID all the  
while a third session attempts to lock it, miserably fails at it, and  
then contemplates life, the universe and everything only to eventually  
fail an assertion that said bit is not set.  Before SKIP LOCKED that was  
indeed a reasonable expectation, but alas! commit df630b0dd5ea falsified  
it.  
  
This bug is as old as time itself, and even older, if you think time  
begins with the oldest supported branch.  Therefore, backpatch to all  
supported branches.  
  
Author: Simon Riggs <[email protected]>  
Discussion: https://postgr.es/m/CANbhV-FeEwMnN8yuMyss7if1ZKjOKfjcgqB26n8pqu1e=q0ebg@mail.gmail.com  

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

Fix index-only scan plans, take 2.

commit   : 9c4f38908447c1c6a910e4a16e0644e0ccade204    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 3 Jan 2022 15:42:27 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 3 Jan 2022 15:42:27 -0500    

Click here for diff

Commit 4ace45677 failed to fix the problem fully, because the  
same issue of attempting to fetch a non-returnable index column  
can occur when rechecking the indexqual after using a lossy index  
operator.  Moreover, it broke EXPLAIN for such indexquals (which  
indicates a gap in our test cases :-().  
  
Revert the code changes of 4ace45677 in favor of adding a new field  
to struct IndexOnlyScan, containing a version of the indexqual that  
can be executed against the index-returned tuple without using any  
non-returnable columns.  (The restrictions imposed by check_index_only  
guarantee this is possible, although we may have to recompute indexed  
expressions.)  Support construction of that during setrefs.c  
processing by marking IndexOnlyScan.indextlist entries as resjunk  
if they can't be returned, rather than removing them entirely.  
(We could alternatively require setrefs.c to look up the IndexOptInfo  
again, but abusing resjunk this way seems like a reasonably safe way  
to avoid needing to do that.)  
  
This solution isn't great from an API-stability standpoint: if there  
are any extensions out there that build IndexOnlyScan structs directly,  
they'll be broken in the next minor releases.  However, only a very  
invasive extension would be likely to do such a thing.  There's no  
change in the Path representation, so typical planner extensions  
shouldn't have a problem.  
  
As before, back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/[email protected]  
Discussion: https://postgr.es/m/[email protected]  

M src/backend/commands/explain.c
M src/backend/executor/nodeIndexonlyscan.c
M src/backend/nodes/copyfuncs.c
M src/backend/nodes/outfuncs.c
M src/backend/nodes/readfuncs.c
M src/backend/optimizer/plan/createplan.c
M src/backend/optimizer/plan/setrefs.c
M src/backend/optimizer/plan/subselect.c
M src/include/nodes/execnodes.h
M src/include/nodes/plannodes.h
M src/test/regress/expected/gist.out
M src/test/regress/sql/gist.sql

Fix typo

commit   : 580e99885970179d058d79914c43fb7bcba9242c    
  
author   : Magnus Hagander <[email protected]>    
date     : Sun, 2 Jan 2022 17:03:32 +0100    
  
committer: Magnus Hagander <[email protected]>    
date     : Sun, 2 Jan 2022 17:03:32 +0100    

Click here for diff

Reported-By: Eric Mutta  
Backpatch-through: 10  
Discussion: https://postgr.es/m/[email protected]  

M doc/src/sgml/high-availability.sgml

Fix index-only scan plans when not all index columns can be returned.

commit   : f789b7732e0b535fe2588879a60f536abfb6c6e0    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 1 Jan 2022 16:12:03 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 1 Jan 2022 16:12:03 -0500    

Click here for diff

If an index has both returnable and non-returnable columns, and one of  
the non-returnable columns is an expression using a Var that is in a  
returnable column, then a query returning that expression could result  
in an index-only scan plan that attempts to read the non-returnable  
column, instead of recomputing the expression from the returnable  
column as intended.  
  
To fix, redefine the "indextlist" list of an IndexOnlyScan plan node  
as containing null Consts in place of any non-returnable columns.  
This solves the problem by preventing setrefs.c from falsely matching  
to such entries.  The executor is happy since it only cares about the  
exposed types of the entries, and ruleutils.c doesn't care because a  
correct plan won't reference those entries.  I considered some other  
ways to prevent setrefs.c from doing the wrong thing, but this way  
seems good since (a) it allows a very localized fix, (b) it makes  
the indextlist structure more compact in many cases, and (c) the  
indextlist is now a more faithful representation of what the index AM  
will actually produce, viz. nulls for any non-returnable columns.  
  
This is easier to hit since we introduced included columns, but it's  
possible to construct failing examples without that, as per the  
added regression test.  Hence, back-patch to all supported branches.  
  
Per bug #17350 from Louis Jachiet.  
  
Discussion: https://postgr.es/m/[email protected]  

M src/backend/optimizer/plan/createplan.c
M src/include/nodes/plannodes.h
M src/test/regress/expected/gist.out
M src/test/regress/sql/gist.sql

Fix overly generic name in with.sql test.

commit   : d536d0304b7891fdf5c74f0077f4de45290f6f63    
  
author   : Thomas Munro <[email protected]>    
date     : Thu, 30 Dec 2021 16:09:53 +1300    
  
committer: Thomas Munro <[email protected]>    
date     : Thu, 30 Dec 2021 16:09:53 +1300    

Click here for diff

Avoid the name "test".  In the 10 branch, this could clash with  
alter_table.sql, as seen in the build farm.  That other instance was  
already renamed in later branches by commit 2cf8c7aa, but it's good to  
future-proof the name here too.  
  
Back-patch to 10.  
  
Reviewed-by: Tom Lane <[email protected]>  
Discussion: https://postgr.es/m/CA%2BhUKGJf4RAXUyAYVUcQawcptX%3DnhEco3SYpuPK5cCbA-F1eLA%40mail.gmail.com  

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

doc: clarify when expression indexes evaluate their expressions

commit   : 9ac9878f15c993a8cbe3025a1ff7b72225841029    
  
author   : Bruce Momjian <[email protected]>    
date     : Wed, 22 Dec 2021 16:29:16 -0500    
  
committer: Bruce Momjian <[email protected]>    
date     : Wed, 22 Dec 2021 16:29:16 -0500    

Click here for diff

Only non-HOT updates evaluate the index expression.  
  
Reported-by: Chris Lowder  
  
Discussion: https://postgr.es/m/[email protected]  
  
Backpatch-through: 10  

M doc/src/sgml/indices.sgml

Correct comment and some documentation about REPLICA_IDENTITY_INDEX

commit   : 861095a40987fb40d0e3ed43f223ca0f79071dea    
  
author   : Michael Paquier <[email protected]>    
date     : Wed, 22 Dec 2021 16:38:49 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Wed, 22 Dec 2021 16:38:49 +0900    

Click here for diff

catalog/pg_class.h was stating that REPLICA_IDENTITY_INDEX with a  
dropped index is equivalent to REPLICA_IDENTITY_DEFAULT.  The code tells  
a different story, as it is equivalent to REPLICA_IDENTITY_NOTHING.  
  
The behavior exists since the introduction of replica identities, and  
fe7fd4e even added tests for this case but I somewhat forgot to fix this  
comment.  
  
While on it, this commit reorganizes the documentation about replica  
identities on the ALTER TABLE page, and a note is added about the case  
of dropped indexes with REPLICA_IDENTITY_INDEX.  
  
Author: Michael Paquier, Wei Wang  
Reviewed-by: Euler Taveira  
Discussion: https://postgr.es/m/OS3PR01MB6275464AD0A681A0793F56879E759@OS3PR01MB6275.jpnprd01.prod.outlook.com  
Backpatch-through: 10  

M doc/src/sgml/ref/alter_table.sgml
M src/include/catalog/pg_class.h

Ensure casting to typmod -1 generates a RelabelType.

commit   : e1fd61c8cea76f1abca8d9a790f2188534724703    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 16 Dec 2021 15:36:02 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 16 Dec 2021 15:36:02 -0500    

Click here for diff

Fix the code changed by commit 5c056b0c2 so that we always generate  
RelabelType, not something else, for a cast to unspecified typmod.  
Otherwise planner optimizations might not happen.  
  
It appears we missed this point because the previous experiments were  
done on type numeric: the parser undesirably generates a call on the  
numeric() length-coercion function, but then numeric_support()  
optimizes that down to a RelabelType, so that everything seems fine.  
It misbehaves for types that have a non-optimized length coercion  
function, such as bpchar.  
  
Per report from John Naylor.  Back-patch to all supported branches,  
as the previous patch eventually was.  Unfortunately, that no longer  
includes 9.6 ... we really shouldn't put this type of change into a  
nearly-EOL branch.  
  
Discussion: https://postgr.es/m/CAFBsxsEfbFHEkouc+FSj+3K1sHipLPbEC67L0SAe-9-da8QtYg@mail.gmail.com  

M src/backend/parser/parse_coerce.c
M src/test/regress/expected/expressions.out
M src/test/regress/sql/expressions.sql

Adjust behavior of some env settings for the TAP tests of MSVC

commit   : f04aa65daf597e2f9eb1e79c553c62adbbe3b897    
  
author   : Michael Paquier <[email protected]>    
date     : Wed, 15 Dec 2021 10:40:15 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Wed, 15 Dec 2021 10:40:15 +0900    

Click here for diff

edc2332 has introduced in vcregress.pl some control on the environment  
variables LZ4, TAR and GZIP_PROGRAM to allow any TAP tests to be able  
use those commands.  This makes the settings more consistent with  
src/Makefile.global.in, as the same default gets used for Make and MSVC  
builds.  
  
Each parameter can be changed in buildenv.pl, but as a default gets  
assigned after loading buldenv.pl, it is not possible to unset any of  
these, and using an empty value would not work with "||=" either.  As  
some environments may not have a compatible command in their PATH (tar  
coming from MinGW is an issue, for one), this could break tests without  
an exit path to bypass any failing test.  This commit changes things so  
as the default values for LZ4, TAR and GZIP_PROGRAM are assigned before  
loading buildenv.pl, not after.  This way, we keep the same amount of  
compatibility as a GNU build with the same defaults, and it becomes  
possible to unset any of those values.  
  
While on it, this adds some documentation about those three variables in  
the section dedicated to the TAP tests for MSVC.  
  
Per discussion with Andrew Dunstan.  
  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 10  

M doc/src/sgml/install-windows.sgml
M src/tools/msvc/vcregress.pl

Remove assertion for replication origins in PREPARE TRANSACTION

commit   : 65af1e842208cf3edec3b74842eec87b4a0138e5    
  
author   : Michael Paquier <[email protected]>    
date     : Tue, 14 Dec 2021 10:58:33 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Tue, 14 Dec 2021 10:58:33 +0900    

Click here for diff

When using replication origins, pg_replication_origin_xact_setup() is an  
optional choice to be able to set a LSN and a timestamp to mark the  
origin, which would be additionally added to WAL for transaction commits  
or aborts (including 2PC transactions).  An assertion in the code path  
of PREPARE TRANSACTION assumed that this data should always be set, so  
it would trigger when using replication origins without setting up an  
origin LSN.  Some tests are added to cover more this kind of scenario.  
  
Oversight in commit 1eb6d65.  
  
Per discussion with Amit Kapila and Masahiko Sawada.  
  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 11  

M contrib/test_decoding/expected/replorigin.out
M contrib/test_decoding/sql/replorigin.sql
M src/backend/access/transam/twophase.c

isolationtester: append session name to application_name.

commit   : a5fe66bfdaec7add9381b61b33f5c361eaacd055    
  
author   : Andres Freund <[email protected]>    
date     : Mon, 13 Dec 2021 12:02:48 -0800    
  
committer: Andres Freund <[email protected]>    
date     : Mon, 13 Dec 2021 12:02:48 -0800    

Click here for diff

When writing / debugging an isolation test it sometimes is useful to see which  
session holds what lock etc. To make it easier, both as part of spec files and  
interactively, append the session name to application_name. Since b1907d688  
application_name already contains the test name, this appends the session's  
name to that.  
  
insert-conflict-specconflict did something like this manually, which can now  
be removed.  
  
As we have done lately with other test infrastructure improvements, backpatch  
this change, to make it easier to backpatch tests.  
  
Author: Andres Freund <[email protected]>  
Reviewed-By: Michael Paquier <[email protected]>  
Reviewed-By: Andrew Dunstan <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  
Backpatch: 10-, to make backpatching of tests easier.  

M src/test/isolation/isolationtester.c

backpatch "Set application_name per-test in isolation and ecpg tests."

commit   : fe490f9ad7ab3fc9279c9810304b524aae36c3b6    
  
author   : Andres Freund <[email protected]>    
date     : Mon, 13 Dec 2021 11:39:52 -0800    
  
committer: Andres Freund <[email protected]>    
date     : Mon, 13 Dec 2021 11:39:52 -0800    

Click here for diff

We started to backpatch test infrastructure improvements more aggressively to  
make it easier to backpatch test. A proposed isolationtester improvement has a  
dependency on b1907d688, backpatch b1907d688 to make it easier to subsequently  
backpatch the new proposed isolationtester change.  
  
Discussion: https://postgr.es/m/[email protected]  
Backpatch: 10-12, the commit already is in 13-HEAD  

M src/interfaces/ecpg/test/pg_regress_ecpg.c
M src/test/isolation/isolation_main.c
M src/test/regress/pg_regress.c

Doc: improve xfunc-c-type-table.

commit   : 0862317b126c02da19da07a42a132f70526669e3    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 8 Dec 2021 16:54:31 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 8 Dec 2021 16:54:31 -0500    

Click here for diff

List types numeric and timestamptz, which don't seem to have ever been  
included here.  Restore bigint, which was no-doubt-accidentally deleted  
in v12.  Fix some errors, or at least obsolete usages (nobody declares  
float arguments as "float8*" anymore, even though they might be that  
under the hood).  Re-alphabetize.  Remove the seeming claim that this  
is a complete list of built-in types.  
  
Per question from Oskar Stenberg.  
  
Discussion: https://postgr.es/m/HE1PR03MB2971DE2527ECE1E99D6C19A8F96E9@HE1PR03MB2971.eurprd03.prod.outlook.com  

M doc/src/sgml/xfunc.sgml

Fix corruption of toast indexes with REINDEX CONCURRENTLY

commit   : 5ed74d874f4964af3cef0991d9406bedfc59281a    
  
author   : Michael Paquier <[email protected]>    
date     : Wed, 8 Dec 2021 11:01:23 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Wed, 8 Dec 2021 11:01:23 +0900    

Click here for diff

REINDEX CONCURRENTLY run on a toast index or a toast relation could  
corrupt the target indexes rebuilt, as a backend running in parallel  
that manipulates toast values would directly release the lock on the  
toast relation when its local operation is done, rather than releasing  
the lock once the transaction that manipulated the toast values  
committed.  
  
The fix done here is simple: we now hold a ROW EXCLUSIVE lock on the  
toast relation when saving or deleting a toast value until the  
transaction working on them is committed, so as a concurrent reindex  
happening in parallel would be able to wait for any activity and see any  
new rows inserted (or deleted).  
  
An isolation test is added to check after the case fixed here, which is  
a bit fancy by design as it relies on allow_system_table_mods to rename  
the toast table and its index to fixed names.  This way, it is possible  
to reindex them directly without any dependency on the OID of the  
underlying relation.  Note that this could not use a DO block either, as  
REINDEX CONCURRENTLY cannot be run in a transaction block.  The test is  
backpatched down to 13, where it is possible, thanks to c4a7a39, to use  
allow_system_table_mods in a test suite.  
  
Reported-by: Alexey Ermakov  
Analyzed-by: Andres Freund, Noah Misch  
Author: Michael Paquier  
Reviewed-by: Nathan Bossart  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 12  

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

Enable settings used in TAP tests for MSVC builds

commit   : 8de159c1fb1bcad47012e1c6ba4e9a50412d7a6c    
  
author   : Andrew Dunstan <[email protected]>    
date     : Tue, 7 Dec 2021 15:05:33 -0500    
  
committer: Andrew Dunstan <[email protected]>    
date     : Tue, 7 Dec 2021 15:05:33 -0500    

Click here for diff

Certain settings from configuration or the Makefile infrastructure are  
used by the TAP tests, but were not being set up by vcregress.pl. This  
remedies those omissions. This should increase test coverage, especially  
on the buildfarm.  
  
Reviewed by Noah Misch  
  
Discussion: https://postgr.es/m/[email protected]  
  
Backpatch to all live branches.  

M src/tools/msvc/vcregress.pl

On Windows, also call shutdown() while closing the client socket.

commit   : a9e572c6d5761e8f9b726ba2b9d63a01186994f1    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 7 Dec 2021 13:34:06 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 7 Dec 2021 13:34:06 -0500    

Click here for diff

Further experimentation shows that commit 6051857fc is not sufficient  
when using (some versions of?) OpenSSL.  The reason is obscure, but  
calling shutdown(socket, SD_SEND) improves matters.  
  
Per testing by Andrew Dunstan and Alexander Lakhin.  
Back-patch as before.  
  
Discussion: https://postgr.es/m/[email protected]  

M src/backend/libpq/pqcomm.c

Doc: Fix misleading wording of CRL parameters

commit   : 386d97781d1779ca76958bff193749082279182f    
  
author   : Daniel Gustafsson <[email protected]>    
date     : Fri, 3 Dec 2021 14:15:50 +0100    
  
committer: Daniel Gustafsson <[email protected]>    
date     : Fri, 3 Dec 2021 14:15:50 +0100    

Click here for diff

ssl_crl_file and ssl_crl_dir are both used to for client certificate  
revocation, not server certificates.  The description for the params  
could be easily misread to mean the opposite however,  as evidenced  
by the bugreport leading to this fix.  Similarly, expand sslcrl and  
and sslcrldir to explicitly mention server certificates. While there  
also mention sslcrldir where previously only sslcrl was discussed.  
  
Backpatch down to v10, with the CRL dir fixes down to 14 where they  
were introduced.  
  
Author: Kyotaro Horiguchi <[email protected]>  
Reviewed-by: Peter Eisentraut <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  
Discussion: https://postgr.es/m/CABWY_HCBUCjY1EJHrEGePGEaSZ5b29apgTohCyygtsqe_ySYng@mail.gmail.com  
Backpatch-through: 10  

M doc/src/sgml/config.sgml
M doc/src/sgml/libpq.sgml

postgres_fdw: Fix unexpected reporting of empty message.

commit   : 21a86b0eba64df8188463a0e497dd323e6909e31    
  
author   : Fujii Masao <[email protected]>    
date     : Fri, 3 Dec 2021 17:35:29 +0900    
  
committer: Fujii Masao <[email protected]>    
date     : Fri, 3 Dec 2021 17:35:29 +0900    

Click here for diff

pgfdw_report_error() in postgres_fdw gets a message from PGresult or  
PGconn to report an error received from a remote server. Previously  
if it could get a message from neither of them, it reported empty  
message unexpectedly. The cause of this issue was that pgfdw_report_error()  
didn't handle properly the case where no message could be obtained  
and its local variable message_primary was set to '\0'.  
  
This commit improves pgfdw_report_error() so that it reports the message  
"could not obtain ..." when it gets no message and message_primary  
is set to '\0'. This is the same behavior as when message_primary is NULL.  
  
dblink_res_error() in dblink has the same issue, so this commit also  
improves it in the same way.  
  
Back-patch to all supported branches.  
  
Author: Fujii Masao  
Reviewed-by: Bharath Rupireddy  
Discussion: https://postgr.es/m/[email protected]  

M contrib/dblink/dblink.c
M contrib/postgres_fdw/connection.c

On Windows, close the client socket explicitly during backend shutdown.

commit   : 3e644dcca1e97d7f4276dc2233c467addb179c88    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 2 Dec 2021 17:14:43 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 2 Dec 2021 17:14:43 -0500    

Click here for diff

It turns out that this is necessary to keep Winsock from dropping any  
not-yet-sent data, such as an error message explaining the reason for  
process termination.  It's pretty weird that the implicit close done  
by the kernel acts differently from an explicit close, but it's hard  
to argue with experimental results.  
  
Independently submitted by Alexander Lakhin and Lars Kanis (comments  
by me, though).  Back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/[email protected]  
Discussion: https://postgr.es/m/[email protected]  

M src/backend/libpq/pqcomm.c

Move into separate file all the SQL queries used in pg_upgrade tests

commit   : b6e525648d723fb915c4bd376de62f4e28099189    
  
author   : Michael Paquier <[email protected]>    
date     : Thu, 2 Dec 2021 10:31:37 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Thu, 2 Dec 2021 10:31:37 +0900    

Click here for diff

The existing pg_upgrade/test.sh and the buildfarm code have been holding  
the same set of SQL queries when doing cross-version upgrade tests to  
adapt the objects created by the regression tests before the upgrade  
(mostly, incompatible or non-existing objects need to be dropped from  
the origin, perhaps re-created).  
  
This moves all those SQL queries into a new, separate, file with a set  
of \if clauses to handle the version checks depending on the old version  
of the cluster to-be-upgraded.  
  
The long-term plan is to make the buildfarm code re-use this new SQL  
file, so as committers are able to fix any compatibility issues in the  
tests of pg_upgrade with a refresh of the core code, without having to  
poke at the buildfarm client.  Note that this is only able to handle the  
main regression test suite, and that nothing is done yet for contrib  
modules yet (these have more issues like their database names).  
  
A backpatch down to 10 is done, adapting the version checks as this  
script needs to be only backward-compatible, so as it becomes possible  
to clean up a maximum amount of code within the buildfarm client.  
  
Author: Justin Pryzby, Michael Paquier  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 10  

M src/bin/pg_upgrade/test.sh
A src/bin/pg_upgrade/upgrade_adapt.sql

Avoid leaking memory during large-scale REASSIGN OWNED BY operations.

commit   : 5cf08b4db79d6e3a82c4b92f8c9cf35e87c70d01    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 1 Dec 2021 13:44:47 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 1 Dec 2021 13:44:47 -0500    

Click here for diff

The various ALTER OWNER routines tend to leak memory in  
CurrentMemoryContext.  That's not a problem when they're only called  
once per command; but in this usage where we might be touching many  
objects, it can amount to a serious memory leak.  Fix that by running  
each call in a short-lived context.  
  
(DROP OWNED BY likely has a similar issue, except that you'll probably  
run out of lock table space before noticing.  REASSIGN is worth fixing  
since for most non-table object types, it won't take any lock.)  
  
Back-patch to all supported branches.  Unfortunately, in the back  
branches this helps to only a limited extent, since the sinval message  
queue bloats quite a lot in this usage before commit 3aafc030a,  
consuming memory more or less comparable to what's actually leaked.  
Still, it's clearly a leak with a simple fix, so we might as well fix it.  
  
Justin Pryzby, per report from Guillaume Lelarge  
  
Discussion: https://postgr.es/m/CAECtzeW2DAoioEGBRjR=CzHP6TdL=yosGku8qZxfX9hhtrBB0Q@mail.gmail.com  

M src/backend/catalog/pg_shdepend.c

Doc: improve documentation about ORDER BY in matviews.

commit   : 2f908e1a3b9c07e43d3ad9ebe6633fae1ed355e3    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 29 Nov 2021 12:13:13 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 29 Nov 2021 12:13:13 -0500    

Click here for diff

Remove the confusing use of ORDER BY in an example materialized  
view.  It adds nothing to the example, but might encourage  
people to follow bad practice.  Clarify REFRESH MATERIALIZED  
VIEW's note about whether view ordering is retained (it isn't).  
  
Maciek Sakrejda  
  
Discussion: https://postgr.es/m/CAOtHd0D-OvrUU0C=4hX28p4BaSE1XL78BAQ0VcDaLLt8tdUzsg@mail.gmail.com  

M doc/src/sgml/ref/refresh_materialized_view.sgml
M doc/src/sgml/rules.sgml

Harden be-gssapi-common.h for headerscheck

commit   : 733f2be094aabf5468a40e5e0137a1d3a071d81f    
  
author   : Alvaro Herrera <[email protected]>    
date     : Fri, 26 Nov 2021 17:00:29 -0300    
  
committer: Alvaro Herrera <[email protected]>    
date     : Fri, 26 Nov 2021 17:00:29 -0300    

Click here for diff

Surround the contents with a test that the feature is enabled by  
configure, to silence header checking tools on systems without GSSAPI  
installed.  
  
Backpatch to 12, where the file appeared.  
  
Discussion: https://postgr.es/m/[email protected]  

M src/include/libpq/be-gssapi-common.h

Fix determination of broken LSN in OVERWRITTEN_CONTRECORD

commit   : 9c6ab1ef338273850c8c33f808d27486d3c5ad76    
  
author   : Alvaro Herrera <[email protected]>    
date     : Fri, 26 Nov 2021 11:14:27 -0300    
  
committer: Alvaro Herrera <[email protected]>    
date     : Fri, 26 Nov 2021 11:14:27 -0300    

Click here for diff

In commit ff9f111bce24 I mixed up inconsistent definitions of the LSN of  
the first record in a page, when the previous record ends exactly at the  
page boundary.  The correct LSN is adjusted to skip the WAL page header;  
I failed to use that when setting XLogReaderState->overwrittenRecPtr,  
so at WAL replay time VerifyOverwriteContrecord would refuse to let  
replay continue past that record.  
  
Backpatch to 10.  9.6 also contains this bug, but it's no longer being  
maintained.  
  
Discussion: https://postgr.es/m/[email protected]  

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

Remove unneeded Python includes

commit   : 0d335cbd5c63009576280ff502b31a84e353a86b    
  
author   : Peter Eisentraut <[email protected]>    
date     : Thu, 25 Nov 2021 14:19:22 +0100    
  
committer: Peter Eisentraut <[email protected]>    
date     : Thu, 25 Nov 2021 14:19:22 +0100    

Click here for diff

Inluding <compile.h> and <eval.h> has not been necessary since Python  
2.4, since they are included via <Python.h>.  Morever, <eval.h> is  
being removed in Python 3.11.  So remove these includes.  
  
Reviewed-by: Tom Lane <[email protected]>  
Discussion: https://www.postgresql.org/message-id/flat/84884.1637723223%40sss.pgh.pa.us  

M src/pl/plpython/plpython.h

Block ALTER TABLE .. DROP NOT NULL on columns in replica identity index

commit   : 216156fec3d885842e2ceffa3a5321fbcd2fe575    
  
author   : Michael Paquier <[email protected]>    
date     : Thu, 25 Nov 2021 15:05:31 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Thu, 25 Nov 2021 15:05:31 +0900    

Click here for diff

Replica identities that depend directly on an index rely on a set of  
properties, one of them being that all the columns defined in this index  
have to be marked as NOT NULL.  There was a hole in the logic with ALTER  
TABLE DROP NOT NULL, where it was possible to remove the NOT NULL  
property of a column part of an index used as replica identity, so block  
it to avoid problems with logical decoding down the road.  
  
The same check was already done columns part of a primary key, so the  
fix is straight-forward.  
  
Author: Haiying Tang, Hou Zhijie  
Reviewed-by: Dilip Kumar, Michael Paquier  
Discussion: https://postgr.es/m/OS0PR01MB6113338C102BEE8B2FFC5BD9FB619@OS0PR01MB6113.jpnprd01.prod.outlook.com  
Backpatch-through: 10  

M src/backend/commands/tablecmds.c
M src/test/regress/expected/replica_identity.out
M src/test/regress/sql/replica_identity.sql

Doc: improve documentation about nextval()/setval().

commit   : 6365e3a0535fc5e6cd55ec4a97c562a11e371fdd    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 24 Nov 2021 13:37:12 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 24 Nov 2021 13:37:12 -0500    

Click here for diff

Clarify that the results of nextval and setval are not guaranteed  
persistent until the calling transaction commits.  Some people  
seem to have drawn the opposite conclusion from the statement that  
these functions are never rolled back, so re-word to avoid saying  
it quite that way.  
  
Discussion: https://postgr.es/m/CAKU4AWohO=NfM-4KiZWvdc+z3c1C9FrUBR6xnReFJ6sfy0i=Lw@mail.gmail.com  

M doc/src/sgml/func.sgml

Fix missing space in docs.

commit   : 4a761b72a9ecb59f26c06fac4d1614e9a02b4677    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Wed, 24 Nov 2021 18:32:56 +0200    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Wed, 24 Nov 2021 18:32:56 +0200    

Click here for diff

Author: Japin Li  
Discussion: https://www.postgresql.org/message-id/MEYP282MB1669C36E5F733C2EFBDCB80BB6619@MEYP282MB1669.AUSP282.PROD.OUTLOOK.COM  

M doc/src/sgml/arch-dev.sgml

Add support for Visual Studio 2022 in build scripts

commit   : 420d5e40b3a385c8ac5952f00ac792704bbc21c9    
  
author   : Michael Paquier <[email protected]>    
date     : Wed, 24 Nov 2021 13:04:03 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Wed, 24 Nov 2021 13:04:03 +0900    

Click here for diff

Documentation and any code paths related to VS are updated to keep the  
whole consistent.  Similarly to 2017 and 2019, the version of VS and the  
version of nmake that we use to determine which code paths to use for  
the build are still inconsistent in their own way.  
  
Backpatch down to 10, so as buildfarm members are able to use this new  
version of Visual Studio on all the stable branches supported.  
  
Author: Hans Buschmann  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 10  

M doc/src/sgml/install-windows.sgml
M src/tools/msvc/MSBuildProject.pm
M src/tools/msvc/README
M src/tools/msvc/Solution.pm
M src/tools/msvc/VSObjectFactory.pm

Adjust pg_dump's priority ordering for casts.

commit   : 69949ea68cf98f842419a074424fe0b07cab1598    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 22 Nov 2021 17:16:29 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 22 Nov 2021 17:16:29 -0500    

Click here for diff

When a stored expression depends on a user-defined cast, the backend  
records the dependency as being on the cast's implementation function  
--- or indeed, if there's no cast function involved but just  
RelabelType or CoerceViaIO, no dependency is recorded at all.  This  
is problematic for pg_dump, which is at risk of dumping things in the  
wrong order leading to restore failures.  Given the lack of previous  
reports, the risk isn't that high, but it can be demonstrated if the  
cast is used in some view whose rowtype is then used as an input or  
result type for some other function.  (That results in the view  
getting hoisted into the functions portion of the dump, ahead of  
the cast.)  
  
A logically bulletproof fix for this would require including the  
cast's OID in the parsed form of the expression, whence it could be  
extracted by dependency.c, and then the stored dependency would force  
pg_dump to do the right thing.  Such a change would be fairly invasive,  
and certainly not back-patchable.  Moreover, since we'd prefer that  
an expression using cast syntax be equal() to one doing the same  
thing by explicit function call, the cast OID field would have to  
have special ignored-by-comparisons semantics, making things messy.  
  
So, let's instead fix this by a very simple hack in pg_dump: change  
the object-type priority order so that casts are initially sorted  
before functions, immediately after types.  This fixes the problem  
in a fairly direct way for casts that have no implementation function.  
For those that do, the implementation function will be hoisted to just  
before the cast by the dependency sorting step, so that we still have  
a valid dump order.  (I'm not sure that this provides a full guarantee  
of no problems; but since it's been like this for many years without  
any previous reports, this is probably enough to fix it in practice.)  
  
Per report from Дмитрий Иванов.  
Back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/CAPL5KHoGa3uvyKp6z6m48LwCnTsK+LRQ_mcA4uKGfqAVSEjV_A@mail.gmail.com  

M src/bin/pg_dump/pg_dump_sort.c

Pacify perlcritic.

commit   : 72582531b8031bb1aada7a4dd6914c880677ea38    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 22 Nov 2021 15:57:31 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 22 Nov 2021 15:57:31 -0500    

Click here for diff

Per buildfarm.  

M config/check_modules.pl

Fix pg_dump --inserts mode for generated columns with dropped columns.

commit   : 1e7f588ad625ac5a14ef7c735cbce13b9d3f5be6    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 22 Nov 2021 15:25:48 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 22 Nov 2021 15:25:48 -0500    

Click here for diff

If a table contains a generated column that's preceded by a dropped  
column, dumpTableData_insert failed to account for the dropped  
column, and would emit DEFAULT placeholder(s) in the wrong column(s).  
This resulted in failures at restore time.  The default COPY code path  
did not have this bug, likely explaining why it wasn't noticed sooner.  
  
While we're fixing this, we can be a little smarter about the  
situation: (1) avoid unnecessarily fetching the values of generated  
columns, (2) omit generated columns from the output, too, if we're  
using --column-inserts.  While these modes aren't expected to be  
as high-performance as the COPY path, we might as well be as  
efficient as we can; it doesn't add much complexity.  
  
Per report from Дмитрий Иванов.  
Back-patch to v12 where generated columns came in.  
  
Discussion: https://postgr.es/m/CAPL5KHrkBniyQt5e1rafm5DdXvbgiiqfEQEJ9GjtVzN71Jj5pA@mail.gmail.com  

M src/bin/pg_dump/pg_dump.c
M src/bin/pg_dump/t/002_pg_dump.pl

Probe $PROVE not $PERL while checking for modules needed by TAP tests.

commit   : 0416c9c18b35c85dd55eb35cd08a4b66564301c1    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 22 Nov 2021 12:54:52 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 22 Nov 2021 12:54:52 -0500    

Click here for diff

Normally "prove" and "perl" come from the same Perl installation,  
but we support the case where they don't (mainly because the MSys  
buildfarm animals need this).  In that case, AX_PROG_PERL_MODULES  
is completely the wrong thing to use, because it's checking what  
"perl" has.  Instead, make a little TAP test script including the  
required modules, and run that under "prove".  
  
We don't need ax_prog_perl_modules.m4 at all after this change,  
so remove it.  
  
Back-patch to all supported branches, for the buildfarm's benefit.  
(In v10, this also back-patches the effects of commit 264eb03aa.)  
  
Andrew Dunstan and Tom Lane, per an observation by Noah Misch  
  
Discussion: https://postgr.es/m/[email protected]  

M aclocal.m4
D config/ax_prog_perl_modules.m4
A config/check_modules.pl
M configure
M configure.in

pg_receivewal, pg_recvlogical: allow canceling initial password prompt.

commit   : 93295932d1f48a929a569a2326c150a2eb060453    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 21 Nov 2021 14:13:35 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 21 Nov 2021 14:13:35 -0500    

Click here for diff

Previously it was impossible to terminate these programs via control-C  
while they were prompting for a password.  We can fix that trivially  
for their initial password prompts, by moving setup of the SIGINT  
handler from just before to just after their initial GetConnection()  
calls.  
  
This fix doesn't permit escaping out of later re-prompts, but those  
should be exceedingly rare, since the user's password or the server's  
authentication setup would have to have changed meanwhile.  We  
considered applying a fix similar to commit 46d665bc2, but that  
seemed more complicated than it'd be worth.  Moreover, this way is  
back-patchable, which that wasn't.  
  
The misbehavior exists in all supported versions, so back-patch to all.  
  
Tom Lane and Nathan Bossart  
  
Discussion: https://postgr.es/m/[email protected]  

M src/bin/pg_basebackup/pg_receivewal.c
M src/bin/pg_basebackup/pg_recvlogical.c

Use appropriate -Wno-warning switches when compiling bitcode.

commit   : f5e3fab4333709d586fc8520025782b2a9d72c3a    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 18 Nov 2021 14:50:13 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 18 Nov 2021 14:50:13 -0500    

Click here for diff

We use "clang" to compile bitcode files for LLVM inlining.  That might  
be different from the build's main C compiler, so it needs its own set  
of compiler flags.  To simplify configure, we don't bother adding any  
-W switches to that flag set; there's little need since the main build  
will show us any warnings.  However, if we don't want to see unwanted  
warnings, we still have to add any -Wno-warning switches we'd normally  
use with clang.  
  
This escaped notice before commit 9ff47ea41, which tried to add  
-Wno-compound-token-split-by-macro; buildfarm animals using mismatched  
CC and CLANG still showed those warnings.  I'm not sure why we never  
saw any effects from the lack of -Wno-unused-command-line-argument  
(maybe that's only activated by -Wall?).  clang does not currently  
support -Wno-format-truncation or -Wno-stringop-truncation, although  
in the interests of future-proofing and consistency I included tests  
for those.  
  
Back-patch to v11 where we started building bitcode files.  
  
Discussion: https://postgr.es/m/[email protected]  

M configure
M configure.in

Fix quoting of ACL item in table for upgrade binary compatibility checks

commit   : 82bb97ed63cb206e8ecc0fe0d8bc3b8d2d336144    
  
author   : Michael Paquier <[email protected]>    
date     : Thu, 18 Nov 2021 12:53:06 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Thu, 18 Nov 2021 12:53:06 +0900    

Click here for diff

Per buildfarm member prion, that runs the regression tests under a role  
name that uses a hyphen.  Issue introduced by 835bcba.  
  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 12  

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

Add table to regression tests for binary-compatibility checks in pg_upgrade

commit   : a9993416f80f5d952cc392333011e4f7d399ec49    
  
author   : Michael Paquier <[email protected]>    
date     : Thu, 18 Nov 2021 10:37:43 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Thu, 18 Nov 2021 10:37:43 +0900    

Click here for diff

This commit adds to the main regression test suite a table with all  
the in-core data types (some exceptions apply).  This table is not  
dropped, so as pg_upgrade would be able to check the binary  
compatibility of the types tracked in the table.  If a new type is added  
in core, this part of the tests would need a refresh but the tests are  
designed to fail if that were to happen.  
  
As this is useful for upgrades and that these rely on the objects  
created in the regression test suite of the old version upgraded from,  
a backpatch down to 12 is done, which is the last point where a binary  
incompatible change has been done (7c15cef).  This will hopefully be  
enough to find out if something gets broken during the development of a  
new version of Postgres, so as it is possible to take actions in  
pg_upgrade itself in this case (like 0ccfc28 for sql_identifier).  
  
An area that is not covered yet is related to external modules, which  
may create their own types.  The testing infrastructure of pg_upgrade is  
not integrated yet with the external modules stored in core  
(src/test/modules/ or contrib/, all use the same database name for their  
tests so there would be an overlap).  This could be improved in the  
future.  
  
Author: Justin Pryzby  
Reviewed-by: Jacob Champion, Peter Eisentraut, Tom Lane, Michael Paquier  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 12  

M src/test/regress/expected/sanity_check.out
M src/test/regress/expected/type_sanity.out
M src/test/regress/sql/type_sanity.sql

Clean up error handling in pg_basebackup's walmethods.c.

commit   : 8378dad4c579438f40c42b8514f2837c38094ec9    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 17 Nov 2021 14:16:34 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 17 Nov 2021 14:16:34 -0500    

Click here for diff

The error handling here was a mess, as a result of a fundamentally  
bad design (relying on errno to keep its value much longer than is  
safe to assume) as well as a lot of just plain sloppiness, both as  
to noticing errors at all and as to reporting the correct errno.  
Moreover, the recent addition of LZ4 compression broke things  
completely, because liblz4 doesn't use errno to report errors.  
  
To improve matters, keep the error state in the DirectoryMethodData or  
TarMethodData struct, and add a string field so we can handle cases  
that don't set errno.  (The tar methods already had a version of this,  
but it can be done more efficiently since all these cases use a  
constant error string.)  Make the dir and tar methods handle errors  
in basically identical ways, which they didn't before.  
  
This requires copying errno into the state struct in a lot of places,  
which is a bit tedious, but it has the virtue that we can get rid of  
ad-hoc code to save and restore errno in a number of places ... not  
to mention that it fixes other places that should've saved/restored  
errno but neglected to.  
  
In passing, fix some pointlessly static buffers to be ordinary  
local variables.  
  
There remains an issue about exactly how to handle errors from  
fsync(), but that seems like material for its own patch.  
  
While the LZ4 problems are new, all the rest of this is fixes for  
old bugs, so backpatch to v10 where walmethods.c was introduced.  
  
Patch by me; thanks to Michael Paquier for review.  
  
Discussion: https://postgr.es/m/[email protected]  

M src/bin/pg_basebackup/walmethods.c

Handle close() failures more robustly in pg_dump and pg_basebackup.

commit   : 12bf118899eb95a9b3afd67ab666698a1019e1e8    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 17 Nov 2021 13:08:25 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 17 Nov 2021 13:08:25 -0500    

Click here for diff

Coverity complained that applying get_gz_error after a failed gzclose,  
as we did in one place in pg_basebackup, is unsafe.  I think it's  
right: it's entirely likely that the call is touching freed memory.  
Change that to inspect errno, as we do for other gzclose calls.  
  
Also, be careful to initialize errno to zero immediately before any  
gzclose() call where we care about the error status.  (There are  
some calls where we don't, because we already failed at some previous  
step.)  This ensures that we don't get a misleadingly irrelevant  
error code if gzclose() fails in a way that doesn't set errno.  
We could work harder at that, but it looks to me like all such cases  
are basically can't-happen if we're not misusing zlib, so it's  
not worth the extra notational cruft that would be required.  
  
Also, fix several places that simply failed to check for close-time  
errors at all, mostly at some remove from the close or gzclose itself;  
and one place that did check but didn't bother to report the errno.  
  
Back-patch to v12.  These mistakes are older than that, but between  
the frontend logging API changes that happened in v12 and the fact  
that frontend code can't rely on %m before that, the patch would need  
substantial revision to work in older branches.  It doesn't quite  
seem worth the trouble given the lack of related field complaints.  
  
Patch by me; thanks to Michael Paquier for review.  
  
Discussion: https://postgr.es/m/[email protected]  

M src/bin/pg_basebackup/pg_basebackup.c
M src/bin/pg_basebackup/receivelog.c
M src/bin/pg_basebackup/walmethods.c
M src/bin/pg_dump/pg_backup_archiver.c
M src/bin/pg_dump/pg_backup_directory.c
M src/bin/pg_dump/pg_backup_tar.c

Doc: add see-also references to CREATE PUBLICATION.

commit   : 02bf176109e796ee371b0e9a07e110421ac97870    
  
author   : Daniel Gustafsson <[email protected]>    
date     : Wed, 17 Nov 2021 13:34:41 +0100    
  
committer: Daniel Gustafsson <[email protected]>    
date     : Wed, 17 Nov 2021 13:34:41 +0100    

Click here for diff

The "See also" section on the reference page for CREATE PUBLICATION  
didn't match the cross references on CREATE SUBSCRIPTION and their  
ALTER counterparts. Fixed by adding an xref to the CREATE and ALTER  
SUBSCRIPTION pages.  Backpatch down to v10 where CREATE PUBLICATION  
was introduced.  
  
Author: Peter Smith <[email protected]>  
Reviewed-by: Masahiko Sawada <[email protected]>  
Discussion: https://postgr.es/m/CAHut+PvGWd3-Ktn96c-z6uq-8TGVVP=TPOkEovkEfntoo2mRhw@mail.gmail.com  
Backpatch-through: 10  

M doc/src/sgml/ref/create_publication.sgml

Invalidate relcache when changing REPLICA IDENTITY index.

commit   : 9816e2d3182681f0cdd31b5b0d15cfb2d62cc784    
  
author   : Amit Kapila <[email protected]>    
date     : Tue, 16 Nov 2021 09:05:51 +0530    
  
committer: Amit Kapila <[email protected]>    
date     : Tue, 16 Nov 2021 09:05:51 +0530    

Click here for diff

When changing REPLICA IDENTITY INDEX to another one, the target table's  
relcache was not being invalidated. This leads to skipping update/delete  
operations during apply on the subscriber side as the columns required to  
search corresponding rows won't get logged.  
  
Author: Tang Haiying, Hou Zhijie  
Reviewed-by: Euler Taveira, Amit Kapila  
Backpatch-through: 10  
Discussion: https://postgr.es/m/OS0PR01MB61133CA11630DAE45BC6AD95FB939@OS0PR01MB6113.jpnprd01.prod.outlook.com  

M src/backend/commands/tablecmds.c
M src/test/subscription/t/100_bugs.pl

Make psql's \password default to CURRENT_USER, not PQuser(conn).

commit   : 523adcc12900d67a3a43bc7ca4ef4e84f062bb9a    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 12 Nov 2021 14:55:32 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 12 Nov 2021 14:55:32 -0500    

Click here for diff

The documentation says plainly that \password acts on "the current user"  
by default.  What it actually acted on, or tried to, was the username  
used to log into the current session.  This is not the same thing if  
one has since done SET ROLE or SET SESSION AUTHENTICATION.  Aside from  
the possible surprise factor, it's quite likely that the current role  
doesn't have permissions to set the password of the original role.  
  
To fix, use "SELECT CURRENT_USER" to get the role name to act on.  
(This syntax works with servers at least back to 7.0.)  Also, in  
hopes of reducing confusion, include the role name that will be  
acted on in the password prompt.  
  
The discrepancy from the documentation makes this a bug, so  
back-patch to all supported branches.  
  
Patch by me; thanks to Nathan Bossart for review.  
  
Discussion: https://postgr.es/m/[email protected]  

M src/bin/psql/command.c

Report any XLogReadRecord() error in XlogReadTwoPhaseData().

commit   : 2d60ce3e1a4658c37a5408e56207d34af8763827    
  
author   : Noah Misch <[email protected]>    
date     : Thu, 11 Nov 2021 17:10:18 -0800    
  
committer: Noah Misch <[email protected]>    
date     : Thu, 11 Nov 2021 17:10:18 -0800    

Click here for diff

Buildfarm members kittiwake and tadarida have witnessed errors at this  
site.  The site discarded key facts.  Back-patch to v10 (all supported  
versions).  
  
Reviewed by Michael Paquier and Tom Lane.  
  
Discussion: https://postgr.es/m/[email protected]  

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

Fix buffer overrun in unicode string normalization with empty input

commit   : de343812b97a0e46388517f80bdd9c403e81b3bd    
  
author   : Michael Paquier <[email protected]>    
date     : Thu, 11 Nov 2021 15:01:57 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Thu, 11 Nov 2021 15:01:57 +0900    

Click here for diff

PostgreSQL 13 and newer versions are directly impacted by that through  
the SQL function normalize(), which would cause a call of this function  
to write one byte past its allocation if using in input an empty  
string after recomposing the string with NFC and NFKC.  Older versions  
(v10~v12) are not directly affected by this problem as the only code  
path using normalization is SASLprep in SCRAM authentication that  
forbids the case of an empty string, but let's make the code more robust  
anyway there so as any out-of-core callers of this function are covered.  
  
The solution chosen to fix this issue is simple, with the addition of a  
fast-exit path if the decomposed string is found as empty.  This would  
only happen for an empty string as at its lowest level a codepoint would  
be decomposed as itself if it has no entry in the decomposition table or  
if it has a decomposition size of 0.  
  
Some tests are added to cover this issue in v13~.  Note that an empty  
string has always been considered as normalized (grammar "IS NF[K]{C,D}  
NORMALIZED", through the SQL function is_normalized()) for all the  
operations allowed (NFC, NFD, NFKC and NFKD) since this feature has been  
introduced as of 2991ac5.  This behavior is unchanged but some tests are  
added in v13~ to check after that.  
  
I have also checked "make normalization-check" in src/common/unicode/,  
while on it (works in 13~, and breaks in older stable branches  
independently of this commit).  
  
The release notes should just mention this commit for v13~.  
  
Reported-by: Matthijs van der Vleuten  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 10  

M src/common/unicode_norm.c

Clean up compilation warnings coming from PL/Perl with clang-12~

commit   : 109279e5729114d8bd118acf6de376012ffc58ec    
  
author   : Michael Paquier <[email protected]>    
date     : Thu, 11 Nov 2021 10:51:17 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Thu, 11 Nov 2021 10:51:17 +0900    

Click here for diff

clang-12 has introduced -Wcompound-token-split-by-macro, that is causing  
a large amount of warnings when building PL/Perl because of its  
interactions with upstream Perl.  This commit adds one -Wno to CFLAGS at  
./configure time if the flag is supported by the compiler to silence all  
those warnings.  
  
Upstream perl has fixed this issue, but it is going to take some time  
before this is spread across the buildfarm, and we have noticed that  
some animals would be useful with an extra -Werror to help with the  
detection of incorrect placeholders (see b0cf544), dangomushi being  
one.  
  
Reviewed-by: Tom Lane  
Discussion: https://postgr.es/m/YYr3qYa/[email protected]  
Backpatch-through: 10  

M configure
M configure.in

Doc: improve protocol spec for logical replication Type messages.

commit   : 886801df4a23d0ee5e2b2119470cbf300242f644    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 10 Nov 2021 13:12:58 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 10 Nov 2021 13:12:58 -0500    

Click here for diff

protocol.sgml documented the layout for Type messages, but completely  
dropped the ball otherwise, failing to explain what they are, when  
they are sent, or what they're good for.  While at it, do a little  
copy-editing on the description of Relation messages.  
  
In passing, adjust the comment for apply_handle_type() to make it  
clearer that we choose not to do anything when receiving a Type  
message, not that we think it has no use whatsoever.  
  
Per question from Stefen Hillman.  
  
Discussion: https://postgr.es/m/CAPgW8pMknK5pup6=T4a_UG=Cz80Rgp=KONqJmTdHfaZb0RvnFg@mail.gmail.com  

M doc/src/sgml/protocol.sgml
M src/backend/replication/logical/worker.c

Fix instability in 026_overwrite_contrecord.pl test.

commit   : 9959a078f2d706d9bbea74891963e6df0a95fedb    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 9 Nov 2021 18:40:19 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 9 Nov 2021 18:40:19 -0500    

Click here for diff

We've seen intermittent failures in this test on slower buildfarm  
machines, which I think can be explained by assuming that autovacuum  
emitted some additional WAL.  Disable autovacuum to stabilize it.  
  
In passing, use stringwise not numeric comparison to compare  
WAL file names.  Doesn't matter at present, but they are  
hex strings not decimal ...  
  
Discussion: https://postgr.es/m/[email protected]  

M src/test/recovery/t/026_overwrite_contrecord.pl