PostgreSQL 13.6 commit log

commit   : d7db9572070a627bae9919fd1b4e16c8208d4fca    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 7 Feb 2022 16:17:41 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 7 Feb 2022 16:17:41 -0500    

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

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

commit   : 763c7aac575101cb4d3b3a37bb9811a66ef052c8    
  
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   : 7d74ff82431ba8836f92ac33ed3f1ab276f51a92    
  
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   : 9c7cf083f26e183e200395b3514061bb9d71cc7e    
  
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   : 58e9d28091e76bfd4a2670bc9ca8ba44d958e57d    
  
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   : 31c9712610c7eec1b2f376fd3bbf5839e4234d64    
  
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   : 4d7d196ff69365041579024848f34ee57ac75223    
  
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   : ff86ee3d2175d0e53e114bdb24137f5dc2dbb73b    
  
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   : bc89af248e04fc07c1c15eb2d3c743a22691c667    
  
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   : 4afb5aeb9f1285bd3ff2b370671c7ad5a91445c9    
  
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   : 0dc0fe7b6c4583955f643c3ba7ea625767f300bb    
  
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   : 5ad70564f46a5fc782191eb8010d90aaca9a762e    
  
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   : e90f258acaf2d78afc20842e7b63f0734c412bae    
  
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   : 785a28e422ea3fecbd38a3a49b488dc168ac3fb3    
  
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   : 81596645ca2ba382918fca9e82aa3089db737e14    
  
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   : 213c5aa3bdba5783529d3c0f103dbfadf4f93f50    
  
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   : f8807e7742e5ce058b6fe05d797852e082e6d2c8    
  
author   : David Rowley <[email protected]>    
date     : Tue, 25 Jan 2022 21:15:00 +1300    
  
committer: David Rowley <[email protected]>    
date     : Tue, 25 Jan 2022 21:15:00 +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   : 35893cc96856ae191fbe5c639a542117c0479880    
  
author   : Michael Paquier <[email protected]>    
date     : Tue, 25 Jan 2022 10:49:41 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Tue, 25 Jan 2022 10:49:41 +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   : d67354d870bbddbde551e5b9804a42fb78af527e    
  
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   : c94c6612da573d2789855b77a47da45a4a19cfbd    
  
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   : 0cbc50737864177a29430be41e5b134a29e77554    
  
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   : 4d8c4d2061f90db009ec834308e260fb5ca1e885    
  
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   : 267ccc38ba6a95889d98959f183de64ceff23087    
  
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   : 31b7b4d26e10086d4a79d49a28fd161da52da49a    
  
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   : 64ebb43df068e3a9c01beeaacf7842080c43e712    
  
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   : fd48e5f5d3a14dda804e7b74e16dac6f5ab1b781    
  
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   : b5f634116e8f3e264cc06c053bd7b4e25a615665    
  
author   : Michael Paquier <[email protected]>    
date     : Fri, 21 Jan 2022 14:54:51 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Fri, 21 Jan 2022 14:54:51 +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   : 4828a80069abc3e4b5baffe3ebffb69e6dd5bc10    
  
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   : 31680730ef7bac82ff09efa0824c2d8e5e8840f1    
  
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   : 8e8e253a7b90d89dd9cb9d33848b55ac79958351    
  
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   : 3ca40a2b18a0638994e35160dfc8d392b1aef898    
  
author   : Michael Paquier <[email protected]>    
date     : Thu, 20 Jan 2022 16:54:58 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Thu, 20 Jan 2022 16:54:58 +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   : 6eec809fbcfbd8e0ab5e1c6485c7f53020f0d0b0    
  
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   : 3204b8a7affc7277ae4eebc3f53c566f859d1815    
  
author   : Michael Paquier <[email protected]>    
date     : Wed, 19 Jan 2022 10:37:53 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Wed, 19 Jan 2022 10:37:53 +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   : 639a9293d4cbf6bdfcc641f335e2c5a2359cce75    
  
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   : 90e0f9fd8cae7cfb09c11534f690edde6d6ee06c    
  
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   : d18ec312f9f36c220aa1a1497d3173729c862d66    
  
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   : f27af7b880de97cccd24e37a62692f294bba5bba    
  
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   : 90a847e6dcc8fcf8d6f0eaf7b8022153d3b0f184    
  
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   : d6817032d26becd3c49f11d16efd6012e2139fc4    
  
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   : acfde7c5837dd3c2a40ff9cc639ba5d914e8e8ea    
  
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   : ca14c4184b55cbe2fa79c87174b8064fc5f90874    
  
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   : 2180833ba90e9657a7e622b419194763890c8a6d    
  
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   : 32cd4264ccfc00234c6500913800983ca1073729    
  
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   : 823d4c7e25383cb4056c21615130b2abde17efba    
  
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   : 410567177cd418569f1acac5e8073a1c407943ee    
  
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   : f3ded9c4600c000cdd7e0eb307bdfccd39a0e90e    
  
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   : 86d4bbb56a8aa94e8926067a5bf86a5a74b8c933    
  
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   : 1105efdc1bba91a60551feae0342ba5973fa69ba    
  
author   : Michael Paquier <[email protected]>    
date     : Thu, 6 Jan 2022 11:41:44 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Thu, 6 Jan 2022 11:41:44 +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   : 3f8062bcf7f9fdc5b0f9dac41cbe62204969ebd1    
  
author   : Michael Paquier <[email protected]>    
date     : Wed, 5 Jan 2022 10:27:53 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Wed, 5 Jan 2022 10:27:53 +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   : 33fdd9f854f8db263d96e2916aa67325b8b26992    
  
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   : 29f9fb8fe87005b2a75bd8ad2bc3d1f3ac0e9561    
  
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   : 20d08b2c61cd7f224739a52fb069e93abe5d448d    
  
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   : 6c8110854168eb3799ccaaddb720678d0de6b0ee    
  
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   : 45ae4271410bfba0daba8e71eeb631c6f91088bb    
  
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   : cadd98cd3088b02581585cc5b1f11d38349a2128    
  
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   : e4f7c5144533c6ee9a84e1b1a30cedb20a3ebc75    
  
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   : 28e1e5c2a91ccc2ad8f2749f36f0ac8eb3bca759    
  
author   : Michael Paquier <[email protected]>    
date     : Wed, 22 Dec 2021 16:38:42 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Wed, 22 Dec 2021 16:38:42 +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   : da0d8a4545e639ca9c22dc2a0a10dcddcdf58761    
  
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   : aadbf825b7c41e241d27dc4d8ed7d77fc4718634    
  
author   : Michael Paquier <[email protected]>    
date     : Wed, 15 Dec 2021 10:40:12 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Wed, 15 Dec 2021 10:40:12 +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   : 0a5682041dbf991bd325a7d14daf39ecfc9bd624    
  
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   : 3f710fc2b48d6326958260f10bd139a1e87fcf53    
  
author   : Michael Paquier <[email protected]>    
date     : Tue, 14 Dec 2021 10:58:29 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Tue, 14 Dec 2021 10:58:29 +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   : e459dcfde80402ab55e2fe84c5be4483ce34fce1    
  
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   : 65f860e78a04f4f035dcec04c5c796793113dfba    
  
author   : Andres Freund <[email protected]>    
date     : Mon, 13 Dec 2021 12:02:45 -0800    
  
committer: Andres Freund <[email protected]>    
date     : Mon, 13 Dec 2021 12:02:45 -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   : 3f06c00cf6dcd838b61c5d452d4908b5b6e17762    
  
author   : Amit Kapila <[email protected]>    
date     : Thu, 9 Dec 2021 09:00:35 +0530    
  
committer: Amit Kapila <[email protected]>    
date     : Thu, 9 Dec 2021 09:00:35 +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   : a96a1d656274d3e1ca7cd4c34b7ba79a2754b71d    
  
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   : 9acea52ea3d48627f12b9a2b4498197d3b05fe2e    
  
author   : Michael Paquier <[email protected]>    
date     : Wed, 8 Dec 2021 11:01:19 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Wed, 8 Dec 2021 11:01:19 +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   : 14c54e40f59a741afafa84015681f13ba083eed6    
  
author   : Andrew Dunstan <[email protected]>    
date     : Tue, 7 Dec 2021 15:05:33 -0500    
  
committer: Andrew Dunstan <[email protected]>    
date     : Tue, 7 Dec 2021 15:05:33 -0500    

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

commit   : a8a983e8299ae7e63b18b3965ca1f55e18f84a06    
  
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   : e2ebc90eb8090def69b2d3aa86f6caf3a8026f6b    
  
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   : f89015b63f532063560ef78bc1d0d8c166173c6d    
  
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   : 6251f86241acd05facefc4b4caacc9430b059d58    
  
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   : fae5f08e17193a8e0c8ca941e0bed4c4d105df14    
  
author   : Michael Paquier <[email protected]>    
date     : Thu, 2 Dec 2021 10:31:34 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Thu, 2 Dec 2021 10:31:34 +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   : 7413caabe66e02b8967825a2dc1041e9db246622    
  
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   : 64e8456bbde159f29aaa528d311e41590a3dbec5    
  
author   : Amit Kapila <[email protected]>    
date     : Wed, 1 Dec 2021 10:26:59 +0530    
  
committer: Amit Kapila <[email protected]>    
date     : Wed, 1 Dec 2021 10:26:59 +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   : a7359913a1c22e8c04f37140b9d983919baf10b2    
  
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   : f76fd05bae047103cb36ef5fb82137c8995142c1    
  
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   : 899a4b25ad6b45c3f7fbdbc177211b7279dba56a    
  
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   : ef41c3fd6c86d6fa504144996b339704347322c9    
  
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   : 04875ae92f14c0b23438e5316d92f82518bb068a    
  
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   : 37827de430deba44f373db1e4efae0c9e320ef2d    
  
author   : Michael Paquier <[email protected]>    
date     : Thu, 25 Nov 2021 15:05:28 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Thu, 25 Nov 2021 15:05:28 +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   : 499552273d47645c759d58c5916b3bc8ecc7f13d    
  
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   : 892da5200aaf31f950021b4bf92916ad35113f2e    
  
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   : baef657d3c846a43932e6c8c467afd69472f273e    
  
author   : Michael Paquier <[email protected]>    
date     : Wed, 24 Nov 2021 13:03:59 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Wed, 24 Nov 2021 13:03:59 +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   : d4f6a36d8265b06d50ec3d55c928fb1d92cb0586    
  
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   : b542e4596e339b8a6ca94723f35ccc1667dbc306    
  
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   : 6fc8b145e74303bfba6bd21fd7c33d343ee37d44    
  
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   : ec383ca2df0a6f77a9b49dcd8853e76e6b328d37    
  
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   : 33edf4a3ca4c1fdb7665ea3a4d01bb5fc7477117    
  
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   : 33b6dd83e26f06c96e7d54af534a70476749cbab    
  
author   : Amit Kapila <[email protected]>    
date     : Fri, 19 Nov 2021 09:24:00 +0530    
  
committer: Amit Kapila <[email protected]>    
date     : Fri, 19 Nov 2021 09:24:00 +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   : 77c8892a1989d91d8f1c9eb988b3c27ddad0ea07    
  
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   : 49f2b1168a8f4ad29b6c1cf9e448ace5e3c8f901    
  
author   : Michael Paquier <[email protected]>    
date     : Thu, 18 Nov 2021 12:53:02 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Thu, 18 Nov 2021 12:53:02 +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   : 755f04c72ef1bac5e34ab698aaf9d3a303ac5197    
  
author   : Michael Paquier <[email protected]>    
date     : Thu, 18 Nov 2021 10:37:39 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Thu, 18 Nov 2021 10:37:39 +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   : c8b5221b57677231511039e943150a74353ed44d    
  
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   : bbda88c3383dd8da07f36f06d34cb876bc4982e7    
  
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   : df9e65b854647aa12607baa6ed8071b02f481a8c    
  
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   : 63c3eeddc2db1b939e7f4fa8ad8ad0f3757232b1    
  
author   : Amit Kapila <[email protected]>    
date     : Tue, 16 Nov 2021 08:46:12 +0530    
  
committer: Amit Kapila <[email protected]>    
date     : Tue, 16 Nov 2021 08:46:12 +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   : 843925fadbd8d450d00229647b1d6933a4aae5e8    
  
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   : a691a229831ad3b72d933b1858c76be44b508400    
  
author   : Michael Paquier <[email protected]>    
date     : Fri, 12 Nov 2021 21:50:08 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Fri, 12 Nov 2021 21:50:08 +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   : d4e9d6946995cceaed97ee4570c4c867b3ea2104    
  
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   : 13c8adf90e9d9bc58209ab820775949336d901f7    
  
author   : Michael Paquier <[email protected]>    
date     : Thu, 11 Nov 2021 15:01:54 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Thu, 11 Nov 2021 15:01:54 +0900    

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

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

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

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

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

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

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