PostgreSQL 14.2 commit log

commit   : 78b1ddc753b3e5e3f3e9eb0e7519b48146018394    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 7 Feb 2022 16:15:36 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 7 Feb 2022 16:15:36 -0500    

commit   : 3c879e61d9ad5968e88e12620e270808b6cb76f5    
  
author   : Peter Eisentraut <[email protected]>    
date     : Mon, 7 Feb 2022 13:31:57 +0100    
  
committer: Peter Eisentraut <[email protected]>    
date     : Mon, 7 Feb 2022 13:31:57 +0100    

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

commit   : 1d9ccc0a6d3c1b3d5c52e6e427a9e1cb824b0a90    
  
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   : d0cd7b77265cf39e0e8984ba9d5bec0c155dccdb    
  
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   : d13a838e1c19df5358d250b8d469544d7ab3dfda    
  
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   : ab22eea83169c8d0eb15050ce61cbe3d7dae4de6    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 4 Feb 2022 14:55:00 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 4 Feb 2022 14:55:00 -0500    

As usual, the release notes for older branches will be made by cutting  
these down, but put them up for community review first.  

commit   : 2a3958e4d9b9b1e82adefa11f3e69ea5c16efb45    
  
author   : Andres Freund <[email protected]>    
date     : Thu, 3 Feb 2022 10:44:26 -0800    
  
committer: Andres Freund <[email protected]>    
date     : Thu, 3 Feb 2022 10:44:26 -0800    

Discussion: https://postgr.es/m/[email protected]  
Backpatch: 14-, like f862d57057f  

commit   : 7b0cec2fa05a123ed96163d7ac8485384570b3e0    
  
author   : Etsuro Fujita <[email protected]>    
date     : Thu, 3 Feb 2022 15:15:01 +0900    
  
committer: Etsuro Fujita <[email protected]>    
date     : Thu, 3 Feb 2022 15:15:01 +0900    

We assume that direct-modify ForeignScan nodes cannot be re-evaluated  
during EvalPlanQual processing, but the rework for inherited  
UPDATE/DELETE in commit 86dc90056 changed things, without considering  
that, so that such ForeignScan nodes get called as part of the  
EvalPlanQual subtree during EvalPlanQual processing in the case of an  
inherited UPDATE/DELETE where the inheritance set contains foreign  
target relations.  To avoid re-evaluating such ForeignScan nodes during  
EvalPlanQual processing, commit c3928b467 modified nodeForeignscan.c,  
but the assumption made there that ExecForeignScan() should never be  
called for such ForeignScan nodes during EvalPlanQual processing turned  
out to be wrong in some cases, leading to a segmentation fault or a  
"cannot re-evaluate a Foreign Update or Delete during EvalPlanQual"  
error.  
  
Fix by modifying nodeForeignscan.c further to avoid re-evaluating such  
ForeignScan nodes even in ExecForeignScan()/ExecReScanForeignScan()  
during EvalPlanQual processing.  Since this makes non-reachable the  
test-and-elog added to ForeignNext() by commit c3928b467 that produced  
the aforesaid error, convert the test-and-elog to an Assert.  
  
Per bug #17355 from Alexander Lakhin.  Back-patch to v14 where both  
commits came in.  
  
Patch by me, reviewed and tested by Alexander Lakhin and Amit Langote.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 25560761289e5dbe21514c9ef2cf7272d9181488    
  
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   : ee57467cb6b2ce1e25d367cbd64cc60ae9ba0eb3    
  
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   : 803f0b1739065b2d1d46c4a72c99b46cdd354f60    
  
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   : 00fdfde6dc726dbbee7e7e3e25a6406e2c76c4f6    
  
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   : 2d44912cf79f1f174a83f587e1c4328315b8a0fa    
  
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   : d81cac47a829c3e2c729ef98acaf132adb7ff3ae    
  
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   : 8484e38126d7522069e44b81cd41ef53f700b2e1    
  
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   : c025067f6d3fbffd1acc8c70ec9d2ecc5be8c90b    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 29 Jan 2022 11:41:12 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 29 Jan 2022 11:41:12 -0500    

Although select_common_type() has a failure-return convention, an  
apparent successful return just provides a type OID that *might* work  
as a common supertype; we've not validated that the required casts  
actually exist.  In the mainstream use-cases that doesn't matter,  
because we'll proceed to invoke coerce_to_common_type() on each input,  
which will fail appropriately if the proposed common type doesn't  
actually work.  However, a few callers didn't read the (nonexistent)  
fine print, and thought that if they got back a nonzero OID then the  
coercions were sure to work.  
  
This affects in particular the recently-added "anycompatible"  
polymorphic types; we might think that a function/operator using  
such types matches cases it really doesn't.  A likely end result  
of that is unexpected "ambiguous operator" errors, as for example  
in bug #17387 from James Inform.  Another, much older, case is that  
the parser might try to transform an "x IN (list)" construct to  
a ScalarArrayOpExpr even when the list elements don't actually have  
a common supertype.  
  
It doesn't seem desirable to add more checking to select_common_type  
itself, as that'd just slow down the mainstream use-cases.  Instead,  
write a separate function verify_common_type that performs the  
missing checks, and add a call to that where necessary.  Likewise add  
verify_common_type_from_oids to go with select_common_type_from_oids.  
  
Back-patch to v13 where the "anycompatible" types came in.  (The  
symptom complained of in bug #17387 doesn't appear till v14, but  
that's just because we didn't get around to converting || to use  
anycompatible till then.)  In principle the "x IN (list)" fix could  
go back all the way, but I'm not currently convinced that it makes  
much difference in real-world cases, so I won't bother for now.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : b30282fccfa34238492c0f64808e7b4aa4ef72b3    
  
author   : Michael Paquier <[email protected]>    
date     : Sat, 29 Jan 2022 10:23:17 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Sat, 29 Jan 2022 10:23:17 +0900    

c532d15 has split the logic of COPY commands into multiple files, one  
change being to move the internals of BeginCopy() to BeginCopyTo().  
Originally the code was written so as we'd switch back-and-forth between  
the current execution memory context and the dedicated memory context  
for the COPY command, and this refactoring has introduced an extra  
switch to the current memory context from the COPY context once  
BeginCopyTo() is done with the past logic coming from BeginCopy().  
  
The code was correctly doing the analyze, rewrite and planning phases in  
the COPY context, but it was not assigning "copy_file" (FILE* used when  
copying to a source file) and "filename" in the COPY context, making the  
COPY status data inconsistent.  
  
Author: Bharath Rupireddy  
Reviewed-by: Japin Li  
Discussion: https://postgr.es/m/CALj2ACWvVa69foi9jhHFY=2BuHxAoYboyE+vXQTARwxZcJnVrQ@mail.gmail.com  
Backpatch-through: 14  

commit   : d99166ed4f6e9f370289a90dd6678c06bfffd41f    
  
author   : Etsuro Fujita <[email protected]>    
date     : Fri, 28 Jan 2022 15:45:01 +0900    
  
committer: Etsuro Fujita <[email protected]>    
date     : Fri, 28 Jan 2022 15:45:01 +0900    

commit   : 6e7ee55e727771d97d0fce531a5cda350bb3fa84    
  
author   : Fujii Masao <[email protected]>    
date     : Fri, 28 Jan 2022 11:24:42 +0900    
  
committer: Fujii Masao <[email protected]>    
date     : Fri, 28 Jan 2022 11:24:42 +0900    

When pg_log_backend_memory_contexts() is executed, the target backend  
should use LOG_SERVER_ONLY to log its memory contexts, to prevent them  
from being sent to its connected client regardless of client_min_messages.  
But previously the backend unexpectedly used LOG to log the message  
"logging memory contexts of PID %d" and it could be sent to the client.  
This is a bug in memory context logging.  
  
To fix the bug, this commit changes that message so that it's logged with  
LOG_SERVER_ONLY.  
  
Back-patch to v14 where pg_log_backend_memory_contexts() was added.  
  
Author: Fujii Masao  
Reviewed-by: Bharath Rupireddy, Atsushi Torikoshi  
Discussion: https://postgr.es/m/[email protected]  

commit   : fb2f8e534aaefa649ada8df3e4863ebad32229f7    
  
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   : 999dc1d2650883b817ea6d4e393ca8ba84a8687d    
  
author   : Andrew Dunstan <[email protected]>    
date     : Thu, 27 Jan 2022 08:17:42 -0500    
  
committer: Andrew Dunstan <[email protected]>    
date     : Thu, 27 Jan 2022 08:17:42 -0500    

Perl instances on some msys toolchains (e.g. UCRT64) have their  
configured osname set to 'MSWin32' rather than 'msys'.  The test for  
the msys2 platform is adjusted accordingly.  
  
Backpatch to release 14.  

commit   : d1cca9441dc488b9e4d82cf34c9cacc998e6470f    
  
author   : Etsuro Fujita <[email protected]>    
date     : Thu, 27 Jan 2022 16:15:02 +0900    
  
committer: Etsuro Fujita <[email protected]>    
date     : Thu, 27 Jan 2022 16:15:02 +0900    

Commit 27e1f1456 failed to process a pending asynchronous request made  
for a given ForeignScan node in postgresReScanForeignScan() (if any) in  
cases where we would only reset the next_tuple counter in that function,  
contradicting the assumption that there should be no pending  
asynchronous requests that have been made for async-capable subplans for  
the parent Append node after ReScan.  This led to an assert failure in  
an assert-enabled build.  I think this would also lead to mis-rewinding  
the cursor in that function in the case where we have already fetched  
one batch for the ForeignScan node and the asynchronous request has been  
made for the second batch, because even in that case we would just reset  
the counter when called from that function, so we would fail to execute  
MOVE BACKWARD ALL.  
  
To fix, modify that function to process the asynchronous request before  
restarting the scan.  
  
While at it, add a comment to a function to match other places.  
  
Per bug #17344 from Alexander Lakhin.  Back-patch to v14 where the  
aforesaid commit came in.  
  
Patch by me.  Test case by Alexander Lakhin, adjusted by me.  Reviewed  
and tested by Alexander Lakhin and Dmitry Dolgov.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : d94a95cce9eb8582f3bb48fd745f21749b317e83    
  
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   : 4afae689ead4ffbfdbaac1cd72794c729446596e    
  
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    

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  

commit   : 75674c7ec1b1607e7013b5cebcb22d9c8b4b2cb6    
  
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   : 357ff66153b4791d32c45724d8a0d3c91d89c937    
  
author   : David Rowley <[email protected]>    
date     : Tue, 25 Jan 2022 21:14:27 +1300    
  
committer: David Rowley <[email protected]>    
date     : Tue, 25 Jan 2022 21:14:27 +1300    

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  

commit   : 29d9da36b7b132476ef7b31a5dace7bc7410cc82    
  
author   : Michael Paquier <[email protected]>    
date     : Tue, 25 Jan 2022 10:49:30 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Tue, 25 Jan 2022 10:49:30 +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   : 1efcc5946d595a168a1abf737030f2e0ee1f4d43    
  
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   : ef9706bbc8ce917a366e4640df8c603c9605817a    
  
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   : 1042de69dbb6f3c0aa92a741a68aeca23f4ed45e    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 23 Jan 2022 13:54:24 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 23 Jan 2022 13:54:24 -0500    

Commit 6df7a9698 wrote appendPQExpBuffer where it should have  
written printfPQExpBuffer.  This resulted in re-issuing the  
previous query along with the desired one, which very accidentally  
had no negative consequences except for some wasted cycles.  
  
Back-patch to v14 where that came in.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : ef4edf88df6592b6a29649f3ae69d44cef478291    
  
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   : 72ac4d71b54fdac5efc9ecfc23663f26c20ddcf9    
  
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   : a192243c75be0f142f829b3e73548bc7cbd3b90d    
  
author   : Tomas Vondra <[email protected]>    
date     : Sun, 23 Jan 2022 02:49:41 +0100    
  
committer: Tomas Vondra <[email protected]>    
date     : Sun, 23 Jan 2022 02:49:41 +0100    

The syscache lookup may return NULL even for valid OID, for example due  
to a concurrent DROP STATISTICS, so a HeapTupleIsValid is necessary.  
Without it, it may fail with a segfault.  
  
Reported by Alexander Lakhin, patch by me. Backpatch to 13, where ALTER  
STATISTICS ... SET STATISTICS was introduced.  
  
Backpatch-through: 13  
Discussion: https://postgr.es/m/17372-bf3b6e947e35ae77%40postgresql.org  

commit   : 3839e29c58b44639bb6800f3415af87f4d1fb655    
  
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   : f4ebf0dbea835da85c21988321258a587a567dbd    
  
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   : 2b7dbe4bd5872ae5c6780e1a4121c2a5a8401e7c    
  
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   : 700e8fe6d414ebaf9820fef364097d9b83cae7fd    
  
author   : Etsuro Fujita <[email protected]>    
date     : Fri, 21 Jan 2022 17:45:02 +0900    
  
committer: Etsuro Fujita <[email protected]>    
date     : Fri, 21 Jan 2022 17:45:02 +0900    

Commit 27e1f1456 resets the per-connection states of connections used to  
scan foreign tables asynchronously during abort cleanup at main  
transaction end, but it failed to do so during subabort cleanup at  
subtransaction end, leading to a segmentation fault when re-executing an  
asynchronous-foreign-table-scan query in a transaction that was  
cancelled in a subtransaction of it.  
  
Fix by modifying pgfdw_abort_cleanup() to reset the per-connection state  
of a given connection also when called for subabort cleanup.  Also,  
modify that function to do the reset in both the abort-cleanup and  
subabort-cleanup cases if necessary, to save cycles, and improve a  
comment on it a little bit.  
  
Back-patch to v14 where the aforesaid commit came in.  
  
Reviewed by Alexander Pyhalov  
  
Discussion: https://postgr.es/m/CAPmGK14cCV-JA7kNsyt2EUTKvZ4xkr2LNRthi1U1C3cqfGppAw@mail.gmail.com  

commit   : 84db5169d4715904b0bffa25509f3c77fcd52188    
  
author   : Michael Paquier <[email protected]>    
date     : Fri, 21 Jan 2022 14:54:47 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Fri, 21 Jan 2022 14:54:47 +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   : cf680bd6538a5a05020ab4d193b43563e9eb0c5e    
  
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   : 156a846d93ee2dab365a89ddd1469ef7a9d1b92e    
  
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   : b9dd162205bf2e1a20ce21a80e6ea497c7980ffe    
  
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    

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  

commit   : a9009f59fff148b11588cfccdc3989d3363cfab1    
  
author   : Michael Paquier <[email protected]>    
date     : Thu, 20 Jan 2022 16:54:54 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Thu, 20 Jan 2022 16:54:54 +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   : b0623625a0a30d66e991deab6488c59bb63ea20e    
  
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   : 0f1367c9f381aae523f6557c0ee28a800b3eace7    
  
author   : Michael Paquier <[email protected]>    
date     : Wed, 19 Jan 2022 10:37:47 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Wed, 19 Jan 2022 10:37:47 +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   : ff4d0d8cc5e2e3823bf3428e707ee33c13d401f6    
  
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    

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  

commit   : 3886785b4ce59147b92319e7204ab64a9d8801cb    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 17 Jan 2022 21:18:49 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 17 Jan 2022 21:18:49 -0500    

The original coding (from c33869cc3) failed with "more than one row  
returned by a subquery used as an expression" if there were unrelated  
triggers of the same tgname on parent partitioned tables.  (That's  
possible because statement-level triggers don't get inherited.)  Fix  
by applying LIMIT 1 after sorting the candidates by inheritance level.  
  
Also, wrap the subquery in a CASE so that we don't have to execute it at  
all when the trigger is visibly non-inherited.  Aside from saving some  
cycles, this avoids the need for a confusing and undocumented NULLIF().  
  
While here, tweak the format of the emitted query to look a bit  
nicer for "psql -E", and add some explanation of this subquery,  
because it badly needs it.  
  
Report and patch by Justin Pryzby (with some editing by me).  
Back-patch to v13 where the faulty code came in.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 4e8726566e4d7c0e712d16c0dc7a27d212ece090    
  
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   : 050949877004f003b7d95fddf8f572a32f3a2f70    
  
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   : 17da9d4c28297fd699cbbda969a9f64c4c09c665    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 16 Jan 2022 16:39:26 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 16 Jan 2022 16:39:26 -0500    

The need for this was foreseen long ago, but when record_eq  
actually became hashable (in commit 01e658fa7), we missed updating  
this spot.  
  
Per bug #17363 from Elvis Pranskevichus.  Back-patch to v14 where  
the faulty commit came in.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : d91d4338e05486f943361260b9d4ad54421d3b44    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 16 Jan 2022 14:59:20 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 16 Jan 2022 14:59:20 -0500    

Since enum labels have to be single-quoted, this part of the  
tab completion machinery got side-swiped by commit cd69ec66c.  
A side-effect of that commit is that (at least with some versions  
of Readline) the text string passed for completion will omit the  
leading quote mark of the enum label literal.  Libedit still acts  
the same as before, though, so adapt COMPLETE_WITH_ENUM_VALUE so  
that it can cope with either convention.  
  
Also, when we fail to find any valid completion, set  
rl_completion_suppress_quote = 1.  Otherwise readline will  
go ahead and append a closing quote, which is unwanted.  
  
Per report from Peter Eisentraut.  Back-patch to v13 where  
cd69ec66c came in.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : ea212bd95fd2456953ca8995cf2a04d3db82ac19    
  
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   : 2cc007fd0359870b4a1e959af0ac94e61df47240    
  
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   : dad1539aec28ae3d024b00ae322f02f7fe0c41ee    
  
author   : Andres Freund <[email protected]>    
date     : Fri, 10 Dec 2021 20:12:26 -0800    
  
committer: Andres Freund <[email protected]>    
date     : Fri, 10 Dec 2021 20:12:26 -0800    

Since dc7420c2c92 the horizon used for pruning is determined "lazily". A more  
accurate horizon is built on-demand, rather than in GetSnapshotData(). If a  
horizon computation is triggered between two HeapTupleSatisfiesVacuum() calls  
for the same tuple, the result can change from RECENTLY_DEAD to DEAD.  
  
heap_page_prune() can process the same tid multiple times (once following an  
update chain, once "directly"). When the result of HeapTupleSatisfiesVacuum()  
of a tuple changes from RECENTLY_DEAD during the first access, to DEAD in the  
second, the "tuple is DEAD and doesn't chain to anything else" path in  
heap_prune_chain() can end up marking the target of a LP_REDIRECT ItemId  
unused.  
  
Initially not easily visible,  
Once the target of a LP_REDIRECT ItemId is marked unused, a new tuple version  
can reuse it. At that point the corruption may become visible, as index  
entries pointing to the "original" redirect item, now point to a unrelated  
tuple.  
  
To fix, compute HTSV for all tuples on a page only once. This fixes the entire  
class of problems of HTSV changing inside heap_page_prune(). However,  
visibility changes can obviously still occur between HTSV checks inside  
heap_page_prune() and outside (e.g. in lazy_scan_prune()).  
  
The computation of HTSV is now done in bulk, in heap_page_prune(), rather than  
on-demand in heap_prune_chain(). Besides being a bit simpler, it also is  
faster: Memory accesses can happen sequentially, rather than in the order of  
HOT chains.  
  
There are other causes of HeapTupleSatisfiesVacuum() results changing between  
two visibility checks for the same tuple, even before dc7420c2c92. E.g.  
HEAPTUPLE_INSERT_IN_PROGRESS can change to HEAPTUPLE_DEAD when a transaction  
aborts between the two checks. None of the these other visibility status  
changes are known to cause corruption, but heap_page_prune()'s approach makes  
it hard to be confident.  
  
A patch implementing a more fundamental redesign of heap_page_prune(), which  
fixes this bug and simplifies pruning substantially, has been proposed by  
Peter Geoghegan in  
https://postgr.es/m/CAH2-WzmNk6V6tqzuuabxoxM8HJRaWU6h12toaS-bqYcLiht16A@mail.gmail.com  
  
However, that redesign is larger change than desirable for backpatching. As  
the new design still benefits from the batched visibility determination  
introduced in this commit, it makes sense to commit this narrower fix to 14  
and master, and then commit Peter's improvement in master.  
  
The precise sequence required to trigger the bug is complicated and hard to do  
exercise in an isolation test (until we have wait points). Due to that the  
isolation test initially posted at  
https://postgr.es/m/20211119003623.d3jusiytzjqwb62p%40alap3.anarazel.de  
and updated in  
https://postgr.es/m/20211122175914.ayk6gg6nvdwuhrzb%40alap3.anarazel.de  
isn't committable.  
  
A followup commit will introduce additional assertions, to detect problems  
like this more easily.  
  
Bug: #17255  
Reported-By: Alexander Lakhin <[email protected]>  
Debugged-By: Andres Freund <[email protected]>  
Debugged-By: Peter Geoghegan <[email protected]>  
Author: Andres Freund <andres@[email protected]>  
Reviewed-By: Peter Geoghegan <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  
Backpatch: 14-, the oldest branch containing dc7420c2c92  

commit   : ad5b6f248ab288c3252d8122d12a1eb410d4a0b6    
  
author   : Michael Paquier <[email protected]>    
date     : Fri, 14 Jan 2022 11:25:39 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Fri, 14 Jan 2022 11:25:39 +0900    

This reverts commits ab27df2, af8d530 and 3a0cced, that introduced  
pg_cryptohash_error().  In order to make the core code able to pass down  
the new error types that this introduced, some of the MD5-related  
routines had to be reworked, causing an ABI breakage, but we found that  
some external extensions rely on them.  Maintaining compatibility  
outweights the error report benefits, so just revert the change in v14.  
  
Reported-by: Laurenz Albe  
Discussion: https://postgr.es/m/[email protected]  

commit   : 4aee39ddb8fa748a6beea2bc1b48882990c226a7    
  
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   : 3c1ffd02dd058666ddf27d7e621ab5bbc4b769bb    
  
author   : Michael Paquier <[email protected]>    
date     : Thu, 13 Jan 2022 09:43:44 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Thu, 13 Jan 2022 09:43:44 +0900    

Both files referred to pg_hmac_ctx->data, which, I guess, comes from the  
early versions of the patch that has resulted in commit e6bdfd9.  
  
Author: Sergey Shinderuk  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 14  

commit   : 41ee68a91f0fc8e1f6583e4f153d79578adb265c    
  
author   : Peter Geoghegan <[email protected]>    
date     : Wed, 12 Jan 2022 15:41:02 -0800    
  
committer: Peter Geoghegan <[email protected]>    
date     : Wed, 12 Jan 2022 15:41:02 -0800    

Commit 9dc718bd added a "logically unchanged by UPDATE" hinting  
mechanism, which is currently used within nbtree indexes only (see  
commit d168b666).  This mechanism determined whether or not the incoming  
item is a logically unchanged duplicate (a duplicate needed only for  
MVCC versioning purposes) once per row updated per non-HOT update.  This  
approach led to memory leaks which were noticeable with an UPDATE  
statement that updated sufficiently many rows, at least on tables that  
happen to have an expression index.  
  
On HEAD, fix the issue by adding a cache to the executor's per-index  
IndexInfo struct.  
  
Take a different approach on Postgres 14 to avoid an ABI break: simply  
pass down the hint to all indexes unconditionally with non-HOT UPDATEs.  
This is deemed acceptable because the hint is currently interpreted  
within btinsert() as "perform a bottom-up index deletion pass if and  
when the only alternative is splitting the leaf page -- prefer to delete  
any LP_DEAD-set items first".  nbtree must always treat the hint as a  
noisy signal about what might work, as a strategy of last resort, with  
costs imposed on non-HOT updaters.  (The same thing might not be true  
within another index AM that applies the hint, which is why the original  
behavior is preserved on HEAD.)  
  
Author: Peter Geoghegan <[email protected]>  
Reported-By: Klaudie Willis <[email protected]>  
Diagnosed-By: Tom Lane <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  
Backpatch: 14-, where the hinting mechanism was added.  

commit   : af8d530e47588d909a3c8d400b21a273e50498d6    
  
author   : Michael Paquier <[email protected]>    
date     : Wed, 12 Jan 2022 12:40:04 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Wed, 12 Jan 2022 12:40:04 +0900    

One of the comments introduced in b69aba7 was worded a bit weirdly, so  
improve it.  
  
Reported-by: Sergey Shinderuk  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 14  

commit   : ab27df2490e3a5dfb8ecb3de66818d16645ef3dd    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 11 Jan 2022 12:03:06 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 11 Jan 2022 12:03:06 -0500    

Experimenting with FIPS mode enabled, I saw  
  
regression=# \password joe  
Enter new password for user "joe":  
Enter it again:  
could not encrypt password: disabled for FIPS  
out of memory  
  
because PQencryptPasswordConn was still of the opinion that "out of  
memory" is always appropriate to print.  
  
Minor oversight in b69aba745.  Like that one, back-patch to v14.  

commit   : 3a0cced86d3b1bbbf0aaa0fb34e2b15edd643979    
  
author   : Michael Paquier <[email protected]>    
date     : Tue, 11 Jan 2022 09:55:24 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Tue, 11 Jan 2022 09:55:24 +0900    

The existing cryptohash facility was causing problems in some code paths  
related to MD5 (frontend and backend) that relied on the fact that the  
only type of error that could happen would be an OOM, as the MD5  
implementation used in PostgreSQL ~13 (the in-core implementation is  
used when compiling with or without OpenSSL in those older versions),  
could fail only under this circumstance.  
  
The new cryptohash facilities can fail for reasons other than OOMs, like  
attempting MD5 when FIPS is enabled (upstream OpenSSL allows that up to  
1.0.2, Fedora and Photon patch OpenSSL 1.1.1 to allow that), so this  
would cause incorrect reports to show up.  
  
This commit extends the cryptohash APIs so as callers of those routines  
can fetch more context when an error happens, by using a new routine  
called pg_cryptohash_error().  The error states are stored within each  
implementation's internal context data, so as it is possible to extend  
the logic depending on what's suited for an implementation.  The default  
implementation requires few error states, but OpenSSL could report  
various issues depending on its internal state so more is needed in  
cryptohash_openssl.c, and the code is shaped so as we are always able to  
grab the necessary information.  
  
The core code is changed to adapt to the new error routine, painting  
more "const" across the call stack where the static errors are stored,  
particularly in authentication code paths on variables that provide  
log details.  This way, any future changes would warn if attempting to  
free these strings.  The MD5 authentication code was also a bit blurry  
about the handling of "logdetail" (LOG sent to the postmaster), so  
improve the comments related that, while on it.  
  
The origin of the problem is 87ae969, that introduced the centralized  
cryptohash facility.  Extra changes are done for pgcrypto in v14 for the  
non-OpenSSL code path to cope with the improvements done by this  
commit.  
  
Reported-by: Michael Mühlbeyer  
Author: Michael Paquier  
Reviewed-by: Tom Lane  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 14  

commit   : 05cdda68f8f6e63cb87bc1776236d7619cd89fb7    
  
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   : 1cd46f168fda4d819e315eacf3d4f3d5aa84859c    
  
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   : 043c1e1a73aace8b459b3290ff7a50c9b124fb33    
  
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   : f5bea8360691eeaef7ad3b6163b3e2bbb9c7c466    
  
author   : Michael Paquier <[email protected]>    
date     : Sat, 8 Jan 2022 16:45:14 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Sat, 8 Jan 2022 16:45:14 +0900    

This addresses some problems in the describe queries used for extended  
statistics:  
- Two schema qualifications for the text type were missing for \dX.  
- The list of extended statistics listed for a table through \d was  
ordered based on the object OIDs, but it is more consistent with the  
other commands to order by namespace and then by object name.  
- A couple of aliases were not used in \d.  These are removed.  
  
This is similar to commits 1f092a3 and 07f8a9e.  
  
Author: Justin Pryzby  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 14  

commit   : 61c8da50cb39ab41c3a7a0122d6943f72bb0798e    
  
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   : a7772e8748a7783776f0095e0d7068bcf42e3d69    
  
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   : f285d95839e05608ee99dba399abe860d3c026c5    
  
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   : 9ae0a4c702324110dde366f9370f9b6c02b4dee8    
  
author   : Michael Paquier <[email protected]>    
date     : Thu, 6 Jan 2022 11:41:40 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Thu, 6 Jan 2022 11:41:40 +0900    

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  

commit   : 5ddfebded41f7754b3c4fc1b576ca33736efcab6    
  
author   : Michael Paquier <[email protected]>    
date     : Wed, 5 Jan 2022 10:27:47 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Wed, 5 Jan 2022 10:27:47 +0900    

get_rel_sync_entry(), which is called each time a change needs to be  
logically replicated, is a rather hot code path in the WAL sender  
sending logical changes.  This code path was doing a relcache access on  
relkind and relpartition for each logical change, but we only need to  
know this information when building or re-building the cached  
information for a relation.  
  
Some measurements prove that this is noticeable in perf profiles,  
particularly when attempting to replicate changes from relations that  
are not published as these cause less overhead in the WAL sender,  
delaying further the replication of changes for relations that are  
published.  
  
Issue introduced in 83fd453.  
  
Author: Hou Zhijie  
Reviewed-by: Kyotaro Horiguchi, Euler Taveira  
Discussion: https://postgr.es/m/OS0PR01MB5716E863AA9E591C1F010F7A947D9@OS0PR01MB5716.jpnprd01.prod.outlook.com  
Backpatch-through: 13  

commit   : f9db153c282de599a7d5ae2694f50fe10fba8461    
  
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   : f185f35a83d980033824c3522b7b97ab1c2de71e    
  
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   : d228af79d0f206f9bd24856b2c1df0909c8db1ec    
  
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   : 52d50261dbd353a34027d057ce2e0b892922fa58    
  
author   : Michael Paquier <[email protected]>    
date     : Mon, 3 Jan 2022 17:34:53 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Mon, 3 Jan 2022 17:34:53 +0900    

Since 4f0b096, pgss_store() does nothing if compute_query_id is disabled  
or if no other module computed a query identifier, but the top comment  
of this function did not reflect that.  This behavior is already  
documented in its own code path, and this just removes the inconsistent  
comment.  
  
Author: Kyotaro Horiguchi  
Reviewed-by: Julien Rouhaud  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 14  

commit   : f0c5866113fb1d85ada6dc3fe67e4909d94bacc2    
  
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   : cabea571d11e020c8c72dfb8ddced441745d7238    
  
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   : cb4f1be43ad2c60ea80b07d3345d8a52ca9f763f    
  
author   : Daniel Gustafsson <[email protected]>    
date     : Thu, 30 Dec 2021 13:23:47 +0100    
  
committer: Daniel Gustafsson <[email protected]>    
date     : Thu, 30 Dec 2021 13:23:47 +0100    

The reverted commit attempted to fix SQL specification compliance for  
the cases which 6aaaa76bb left.  This however broke existing behavior  
which takes precedence over spec compliance so revert. The introduced  
tests are left after the revert since the codepath isn't well covered.  
Per bug report 17346. Backpatch down to 14 where it was introduced.  
  
Reported-by: Andrew Bille <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  

commit   : f7d7ac23d19240a90bbb8d91cb231ef7f883dd02    
  
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   : 2ff209953e0a7b4ce9df1c1ba15783345ef5659f    
  
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   : 420f9ac1b77cca142d4ab7919a4f2b703c1278b8    
  
author   : Michael Paquier <[email protected]>    
date     : Wed, 22 Dec 2021 16:38:38 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Wed, 22 Dec 2021 16:38:38 +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   : 8a22a40b2cfd1ea3218663153e5c6d7ebc68d2bf    
  
author   : Michael Paquier <[email protected]>    
date     : Wed, 22 Dec 2021 15:38:05 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Wed, 22 Dec 2021 15:38:05 +0900    

One code path related to this flavor of ALTER TABLE was checking that  
the relation to detach has to be a normal table or a partitioned table,  
which would fail if using the command with a different relation kind.  
  
Views, sequences and materialized views cannot be part of a partition  
tree, so these would cause the command to fail anyway, but the assertion  
was triggered.  Foreign tables can be part of a partition tree, and  
again the assertion would have failed.  The simplest solution is just to  
remove this assertion, so as we get the same failure as the  
non-concurrent code path.  
  
While on it, add a regression test in postgres_fdw for the concurrent  
partition detach of a foreign table, as per a suggestion from Alexander  
Lakhin.  
  
Issue introduced in 71f4c8c.  
  
Reported-by: Alexander Lakhin  
Author: Michael Paquier, Alexander Lakhin  
Reviewed-by: Peter Eisentraut, Kyotaro Horiguchi  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 14  

commit   : f9a8bc9f27e6c7569f30fc86b82129647068f6a0    
  
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   : 4ddbd7456a2d1a2f06f0860151bcbc720bf75e55    
  
author   : Michael Paquier <[email protected]>    
date     : Wed, 15 Dec 2021 10:40:08 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Wed, 15 Dec 2021 10:40:08 +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   : 25c7faa1feeeff040242100d61b1f8914db3d3ea    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 14 Dec 2021 11:46:36 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 14 Dec 2021 11:46:36 -0500    

This could only matter if (a) long is wider than int, and (b) the heap  
of free blocks exceeds UINT_MAX entries, which seems pretty unlikely.  
Still, it's a theoretical bug, so backpatch to v13 where the typo came  
in (in commit c02fdc922).  
  
In passing, also make swap_nodes() use consistent datatypes.  
  
Ma Liangzhu  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 4be3e005e5da931aa816e3c04e1217c33de52fd6    
  
author   : Michael Paquier <[email protected]>    
date     : Tue, 14 Dec 2021 10:58:25 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Tue, 14 Dec 2021 10:58:25 +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   : a80fd2ae4cd4058b745959de1092f73810077779    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 13 Dec 2021 17:49:36 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 13 Dec 2021 17:49:36 -0500    

In commit 791090bd7, I made an effort to fill in documentation  
for all geometric operators listed in pg_operator.  However,  
it now appears that at least some of the omissions may have been  
intentional, because some of those operator entries point at  
unimplemented stub functions.  Remove those from the docs again.  
  
(In HEAD, poly_distance stays, because c5c192d7b just added an  
implementation for it.)  
  
Per complaint from Anton Voloshin.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 5b5455b035c62a710ebd6facb164112e36e9fa49    
  
author   : Andres Freund <[email protected]>    
date     : Mon, 13 Dec 2021 12:02:42 -0800    
  
committer: Andres Freund <[email protected]>    
date     : Mon, 13 Dec 2021 12:02:42 -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   : 7615edd1db92b0bf909037480e8d9fcdb1be5f4b    
  
author   : Alexander Korotkov <[email protected]>    
date     : Mon, 13 Dec 2021 17:17:33 +0300    
  
committer: Alexander Korotkov <[email protected]>    
date     : Mon, 13 Dec 2021 17:17:33 +0300    

The multirange_get_range() function fails when two boundaries of the same  
range have different alignments.  Fix that by adding proper pointer alignment.  
  
Reported-by: Alexander Lakhin  
Discussion: https://postgr.es/m/17300-dced2d01ddeb1f2f%40postgresql.org  
Backpatch-through: 14  

commit   : a04fc56d03b33780612cf7630bb3f1a9388a9a02    
  
author   : Michael Paquier <[email protected]>    
date     : Thu, 9 Dec 2021 15:20:45 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Thu, 9 Dec 2021 15:20:45 +0900    

One of the changes impacts the documentation, so backpatch.  
  
Author: Peter Smith  
Discussion: https://postgr.es/m/CAHut+Pu6+c+r3mY24VT7u+H+E_s6vMr5OdRiZ8NT3EOa-E5Lmw@mail.gmail.com  
Backpatch-through: 14  

commit   : 614b77d65a3859ad8d2c1c28475e98ddee06dc50    
  
author   : Amit Kapila <[email protected]>    
date     : Thu, 9 Dec 2021 08:49:50 +0530    
  
committer: Amit Kapila <[email protected]>    
date     : Thu, 9 Dec 2021 08:49:50 +0530    

We publish the child table's data twice for a publication that has both  
child and parent tables and is published with publish_via_partition_root  
as true. This happens because subscribers will initiate synchronization  
using both parent and child tables, since it gets both as separate tables  
in the initial table list.  
  
Ensure that pg_publication_tables returns only parent tables in such  
cases.  
  
Author: Hou Zhijie  
Reviewed-by: Greg Nancarrow, Amit Langote, Vignesh C, Amit Kapila  
Backpatch-through: 13  
Discussion: https://postgr.es/m/OS0PR01MB57167F45D481F78CDC5986F794B99@OS0PR01MB5716.jpnprd01.prod.outlook.com  

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

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   : e4d73d089f4a1200c5d24f9d9dd014d911567f53    
  
author   : Andrew Dunstan <[email protected]>    
date     : Wed, 8 Dec 2021 16:45:39 -0500    
  
committer: Andrew Dunstan <[email protected]>    
date     : Wed, 8 Dec 2021 16:45:39 -0500    

This reverts commit f920f7e799c587228227ec94356c760e3f3d5f2b.  
  
The patch in effect fixed a problem we didn't have and caused another  
instead.  
  
Backpatch to release 14 like original  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 90c08ed11332b766769b2e5ba114fb7ecb34e401    
  
author   : Andrew Dunstan <[email protected]>    
date     : Wed, 8 Dec 2021 10:21:35 -0500    
  
committer: Andrew Dunstan <[email protected]>    
date     : Wed, 8 Dec 2021 10:21:35 -0500    

Issue exposed by commit edc2332550 and the buildfarm.  
  
Backpatch to release 14 where this usage started.  

commit   : f2e1730ee9bc1a8a3875a69a174cfb365b210821    
  
author   : Amit Kapila <[email protected]>    
date     : Wed, 8 Dec 2021 15:21:12 +0530    
  
committer: Amit Kapila <[email protected]>    
date     : Wed, 8 Dec 2021 15:21:12 +0530    

This happens because we were passing incorrect arguments to  
ReorderBufferFinishPrepared().  
  
Author: Masahiko Sawada  
Reviewed-by: Vignesh C  
Backpatch-through: 14  
Discussion: https://postgr.es/m/CAD21AoBqhUqgDZUhUVnnwKRubPDNJ6m6fJDPgok3E5cWJLL+pA@mail.gmail.com  

commit   : 64ab21f0e5deb80ff67f953c6e3c8640a007a929    
  
author   : Michael Paquier <[email protected]>    
date     : Wed, 8 Dec 2021 11:01:14 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Wed, 8 Dec 2021 11:01:14 +0900    

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  

commit   : 93094232c8958a42fdd066ef52d4673108e768e3    
  
author   : Andrew Dunstan <[email protected]>    
date     : Tue, 7 Dec 2021 14:53:39 -0500    
  
committer: Andrew Dunstan <[email protected]>    
date     : Tue, 7 Dec 2021 14:53:39 -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   : ea5ecdadf6eacdc1ef5c67648ebaed2efcb0d07a    
  
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   : b6360aa46ce966f77fba290637f51f5bb2de12a9    
  
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   : 5cb86a2622f616cbacc0c4fc05a2d34e458863b6    
  
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   : 4cd2928543c1148278f8c1f393ee58dd72816df0    
  
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   : b6dac98b05618c22bf357e5fcf23ad2419013439    
  
author   : Michael Paquier <[email protected]>    
date     : Thu, 2 Dec 2021 10:31:29 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Thu, 2 Dec 2021 10:31:29 +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   : 8f4b0200e15a5684f6331f94caea002370754257    
  
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   : 4b8eec716a524b9c9f4a65660a7006628c1d8da3    
  
author   : Amit Kapila <[email protected]>    
date     : Wed, 1 Dec 2021 10:18:27 +0530    
  
committer: Amit Kapila <[email protected]>    
date     : Wed, 1 Dec 2021 10:18:27 +0530    

ATTACHing a table into a partition tree whose root is published using a  
publication with publish_via_partition_root set to true does not result in  
the table's existing contents being replicated. This happens because  
subscriber doesn't consider replicating the newly attached partition as  
the root table is already in a 'ready' state.  
  
This behavior was introduced in PG13 (83fd4532a7) where we allowed to  
publish partition changes via ancestors.  
  
We can consider fixing this limitation in the future.  
  
Author: Amit Langote  
Reviewed-by: Hou Zhijie, Amit Kapila  
Backpatch-through: 13  
Discussion: https://postgr.es/m/OS0PR01MB5716E97F00732B52DC2BBC2594989@OS0PR01MB5716.jpnprd01.prod.outlook.com  

commit   : 175edafd1f30a78643359b56c5545b5e7aabfb50    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 30 Nov 2021 17:18:04 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 30 Nov 2021 17:18:04 -0500    

Commit 16f96c74d neglected to consider the possibility of cross-compiling,  
causing cross-compiles to fail at the configure stage unless you'd  
selected --with-openssl.  Since we're now more or less assuming that  
/dev/urandom is available everywhere, it seems reasonable to assume  
that the cross-compile target has it too, rather than failing.  
  
Per complaint from Vincas Dargis.  Back-patch to v14 where this came in.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 5550a9c385198ac51d2f3b17be2f6ff9f886d76d    
  
author   : Michael Paquier <[email protected]>    
date     : Tue, 30 Nov 2021 09:55:56 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Tue, 30 Nov 2021 09:55:56 +0900    

GetFinalPathNameByHandleA() cannot be used in compilation environments  
where _WIN32_WINNT < 0x0600, meaning at least Windows XP used by some  
buildfarm members under MinGW that Postgres still needs to support.  
This was reported as a compilation warning by the buildfarm, but this is  
actually worse than the report as the code would have not worked.  
  
Instead, this switches to GetFileInformationByHandle() that is able to  
fail for standard streams and succeed for redirected ones, which is what  
we are looking for herein the code emulating fstat().  We also know that  
it is able to work in all the environments still supported, thanks to  
the existing logic of win32stat.c.  
  
Issue introduced by 10260c7, so backpatch down to 14.  
  
Reported-by: Justin Pryzby, via buildfarm member jacana  
Author: Michael Paquier  
Reviewed-by: Juan José Santamaría Flecha  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 14  

commit   : ce43b3dc52c90082981f2f1de5351a95fc21c405    
  
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   : 1b1e4bfe7da770ad159c0f4291925a3597a65dbc    
  
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    

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]  

commit   : 2187a229410f12168d48eb41fce22ba348b2b757    
  
author   : Alvaro Herrera <[email protected]>    
date     : Fri, 26 Nov 2021 14:31:57 -0300    
  
committer: Alvaro Herrera <[email protected]>    
date     : Fri, 26 Nov 2021 14:31:57 -0300    

The doc blurb failed to mention units, as well as lacking the point  
about changeability.  
  
Backpatch to 13.  
  
Reviewed-by: Kyotaro Horiguchi <[email protected]>  
Reported by: [email protected]  
Discussion: https://postgr.es/m/[email protected]  

commit   : d24dac9549067716f5b4d8e44ccf87dd5274bfcd    
  
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   : 371087d006e04991080bf17cf2287db38d3ea92e    
  
author   : Daniel Gustafsson <[email protected]>    
date     : Fri, 26 Nov 2021 14:02:01 +0100    
  
committer: Daniel Gustafsson <[email protected]>    
date     : Fri, 26 Nov 2021 14:02:01 +0100    

Commit 6aaaa76bb added support for the GRANTED BY clause in GRANT and  
REVOKE statements, but missed adding support for checking the role in  
the REVOKE ROLE case. Fix by checking that the parsed role matches the  
CURRENT_ROLE/CURRENT_USER requirement, and also add some tests for it.  
Backpatch to v14 where GRANTED BY support was introduced.  
  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 14  

commit   : 1cc13b83eb125fb63eeb1249aa5b28d06fbd2b6c    
  
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   : e415916e24ccf28a88d87182e716beace9820753    
  
author   : Michael Paquier <[email protected]>    
date     : Thu, 25 Nov 2021 15:05:24 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Thu, 25 Nov 2021 15:05:24 +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   : d2198b4593cca21390907a1d6762e3a0357298db    
  
author   : Michael Paquier <[email protected]>    
date     : Thu, 25 Nov 2021 12:17:05 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Thu, 25 Nov 2021 12:17:05 +0900    

The emulation of fstat() in win32stat.c caused two issues with the  
existing in-core callers, failing on EINVAL when using a stream as  
argument:  
- psql's \copy would crash when using a stream.  
- pg_recvlogical would fail with -f -.  
  
The tests in copyselect.sql from the main test suite covers the first  
case, and there is a TAP test for the second case.  However, in both  
cases, as the standard streams are always redirected, automated tests  
did not notice those issues, requiring a terminal on Windows to be  
reproducible.  
  
This issue has been introduced in bed9075, and the origin of the problem  
is that GetFileInformationByHandle() does not work directly on streams,  
so this commit adds an extra code path to emulate and return a set of  
stats that match best with the reality.  Note that redirected streams  
rely on handles that can be queried with GetFileInformationByHandle(),  
but we can rely on GetFinalPathNameByHandleA() to detect this case.  
  
Author: Dmitry Koval, Juan José Santamaría Flecha  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 14  

commit   : 6d1bdd5e0712c0c3460d68dc2175f842530b1f83    
  
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   : 88482d75cce5f3527ebad1cf42ec59a355f4b033    
  
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   : c2dc7b9e15039ce90c0a631ff291feb81d2c8051    
  
author   : David Rowley <[email protected]>    
date     : Wed, 24 Nov 2021 23:29:56 +1300    
  
committer: David Rowley <[email protected]>    
date     : Wed, 24 Nov 2021 23:29:56 +1300    

It's possible that a subplan below a Memoize node contains a parameter  
from above the Memoize node.  If this parameter changes then cache entries  
may become out-dated due to the new parameter value.  
  
Previously Memoize was mistakenly not aware of this.  We fix this here by  
flushing the cache whenever a parameter that's not part of the cache  
key changes.  
  
Bug: #17213  
Reported by: Elvis Pranskevichus  
Author: David Rowley  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 14, where Memoize was added  

commit   : 0e681fa458750b08a5c7885820320fb85cd9ddf1    
  
author   : Michael Paquier <[email protected]>    
date     : Wed, 24 Nov 2021 13:03:55 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Wed, 24 Nov 2021 13:03:55 +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   : 7933bc0d13616844ed66271942eac12c3a7f0488    
  
author   : David Rowley <[email protected]>    
date     : Wed, 24 Nov 2021 15:28:34 +1300    
  
committer: David Rowley <[email protected]>    
date     : Wed, 24 Nov 2021 15:28:34 +1300    

This reverts commit f94edb06ab60545a0e9e90aedc39e3b81b2b9e3f.  

commit   : f94edb06ab60545a0e9e90aedc39e3b81b2b9e3f    
  
author   : David Rowley <[email protected]>    
date     : Wed, 24 Nov 2021 14:57:07 +1300    
  
committer: David Rowley <[email protected]>    
date     : Wed, 24 Nov 2021 14:57:07 +1300    

It's possible that a subplan below a Memoize node contains a parameter  
from above the Memoize node.  If this parameter changes then cache entries  
may become out-dated due to the new parameter value.  
  
Previously Memoize was mistakenly not aware of this.  We fix this here by  
flushing the cache whenever a parameter that's not part of the cache  
key changes.  
  
Bug: #17213  
Reported by: Elvis Pranskevichus  
Author: David Rowley  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 14, where Memoize was added  

commit   : 6c32c0977783fae217b5eaa1d22d26c96e5b0085    
  
author   : David Rowley <[email protected]>    
date     : Wed, 24 Nov 2021 10:07:38 +1300    
  
committer: David Rowley <[email protected]>    
date     : Wed, 24 Nov 2021 10:07:38 +1300    

Memoize would always use the hash equality operator for the cache key  
types to determine if the current set of parameters were the same as some  
previously cached set.  Certain types such as floating points where -0.0  
and +0.0 differ in their binary representation but are classed as equal by  
the hash equality operator may cause problems as unless the join uses the  
same operator it's possible that whichever join operator is being used  
would be able to distinguish the two values.  In which case we may  
accidentally return in the incorrect rows out of the cache.  
  
To fix this here we add a binary mode to Memoize to allow it to the  
current set of parameters to previously cached values by comparing  
bit-by-bit rather than logically using the hash equality operator.  This  
binary mode is always used for LATERAL joins and it's used for normal  
joins when any of the join operators are not hashable.  
  
Reported-by: Tom Lane  
Author: David Rowley  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 14, where Memoize was added  

commit   : 0fdf67476ccbcc60bba185fd08a90b95cd91ce2d    
  
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   : 72842a5756857a1ce6e2b2bd7a162cdf1a279fa9    
  
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   : aedc4600d84dd1ebd9386e72ac78f329b8be4804    
  
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    

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  

commit   : e9af18c6c5512566c409c2ff99083fc1d89ff314    
  
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   : c985a43df379e044e0de43c41daa1ba0847de459    
  
author   : Alvaro Herrera <[email protected]>    
date     : Mon, 22 Nov 2021 12:38:41 -0300    
  
committer: Alvaro Herrera <[email protected]>    
date     : Mon, 22 Nov 2021 12:38:41 -0300    

Reported by Zhihong Yu.  
  
Discussion: https://postgr.es/m/CALNJ-vR6uZivg_XkB1zKjEXeyZDEgoYanFXB-++1kBT9yZQoUw@mail.gmail.com  

commit   : 3bd7556bbe0ade42552e3a094c3b0fd99039854e    
  
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   : 6d07cbc509d83d299552c4155b3511cf71c67276    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 20 Nov 2021 14:29:56 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 20 Nov 2021 14:29:56 -0500    

Commit ac9099fc1 rearranged the logic in spgGetCache() that determines  
the index's attType (nominal input data type) and leafType (actual  
type stored in leaf index tuples).  Turns out this broke things for  
the case where (a) the actual input data type is different from the  
nominal type, (b) the opclass's config function leaves leafType  
defaulted, and (c) the opclass has no "compress" function.  (b) caused  
us to assign the actual input data type as leafType, and then since  
that's not attType, we complained that a "compress" function is  
required.  For non-polymorphic opclasses, condition (a) arises in  
binary-compatible cases, such as using SP-GiST text_ops for a varchar  
column, or using any opclass on a domain over its nominal input type.  
  
To fix, use attType for leafType when the index's declared column type  
is different from but binary-compatible with attType.  Do this only in  
the defaulted-leafType case, to avoid overriding any explicit  
selection made by the opclass.  
  
Per bug #17294 from Ilya Anfimov.  Back-patch to v14.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : ead49ebc07a7eaae4d57008dd7fd1f3d71fa1ec4    
  
author   : Amit Kapila <[email protected]>    
date     : Fri, 19 Nov 2021 09:14:09 +0530    
  
committer: Amit Kapila <[email protected]>    
date     : Fri, 19 Nov 2021 09:14:09 +0530    

While determining xid horizons, we skip over backends that are running  
Vacuum. We also ignore Create Index Concurrently, or Reindex Concurrently  
for the purposes of computing Xmin for Vacuum. But we were not setting the  
flags corresponding to these operations when they are performed in  
parallel which was preventing Xid horizon from advancing.  
  
The optimization related to skipping Create Index Concurrently, or Reindex  
Concurrently operations was implemented in PG-14 but the fix is the same  
for the Parallel Vacuum as well so back-patched till PG-13.  
  
Author: Masahiko Sawada  
Reviewed-by: Amit Kapila  
Backpatch-through: 13  
Discussion: https://postgr.es/m/CAD21AoCLQqgM1sXh9BrDFq0uzd3RBFKi=Vfo6cjjKODm0Onr5w@mail.gmail.com  

commit   : ed1c261a00e51f7f216911df2278827ba8cc211f    
  
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   : 048f3ee618552790125a5412b5c8a4b48a36a480    
  
author   : Michael Paquier <[email protected]>    
date     : Thu, 18 Nov 2021 12:52:56 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Thu, 18 Nov 2021 12:52:56 +0900    

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  

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

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  

commit   : 53c4a580e4ab90295a0a3f0814089ac978901b3f    
  
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   : 6b413b41b45fe0412ee55b29f23ce31ce894fc90    
  
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    

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]  

commit   : 5d5779aeaf0780210de0e51dabeee8c9ceedb0ee    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 17 Nov 2021 11:31:31 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 17 Nov 2021 11:31:31 -0500    

If a SQL-standard function body contains an INSERT ... SELECT statement,  
any function parameters referenced within the SELECT were always printed  
in $N style, rather than using the parameter name if any.  While not  
strictly incorrect, this wasn't the intention, and it's inconsistent  
with the way that such parameters would be printed in any other kind  
of statement.  
  
The cause is that the recursion to get_query_def from  
get_insert_query_def neglected to pass down the context->namespaces  
list, passing constant NIL instead.  This is a very ancient oversight,  
but AFAICT it had no visible consequences before commit e717a9a18  
added an outermost namespace with function parameters.  We don't allow  
INSERT ... SELECT as a sub-query, except in a top-level WITH clause,  
where it couldn't contain any outer references that might need to access  
upper namespaces.  So although that's arguably a bug, I don't see any  
point in changing it before v14.  
  
In passing, harden the code added to get_parameter by e717a9a18 so that  
it won't crash if a PARAM_EXTERN Param appears in an unexpected place.  
  
Per report from Erki Eessaar.  Code fix by me, regression test case  
by Masahiko Sawada.  
  
Discussion: https://postgr.es/m/AM9PR01MB8268347BED344848555167FAFE949@AM9PR01MB8268.eurprd01.prod.exchangelabs.com  

commit   : 51d4213689ff30af6db4b7ecb410358dd5c35491    
  
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   : 232fd72a5eab3ab429497796bce6e7da9e67ca3f    
  
author   : Amit Kapila <[email protected]>    
date     : Tue, 16 Nov 2021 08:34:24 +0530    
  
committer: Amit Kapila <[email protected]>    
date     : Tue, 16 Nov 2021 08:34:24 +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   : 99389cb66bb743ef6b94edc77034bdd9bf5e9928    
  
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   : 5f81a480d537956efc0b9bf2eee7d651a03c596a    
  
author   : Michael Paquier <[email protected]>    
date     : Fri, 12 Nov 2021 21:50:04 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Fri, 12 Nov 2021 21:50:04 +0900    

pg_stat_get_slru() in pgstatfuncs.c would point to one element after the  
end of the array PgStat_SLRUStats when finishing to scan its entries.  
This had no direct consequences as no data from the extra memory area  
was read, but static analyzers would rightfully complain here.  So let's  
be clean.  
  
While on it, this adds one regression test in the area reserved for  
system views.  
  
Reported-by: Alexander Kozhemyakin, via AddressSanitizer  
Author: Kyotaro Horiguchi  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 13  

commit   : 675cd765c2a5d5f2f020a5bf647086c178612abf    
  
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   : 9aa91cb33b70c5bc207e1a136d60f742acd67c32    
  
author   : Alvaro Herrera <[email protected]>    
date     : Thu, 11 Nov 2021 11:03:29 -0300    
  
committer: Alvaro Herrera <[email protected]>    
date     : Thu, 11 Nov 2021 11:03:29 -0300    

Commit 27838981be9d mistakenly reduced the lock level from exclusive to  
shared that is acquired to set PGPROC->statusFlags; this was reverted  
by dcfff74fb166, but failed to do so in one spot.  Fix it.  
  
Backpatch to 14.  
  
Noted by Andres Freund.  
  
Discussion: https://postgr.es/m/[email protected]