PostgreSQL 11.15 commit log

commit   : ff2a6d2621439d3d3f6e340c363d3b5e71749919    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 7 Feb 2022 16:20:23 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 7 Feb 2022 16:20:23 -0500    

commit   : d793dcf28b5dc6da4a76cbf3c059b36c2c8763f4    
  
author   : Peter Eisentraut <[email protected]>    
date     : Mon, 7 Feb 2022 13:51:36 +0100    
  
committer: Peter Eisentraut <[email protected]>    
date     : Mon, 7 Feb 2022 13:51:36 +0100    

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

commit   : 714343b8a800abcf3116b0d8c638cf29f0c62422    
  
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    

commit   : 94199879b67af21f934ccef7cb8a18da6a924510    
  
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    

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]  

commit   : 46bf1f2dc750de8e620d63f3dc2ad6f569886175    
  
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    

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]  

commit   : 6d511a463a5e5012292fdeb4c39a1f734c06e823    
  
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    

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

commit   : 0b25f5e444ff471135bcf58cbb1e4cbda165efa5    
  
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    

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

commit   : e41176bd6f47f580fdc4d2c18eab727021e62562    
  
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    

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]  

commit   : e3689105437c2a0451d1dbefcd0dc45f60bda618    
  
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    

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

commit   : 923f9f416179ebec009b93a892eb9e2c1a48bb36    
  
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    

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]  

commit   : ac374485b8420ca8ad5f8d1f9326af39cac45924    
  
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    

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  

commit   : ad95a639ab0948ca931d54a158a2f20f0cebd4a5    
  
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    

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  

commit   : 5cb88648ed4559c4ddcf246c2845db08cfc1f96b    
  
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    

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  

commit   : e092f00d061ede6faffe17638b4a1dc9f71bc47d    
  
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    

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]  

commit   : bbb1caf6b22027cc85212e8b4fbf8f1d61734329    
  
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    

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  

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

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  

commit   : 4ec54498c5eae338bbc8ce391df4297c314624ff    
  
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    

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]  

commit   : 449a696236ff6d8a86b98ae6503aa51dc39a37b2    
  
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    

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]  

commit   : bd110e250e9d9291d7fc1ea12ddd5d177a2460bd    
  
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    

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  

commit   : 5e9fe25307711030ca7168b78a369e30e1980887    
  
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    

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  

commit   : 26c841ed1b2d4ca33bc530a12956eb690253fdb2    
  
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    

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  

commit   : 37f5dc8b8cb4c3a58b0cc7df36378a1fdc7a8659    
  
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    

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  

commit   : 2c15b29f7c22231788571b5fd6671e2497e4b054    
  
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    

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-  

commit   : 0ffe2975c37473981113fc461990c7533bbcf26d    
  
author   : Michael Paquier <[email protected]>    
date     : Fri, 21 Jan 2022 14:54:59 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Fri, 21 Jan 2022 14:54:59 +0900    

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  

commit   : 17019c00ff48ad9dd6a9d4e4a2a4a5b42d655f57    
  
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    

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  

commit   : 0a79feeca718f6934f57672ae4a5846f3da3d159    
  
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    

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.  

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

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  

commit   : 99aa0ff68a2cda3227732fdc722d8abd37ca035d    
  
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    

"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]  

commit   : d696e63963d24cbd5c5715a331b70bfbffb2b113    
  
author   : Michael Paquier <[email protected]>    
date     : Wed, 19 Jan 2022 10:38:02 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Wed, 19 Jan 2022 10:38:02 +0900    

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  

commit   : 92e6c1c9be159e5f46b11465200ac08965c225b9    
  
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    

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]  

commit   : 8b107467c632705b739e1b27795af32de6f14d15    
  
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    

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]  

commit   : 491182e52909564ce2fe9bc9c5f8ae6640682b30    
  
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    

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  

commit   : b3cac25f4d50d66ef08a9a706df045c888578f8f    
  
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    

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  

commit   : 3a1bfe256575bc1b9e9fd7c10a458084fedbd3a1    
  
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    

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]  

commit   : 790d6edf639a8c6cb12eb9f81069349c28767976    
  
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    

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]  

commit   : 03c545b66f748b9318d13bbc90f05f136a465484    
  
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    

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

commit   : 38cbdd22d633851413471d501633a038d36dc649    
  
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    

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]  

commit   : 7b5f0e5825210958212fc5a4878022a2611993a2    
  
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    

Backpatch-through: 10  

commit   : c7fa0f55deb17960de97285595e4a5342f0136c1    
  
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    

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]  

commit   : 2ce113a4f085e078286a921d4cbe63b0dc34794e    
  
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    

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]  

commit   : b63851a45635299929301a849327c392da3c1a34    
  
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    

commit   : 28cd57416eb7cb6642eb23bd8acbf2f41ce76844    
  
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    

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  

commit   : ec367452179c9b62e8d578c9abfab953838fb01d    
  
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    

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]  

commit   : 79a4bf45e83ec92ea24421c0ce0790ecb0aa1542    
  
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    

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

commit   : e3a4c798166797a055fc83413b182953cd76a951    
  
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    

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]  

commit   : 81b12fb33a5eb499bc43ba4589e8c9a709d9eb5c    
  
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    

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  

commit   : f163cc8f4d6952da79eda461b67626d1fdfafed0    
  
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    

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

commit   : 1a0ef5e2cc63797feec1bbbf2ca89906fed76bfb    
  
author   : Michael Paquier <[email protected]>    
date     : Wed, 22 Dec 2021 16:38:53 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Wed, 22 Dec 2021 16:38:53 +0900    

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  

commit   : c43d72b245ecfac9fed68363b5c682fc8958bf86    
  
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    

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  

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

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  

commit   : 8abb6c27ec7538a4975544896c35e2f9a73a9f30    
  
author   : Michael Paquier <[email protected]>    
date     : Tue, 14 Dec 2021 10:58:37 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Tue, 14 Dec 2021 10:58:37 +0900    

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  

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

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.  

commit   : dfdf445fe515032afe573302ccdf0aa9f9b51899    
  
author   : Andres Freund <[email protected]>    
date     : Mon, 13 Dec 2021 11:40:56 -0800    
  
committer: Andres Freund <[email protected]>    
date     : Mon, 13 Dec 2021 11:40:56 -0800    

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  

commit   : bbbf22cf3351f0bc738cf9389b910e77dc653aba    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 12 Dec 2021 19:12:00 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 12 Dec 2021 19:12:00 -0500    

Recent versions of gcc whine about the admittedly-completely-illegible  
formatting of this macro.  We've not noticed for a few reasons:  
  
* In v12 and up, the problem is gone thanks to 48e24ba6b.  
(Back-patching that doesn't seem prudent, though, so this patch  
just manually improves the macro's formatting.)  
  
* Buildfarm animals that might have complained, such as caiman,  
do not because they use --with-openssl and so don't build imath.c.  
  
* In a manual run such as "make all check-world", you won't see the  
warning because it gets buried in an install.log file.  You have to  
do "make -C contrib all" or the like to see it.  
  
I noticed this because in older branches, the last bit doesn't  
happen so "check-world" actually does spew the warnings to stderr.  
Maybe we should rethink how that works, because the newer behavior  
is not an improvement IMO.  
  
Back-patch down to 9.2, pursuant to newly-established project policy  
about keeping out-of-support branches buildable.  
  
Discussion: https://postgr.es/m/[email protected]  

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

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  

commit   : da57b1529cc117272a034e7942f76e6647af1732    
  
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    

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.  

commit   : 23bc57d564b2dedb8b1d823a4fc71774afd9ff94    
  
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    

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]  

commit   : 7b0643c77b464bd00eb6b63f6538057e024c775e    
  
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    

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  

commit   : 82d1e13344985369a0f5c5d1c9e72f81d997e2ca    
  
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    

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]  

commit   : a87c8c3edd7f93ec39abd2c54b46014caadd290f    
  
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    

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]  

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

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  

commit   : 82d354411749ac9756974c789bec4f78f2dafbf7    
  
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    

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  

commit   : 3f43dcc1c6868aac1f22861e6363577a431772cf    
  
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    

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  

commit   : 2c3fddcbbd8aa542beec8e3abf3369168517174e    
  
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    

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]  

commit   : a83b1bab0bdb341f952fc982899be70284c11bdc    
  
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    

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  

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

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  

commit   : b0a7161c564089d4119bbcd5e874a1f4430de1bc    
  
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    

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  

commit   : a00bd7aa17f652d88c8c0fe52286ef93bb4ec3cc    
  
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    

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

commit   : 1061e41ff9ae204d1e0097e8a95d0c2d8a7d4201    
  
author   : Michael Paquier <[email protected]>    
date     : Wed, 24 Nov 2021 13:04:07 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Wed, 24 Nov 2021 13:04:07 +0900    

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  

commit   : 54619a25df7c849d652a75ad990591a7821d9f2f    
  
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    

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  

commit   : 22d2b6611caa4d191131b5d933369181b5e4a03f    
  
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    

Per buildfarm.  

commit   : ead5c367d32e08a5779617a6f8adf97082dde557    
  
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    

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]  

commit   : c2242d3640eadbe42556aad2f37eae393e84a4df    
  
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    

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]  

commit   : dff01e40496122a9a4b3fb5a47ed5d124d32aff9    
  
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    

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]  

commit   : a414eb850dd8cf9337dd5e8000e2f4e68b61769f    
  
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    

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]  

commit   : 6ecaefa95aca44673b1a28b5b132182ebd583f7a    
  
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    

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  

commit   : 40fb634b1a7be5cf27e0d6c391a6f8f0eb4de412    
  
author   : Amit Kapila <[email protected]>    
date     : Tue, 16 Nov 2021 09:25:04 +0530    
  
committer: Amit Kapila <[email protected]>    
date     : Tue, 16 Nov 2021 09:25:04 +0530    

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  

commit   : b062ca508cd4ab701fffc892afd59e07cb7f0c9f    
  
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    

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]  

commit   : cae393f0f9fc036241931744b4b812632529fdf1    
  
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    

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]  

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

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  

commit   : 5e8a0dc7295fd5c3d952a54f09881fb02eb94269    
  
author   : Michael Paquier <[email protected]>    
date     : Thu, 11 Nov 2021 10:51:23 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Thu, 11 Nov 2021 10:51:23 +0900    

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  

commit   : f4ab856e5d5080da076125bcbb09679fc46510f2    
  
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    

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  

commit   : 4dc2cb74d00ed487ec785cdc66a5a5a0a9aa40b2    
  
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    

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]