PostgreSQL 13.0 (upcoming) commit log

commit   : fae5f08e17193a8e0c8ca941e0bed4c4d105df14    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 2 Dec 2021 10:31:34 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
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/20201206180248.GI24052@telsasoft.com  
Backpatch-through: 10  

commit   : 7413caabe66e02b8967825a2dc1041e9db246622    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 1 Dec 2021 13:44:47 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
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 <akapila@postgresql.org>    
date     : Wed, 1 Dec 2021 10:26:59 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
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 <tgl@sss.pgh.pa.us>    
date     : Mon, 29 Nov 2021 12:13:13 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
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 <alvherre@alvh.no-ip.org>    
date     : Fri, 26 Nov 2021 17:00:29 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
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/202111161709.u3pbx5lxdimt@alvherre.pgsql  

commit   : 899a4b25ad6b45c3f7fbdbc177211b7279dba56a    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 26 Nov 2021 14:31:57 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
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 <horikyota.ntt@gmail.com>  
Reported by: b1000101@pm.me  
Discussion: https://postgr.es/m/163760291192.26193.10801700492025355788@wrigleys.postgresql.org  

commit   : ef41c3fd6c86d6fa504144996b339704347322c9    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 26 Nov 2021 11:14:27 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
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/45597.1637694259@sss.pgh.pa.us  

commit   : 04875ae92f14c0b23438e5316d92f82518bb068a    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 25 Nov 2021 14:19:22 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
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 <tgl@sss.pgh.pa.us>  
Discussion: https://www.postgresql.org/message-id/flat/84884.1637723223%40sss.pgh.pa.us  

commit   : 37827de430deba44f373db1e4efae0c9e320ef2d    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 25 Nov 2021 15:05:28 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
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 <tgl@sss.pgh.pa.us>    
date     : Wed, 24 Nov 2021 13:37:12 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
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 <heikki.linnakangas@iki.fi>    
date     : Wed, 24 Nov 2021 18:32:56 +0200    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
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 <michael@paquier.xyz>    
date     : Wed, 24 Nov 2021 13:03:59 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
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/1633101364685.39218@nidsa.net  
Backpatch-through: 10  

commit   : d4f6a36d8265b06d50ec3d55c928fb1d92cb0586    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 22 Nov 2021 17:16:29 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
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 <tgl@sss.pgh.pa.us>    
date     : Mon, 22 Nov 2021 15:57:31 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 22 Nov 2021 15:57:31 -0500    

Per buildfarm.  

commit   : 6fc8b145e74303bfba6bd21fd7c33d343ee37d44    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 22 Nov 2021 15:25:48 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
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 <tgl@sss.pgh.pa.us>    
date     : Mon, 22 Nov 2021 12:54:52 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
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/E1moZHS-0002Cu-Ei@gemulon.postgresql.org  

commit   : 33edf4a3ca4c1fdb7665ea3a4d01bb5fc7477117    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 21 Nov 2021 14:13:35 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
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/747443.1635536754@sss.pgh.pa.us  

commit   : 33b6dd83e26f06c96e7d54af534a70476749cbab    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Fri, 19 Nov 2021 09:24:00 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
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 <tgl@sss.pgh.pa.us>    
date     : Thu, 18 Nov 2021 14:50:13 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
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/2921539.1637254619@sss.pgh.pa.us  

commit   : 49f2b1168a8f4ad29b6c1cf9e448ace5e3c8f901    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 18 Nov 2021 12:53:02 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
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/YZW4MvzCZ+hQ34vw@paquier.xyz  
Backpatch-through: 12  

commit   : 755f04c72ef1bac5e34ab698aaf9d3a303ac5197    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 18 Nov 2021 10:37:39 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
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/20201206180248.GI24052@telsasoft.com  
Backpatch-through: 12  

commit   : c8b5221b57677231511039e943150a74353ed44d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 17 Nov 2021 14:16:34 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
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/1343113.1636489231@sss.pgh.pa.us  

commit   : bbda88c3383dd8da07f36f06d34cb876bc4982e7    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 17 Nov 2021 13:08:25 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
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/1343113.1636489231@sss.pgh.pa.us  

commit   : df9e65b854647aa12607baa6ed8071b02f481a8c    
  
author   : Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Wed, 17 Nov 2021 13:34:41 +0100    
  
committer: Daniel Gustafsson <dgustafsson@postgresql.org>    
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 <smithpb2250@gmail.com>  
Reviewed-by: Masahiko Sawada <sawada.mshk@gmail.com>  
Discussion: https://postgr.es/m/CAHut+PvGWd3-Ktn96c-z6uq-8TGVVP=TPOkEovkEfntoo2mRhw@mail.gmail.com  
Backpatch-through: 10  

commit   : 63c3eeddc2db1b939e7f4fa8ad8ad0f3757232b1    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Tue, 16 Nov 2021 08:46:12 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
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 <tgl@sss.pgh.pa.us>    
date     : Fri, 12 Nov 2021 14:55:32 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
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/747443.1635536754@sss.pgh.pa.us  

commit   : a691a229831ad3b72d933b1858c76be44b508400    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 12 Nov 2021 21:50:08 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
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/17280-37da556e86032070@postgresql.org  
Backpatch-through: 13  

commit   : d4e9d6946995cceaed97ee4570c4c867b3ea2104    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Thu, 11 Nov 2021 17:10:18 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
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/20211107013157.GB790288@rfd.leadboat.com  

commit   : 13c8adf90e9d9bc58209ab820775949336d901f7    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 11 Nov 2021 15:01:54 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
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/17277-0c527a373794e802@postgresql.org  
Backpatch-through: 10  

commit   : aa449e5caed8b3745ec86d358bbfdaaacf8dbfbe    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 11 Nov 2021 10:51:12 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
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/R3Gw+Sbg@paquier.xyz  
Backpatch-through: 10  

commit   : 78f058411b02a54e4fde43744e35089d0ab57683    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 10 Nov 2021 13:12:58 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
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 <tgl@sss.pgh.pa.us>    
date     : Tue, 9 Nov 2021 18:40:19 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
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/1372189.1636499287@sss.pgh.pa.us  

commit   : 084346ccee8ead6b387a90cdf6a29036ae9ec77e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 8 Nov 2021 17:00:24 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 8 Nov 2021 17:00:24 -0500    

commit   : 402c3ba3954d81531b6c9ff9b5d554552a85c6a7    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 8 Nov 2021 14:02:16 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 8 Nov 2021 14:02:16 -0500    

Security: CVE-2021-23214, CVE-2021-23222  

commit   : 844b3169204c28cd086c1b4fae4a2cbdd0540640    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 8 Nov 2021 11:14:56 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 8 Nov 2021 11:14:56 -0500    

libpq collects up to a bufferload of data whenever it reads data from  
the socket.  When SSL or GSS encryption is requested during startup,  
any additional data received with the server's yes-or-no reply  
remained in the buffer, and would be treated as already-decrypted data  
once the encryption handshake completed.  Thus, a man-in-the-middle  
with the ability to inject data into the TCP connection could stuff  
some cleartext data into the start of a supposedly encryption-protected  
database session.  
  
This could probably be abused to inject faked responses to the  
client's first few queries, although other details of libpq's behavior  
make that harder than it sounds.  A different line of attack is to  
exfiltrate the client's password, or other sensitive data that might  
be sent early in the session.  That has been shown to be possible with  
a server vulnerable to CVE-2021-23214.  
  
To fix, throw a protocol-violation error if the internal buffer  
is not empty after the encryption handshake.  
  
Our thanks to Jacob Champion for reporting this problem.  
  
Security: CVE-2021-23222  

commit   : e92ed93e8eb76ee0701b42d4f0ce94e6af3fc741    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 8 Nov 2021 11:01:43 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 8 Nov 2021 11:01:43 -0500    

The server collects up to a bufferload of data whenever it reads data  
from the client socket.  When SSL or GSS encryption is requested  
during startup, any additional data received with the initial  
request message remained in the buffer, and would be treated as  
already-decrypted data once the encryption handshake completed.  
Thus, a man-in-the-middle with the ability to inject data into the  
TCP connection could stuff some cleartext data into the start of  
a supposedly encryption-protected database session.  
  
This could be abused to send faked SQL commands to the server,  
although that would only work if the server did not demand any  
authentication data.  (However, a server relying on SSL certificate  
authentication might well not do so.)  
  
To fix, throw a protocol-violation error if the internal buffer  
is not empty after the encryption handshake.  
  
Our thanks to Jacob Champion for reporting this problem.  
  
Security: CVE-2021-23214  

commit   : 7c0a78f089980cec45927aa3160add1781aed402    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 8 Nov 2021 09:17:24 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 8 Nov 2021 09:17:24 -0300    

Introduced in 1d97d3d0867f.  
  
Co-authored-by: Alexander Lakhin <exclusion@gmail.com>  
Discussion: https://postgr.es/m/83641f59-d566-b33e-ef21-a272a98675aa@gmail.com  

commit   : 98da5cd0d1b1c47a19f8453413c0fd01c07b3830    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 8 Nov 2021 10:08:56 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 8 Nov 2021 10:08:56 +0100    

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

commit   : 5d73415d20086406f083eb0929626036e10797a1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 7 Nov 2021 14:21:50 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 7 Nov 2021 14:21:50 -0500    

commit   : e1fee28a0441652f021045646808a772314798f9    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Sat, 6 Nov 2021 18:31:21 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Sat, 6 Nov 2021 18:31:21 +0300    

Currently, lastOverflowedXid is never reset.  It's just adjusted on new  
transactions known to be overflowed.  But if there are no overflowed  
transactions for a long time, snapshots could be mistakenly marked as  
suboverflowed due to wraparound.  
  
This commit fixes this issue by resetting lastOverflowedXid when needed  
altogether with KnownAssignedXids.  
  
Backpatch to all supported versions.  
  
Reported-by: Stan Hu  
Discussion: https://postgr.es/m/CAMBWrQ%3DFp5UAsU_nATY7EMY7NHczG4-DTDU%3DmCvBQZAQ6wa2xQ%40mail.gmail.com  
Author: Kyotaro Horiguchi, Alexander Korotkov  
Reviewed-by: Stan Hu, Simon Riggs, Nikolay Samokhvalov, Andrey Borodin, Dmitry Dolgov  

commit   : bf5cdcfd5e444756378e60307a89b8cad16f65c0    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 5 Nov 2021 12:29:34 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 5 Nov 2021 12:29:34 -0300    

When a role being dropped contains is referenced by catalog objects that  
are concurrently also being dropped, a crash can result while trying to  
construct the string that describes the objects.  Suppress that by  
ignoring objects whose descriptions are returned as NULL.  
  
The majority of relevant codesites were already cautious about this  
already; we had just missed a couple.  
  
This is an old bug, so backpatch all the way back.  
  
Reported-by: Alexander Lakhin <exclusion@gmail.com>  
Discussion: https://postgr.es/m/17126-21887f04508cb5c8@postgresql.org  

commit   : b7299b66469fe90c5cbb19c1d02d8e91fc95e4f2    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 3 Nov 2021 19:38:17 +0200    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 3 Nov 2021 19:38:17 +0200    

Previous commit added a test to 'largeobject', but neglected the  
alternative expected output file 'largeobject_1.source'. Per failure  
on buildfarm animal 'hamerkop'.  
  
Discussion: https://www.postgresql.org/message-id/DBA08346-9962-4706-92D1-230EE5201C10@yesql.se  

commit   : 07070c0082aacc9e9bf09d1d08bc3a60c999332e    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 3 Nov 2021 10:28:52 +0200    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 3 Nov 2021 10:28:52 +0200    

If lo_export() fails to open the target file or to write to it, it leaks  
the created LargeObjectDesc and its snapshot in the top-transaction  
context and resource owner. That's pretty harmless, it's a small leak  
after all, but it gives the user a "Snapshot reference leak" warning.  
  
Fix by using a short-lived memory context and no resource owner for  
transient LargeObjectDescs that are opened and closed within one function  
call. The leak is easiest to reproduce with lo_export() on a directory  
that doesn't exist, but in principle the other lo_* functions could also  
fail.  
  
Backpatch to all supported versions.  
  
Reported-by: Andrew B  
Reviewed-by: Alvaro Herrera  
Discussion: https://www.postgresql.org/message-id/32bf767a-2d65-71c4-f170-122f416bab7e@iki.fi  

commit   : ada667b45496998674818e135e9cd6580f1bc019    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 2 Nov 2021 13:36:47 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 2 Nov 2021 13:36:47 -0400    

This undoes a mistake in 1ec7679f1: domainval and domainnull were  
meant to live across loop iterations, but they were incorrectly  
moved inside the loop.  The effect was only to emit useless extra  
EEOP_MAKE_READONLY steps, so it's not a big deal; nonetheless,  
back-patch to v13 where the mistake was introduced.  
  
Ranier Vilela  
  
Discussion: https://postgr.es/m/CAEudQAqXuhbkaAp-sGH6dR6Nsq7v28_0TPexHOm6FiDYqwQD-w@mail.gmail.com  

commit   : 0151af40cd4e0321bc549cea9f0c631bce0303c5    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 2 Nov 2021 11:31:54 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 2 Nov 2021 11:31:54 -0400    

As in commits 6301c3ada and e9d9ba2a4, avoid doing repetitive  
list_delete_first() operations, since that would be expensive when  
there are many files waiting to be unlinked.  This is a slightly  
larger change than in those cases.  We have to keep the list state  
valid for calls to AbsorbSyncRequests(), so it's necessary to invent a  
"canceled" field instead of immediately deleting PendingUnlinkEntry  
entries.  Also, because we might not be able to process all the  
entries, we need a new list primitive list_delete_first_n().  
  
list_delete_first_n() is almost list_copy_tail(), but it modifies the  
input List instead of making a new copy.  I found a couple of existing  
uses of the latter that could profitably use the new function.  (There  
might be more, but the other callers look like they probably shouldn't  
overwrite the input List.)  
  
As before, back-patch to v13.  
  
Discussion: https://postgr.es/m/CD2F0E7F-9822-45EC-A411-AE56F14DEA9F@amazon.com  

commit   : e477642a1ba8041c94cae2f8bbdb689f05cb0260    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 1 Nov 2021 16:24:40 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 1 Nov 2021 16:24:40 -0400    

In the same spirit as 6301c3ada, fix some more places where we were  
using list_delete_first() in a loop and thereby risking O(N^2)  
behavior.  It's not clear that the lists manipulated in these spots  
can get long enough to be really problematic ... but it's not clear  
that they can't, either, and the fixes are simple enough.  
  
As before, back-patch to v13.  
  
Discussion: https://postgr.es/m/CD2F0E7F-9822-45EC-A411-AE56F14DEA9F@amazon.com  

commit   : 17227825ca4288c70af45038ac6af26be7fde570    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 1 Nov 2021 13:07:23 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 1 Nov 2021 13:07:23 -0300    

Failing to do so results in inability of logical decoding to process the  
WAL stream.  Handle it by doing nothing.  
  
Backpatch all the way back.  
  
Reported-by: Petr Jelínek <petr.jelinek@enterprisedb.com>  

commit   : 77f7909a409eac9ee9a5728a4f80741925580fb6    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 1 Nov 2021 11:40:29 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 1 Nov 2021 11:40:29 +0900    

The opclass parameter Datums from the old index are fetched in the same  
way as for predicates and expressions, by grabbing them directly from  
the system catalogs.  They are then copied into the new IndexInfo that  
will be used for the creation of the new copy.  
  
This caused the new index to be rebuilt with default parameters rather  
than the ones pre-defined by a user.  The only way to get back a new  
index with correct opclass parameters would be to recreate a new index  
from scratch.  
  
The issue has been introduced by 911e702.  
  
Author: Michael Paquier  
Reviewed-by: Zhihong Yu  
Discussion: https://postgr.es/m/YX0CG/QpLXcPr8HJ@paquier.xyz  
Backpatch-through: 13  

commit   : 3a5b313ce74864303a8a5d6556b49d642c422922    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 31 Oct 2021 19:13:48 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 31 Oct 2021 19:13:48 -0400    

Windows fails on a request to read() more than INT_MAX bytes,  
and perhaps other platforms could have similar issues.  Let's  
adjust this code to read at most 1GB per call.  
  
(One would not have thought the file could get that big, but now  
we have a field report of trouble, so it can.  We likely ought to  
add some mechanism to limit the size of the query-texts file  
separately from the size of the hash table.  That is not this  
patch, though.)  
  
Per bug #17254 from Yusuke Egashira.  It's been like this for  
awhile, so back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/17254-a926c89dc03375c2@postgresql.org  

commit   : df238aed1090249a2bcd21e1688a398c6f513dfd    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 31 Oct 2021 15:31:29 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 31 Oct 2021 15:31:29 -0400    

When replaying a transaction that held many exclusive locks on the  
primary, a standby server's startup process would expend O(N^2)  
effort on manipulating the list of locks.  This code was fine when  
written, but commit 1cff1b95a made repetitive list_delete_first()  
calls inefficient, as explained in its commit message.  Fix by just  
iterating the list normally, and releasing storage only when done.  
(This'd be inadequate if we needed to recover from an error occurring  
partway through; but we don't.)  
  
Back-patch to v13 where 1cff1b95a came in.  
  
Nathan Bossart  
  
Discussion: https://postgr.es/m/CD2F0E7F-9822-45EC-A411-AE56F14DEA9F@amazon.com  

commit   : 4cd72add0579d33e741cb1a2effe6ee727a994dd    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 29 Oct 2021 11:38:18 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 29 Oct 2021 11:38:18 -0400    

DST law changes in Fiji, Jordan, Palestine, and Samoa.  Historical  
corrections for Barbados, Cook Islands, Guyana, Niue, Portugal, and  
Tonga.  
  
Also, the Pacific/Enderbury zone has been renamed to Pacific/Kanton.  
The following zones have been merged into nearby, more-populous zones  
whose clocks have agreed since 1970: Africa/Accra, America/Atikokan,  
America/Blanc-Sablon, America/Creston, America/Curacao,  
America/Nassau, America/Port_of_Spain, Antarctica/DumontDUrville,  
and Antarctica/Syowa.  

commit   : 5a4b8a8a720ca699c5cbcfc04069dfe089f218c8    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 28 Oct 2021 11:45:14 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 28 Oct 2021 11:45:14 -0400    

Commits fdd965d07 and 3cd9c3b92 tested CREATE INDEX CONCURRENTLY by  
launching two separate pgbench runs concurrently.  This was needed so  
that only a single client thread would run CREATE INDEX CONCURRENTLY,  
avoiding deadlock between two CICs.  However, there's a better way,  
which is to use an advisory lock to prevent concurrent CICs.  That's  
better in part because the test code is shorter and more readable, but  
mostly because it automatically scales things to launch an appropriate  
number of CICs relative to the number of INSERT transactions.  
As committed, typically half to three-quarters of the CIC transactions  
were pointless because the INSERT transactions had already stopped.  
  
In passing, remove background_pgbench, which was added to support  
these tests and isn't needed anymore.  We can always put it back  
if we find a use for it later.  
  
Back-patch to v12; older pgbench versions lack the  
conditional-execution features needed for this method.  
  
Tom Lane and Andrey Borodin  
  
Discussion: https://postgr.es/m/139687.1635277318@sss.pgh.pa.us  

commit   : 0a75e1186afe58e140cc5eb0f6f0c13f5b7d8c3b    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 28 Oct 2021 09:26:18 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 28 Oct 2021 09:26:18 +0900    

Reported-by: Anton Voloshin  
Discussion: https://postgr.es/m/15a86d4e-a237-1acd-18a2-fd69730f1ab9@postgrespro.ru  
Backpatch-through: 10  

commit   : d5a2ffbce534e4fe9d207da14c9b7cf7a00a7953    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Wed, 27 Oct 2021 13:09:00 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Wed, 27 Oct 2021 13:09:00 -0700    

Oversight in commit a5213adf.  
  
Backpatch: 13-, just like commit a5213adf.  

commit   : f8cce4a3d88ccce830086bc80b563bd152f4955f    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Wed, 27 Oct 2021 12:10:43 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Wed, 27 Oct 2021 12:10:43 -0700    

Add more defensive checks around posting list split code.  These should  
detect corruption involving duplicate table TIDs earlier and more  
reliably than any existing check.  
  
Follow up to commit 8f72bbac.  
  
Discussion: https://postgr.es/m/CAH2-WzkrSY_kjyd1_M5xJK1uM0govJXMxPn8JUSvwcUOiHuWVw@mail.gmail.com  
Backpatch: 13-, where nbtree deduplication was introduced.  

commit   : dd111887fbaead778d1077dfbc92b520a5188b51    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Wed, 27 Oct 2021 16:20:02 +0200    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Wed, 27 Oct 2021 16:20:02 +0200    

Make this more clear both in the help message and docs.  
  
Reviewed-By: Michael Paquier  
Backpatch-through: 9.6  
Discussion: https://postgr.es/m/CABUevEw6Je0WUFTLhPKOk4+BoBuDrE-fKw3N4ckqgDBMFu4paA@mail.gmail.com  

commit   : 24b7cf8a5cff0b0e2dba12a3a1f5c7638ace9986    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Tue, 26 Oct 2021 12:54:55 +1300    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Tue, 26 Oct 2021 12:54:55 +1300    

It doesn't work (it could, but hasn't been implemented).  
Back-patch to 12, where shared_memory_type arrived.  
  
Reported-by: Alexander Lakhin <exclusion@gmail.com>  
Reviewed-by: Alexander Lakhin <exclusion@gmail.com>  
Discussion: https://postgr.es/m/163271880203.22789.1125998876173795966@wrigleys.postgresql.org  

commit   : a9d0a54094153d8714a66444e89e565bb3eb21e4    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sat, 23 Oct 2021 18:36:38 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sat, 23 Oct 2021 18:36:38 -0700    

The purpose of commit 8a54e12a38d1545d249f1402f66c8cde2837d97c was to  
fix this, and it sufficed when the PREPARE TRANSACTION completed before  
the CIC looked for lock conflicts.  Otherwise, things still broke.  As  
before, in a cluster having used CIC while having enabled prepared  
transactions, queries that use the resulting index can silently fail to  
find rows.  It may be necessary to reindex to recover from past  
occurrences; REINDEX CONCURRENTLY suffices.  Fix this for future index  
builds by making CIC wait for arbitrarily-recent prepared transactions  
and for ordinary transactions that may yet PREPARE TRANSACTION.  As part  
of that, have PREPARE TRANSACTION transfer locks to its dummy PGPROC  
before it calls ProcArrayClearTransaction().  Back-patch to 9.6 (all  
supported versions).  
  
Andrey Borodin, reviewed (in earlier versions) by Andres Freund.  
  
Discussion: https://postgr.es/m/01824242-AA92-4FE9-9BA7-AEBAFFEA3D0C@yandex-team.ru  

commit   : 2e33b43599ad3868ee180f149050444bf0a7ca15    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sat, 23 Oct 2021 18:36:38 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sat, 23 Oct 2021 18:36:38 -0700    

CIC and REINDEX CONCURRENTLY assume backends see their catalog changes  
no later than each backend's next transaction start.  That failed to  
hold when a backend absorbed a relevant invalidation in the middle of  
running RelationBuildDesc() on the CIC index.  Queries that use the  
resulting index can silently fail to find rows.  Fix this for future  
index builds by making RelationBuildDesc() loop until it finishes  
without accepting a relevant invalidation.  It may be necessary to  
reindex to recover from past occurrences; REINDEX CONCURRENTLY suffices.  
Back-patch to 9.6 (all supported versions).  
  
Noah Misch and Andrey Borodin, reviewed (in earlier versions) by Andres  
Freund.  
  
Discussion: https://postgr.es/m/20210730022548.GA1940096@gust.leadboat.com  

commit   : 7c949f1b3aab8f0cf02afa42c44a9dfc66188c70    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sat, 23 Oct 2021 14:43:45 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sat, 23 Oct 2021 14:43:45 +0900    

The documentation was imprecise about the starting LSN used for WAL  
streaming if nothing can be found in the local archive directory  
defined with the pg_receivewal command, so be more talkative on this  
matter.  
  
Extracted from a larger patch by the same author.  
  
Author: Ronan Dunklau, Michael Paquier  
Discussion: https://postgr.es/m/18708360.4lzOvYHigE@aivenronan  
Backpatch-through: 10  

commit   : 2e01d050d989d67f491349018a09574427d1d0ba    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 22 Oct 2021 16:43:38 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 22 Oct 2021 16:43:38 -0400    

The code does not expect sh_error() to return, but the patch  
that made this header usable in frontend didn't get that memo.  
  
While here, plaster unlikely() on the tests that decide whether  
to invoke sh_error(), and add our standard copyright notice.  
  
Noted by Andres Freund.  Back-patch to v13 where this frontend  
support came in.  
  
Discussion: https://postgr.es/m/0D54435C-1199-4361-9D74-2FBDCF8EA164@anarazel.de  

commit   : 476006023538730d2291125b883bfe07d03f3dfa    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 22 Oct 2021 15:22:26 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 22 Oct 2021 15:22:26 -0400    

Non-global default privilege entries should be dumped as-is,  
not made relative to the default ACL for their object type.  
This would typically only matter if one had revoked some  
on-by-default privileges in a global entry, and then wanted  
to grant them again in a non-global entry.  
  
Per report from Boris Korzun.  This is an old bug, so back-patch  
to all supported branches.  
  
Neil Chen, test case by Masahiko Sawada  
  
Discussion: https://postgr.es/m/111621616618184@mail.yandex.ru  
Discussion: https://postgr.es/m/CAA3qoJnr2+1dVJObNtfec=qW4Z0nz=A9+r5bZKoTSy5RDjskMw@mail.gmail.com  

commit   : 23469b867ac000b8ed36fdeaab5c40ba9be23772    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Thu, 21 Oct 2021 09:36:27 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Thu, 21 Oct 2021 09:36:27 +0530    

This was originally done in commit 5e77625b26 for 15 only, as a  
troubleshooting aid but multiple people showed interest in back-patching  
this.  
  
Author: Jeremy Schneider  
Reviewed-by: Amit Kapila  
Backpatch-through: 9.6  
Discussion: https://postgr.es/m/808ed65b-994c-915a-361c-577f088b837f@amazon.com  

commit   : a73a3671daea34f244e1c51321d714be3200f2d9    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 20 Oct 2021 13:05:42 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 20 Oct 2021 13:05:42 -0300    

Discussion: https://postgr.es/m/YW/MYdSRQZtPFBWR@paquier.xyz  

commit   : abb9ee92c5070d2b742aea9175c6a59ee403049f    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 20 Oct 2021 16:49:00 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 20 Oct 2021 16:49:00 +0900    

The build scripts of Visual Studio would fail to detect properly a 3.0.0  
build as the check on the second digit was failing.  This is adjusted  
where needed, allowing the builds to complete.  Note that the MSIs of  
OpenSSL mentioned in the documentation have not changed any library  
names for Win32 and Win64, making this change straight-forward.  
  
Reported-by: htalaco, via github  
Reviewed-by: Daniel Gustafsson  
Discussion: https://postgr.es/m/YW5XKYkq6k7OtrFq@paquier.xyz  
Backpatch-through: 9.6  

commit   : 842fe6123c8acd09fac904ffb89bee883b36ac12    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 19 Oct 2021 19:08:45 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 19 Oct 2021 19:08:45 -0300    

Commit 1b5d797cd4f7 intended to relax the lock level used to rename  
indexes, but inadvertently allowed *any* relation to be renamed with a  
lowered lock level, as long as the command is spelled ALTER INDEX.  
That's undesirable for other relation types, so retry the operation with  
the higher lock if the relation turns out not to be an index.  
  
After this fix, ALTER INDEX <sometable> RENAME will require access  
exclusive lock, which it didn't before.  
  
Author: Nathan Bossart <bossartn@amazon.com>  
Author: Álvaro Herrera <alvherre@alvh.no-ip.org>  
Reported-by: Onder Kalaci <onderk@microsoft.com>  
Discussion: https://postgr.es/m/PH0PR21MB1328189E2821CDEC646F8178D8AE9@PH0PR21MB1328.namprd21.prod.outlook.com  

commit   : 246a035f05c6accca34113de8e78f7afad90b329    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Tue, 19 Oct 2021 10:14:49 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Tue, 19 Oct 2021 10:14:49 -0700    

ldapsearch's deprecated -h/-p arguments were removed, need to use -H now -  
which has been around for over 20 years.  
  
As perltidy insists on reflowing the parameters anyway, change order and  
"phrasing" to yield a less confusing layout (per suggestion from Tom Lane).  
  
Discussion: https://postgr.es/m/20211009233850.wvr6apcrw2ai6cnj@alap3.anarazel.de  
Backpatch: 11-, where the tests were added.  

commit   : 30e61a8cdc8624102ebdb1abbbb1e45457877c5c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 19 Oct 2021 13:54:46 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 19 Oct 2021 13:54:46 -0400    

An update such as "UPDATE ... SET fld[n].subfld = whatever"  
failed if the array elements were domains rather than plain  
composites.  That's because isAssignmentIndirectionExpr()  
failed to cope with the CoerceToDomain node that would appear  
in the expression tree in this case.  The result would typically  
be a crash, and even if we accidentally didn't crash, we'd not  
correctly preserve other fields of the same array element.  
  
Per report from Onder Kalaci.  Back-patch to v11 where arrays of  
domains came in.  
  
Discussion: https://postgr.es/m/PH0PR21MB132823A46AA36F0685B7A29AD8BD9@PH0PR21MB1328.namprd21.prod.outlook.com  

commit   : cf33fb7f4a199213a0a83209b81caa728f5c7750    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 19 Oct 2021 11:35:15 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 19 Oct 2021 11:35:15 -0400    

I think when I added this assertion (in commit 8f889b108), I was only  
thinking of the use of transformExpressionList at top level of INSERT  
and VALUES.  But it's also called by transformRowExpr(), which can  
certainly occur in an UPDATE targetlist, so it's inappropriate to  
suppose that p_multiassign_exprs must be empty.  Besides, since the  
input is not expected to contain ResTargets, there's no reason it  
should contain MultiAssignRefs either.  Hence this code need not  
be concerned about the state of p_multiassign_exprs, and we should  
just drop the assertion.  
  
Per bug #17236 from ocean_li_996.  It's been wrong for years,  
so back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/17236-3210de9bcba1d7ca@postgresql.org  

commit   : 687fe8a9d7a636d0792da39eb4dc1630741c7937    
  
author   : Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Tue, 19 Oct 2021 12:59:54 +0200    
  
committer: Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Tue, 19 Oct 2021 12:59:54 +0200    

If the blob TOC file cannot be parsed, the error message was failing  
to print the filename as the variable holding it was shadowed by the  
destination buffer for parsing.  When the filename fails to parse,  
the error will print an empty string:  
  
 ./pg_restore -d foo -F d dump  
 pg_restore: error: invalid line in large object TOC file "": ..  
  
..instead of the intended error message:  
  
 ./pg_restore -d foo -F d dump  
 pg_restore: error: invalid line in large object TOC file "dump/blobs.toc": ..  
  
Fix by renaming both variables as the shared name was too generic to  
store either and still convey what the variable held.  
  
Backpatch all the way down to 9.6.  
  
Reviewed-by: Tom Lane  
Discussion: https://postgr.es/m/A2B151F5-B32B-4F2C-BA4A-6870856D9BDE@yesql.se  
Backpatch-through: 9.6  

commit   : d3a4c1eb3d2188e8df58b4f2837cd17acc8629e1    
  
author   : Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Tue, 19 Oct 2021 12:59:50 +0200    
  
committer: Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Tue, 19 Oct 2021 12:59:50 +0200    

Make sure that the string parsing is limited by the size of the  
destination buffer.  
  
In pg_basebackup the available values sent from the server  
is limited to two characters so there was no risk of overflow.  
  
In pg_dump the buffer is bounded by MAXPGPATH, and thus the limit  
must be inserted via preprocessor expansion and the buffer increased  
by one to account for the terminator. There is no risk of overflow  
here, since in this case, the buffer scanned is smaller than the  
destination buffer.  
  
Backpatch the pg_basebackup fix to 11 where it was introduced, and  
the pg_dump fix all the way down to 9.6.  
  
Reviewed-by: Tom Lane  
Discussion: https://postgr.es/m/B14D3D7B-F98C-4E20-9459-C122C67647FB@yesql.se  
Backpatch-through: 11 and 9.6  

commit   : 85dc4292a7a1c0b9943cd285cbb3a90a5e368b3f    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 19 Oct 2021 11:04:04 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 19 Oct 2021 11:04:04 +0900    

The grammar of this command run on indexes with column names has always  
been authorized by the parser, and it has never been documented.  
  
Since 911e702, it is possible to define opclass parameters as of CREATE  
INDEX, which actually broke the old case of ALTER INDEX/TABLE where  
relation-level parameters n_distinct and n_distinct_inherited could be  
defined for an index (see 76a47c0 and its thread where this point has  
been touched, still remained unused).  Attempting to do that in v13~  
would cause the index to become unusable, as there is a new dedicated  
code path to load opclass parameters instead of the relation-level ones  
previously available.  Note that it is possible to fix things with a  
manual catalog update to bring the relation back online.  
  
This commit disables this command for now as the use of column names for  
indexes does not make sense anyway, particularly when it comes to index  
expressions where names are automatically computed.  One way to properly  
support this case properly in the future would be to use column numbers  
when it comes to indexes, in the same way as ALTER INDEX .. ALTER COLUMN  
.. SET STATISTICS.  
  
Partitioned indexes were already blocked, but not indexes.  Some tests  
are added for both cases.  
  
There was some code in ANALYZE to enforce n_distinct to be used for an  
index expression if the parameter was defined, but just remove it for  
now until/if there is support for this (note that index-level parameters  
never had support in pg_dump either, previously), so this was just dead  
code.  
  
Reported-by: Matthijs van der Vleuten  
Author: Nathan Bossart, Michael Paquier  
Reviewed-by: Vik Fearing, Dilip Kumar  
Discussion: https://postgr.es/m/17220-15d684c6c2171a83@postgresql.org  
Backpatch-through: 13  

commit   : fe35528a5ed6934e0d60c19a02798236160d93f1    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 18 Oct 2021 19:08:25 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 18 Oct 2021 19:08:25 -0300    

Failing to do that, any direct inserts/updates of those partitions  
would fail to enforce the correct constraint, that is, one that  
considers the new partition constraint of their parent table.  
  
Backpatch to 10.  
  
Reported by: Hou Zhijie <houzj.fnst@fujitsu.com>  
Author: Amit Langote <amitlangote09@gmail.com>  
Author: Álvaro Herrera <alvherre@alvh.no-ip.org>  
Reviewed-by: Nitin Jadhav <nitinjadhavpostgres@gmail.com>  
Reviewed-by: Pavel Borisov <pashkin.elfe@gmail.com>  
  
Discussion: https://postgr.es/m/OS3PR01MB5718DA1C4609A25186D1FBF194089%40OS3PR01MB5718.jpnprd01.prod.outlook.com  

commit   : 8f4fe8d7f8dc790545c84be4ed7af5d5d47d5ea7    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 18 Oct 2021 11:56:52 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 18 Oct 2021 11:56:52 +0900    

During a replication slot creation, an ERROR generated in the same  
transaction as the one creating a to-be-exported snapshot would have  
left the backend in an inconsistent state, as the associated static  
export snapshot state was not being reset on transaction abort, but only  
on the follow-up command received by the WAL sender that created this  
snapshot on replication slot creation.  This would trigger inconsistency  
failures if this session tried to export again a snapshot, like during  
the creation of a replication slot.  
  
Note that a snapshot export cannot happen in a transaction block, so  
there is no need to worry resetting this state for subtransaction  
aborts.  Also, this inconsistent state would very unlikely show up to  
users.  For example, one case where this could happen is an  
out-of-memory error when building the initial snapshot to-be-exported.  
Dilip found this problem while poking at a different patch, that caused  
an error in this code path for reasons unrelated to HEAD.  
  
Author: Dilip Kumar  
Reviewed-by: Michael Paquier, Zhihong Yu  
Discussion: https://postgr.es/m/CAFiTN-s0zA1Kj0ozGHwkYkHwa5U0zUE94RSc_g81WrpcETB5=w@mail.gmail.com  
Backpatch-through: 9.6  

commit   : 0b5f557b7e87527c0f14230326b7e279c9fd26c1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 16 Oct 2021 15:02:55 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 16 Oct 2021 15:02:55 -0400    

Commit f0e21f2f6 missed adding a tgisinternal output column  
to getTriggers' query for pre-8.3 servers.  Back-patch to v11,  
like that commit.  

commit   : 6a262ba8c8648d7f2bfb419313d2d5d6daefeeb7    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 16 Oct 2021 12:23:57 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 16 Oct 2021 12:23:57 -0400    

It was clearly the intent to do so all along, but the original coding  
fat-fingered this by checking the wrong array element.  We fixed it  
in passing in 403a3d91c, but that later got reverted, and we forgot  
to keep this bug fix.  
  
Most of the time this'd be relatively harmless, since once we lock  
any of the partitioned table's leaf partitions, that would suffice  
to prevent major DDL on the partitioned table itself.  However, a  
childless partitioned table would get dumped with no relevant lock  
whatsoever, possibly allowing dump failure or inconsistent output.  
  
Unlike 403a3d91c, there are no versioning concerns, since every server  
version that has partitioned tables will allow you to lock one.  
  
Back-patch to v10 where partitioned tables were introduced.  
  
Discussion: https://postgr.es/m/1018205.1634346327@sss.pgh.pa.us  

commit   : 20f785732fdd8872d9942761e2fbc1677adec9b7    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Thu, 14 Oct 2021 12:24:47 -0700    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Thu, 14 Oct 2021 12:24:47 -0700    

An extension may want to call GetSecurityLabel() on a shared object  
before the shared relcaches are fully initialized. For instance, a  
ClientAuthentication_hook might want to retrieve the security label on  
a role.  
  
Discussion: https://postgr.es/m/ecb7af0b26e3be1d96d291c8453a86f1f82d9061.camel@j-davis.com  
Backpatch-through: 9.6  

commit   : fdd6a4d8d90aee36d2d81f0ab29399021228183a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 14 Oct 2021 12:43:43 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 14 Oct 2021 12:43:43 -0400    

If a function-in-FROM laterally references the output of some sub-SELECT  
earlier in the FROM clause, and we are able to flatten that sub-SELECT  
into the outer query, the expression(s) copied into the function RTE  
missed being processed by eval_const_expressions.  This'd lead to trouble  
and probable crashes at execution if such expressions contained  
named-argument function call syntax or functions with defaulted arguments.  
The bug is masked if the query contains any explicit JOIN syntax, which  
may help explain why we'd not noticed.  
  
Per bug #17227 from Bernd Dorn.  This is an oversight in commit 7266d0997,  
so back-patch to v13 where that came in.  
  
Discussion: https://postgr.es/m/17227-5a28ed1512189fa4@postgresql.org  

commit   : 2cdf97fd1ec86301c70ccffb2414a6047c9f8dd1    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 13 Oct 2021 18:49:27 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 13 Oct 2021 18:49:27 -0300    

The test code added with ff9f111bce24 fails under valgrind, and probably  
other slow cases too, because if (say) autovacuum runs in between and  
produces WAL of its own, the large INSERT fails to account for that in  
the LSN calculations.  Rewrite to use a DO loop.  
  
Per complaint from Andres Freund  
  
Backpatch to all branches.  
  
Discussion: https://postgr.es/m/20211013180338.5guyqzpkcisqugrl@alap3.anarazel.de  

commit   : cdab0a80d28501692584e798abbbfcfe9b5a6b48    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Wed, 13 Oct 2021 19:00:03 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Wed, 13 Oct 2021 19:00:03 +0900    

The comments were misplaced when adding postgres_fdw.  Fix that by  
moving the comments to more appropriate functions.  
  
Author: Etsuro Fujita  
Backpatch-through: 9.6  
Discussion: https://postgr.es/m/CAPmGK164sAXQtC46mDFyu6d-T25Mzvh5qaRNkit06VMmecYnOA%40mail.gmail.com  

commit   : 2a8dee6a67ccde6074f463786d9152dbb87c7eb9    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 13 Oct 2021 09:22:00 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 13 Oct 2021 09:22:00 +0900    

This fixes a set of issues that cause different breakages or annoyances  
when using pg_upgrade's test.sh to do upgrades across different major  
versions:  
- test.sh is completely broken when using v14 as new version because of  
the removal of testtablespace/ as Makefile rule.  Older versions of  
pg_regress don't support --make-tablespacedir, blocking the creation of  
the tablespace.  In order to fix that, it is simple enough to create  
those directories in the script itself, but only do that when an old  
version is involved.  This fix is needed on HEAD and REL_14_STABLE.  
- The script would fail when using PG <= v11 as old version because of  
WITH OIDS relations not supported in v12.  In order to fix this, this  
steals a method from the buildfarm that uses a DO block to change all  
the relations marked as WITH OIDS, allowing pg_upgrade to pass.  This is  
more portable than using ALTER TABLE queries on the relations causing  
issues.  This is fixed down to v12, and authored originally by Andrew  
Dunstan.  
- Not using --extra-float-digits=0 with v11 as old version causes  
a lot of diffs in the dumps, making the whole unreadable.  This gets  
only done when using v11 as old version.  This is fixed down to v12.  
The buildfarm code uses that already.  
  
Note that the addition of --wal-segsize and --allow-group-access breaks  
the script when using v10 or older at initdb time as these got added in  
11.  10 would be EOL'd next year and nobody has complained about those  
problems yet, so nothing is done about that.  This means that this  
commit fixes upgrade tests using test.sh with v11 as minimum older  
version, up to HEAD, and that it is enough to apply this change down to  
12.  The old and new dumps still generate diffs, still require manual  
checks, and more could be done to reduce the noise, but this allows the  
tests to run with a rather minimal amount of them.  
  
I have tested this commit and test.sh with v11 as minimum across all the  
branches where this is applied.  Note that this commit has no impact on  
the normal pg_upgrade test run with a simple "make check".  
  
Author:  Justin Pryzby, Andrew Dunstan, Michael Paquier  
Discussion: https://postgr.es/m/20201206180248.GI24052@telsasoft.com  
Backpatch-through: 12  

commit   : bab0ff2e44b781ec1b1180c5e96bdb95c385c80b    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 12 Oct 2021 11:16:25 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 12 Oct 2021 11:16:25 +0900    

Incrementing the level of the call stack reported is useful for  
debugging purposes as it allows to control which part of the test is  
exactly failing, especially if a test is structured with subroutines  
that call routines from Test::More.  
  
This adds more incrementations of $Test::Builder::Level where debugging  
gets improved (for example it does not make sense for some paths like  
pg_rewind where long subroutines are used).  
  
A note is added to src/test/perl/README about that, based on a  
suggestion from Andrew Dunstan and a wording coming from both of us.  
  
Usage of Test::Builder::Level has spread in 12, so a backpatch down to  
this version is done.  
  
Reviewed-by: Andrew Dunstan, Peter Eisentraut, Daniel Gustafsson  
Discussion: https://postgr.es/m/YV1CCFwgM1RV1LeS@paquier.xyz  
Backpatch-through: 12  

commit   : 08f37e2592920a6df9584821614aa8deb93ed39f    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Thu, 7 Oct 2021 17:45:03 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Thu, 7 Oct 2021 17:45:03 +0900    

Author: Amit Langote  
Backpatch-through: 13  
Discussion: https://postgr.es/m/CA%2BHiwqGQNbtamQ_9DU3osR1XiWR4wxWFZurPmN6zgbdSZDeWmw%40mail.gmail.com  

commit   : aee83f39a86bb66baa66d65e87ca8415ac26800b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 6 Oct 2021 15:50:24 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 6 Oct 2021 15:50:24 -0400    

Commit c7b7311f6 adjusted conversion_error_callback to always use  
information from the query's rangetable, to avoid doing catalog lookups  
in an already-failed transaction.  However, as a result of the utterly  
inadequate documentation for make_tuple_from_result_row, I failed to  
realize that fsstate could be NULL in some contexts.  That led to a  
crash if we got a conversion error in such a context.  Fix by falling  
back to the previous coding when fsstate is NULL.  Improve the  
commentary, too.  
  
Per report from Andrey Borodin.  Back-patch to 9.6, like the previous  
patch.  
  
Discussion: https://postgr.es/m/08916396-55E4-4D68-AB3A-BD6066F9E5C0@yandex-team.ru  

commit   : 9ab94ccb15af288f9ff295b4f04b28d86115b803    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Wed, 6 Oct 2021 13:20:23 +0100    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Wed, 6 Oct 2021 13:20:23 +0100    

This fixes a loss of precision that occurs when the first input is  
very close to 1, so that its logarithm is very small.  
  
Formerly, during the initial low-precision calculation to estimate the  
result weight, the logarithm was computed to a local rscale that was  
capped to NUMERIC_MAX_DISPLAY_SCALE (1000). However, the base may be  
as close as 1e-16383 to 1, hence its logarithm may be as small as  
1e-16383, and so the local rscale needs to be allowed to exceed 16383,  
otherwise all precision is lost, leading to a poor choice of rscale  
for the full-precision calculation.  
  
Fix this by removing the cap on the local rscale during the initial  
low-precision calculation, as we already do in the full-precision  
calculation. This doesn't change the fact that the initial calculation  
is a low-precision approximation, computing the logarithm to around 8  
significant digits, which is very fast, especially when the base is  
very close to 1.  
  
Patch by me, reviewed by Alvaro Herrera.  
  
Discussion: https://postgr.es/m/CAEZATCV-Ceu%2BHpRMf416yUe4KKFv%3DtdgXQAe5-7S9tD%3D5E-T1g%40mail.gmail.com  

commit   : d6d68e223379985661df45c728c32c3b6d462629    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 6 Oct 2021 13:28:35 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 6 Oct 2021 13:28:35 +0900    

Oversight in a3fcbcd.  
  
Reported-by: Thomas Munro  
Discussion: https://postgr.es/m/CA+hUKGKnajZEwe91OTjro9kQLCMGGFHh2vvFn8tgHgbyn4bF9w@mail.gmail.com  
Backpatch-through: 13  

commit   : 9024a35c11d7e8c42c2489ae2f912e4d0572f1df    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 5 Oct 2021 10:24:14 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 5 Oct 2021 10:24:14 -0400    

queries.sgml failed to mention the rather important point that  
INTERSECT binds more tightly than UNION or EXCEPT.  I thought  
it could also use more discussion of the role of parentheses  
in these constructs.  
  
Per gripe from Christopher Painter-Wakefield.  
  
Discussion: https://postgr.es/m/163338891727.12510.3939775743980651160@wrigleys.postgresql.org  

commit   : 0a6549316ee852ebea843671b755dc6d54b0e85b    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 4 Oct 2021 17:10:59 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 4 Oct 2021 17:10:59 -0400    

The old URL was HTTP 404 and the git link didn't build.  Also update two  
other ICU links.  If we ever get a good link we will add it back.  
  
Reported-by: Anton Voloshin  
  
Author: Laurenz Albe  
  
Backpatch-through: 10  

commit   : 5ba397f7404e911c7822e85441d42673080c5b98    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 4 Oct 2021 13:28:06 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Mon, 4 Oct 2021 13:28:06 -0700    

3c5b0685b921 used setFilePointer() to set the position of the filehandle, but  
passed the wrong filehandle, always leaving the position at 0. Instead of just  
fixing that, remove use of setFilePointer(), we have a perl fd at this point,  
so we can just use perl's seek().  
  
Additionally, the perl filehandle wasn't closed, just the windows filehandle.  
  
Reviewed-By: Andrew Dunstan <andrew@dunslane.net>  
Author: Andres Freund <andres@anarazel.de>  
Discussion: https://postgr.es/m/20211003173038.64mmhgxctfqn7wl6@alap3.anarazel.de  
Backpatch: 9.6-, like 3c5b0685b921  

commit   : c53ff69e1fd24ae4905fe50ce8d3ca3a08d6a3c2    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 4 Oct 2021 14:52:17 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 4 Oct 2021 14:52:17 -0400    

Per discussion, let's just follow CLDR's default zone mappings  
faithfully.  There are two changes here that are clear improvements:  
  
* Mapping "Greenwich Standard Time" to Atlantic/Reykjavik is actually  
a better fit than using London, because Iceland hasn't observed DST  
since 1968, so this is more nearly what people might expect.  
  
* Since the "Samoa" zone is specified to be UTC+13:00, we must map  
it to Pacific/Apia not Pacific/Samoa; the latter refers to American  
Samoa which is now on the other side of the date line.  
  
The rest of these changes look like they're choosing the most populous  
IANA zone as representative.  Whatever the details, we're just going  
to say "if you don't like this mapping, complain to CLDR".  
  
Discussion: https://postgr.es/m/3266414.1633045628@sss.pgh.pa.us  

commit   : 194e535a07b3c36738b67f59aaa1291276929e9b    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 4 Oct 2021 14:05:52 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 4 Oct 2021 14:05:52 +0900    

Some specific logic is done at the end of recovery when involving 2PC  
transactions:  
1) Call RecoverPreparedTransactions(), to recover the state of 2PC  
transactions into memory (re-acquire locks, etc.).  
2) ShutdownRecoveryTransactionEnvironment(), to move back to normal  
operations, mainly cleaning up recovery locks and KnownAssignedXids  
(including any 2PC transaction tracked previously).  
3) Switch XLogCtl->SharedRecoveryState to RECOVERY_STATE_DONE, which is  
the tipping point for any process calling RecoveryInProgress() to check  
if the cluster is still in recovery or not.  
  
Any snapshot taken between steps 2) and 3) would be empty, causing any  
transaction relying on a snapshot at this point to potentially corrupt  
data as there could still be some 2PC transactions to track, with  
RecentXmin moving backwards on successive calls to GetSnapshotData() in  
the same transaction.  
  
As SharedRecoveryState is the point to take into account to know if it  
is safe to discard KnownAssignedXids, this commit moves step 2) after  
step 3), so as we can never finish with empty snapshots.  
  
This exists since the introduction of hot standby, so backpatch all the  
way down.  The window with incorrect snapshots is extremely small, but I  
have seen it when running 023_pitr_prepared_xact.pl, as did buildfarm  
member fairywren.  Thomas Munro also found it independently.  Special  
thanks to Andres Freund for taking the time to analyze this issue.  
  
Reported-by: Thomas Munro, Michael Paquier  
Analyzed-by: Andres Freund  
Discussion: https://postgr.es/m/20210422203603.fdnh3fu2mmfp2iov@alap3.anarazel.de  
Backpatch-through: 9.6  

commit   : 9c76689de442fc5849e383cc370d0769f8196bf6    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 2 Oct 2021 16:05:42 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 2 Oct 2021 16:05:42 -0400    

This corrects a bunch of entries in win32_tzmap[], and adds a few  
new ones, based on the CLDR project's windowsZones.xml file.  
Non-cosmetic changes fall into four main categories:  
  
* Flat-out errors:  
  
US/Aleutan doesn't exist  
America/Salvador doesn't exist  
Asia/Baku is wrong for Yerevan  
Asia/Dhaka (Bangladesh) is wrong for Astana (Kazakhstan)  
Europe/Bucharest is wrong for Chisinau  
America/Mexico_City is wrong for Chetumal  
America/Buenos_Aires is wrong for Cayenne  
America/Caracas has its own zone, so poor fit for La Paz  
US/Eastern is wrong for Haiti  
US/Eastern is wrong for Indiana (East)  
Asia/Karachi is wrong for Tashkent  
Etc/UTC+12 doesn't exist  
Signs of Etc/GMT zones were backwards  
  
* Judgment calls:  
  
(These changes follow CLDR's choices, except for the first one)  
  
Use Europe/London for "Greenwich Standard Time", since that seems much  
more likely than Africa/Casablanca to be what people will think that  
zone name means.  CLDR has Atlantic/Reykjavik here, but that's no better.  
  
Asia/Shanghai seems a better fit than Hong Kong for "China Standard  
Time".  
  
Europe/Sarajevo is now a link to Belgrade, ie "Central Europe Standard  
Time"; so use Warsaw for "Central European Standard Time".  
  
America/Sao_Paulo seems more representative than Araguaina for  
"E. South America Standard Time".  
  
Africa/Johannesburg seems more representative than Harare for  
"South Africa Standard Time".  
  
* New Windows zone names:  
  
"Israel Standard Time"  
"Kaliningrad Standard Time"  
"Russia Time Zone N" for various N  
"Singapore Standard Time"  
"South Sudan Standard Time"  
"W. Central Africa Standard Time"  
"West Bank Standard Time"  
"Yukon Standard Time"  
  
Some of these replace older spellings, but I kept the older spellings  
too in case our code runs on a machine with the older data.  
  
* Replace aliases (tzdb Links) with underlying city-named zones:  
  
(This tracks tzdb's longstanding practice, and reduces inconsistency  
with the rest of the entries, as well as with CLDR.)  
  
US/Alaska  
Asia/Kuwait  
Asia/Muscat  
Canada/Atlantic  
Australia/Canberra  
Canada/Saskatchewan  
US/Central  
US/Eastern  
US/Hawaii  
US/Mountain  
Canada/Newfoundland  
US/Pacific  
  
Back-patch to all supported branches, as is our usual practice for  
time zone data updates.  
  
Discussion: https://postgr.es/m/3266414.1633045628@sss.pgh.pa.us  

commit   : 7ba8eb81f6b79e7c1aaa3001137f38a61de80aba    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 2 Oct 2021 16:05:10 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 2 Oct 2021 16:05:10 -0400    

The original intent seems to have been to sort case-insensitively  
by the Windows zone name, but various changes over the years did  
not get that memo.  This commit just moves a few entries to  
restore exact alphabetic order, to ease comparison to the outputs  
of processing scripts.  
  
Back-patch to all supported branches, as is our usual practice for  
time zone data updates.  
  
Discussion: https://postgr.es/m/3266414.1633045628@sss.pgh.pa.us  

commit   : 170206e458bce1d4be34bb805f884b2735430519    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 1 Oct 2021 18:29:18 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 1 Oct 2021 18:29:18 -0300    

Both bugs #16676[1] and #17141[2] illustrate that the combination of  
SKIP LOCKED and FETCH FIRST WITH TIES break expectations when it comes  
to rows returned to other sessions accessing the same row.  Since this  
situation is detectable from the syntax and hard to fix otherwise,  
forbid for now, with the potential to fix in the future.  
  
[1] https://postgr.es/m/16676-fd62c3c835880da6@postgresql.org  
[2] https://postgr.es/m/17141-913d78b9675aac8e@postgresql.org  
  
Backpatch-through: 13, where WITH TIES was introduced  
Author: David Christensen <david.christensen@crunchydata.com>  
Discussion: https://postgr.es/m/CAOxo6XLPccCKru3xPMaYDpa+AXyPeWFs+SskrrL+HKwDjJnLhg@mail.gmail.com  

commit   : 7adbe186f7fd7e036d2cab7d8ed8ee99354ec219    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 1 Oct 2021 14:59:35 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 1 Oct 2021 14:59:35 -0400    

get_variable_range() would incautiously believe that statistics  
containing only an MCV list are sufficient to derive a range estimate.  
That's okay for an enum-like column that contains only MCVs, but  
otherwise the estimate could be pretty bad.  Make it report that the  
range is indeterminate unless the MCVs plus nullfrac account for  
the whole table.  
  
I don't think this needs a dedicated test case, since a quick code  
coverage check verifies that the existing regression tests traverse  
all the alternatives.  There is room to doubt that a future-proof  
test case could be built anyway, given that the submitted example  
accidentally doesn't fail before v11.  
  
Per bug #17207 from Simon Perepelitsa.  Back-patch to v10.  
In principle this has been broken all along, but I'm hesitant to  
make such changes in 9.6, since if anyone is unhappy with 9.6.24's  
behavior there will be no second chance to fix it.  
  
Discussion: https://postgr.es/m/17207-5265aefa79e333b4@postgresql.org  

commit   : 04ef2021e3ca7207b87ffce437b0b4db73a7f6b2    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 1 Oct 2021 11:10:12 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 1 Oct 2021 11:10:12 -0400    

Commit 84f5c2908 forgot to consider the possibility that  
EnsurePortalSnapshotExists could run inside a subtransaction with  
lifespan shorter than the Portal's.  In that case, the new active  
snapshot would be popped at the end of the subtransaction, leaving  
a dangling pointer in the Portal, with mayhem ensuing.  
  
To fix, make sure the ActiveSnapshot stack entry is marked with  
the same subtransaction nesting level as the associated Portal.  
It's certainly safe to do so since we won't be here at all unless  
the stack is empty; hence we can't create an out-of-order stack.  
  
Let's also apply this logic in the case where PortalRunUtility  
sets portalSnapshot, just to be sure that path can't cause similar  
problems.  It's slightly less clear that that path can't create  
an out-of-order stack, so add an assertion guarding it.  
  
Report and patch by Bertrand Drouvot (with kibitzing by me).  
Back-patch to v11, like the previous commit.  
  
Discussion: https://postgr.es/m/ff82b8c5-77f4-3fe7-6028-fcf3303e82dd@amazon.com  

commit   : 649e561f65c579630e5c31ee65308eefdd21ec93    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 30 Sep 2021 16:23:10 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 30 Sep 2021 16:23:10 -0400    

Computing related timestamps by subtracting "N days" is sensitive  
to the prevailing timezone, since we interpret that as "same local  
time on the N'th prior day".  Even though the intervals in question  
are only two to four days, through remarkable bad luck they managed  
to cross the end of Ramadan in 2014, causing the test's output to  
change if timezone is set to Africa/Casablanca.  (Maybe in other  
Muslim areas as well; I didn't check.)  There's absolutely no reason  
for this test to exercise interval subtraction, so just get rid of  
that and use plain timestamptz constants representing the intended  
values.  
  
Per report from Andres Freund.  Back-patch to v10 where this test  
script came in.  
  
Discussion: https://postgr.es/m/20210930183641.7lh4jhvpipvromca@alap3.anarazel.de  

commit   : 1d97d3d0867faf967a3ab977b6a0b675b6a451da    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 29 Sep 2021 11:21:51 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 29 Sep 2021 11:21:51 -0300    

Physical replication always ships WAL segment files to replicas once  
they are complete.  This is a problem if one WAL record is split across  
a segment boundary and the primary server crashes before writing down  
the segment with the next portion of the WAL record: WAL writing after  
crash recovery would happily resume at the point where the broken record  
started, overwriting that record ... but any standby or backup may have  
already received a copy of that segment, and they are not rewinding.  
This causes standbys to stop following the primary after the latter  
crashes:  
  LOG:  invalid contrecord length 7262 at A8/D9FFFBC8  
because the standby is still trying to read the continuation record  
(contrecord) for the original long WAL record, but it is not there and  
it will never be.  A workaround is to stop the replica, delete the WAL  
file, and restart it -- at which point a fresh copy is brought over from  
the primary.  But that's pretty labor intensive, and I bet many users  
would just give up and re-clone the standby instead.  
  
A fix for this problem was already attempted in commit 515e3d84a0b5, but  
it only addressed the case for the scenario of WAL archiving, so  
streaming replication would still be a problem (as well as other things  
such as taking a filesystem-level backup while the server is down after  
having crashed), and it had performance scalability problems too; so it  
had to be reverted.  
  
This commit fixes the problem using an approach suggested by Andres  
Freund, whereby the initial portion(s) of the split-up WAL record are  
kept, and a special type of WAL record is written where the contrecord  
was lost, so that WAL replay in the replica knows to skip the broken  
parts.  With this approach, we can continue to stream/archive segment  
files as soon as they are complete, and replay of the broken records  
will proceed across the crash point without a hitch.  
  
Because a new type of WAL record is added, users should be careful to  
upgrade standbys first, primaries later. Otherwise they risk the standby  
being unable to start if the primary happens to write such a record.  
  
A new TAP test that exercises this is added, but the portability of it  
is yet to be seen.  
  
This has been wrong since the introduction of physical replication, so  
backpatch all the way back.  In stable branches, keep the new  
XLogReaderState members at the end of the struct, to avoid an ABI  
break.  
  
Author: Álvaro Herrera <alvherre@alvh.no-ip.org>  
Reviewed-by: Kyotaro Horiguchi <horikyota.ntt@gmail.com>  
Reviewed-by: Nathan Bossart <bossartn@amazon.com>  
Discussion: https://postgr.es/m/202108232252.dh7uxf6oxwcy@alvherre.pgsql  

commit   : 8cf4f7118596a2a3f5b51c04f73f1a06b4e363da    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Wed, 29 Sep 2021 21:01:10 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Wed, 29 Sep 2021 21:01:10 +0900    

Previously socket errors such as invalid socket or socket wait method failures  
during benchmark caused pgbench to exit with status 0. Instead, errors during  
the run should result in exit status 2.  
  
Back-patch to v12 where pgbench started reporting exit status.  
  
Original complaint and patch by Hayato Kuroda.  
  
Author: Yugo Nagata, Fabien COELHO  
Reviewed-by: Kyotaro Horiguchi, Fujii Masao  
Discussion: https://postgr.es/m/TYCPR01MB5870057375ACA8A73099C649F5349@TYCPR01MB5870.jpnprd01.prod.outlook.com  

commit   : 3cc85d7d5353945bf5bdb26bb7771f40aeacaf0b    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Wed, 29 Sep 2021 20:35:00 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Wed, 29 Sep 2021 20:35:00 +0900    

The failure of socket wait method like "select()" doesn't terminate pgbench.  
So the log level of error message when that failure happens should be ERROR.  
But previously FATAL was used in that case.  
  
Back-patch to v13 where pgbench started using common logging API.  
  
Author: Yugo Nagata, Fabien COELHO  
Reviewed-by: Kyotaro Horiguchi, Fujii Masao  
Discussion: https://postgr.es/m/20210617005934.8bd37bf72efd5f1b38e6f482@sraoss.co.jp  

commit   : cf26a8d8a75ff4ae78bf0818ebb2bf6cf90db69c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 28 Sep 2021 17:34:31 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 28 Sep 2021 17:34:31 -0400    

It turns out that the instability complained of in commit d3c09b9b1  
has an embarrassingly simple explanation.  The test script waits for  
the standby to flush incoming WAL to disk, but it should wait for  
the WAL to be replayed, since we are testing for the effects of that  
to be visible.  
  
While at it, use wait_for_catchup instead of reinventing that logic,  
and adjust $Test::Builder::Level to improve future error reports.  
  
Back-patch to v12 where the necessary infrastructure came in  
(cf. aforesaid commit).  Also back-patch 7d1aa6bf1 so that the  
test will actually get run.  
  
Discussion: https://postgr.es/m/2854602.1632852664@sss.pgh.pa.us  

commit   : 78515b89f2985ef78136732cd239609c569797b3    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sun, 26 Sep 2021 19:18:27 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sun, 26 Sep 2021 19:18:27 +0900    

Author: Justin Pryzby  
Discussion: https://postgr.es/m/20210924215827.GS831@telsasoft.com  
Backpatch-through: 9.6  

commit   : 739b872f6c98459a460b522e726f369b6fc67ca3    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 25 Sep 2021 10:53:54 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 25 Sep 2021 10:53:54 -0400    

Be a little more vocal about the risks of remote collations not  
matching local ones.  Actually fixing these risks seems hard,  
and I've given up on the idea that it might be back-patchable.  
So the best we can do for the back branches is add documentation.  
  
Per discussion of bug #16583 from Jiří Fejfar.  
  
Discussion: https://postgr.es/m/2438715.1632510693@sss.pgh.pa.us  

commit   : 8e7199453bf9fe142f3f4a5e17010320c24867e7    
  
author   : Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Sat, 25 Sep 2021 11:27:28 +0200    
  
committer: Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Sat, 25 Sep 2021 11:27:28 +0200    

OpenSSL 3 introduced the concept of providers to support modularization,  
and moved the outdated ciphers to the new legacy provider. In case it's  
not loaded in the users openssl.cnf file there will be a lot of regress  
test failures, so add alternative outputs covering those.  
  
Also document the need to load the legacy provider in order to use older  
ciphers with OpenSSL-enabled pgcrypto.  
  
This will be backpatched to all supported version once there is sufficient  
testing in the buildfarm of OpenSSL 3.  
  
Reviewed-by: Michael Paquier  
Discussion: https://postgr.es/m/FEF81714-D479-4512-839B-C769D2605F8A@yesql.se  
Backpatch-through: 9.6  

commit   : 135d8687adf12a0d4cd7c94d1095ed5a7a08f7ed    
  
author   : Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Sat, 25 Sep 2021 11:27:20 +0200    
  
committer: Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Sat, 25 Sep 2021 11:27:20 +0200    

The PX layer in pgcrypto is handling digest padding on its own uniformly  
for all backend implementations. Starting with OpenSSL 3.0.0, DecryptUpdate  
doesn't flush the last block in case padding is enabled so explicitly  
disable it as we don't use it.  
  
This will be backpatched to all supported version once there is sufficient  
testing in the buildfarm of OpenSSL 3.  
  
Reviewed-by: Peter Eisentraut, Michael Paquier  
Discussion: https://postgr.es/m/FEF81714-D479-4512-839B-C769D2605F8A@yesql.se  
Backpatch-through: 9.6  

commit   : a69e1506f618d4577bf7fdbfea51924a44c6e7de    
  
author   : Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Sat, 25 Sep 2021 11:25:48 +0200    
  
committer: Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Sat, 25 Sep 2021 11:25:48 +0200    

This has previously not been a problem (that anyone ever reported),  
but in future OpenSSL versions (3.0.0), where legacy ciphers are/can  
be disabled, this is the place where this is reported.  So we need to  
catch the error here, otherwise the higher-level functions would  
return garbage.  The nearby encryption code already handled errors  
similarly.  
  
Author: Peter Eisentraut <peter@eisentraut.org>  
Reviewed-by: Daniel Gustafsson <daniel@yesql.se>  
Discussion: https://www.postgresql.org/message-id/9e9c431c-0adc-7a6d-9b1a-915de1ba3fe7@enterprisedb.com  
Backpatch-through: 9.6  

commit   : 52f8575a9e75e67ed7a7ae1585be28a85e85ae0e    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sat, 25 Sep 2021 15:12:00 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sat, 25 Sep 2021 15:12:00 +0900    

Index vacuums may happen multiple times depending on the number of dead  
tuples stored, as of maintenance_work_mem for a manual VACUUM.  For  
autovacuum, this is controlled by autovacuum_work_mem instead, if set.  
The documentation mentioned the former, but not the latter in the  
context of autovacuum.  
  
Reported-by: Nikolai Berkoff  
Author: Laurenz Albe, Euler Taveira  
Discussion: https://postgr.es/m/161545365522.10134.12195402324485546870@wrigleys.postgresql.org  
Backpatch-through: 9.6  

commit   : ca925fe3c4d3727679f00deedde83765b89c32bb    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sat, 25 Sep 2021 14:48:13 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sat, 25 Sep 2021 14:48:13 +0900    

Reported-by: rir  
Discussion: https://postgr.es/m/20210924183658.3syyitp3yuxjv2fp@localhost  
Backpatch-through: 9.6  

commit   : fd22aec631af9f2b967af20e23206840c6594c72    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Thu, 23 Sep 2021 19:59:03 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Thu, 23 Sep 2021 19:59:03 +0300    

That allows to include just visibilitymapdefs.h from file.c, and in turn,  
remove include of postgres.h from relcache.h.  
  
Reported-by: Andres Freund  
Discussion: https://postgr.es/m/20210913232614.czafiubr435l6egi%40alap3.anarazel.de  
Author: Alexander Korotkov  
Reviewed-by: Andres Freund, Tom Lane, Alvaro Herrera  
Backpatch-through: 13  

commit   : c0386f403a832f50d61fc7bb9bb265f7700273f3    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Tue, 21 Sep 2021 01:13:11 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Tue, 21 Sep 2021 01:13:11 +0200    

Calculating degree of a functional dependency may allocate a lot of  
memory - we have released mot of the explicitly allocated memory, but  
e.g. detoasted varlena values were left behind. That may be an issue,  
because we consider a lot of dependencies (all combinations), and the  
detoasting may happen for each one again.  
  
Fixed by calling dependency_degree() in a dedicated context, and  
resetting it after each call. We only need the calculated dependency  
degree, so we don't need to copy anything.  
  
Backpatch to PostgreSQL 10, where extended statistics were introduced.  
  
Backpatch-through: 10  
Discussion: https://www.postgresql.org/message-id/20210915200928.GP831%40telsasoft.com  

commit   : b564eb0181e678ee58c1be2e9f3c53eeb68f8c4b    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Tue, 21 Sep 2021 01:14:11 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Tue, 21 Sep 2021 01:14:11 +0200    

Until now, all extended statistics on a given relation were built in the  
same memory context, without resetting. Some of the memory was released  
explicitly, but not all of it - for example memory allocated while  
detoasting values is hard to free. This is how it worked since extended  
statistics were introduced in PostgreSQL 10, but adding support for  
extended stats on expressions made the issue somewhat worse as it  
increases the number of statistics to build.  
  
Fixed by adding a memory context which gets reset after building each  
statistics object (all the statistics kinds included in it). Resetting  
it after building each statistics kind would be even better, but it  
would require more invasive changes and copying of results, making it  
harder to backpatch.  
  
Backpatch to PostgreSQL 10, where extended statistics were introduced.  
  
Author: Justin Pryzby  
Reported-by: Justin Pryzby  
Reviewed-by: Tomas Vondra  
Backpatch-through: 10  
Discussion: https://www.postgresql.org/message-id/20210915200928.GP831%40telsasoft.com  

commit   : f09a81f1c08fa5c2fed12bed88d53a11a72ff993    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Wed, 22 Sep 2021 08:24:20 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Wed, 22 Sep 2021 08:24:20 +0530    

Updates/Deletes on a partition were allowed even without replica identity  
after the parent table was added to a publication. This would later lead  
to an error on subscribers. The reason was that we were not invalidating  
the partition's relcache and the publication information for partitions  
was not getting rebuilt. Similarly, we were not invalidating the  
partitions' relcache after dropping a partitioned table from a publication  
which will prohibit Updates/Deletes on its partition without replica  
identity even without any publication.  
  
Reported-by: Haiying Tang  
Author: Hou Zhijie and Vignesh C  
Reviewed-by: Vignesh C and Amit Kapila  
Backpatch-through: 13  
Discussion: https://postgr.es/m/OS0PR01MB6113D77F583C922F1CEAA1C3FBD29@OS0PR01MB6113.jpnprd01.prod.outlook.com  

commit   : 583e15af9976f8905e2b27f985d619e758270e16    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 22 Sep 2021 08:43:10 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 22 Sep 2021 08:43:10 +0900    

Contrary to the output of native perl, Msys perl generates outputs with  
CRLFs characters.  There are already places in the TAP code where CRLFs  
(\r\n) are automatically converted to LF (\n) on Msys, but we missed a  
couple of places when running commands and using their output for  
comparison, that would lead to failures.  
  
This problem has been found thanks to the test added in 5adb067 using  
TestLib::command_checks_all(), but after a closer look more code paths  
were missing a filter.  
  
This is backpatched all the way down to prevent any surprises if a new  
test is introduced in stable branches.  
  
Reviewed-by: Andrew Dunstan, Álvaro Herrera  
Discussion: https://postgr.es/m/1252480.1631829409@sss.pgh.pa.us  
Backpatch-through: 9.6  

commit   : 5f0a073cbbf8bdc276e570ffa006e762fc815e44    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 21 Sep 2021 19:06:33 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 21 Sep 2021 19:06:33 -0400    

Before commit 84f5c2908, a STABLE function in a plpgsql CALL  
statement's argument list would see an up-to-date snapshot,  
because exec_stmt_call would push a new snapshot.  I got rid of  
that because the possibility of the snapshot disappearing within  
COMMIT made it too hard to manage a snapshot across the CALL  
statement.  That's fine so far as the procedure itself goes,  
but I forgot to think about the possibility of STABLE functions  
within the CALL argument list.  As things now stand, those'll  
be executed with the Portal's snapshot as ActiveSnapshot,  
keeping them from seeing updates more recent than Portal startup.  
  
(VOLATILE functions don't have a problem because they take their  
own snapshots; which indeed is also why the procedure itself  
doesn't have a problem.  There are no STABLE procedures.)  
  
We can fix this by pushing a new snapshot transiently within  
ExecuteCallStmt itself.  Popping the snapshot before we get  
into the procedure proper eliminates the management problem.  
The possibly-useless extra snapshot-grab is slightly annoying,  
but it's no worse than what happened before 84f5c2908.  
  
Per bug #17199 from Alexander Nawratil.  Back-patch to v11,  
like the previous patch.  
  
Discussion: https://postgr.es/m/17199-1ab2561f0d94af92@postgresql.org  

commit   : a1708ab652eaef3e9405d5119721a9a4ecb6fcbd    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 20 Sep 2021 14:26:22 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 20 Sep 2021 14:26:22 -0700    

A broken HOT chain is not an unexpected condition, even when the offset  
number points past the end of the page's line pointer array.  
heap_prune_chain() does not (and never has) treated this condition as  
unexpected, so derivative code in heap_index_delete_tuples() shouldn't  
do so either.  
  
Oversight in commit 4228817449.  
  
The assertion can probably only fail on Postgres 14 and master.  Earlier  
releases don't have commit 3c3b8a4b, which taught VACUUM to truncate the  
line pointer array of heap pages.  Backpatch all the same, just to be  
consistent.  
  
Author: Peter Geoghegan <pg@bowt.ie>  
Reported-By: Alexander Lakhin <exclusion@gmail.com>  
Discussion: https://postgr.es/m/17197-9438f31f46705182@postgresql.org  
Backpatch: 12-, just like commit 4228817449.  

commit   : dede1439978120d2196e0d3963bb809a8b262e5b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 20 Sep 2021 11:48:52 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 20 Sep 2021 11:48:52 -0400    

Casting a value that's already of a type with a specific typmod  
to an unspecified typmod doesn't do anything so far as run-time  
behavior is concerned.  However, it really ought to change the  
exposed type of the expression to match.  Up to now,  
coerce_type_typmod hasn't bothered with that, which creates gotchas  
in contexts such as recursive unions.  If for example one side of  
the union is numeric(18,3), but it needs to be plain numeric to  
match the other side, there's no direct way to express that.  
  
This is easy enough to fix, by inserting a RelabelType to update the  
exposed type of the expression.  However, it's a bit nervous-making  
to change this behavior, because it's stood for a really long time.  
But no complaints have emerged about 14beta3, so go ahead and  
back-patch.  
  
Back-patch of 5c056b0c2 into previous supported branches.  
  
Discussion: https://postgr.es/m/CABNQVagu3bZGqiTjb31a8D5Od3fUMs7Oh3gmZMQZVHZ=uWWWfQ@mail.gmail.com  
Discussion: https://postgr.es/m/1488389.1631984807@sss.pgh.pa.us  

commit   : 89b5676b65b5f27fcab4f972390197983d7a9bfe    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 19 Sep 2021 11:36:53 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 19 Sep 2021 11:36:53 -0400    

"PGcon" should be "PGconn".  Noted by D. Frey.  
  
Discussion: https://postgr.es/m/163191739352.4680.16994248583642672629@wrigleys.postgresql.org  

commit   : e0b0d1eab48c85f961a39c263d2074ad11931920    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 17 Sep 2021 15:41:16 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 17 Sep 2021 15:41:16 -0400    

Commit 55dc86eca changed pull_varnos to use (if possible) the associated  
ph_eval_at for a PlaceHolderVar.  I missed a fine point though: we might  
be looking at a PHV in the quals or tlist of a child appendrel, in which  
case we need to compute a ph_eval_at value that's been translated in the  
same way that the PHV itself has been (cf. adjust_appendrel_attrs).  
Fortunately, enough info is available in the PlaceHolderInfo to make  
such translation possible without additional outside data, so we don't  
need another round of uglification of planner APIs.  This is a little  
bit complicated, but since it's a hard-to-hit corner case, I'm not much  
worried about adding cycles here.  
  
Per report from Jaime Casanova.  Back-patch to v12, like the previous  
commit.  
  
Discussion: https://postgr.es/m/20210915230959.GB17635@ahch-to  

commit   : 8767a86fa2b1d24537cca318a26fc68d7e457911    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Thu, 16 Sep 2021 13:07:29 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Thu, 16 Sep 2021 13:07:29 +0900    

ProcArrayGroupClearXid function has a parameter named "proc",  
but the same name was used for its local variables. This commit fixes  
this variable shadowing, to improve code readability.  
  
Back-patch to all supported versions, to make future back-patching  
easy though this patch is classified as refactoring only.  
  
Reported-by: Ranier Vilela  
Author: Ranier Vilela, Aleksander Alekseev  
https://postgr.es/m/CAEudQAqyoTZC670xWi6w-Oe2_Bk1bfu2JzXz6xRfiOUzm7xbyQ@mail.gmail.com  

commit   : e06cc024bd3372cb4280246e114d7508e3e2c20a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 15 Sep 2021 12:31:56 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 15 Sep 2021 12:31:56 -0400    

It's possible to execute user-defined SQL in some background processes;  
for example, logical replication workers can fire triggers.  This opens  
the possibility that someone would try to execute LISTEN in such a  
context.  But since only regular backends ever call  
ProcessNotifyInterrupt, no messages would actually be received, and  
thus the registered listener would simply prevent the message queue  
from being cleaned.  Eventually NOTIFY would stop working, which is bad.  
  
Perhaps someday somebody will invent infrastructure to make listening  
in a background worker actually useful.  In the meantime, forbid it.  
  
Back-patch to v13, which is where we introduced the MyBackendType  
variable.  It'd be a lot harder to implement the check without that,  
and it doesn't seem worth the trouble.  
  
Discussion: https://postgr.es/m/153243441449.1404.2274116228506175596@wrigleys.postgresql.org  

commit   : 63f28776cb9fbefd99c5e2134f02c80057b8b717    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 14 Sep 2021 17:18:25 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 14 Sep 2021 17:18:25 -0400    

Formerly, we sent signals for outgoing NOTIFY messages within  
ProcessCompletedNotifies, which was also responsible for sending  
relevant ones of those messages to our connected client.  It therefore  
had to run during the main-loop processing that occurs just before  
going idle.  This arrangement had two big disadvantages:  
  
* Now that procedures allow intra-command COMMITs, it would be  
useful to send NOTIFYs to other sessions immediately at COMMIT  
(though, for reasons of wire-protocol stability, we still shouldn't  
forward them to our client until end of command).  
  
* Background processes such as replication workers would not send  
NOTIFYs at all, since they never execute the client communication  
loop.  We've had requests to allow triggers running in replication  
workers to send NOTIFYs, so that's a problem.  
  
To fix these things, move transmission of outgoing NOTIFY signals  
into AtCommit_Notify, where it will happen during CommitTransaction.  
Also move the possible call of asyncQueueAdvanceTail there, to  
ensure we don't bloat the async SLRU if a background worker sends  
many NOTIFYs with no one listening.  
  
We can also drop the call of asyncQueueReadAllNotifications,  
allowing ProcessCompletedNotifies to go away entirely.  That's  
because commit 790026972 added a call of ProcessNotifyInterrupt  
adjacent to PostgresMain's call of ProcessCompletedNotifies,  
and that does its own call of asyncQueueReadAllNotifications,  
meaning that we were uselessly doing two such calls (inside two  
separate transactions) whenever inbound notify signals coincided  
with an outbound notify.  We need only set notifyInterruptPending  
to ensure that ProcessNotifyInterrupt runs, and we're done.  
  
The existing documentation suggests that custom background workers  
should call ProcessCompletedNotifies if they want to send NOTIFY  
messages.  To avoid an ABI break in the back branches, reduce it  
to an empty routine rather than removing it entirely.  Removal  
will occur in v15.  
  
Although the problems mentioned above have existed for awhile,  
I don't feel comfortable back-patching this any further than v13.  
There was quite a bit of churn in adjacent code between 12 and 13.  
At minimum we'd have to also backpatch 51004c717, and a good deal  
of other adjustment would also be needed, so the benefit-to-risk  
ratio doesn't look attractive.  
  
Per bug #15293 from Michael Powers (and similar gripes from others).  
  
Artur Zakirov and Tom Lane  
  
Discussion: https://postgr.es/m/153243441449.1404.2274116228506175596@wrigleys.postgresql.org  

commit   : c49e6f9d974966c7b0fc3eac43a6be922cf6eaee    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 13 Sep 2021 18:07:19 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Mon, 13 Sep 2021 18:07:19 -0700    

If an allocation failed within LLVM it is not safe to call back into LLVM as  
LLVM is not generally safe against exceptions / stack-unwinding. Thus errors  
while in LLVM code are promoted to FATAL. However llvm_shutdown() did call  
back into LLVM even in such cases, while llvm_release_context() was careful  
not to do so.  
  
We cannot generally skip shutting down LLVM, as that can break profiling. But  
it's OK to do so if there was an error from within LLVM.  
  
Reported-By: Jelte Fennema <Jelte.Fennema@microsoft.com>  
Author: Andres Freund <andres@anarazel.de>  
Author: Justin Pryzby <pryzby@telsasoft.com>  
Discussion: https://postgr.es/m/AM5PR83MB0178C52CCA0A8DEA0207DC14F7FF9@AM5PR83MB0178.EURPRD83.prod.outlook.com  
Backpatch: 11-, where jit was introduced  

commit   : 745abdd951ab31f3276adbbbf67bbc3b7dac0923    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 13 Sep 2021 12:42:03 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 13 Sep 2021 12:42:03 -0400    

Ordinarily, using EXIT this way would draw "control reached end of  
function without RETURN".  However, if the function is one where we  
don't require an explicit RETURN (such as a DO block), that should  
not happen.  It did anyway, because add_dummy_return() neglected to  
account for the case.  
  
Per report from Herwig Goemans.  Back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/868ae948-e3ca-c7ec-95a6-83cfc08ef750@gmail.com  

commit   : b7b8e2c4a5cb9d520c907f12fe9ebd3837dffc49    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Mon, 13 Sep 2021 17:30:02 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Mon, 13 Sep 2021 17:30:02 +0900    

The type information for FDW options is only added to HEAD; remove this  
from back branches.  Oversight in commit aa769f80e.  
  
Apply the patch to v12, v13, and v14.  
  
Discussion: https://postgr.es/m/CAPmGK14z92twaKwRoccHbbh5Va5vbRDZcTYYTx50+0JTQ8xx_g@mail.gmail.com  

commit   : 58cf794ca68d90ea11888f200e0b74d01d0c7093    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Mon, 13 Sep 2021 10:46:58 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Mon, 13 Sep 2021 10:46:58 +0530    

While processing toast changes in logical decoding, we rejigger the  
tuple change to point to in-memory toast tuples instead to on-disk toast  
tuples. And, to make sure the memory accounting is correct, we were  
subtracting the old change size and then after re-computing the new tuple,  
re-adding its size at the end. Now, if there is any error before we add  
the new size, we will release the changes and that will update the  
accounting info (subtracting the size from the counters). And we were  
underflowing there which leads to an assertion failure in assert enabled  
builds and wrong memory accounting in reorder buffer otherwise.  
  
Author: Bertrand Drouvot  
Reviewed-by: Amit Kapila  
Backpatch-through: 13, where memory accounting was introduced  
Discussion: https://postgr.es/m/92b0ee65-b8bd-e42d-c082-4f3f4bf12d34@amazon.com  

commit   : b589d212fdd7e449ec0d5da8e46c0d86eee943d6    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 13 Sep 2021 13:24:20 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 13 Sep 2021 13:24:20 +0900    

An out-of-memory failure happening when allocating the structures to  
store the connection parameter keywords and values would mess up with  
the set of connections saved, as on failure the pthread mutex would  
still be hold with the new connection object listed but free()'d.  
  
Rather than just unlocking the mutex, which would leave the static list  
of connections into an inconsistent state, move the allocation for the  
structures of the connection parameters before beginning the test  
manipulation.  This ensures that the list of connections and the  
connection mutex remain consistent all the time in this code path.  
  
This error is unlikely going to happen, but this could mess up badly  
with ECPG clients in surprising ways, so backpatch all the way down.  
  
Reported-by: ryancaicse  
Discussion: https://postgr.es/m/17186-b4cfd8f0eb4d1dee@postgresql.org  
Backpatch-through: 9.6  

commit   : 7e420072ea4a9f873d3378c8b35f2d939d925022    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 11 Sep 2021 15:19:31 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 11 Sep 2021 15:19:31 -0400    

If search_start is greater than the length of the string, we should just  
return REG_NOMATCH immediately.  (Note that the equality case should  
*not* be rejected, since the pattern might be able to match zero  
characters.)  This guards various internal assumptions that the min of a  
range of string positions is not more than the max.  Violation of those  
assumptions could allow an attempt to fetch string[search_start-1],  
possibly causing a crash.  
  
Jaime Casanova pointed out that this situation is reachable with the  
new regexp_xxx functions that accept a user-specified start position.  
I don't believe it's reachable via any in-core call site in v14 and  
below.  However, extensions could possibly call pg_regexec with an  
out-of-range search_start, so let's back-patch the fix anyway.  
  
Discussion: https://postgr.es/m/20210911180357.GA6870@ahch-to  

commit   : fa5d0415f10fac3c2aa4c301840fde1780b91b79    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 10 Sep 2021 13:18:32 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 10 Sep 2021 13:18:32 -0400    

We have long forbidden fetching backwards from a NO SCROLL cursor,  
but the prohibition didn't extend to cases in which we rewind the  
query altogether and then re-fetch forwards.  I think the reason is  
that this logic was mainly meant to protect plan nodes that can't  
be run in the reverse direction.  However, re-reading the query output  
is problematic if the query is volatile (which includes SELECT FOR  
UPDATE, not just queries with volatile functions): the re-read can  
produce different results, which confuses the cursor navigation logic  
completely.  Another reason for disliking this approach is that some  
code paths will either fetch backwards or rewind-and-fetch-forwards  
depending on the distance to the target row; so that seemingly  
identical use-cases may or may not draw the "cursor can only scan  
forward" error.  Hence, let's clean things up by disallowing rewind  
as well as fetch-backwards in a NO SCROLL cursor.  
  
Ordinarily we'd only make such a definitional change in HEAD, but  
there is a third reason to consider this change now.  Commit ba2c6d6ce  
created some new user-visible anomalies for non-scrollable cursors  
WITH HOLD, in that navigation in the cursor result got confused if the  
cursor had been partially read before committing.  The only good way  
to resolve those anomalies is to forbid rewinding such a cursor, which  
allows removal of the incorrect cursor state manipulations that  
ba2c6d6ce added to PersistHoldablePortal.  
  
To minimize the behavioral change in the back branches (including  
v14), refuse to rewind a NO SCROLL cursor only when it has a holdStore,  
ie has been held over from a previous transaction due to WITH HOLD.  
This should avoid breaking most applications that have been sloppy  
about whether to declare cursors as scrollable.  We'll enforce the  
prohibition across-the-board beginning in v15.  
  
Back-patch to v11, as ba2c6d6ce was.  
  
Discussion: https://postgr.es/m/3712911.1631207435@sss.pgh.pa.us  

commit   : d8d93bc8baa934fb23c90271d200e061386b546d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 9 Sep 2021 13:36:31 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 9 Sep 2021 13:36:31 -0400    

Some plan node types don't react well to being called again after  
they've already returned NULL.  PortalRunSelect() has long dealt  
with this by calling the executor with NoMovementScanDirection  
if it sees that we've already run the portal to the end.  However,  
commit ba2c6d6ce overlooked this point, so that persisting an  
already-fully-fetched cursor would fail if it had such a plan.  
  
Per report from Tomas Barton.  Back-patch to v11, as the faulty  
commit was.  (I've omitted a test case because the type of plan  
that causes a problem isn't all that stable.)  
  
Discussion: https://postgr.es/m/CAPV2KRjd=ErgVGbvO2Ty20tKTEZZr6cYsYLxgN_W3eAo9pf5sw@mail.gmail.com  

commit   : 04118de78fe9a8a7160775b47e89bf21a5efb620    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 9 Sep 2021 11:45:48 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 9 Sep 2021 11:45:48 -0400    

We don't allow relations to exceed 2^32-1 blocks, because block  
numbers are 32 bits and the last possible block number is reserved  
to mean InvalidBlockNumber.  There is a check for this in mdextend,  
but that's really way too late, because the smgr API requires us to  
create a buffer for the block-to-be-added, and we do not want to  
have any buffer with blocknum InvalidBlockNumber.  (Such a case  
can trigger assertions in bufmgr.c, plus I think it might confuse  
ReadBuffer's logic for data-past-EOF later on.)  So put the check  
into ReadBuffer.  
  
Per report from Christoph Berg.  It's been like this forever,  
so back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/YTn1iTkUYBZfcODk@msg.credativ.de  

commit   : dd9b3fced83edb51a3e2f44d3d4476a45d0f5a24    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Thu, 9 Sep 2021 23:58:05 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Thu, 9 Sep 2021 23:58:05 +0900    

Previously, walreceiver always closed the currently-opened WAL segment  
and created its archive notification file, after it finished writing  
the current segment up and received any WAL data that should be  
written into the next segment. If walreceiver exited just before  
any WAL data in the next segment arrived at standby, it did not  
create the archive notification file of the current segment  
even though that's known completed. This behavior could cause  
WAL archiving of the segment to be delayed until subsequent  
restartpoints or checkpoints created its notification file.  
  
To fix the issue, this commit changes walreceiver so that it creates  
an archive notification file of a current WAL segment immediately  
if that's known completed before receiving next WAL data.  
  
Back-patch to all supported branches.  
  
Reported-by: Kyotaro Horiguchi  
Author: Fujii Masao  
Reviewed-by: Kyotaro Horiguchi  
Discussion: https://postgr.es/m/20200630.165503.1465894182551545886.horikyota.ntt@gmail.com  

commit   : da7d81dd0579a2579741bcfc816cf614c58d0aab    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 8 Sep 2021 15:09:42 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 8 Sep 2021 15:09:42 -0400    

Coverity complained that one caller of getFormattedTypeName() failed  
to free the returned string.  Which is true, but rather than fixing  
that one, let's get rid of this tedious and error-prone requirement.  
Now that getFormattedTypeName() caches its result, strdup'ing that  
result and expecting the caller to free it accomplishes little except  
to waste cycles.  We do create a leak in the case where getTypes didn't  
make a TypeInfo for the type, but that basically shouldn't ever happen.  
  
Back-patch, as commit 6c450a861 was.  This isn't a particularly  
interesting bug fix, but the API change seems like a hazard for  
future back-patching activity if we don't back-patch it.  

commit   : cbba6ba3a0628fdc47185f71d5f06ed7af95c147    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 8 Sep 2021 12:05:43 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 8 Sep 2021 12:05:43 -0400    

If we copy data-modifying CTEs from the original query to a replacement  
query (from a DO INSTEAD rule), we must set hasModifyingCTE properly  
in the replacement query.  Failure to do this can cause various  
unpleasantness, such as unsafe usage of parallel plans.  The code also  
neglected to propagate hasRecursive, though that's only cosmetic at  
the moment.  
  
A difficulty arises if the rule action is an INSERT...SELECT.  We  
attach the original query's RTEs and CTEs to the sub-SELECT Query, but  
data-modifying CTEs are only allowed to appear in the topmost Query.  
For the moment, throw an error in such cases.  It would probably be  
possible to avoid this error by attaching the CTEs to the top INSERT  
Query instead; but that would require a bunch of new code to adjust  
ctelevelsup references.  Given the narrowness of the use-case, and  
the need to back-patch this fix, it does not seem worth the trouble  
for now.  We can revisit this if we get field complaints.  
  
Per report from Greg Nancarrow.  Back-patch to all supported branches.  
(The test case added here does not fail before v10, but there are  
plenty of places checking top-level hasModifyingCTE in 9.6, so I have  
no doubt that this code change is necessary there too.)  
  
Greg Nancarrow and Tom Lane  
  
Discussion: https://postgr.es/m/CAJcOf-f68DT=26YAMz_i0+Au3TcLO5oiHY5=fL6Sfuits6r+_w@mail.gmail.com  
Discussion: https://postgr.es/m/CAJcOf-fAdj=nDKMsRhQzndm-O13NY4dL6xGcEvdX5Xvbbi0V7g@mail.gmail.com  

commit   : ddfc7299d0a3a41f0c178a8157bd751430428e8a    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Wed, 8 Sep 2021 10:20:02 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Wed, 8 Sep 2021 10:20:02 +0530    

Updates/Deletes on a relation were allowed even without replica identity  
after we define the publication for all tables. This would later lead to  
an error on subscribers. The reason was that for such publications we were  
not invalidating the relcache and the publication information for  
relations was not getting rebuilt. Similarly, we were not invalidating the  
relcache after dropping of such publications which will prohibit  
Updates/Deletes without replica identity even without any publication.  
  
Author: Vignesh C and Hou Zhijie  
Reviewed-by: Hou Zhijie, Kyotaro Horiguchi, Amit Kapila  
Backpatch-through: 10, where it was introduced  
Discussion: https://postgr.es/m/CALDaNm0pF6zeWqCA8TCe2sDuwFAy8fCqba=nHampCKag-qLixg@mail.gmail.com  

commit   : aae398a87cfafcb1d62fd1e464b2c4d2525a039a    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Mon, 6 Sep 2021 11:27:59 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 6 Sep 2021 11:27:59 -0700    

We make each AIX shared library export all globals found in .o files  
that originate in the library.  That doesn't include symbols acquired by  
-lpgcommon_shlib.  That is good on average, but it became a problem for  
libpq when commit e6afa8918c461c1dd80c5063a950518fa4e950cd moved five  
official libpq API symbols into src/common.  Fix this by implementing  
the SHLIB_EXPORTS mechanism for AIX, so affected libraries export the  
same symbols that they export on Linux.  This reintroduces symbols  
pg_encoding_to_char, pg_utf_mblen, pg_char_to_encoding,  
pg_valid_server_encoding, and pg_valid_server_encoding_id.  Back-patch  
to v13, where the aforementioned commit first appeared.  While a minor  
release is usually the wrong time to add or remove symbol exports in  
libpq or libecpg, we should expect users to want each documented symbol.  
  
Tony Reix  
  
Discussion: https://postgr.es/m/PR3PR02MB6396742E2FC3E77D37A920BC86C79@PR3PR02MB6396.eurprd02.prod.outlook.com  

commit   : d8a266c5e1bd50785d4619ecb3e686f86771685f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 6 Sep 2021 11:29:52 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 6 Sep 2021 11:29:52 -0400    

timetz_zone() delivered completely wrong answers if the zone was  
specified by a dynamic TZ abbreviation, because it failed to account  
for the difference between the POSIX conventions for field values in  
struct pg_tm and the conventions used in PG-specific datetime code.  
  
As a stopgap fix, just adjust the tm_year and tm_mon fields to match  
PG conventions.  This is fixed in a different way in HEAD (388e71af8)  
but I don't want to back-patch the change of reference point.  
  
Discussion: https://postgr.es/m/CAJ7c6TOMG8zSNEZtCn5SPe+cCk3Lfxb71ZaQwT2F4T7PJ_t=KA@mail.gmail.com  

commit   : 9f9ae019d194d012c74084cec3722ba2d67af8eb    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 6 Sep 2021 09:41:03 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 6 Sep 2021 09:41:03 +0200    

Since ea53100d5 (PostgreSQL 12), the shipped pkg-config files have  
been broken for statically linking libpq because libpgcommon and  
libpgport are missing.  This patch adds those two missing private  
dependencies (in a non-hardcoded way).  
  
Reported-by: Filip Gospodinov <f@gospodinov.ch>  
Discussion: https://www.postgresql.org/message-id/flat/c7108bde-e051-11d5-a234-99beec01ce2a@gospodinov.ch  

commit   : 2c0dd669c3c909484c24b40a797bd99b352c6f0b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 4 Sep 2021 16:29:08 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 4 Sep 2021 16:29:08 -0400    

Attempting to make hashfloat4() look as much as possible like  
hashfloat8(), I'd figured I could replace NaNs with get_float4_nan()  
before widening to float8.  However, results from protosciurus  
and topminnow show that on some platforms that produces a different  
bit-pattern from get_float8_nan(), breaking the intent of ce773f230.  
Rearrange so that we use the result of get_float8_nan() for all NaN  
cases.  As before, back-patch.  

commit   : 518621c40b23b4188478578d21de62d25582d9e3    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Sat, 4 Sep 2021 12:14:30 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Sat, 4 Sep 2021 12:14:30 -0400    

This reverts commit 515e3d84a0b5 and equivalent commits in back  
branches.  This solution to the problem has a number of problems, so  
we'll try again with a different approach.  
  
Per note from Andres Freund  
  
Discussion: https://postgr.es/m/20210831042949.52eqp5xwbxgrfank@alap3.anarazel.de  

commit   : 742b30caee65a8d54388c1a249e93f27c65315f5    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 3 Sep 2021 21:04:44 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 3 Sep 2021 21:04:44 -0400    

Replace fixed-length command buffers with psprintf() calls.  We didn't  
have anything as convenient as psprintf() when this code was written,  
but now that we do, there's little reason for the limitation to  
stand.  Removing it eliminates some corner cases where (for example)  
starting the postmaster with a whole lot of options fails.  
  
Most individual file names that pg_ctl deals with are still restricted  
to MAXPGPATH, but we've seldom had complaints about that limitation  
so long as it only applies to one filename.  
  
Back-patch to all supported branches.  
  
Phil Krylov  
  
Discussion: https://postgr.es/m/567e199c6b97ee19deee600311515b86@krylov.eu  

commit   : 132be60006b334df00093973465215cd8b892f37    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 3 Sep 2021 16:38:55 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 3 Sep 2021 16:38:55 -0400    

Previously this was allowed, but the collation effectively vanished  
into the ether because of the way lookup_collation() works: you could  
not use the collation, nor even drop it.  Seems better to give an  
error up front than to leave the user wondering why it doesn't work.  
  
(Because this test is in DefineCollation not CreateCollation, it does  
not prevent pg_import_system_collations from creating ICU collations,  
regardless of the initially-chosen encoding.)  
  
Per bug #17170 from Andrew Bille.  Back-patch to v10 where ICU support  
was added.  
  
Discussion: https://postgr.es/m/17170-95845cf3f0a9c36d@postgresql.org  

commit   : 9089f1543ef50414e1cecf89bc34eeb3ab1cb968    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 3 Sep 2021 10:01:02 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 3 Sep 2021 10:01:02 -0400    

Modern POSIX seems to require strtod() to accept "-NaN", but there's  
nothing about NaN in SUSv2, and some of our oldest buildfarm members  
don't like it.  Let's try writing it as -'NaN' instead; that seems  
to produce the same result, at least on Intel hardware.  
  
Per buildfarm.  

commit   : be2beadaff1ad87792efa58273698898d84afd4e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 2 Sep 2021 17:24:42 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 2 Sep 2021 17:24:42 -0400    

The IEEE 754 standard allows a wide variety of bit patterns for NaNs,  
of which at least two ("NaN" and "-NaN") are pretty easy to produce  
from SQL on most machines.  This is problematic because our btree  
comparison functions deem all NaNs to be equal, but our float hash  
functions know nothing about NaNs and will happily produce varying  
hash codes for them.  That causes unexpected results from queries  
that hash a column containing different NaN values.  It could also  
produce unexpected lookup failures when using a hash index on a  
float column, i.e. "WHERE x = 'NaN'" will not find all the rows  
it should.  
  
To fix, special-case NaN in the float hash functions, not too much  
unlike the existing special case that forces zero and minus zero  
to hash the same.  I arranged for the most vanilla sort of NaN  
(that coming from the C99 NAN constant) to still have the same  
hash code as before, to reduce the risk to existing hash indexes.  
  
I dithered about whether to back-patch this into stable branches,  
but ultimately decided to do so.  It's a clear improvement for  
queries that hash internally.  If there is anybody who has -NaN  
in a hash index, they'd be well advised to re-index after applying  
this patch ... but the misbehavior if they don't will not be much  
worse than the misbehavior they had before.  
  
Per bug #17172 from Ma Liangzhu.  
  
Discussion: https://postgr.es/m/17172-7505bea9e04e230f@postgresql.org  

commit   : e976cc4a79af63b3f1453a8e2d9eb9bcdeb91616    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 2 Sep 2021 11:36:01 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 2 Sep 2021 11:36:01 +0900    

This makes the documentation more accurate grammatically.  
  
Author: Elena Indrupskaya  
Discussion: https://postgr.es/m/1c994b3d-951e-59bb-1ac2-7b9221c0e4cf@postgrespro.ru  
Backpatch-through: 9.6  

commit   : b51985d8a0e1a7487d17559cbeefc87892c4d916    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Wed, 1 Sep 2021 09:16:35 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Wed, 1 Sep 2021 09:16:35 +0530    

The check to test whether the subscription workers were restarting after a  
change in the subscription was failing. The reason was that the test was  
assuming the walsender started before it reaches the 'streaming' state and  
the walsender was exiting due to an error before that. Now, the walsender  
was erroring out before reaching the 'streaming' state because it tries to  
acquire the slot before the previous walsender has exited.  
  
In passing, improve the die messages so that it is easier to investigate  
the failures in the future if any.  
  
Reported-by: Michael Paquier, as per buildfarm  
Author: Ajin Cherian  
Reviewed-by: Masahiko Sawada, Amit Kapila  
Backpatch-through: 10, where this test was introduced  
Discussion: https://postgr.es/m/YRnhFxa9bo73wfpV@paquier.xyz  

commit   : db11b4a3db5f6613c844c1b3a6c203bbceb05532    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 31 Aug 2021 15:04:05 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 31 Aug 2021 15:04:05 -0400    

For no particularly good reason, getPolicies() queried pg_policy  
separately for each table.  We can collect all the policies in  
a single query instead, and attach them to the correct TableInfo  
objects using findTableByOid() lookups.  On the regression  
database, this reduces the number of queries substantially, and  
provides a visible savings even when running against a local  
server.  
  
Per complaint from Hubert Depesz Lubaczewski.  Since this is such  
a simple fix and can have a visible performance benefit, back-patch  
to all supported branches.  
  
Discussion: https://postgr.es/m/20210826084430.GA26282@depesz.com  

commit   : 904ce45bfa8862d4ae04065c8033182ad812b009    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 31 Aug 2021 13:53:33 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 31 Aug 2021 13:53:33 -0400    

There's long been a "TODO: there might be some value in caching  
the results" annotation on pg_dump's getFormattedTypeName function;  
but we hadn't gotten around to checking what it was costing us to  
repetitively look up type names.  It turns out that when dumping the  
current regression database, about 10% of the total number of queries  
issued are duplicative format_type() queries.  However, Hubert Depesz  
Lubaczewski reported a not-unusual case where these account for over  
half of the queries issued by pg_dump.  Individually these queries  
aren't expensive, but when network lag is a factor, they add up to a  
problem.  We can very easily add some caching to getFormattedTypeName  
to solve it.  
  
Since this is such a simple fix and can have a visible performance  
benefit, back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/20210826084430.GA26282@depesz.com  

commit   : c8213aa949626deb19f098332eded3586624ff59    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Tue, 31 Aug 2021 19:21:29 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Tue, 31 Aug 2021 19:21:29 +0200    

Commit 5be8ce82e8 added a new role to the stats_ext regression suite,  
but the role name did not start with regress_ causing failures when  
running with ENFORCE_REGRESSION_TEST_NAME_RESTRICTIONS. Fixed by  
renaming the role to start with the expected regress_ prefix.  
  
Backpatch-through: 10, same as the new regression test  
Discussion: https://postgr.es/m/1F238937-7CC2-4703-A1B1-6DC225B8978A%40enterprisedb.com  

commit   : 1fe1a04af81de4c659ab2a85e578a6bbd4903035    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Tue, 31 Aug 2021 18:03:05 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Tue, 31 Aug 2021 18:03:05 +0200    

When an ownership check on extended statistics object failed, the code  
was calling aclcheck_error_type to report the failure, which is clearly  
wrong, resulting in cache lookup errors. Fix by calling aclcheck_error.  
  
This issue exists since the introduction of extended statistics, so  
backpatch all the way back to PostgreSQL 10. It went unnoticed because  
there were no tests triggering the error, so add one.  
  
Reported-by: Mark Dilger  
Backpatch-through: 10, where extended stats were introduced  
Discussion: https://postgr.es/m/1F238937-7CC2-4703-A1B1-6DC225B8978A%40enterprisedb.com  

commit   : 6197d7b5383e69383801a4e1c6eed7b7dbc086a3    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 30 Aug 2021 16:29:12 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 30 Aug 2021 16:29:12 -0400    

Most data-corruption reports mention the location of the problem, but  
this one failed to.  Add it.  
  
Backpatch all the way back.  In 12 and older, also assign the  
ERRCODE_DATA_CORRUPTED error code as was done in commit fd6ec93bf890 for  
13 and later.  
  
Discussion: https://postgr.es/m/202108191637.oqyzrdtnheir@alvherre.pgsql  

commit   : 8ba3bad4c362ef71bf6a13ecf4ae5e26066a4876    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Mon, 30 Aug 2021 09:26:49 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Mon, 30 Aug 2021 09:26:49 +0530    

ERRCODE_CONFIGURATION_LIMIT_EXCEEDED was used for checksum failure, use  
ERRCODE_DATA_CORRUPTED instead.  
  
Reported-by: Tatsuhito Kasahara  
Author: Tatsuhito Kasahara  
Backpatch-through: 9.6, where it was introduced  
Discussion: https://postgr.es/m/CAP0=ZVLHtYffs8SOWcFJWrBGoRzT9QQbk+_aP+E5AHLNXiOorA@mail.gmail.com  

commit   : 9a33ed8fa10354bdb3f12d87ccd9f387bec338d1    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Sat, 28 Aug 2021 11:45:47 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Sat, 28 Aug 2021 11:45:47 -0400    

Strictly speaking this isn't a bug, but since all references to catalog  
objects are schema-qualified, we might as well be consistent.  The  
omission first appeared in commit 1c5d9270e339, so backpatch to 12.  
  
Author: Justin Pryzby <pryzbyj@telsasoft.com>  
Discussion: https://postgr.es/m/20210827193151.GN26465@telsasoft.com  

commit   : b18669f5e652f1d0c1dbf332fd7cd24a38c7ed31    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Fri, 27 Aug 2021 23:33:23 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Fri, 27 Aug 2021 23:33:23 -0700    

If the system crashed between CREATE TABLESPACE and the next checkpoint,  
the result could be some files in the tablespace unexpectedly containing  
no rows.  Affected files would be those for which the system did not  
write WAL; see the wal_skip_threshold documentation.  Before v13, a  
different set of conditions governed the writing of WAL; see v12's  
<sect2 id="populate-pitr">.  (The v12 conditions were broader in some  
ways and narrower in others.)  Users may want to audit non-default  
tablespaces for unexpected short files.  The bug could have truncated an  
index without affecting the associated table, and reindexing the index  
would fix that particular problem.  
  
This fixes the bug by making create_tablespace_directories() more like  
TablespaceCreateDbspace().  create_tablespace_directories() was  
recursively removing tablespace contents, reasoning that WAL redo would  
recreate everything removed that way.  That assumption holds for other  
wal_level values.  Under wal_level=minimal, the old approach could  
delete files for which no other copy existed.  Back-patch to 9.6 (all  
supported versions).  
  
Reviewed by Robert Haas and Prabhat Sahu.  Reported by Robert Haas.  
  
Discussion: https://postgr.es/m/CA+TgmoaLO9ncuwvr2nN-J4VEP5XyAcy=zKiHxQzBbFRxxGxm0w@mail.gmail.com  

commit   : dbb239d518eef791ec6e8f2180e71078e7f89e38    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 27 Aug 2021 19:42:42 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 27 Aug 2021 19:42:42 -0400    

Somehow, spgist overlooked the need to call pgstat_count_index_scan().  
Hence, pg_stat_all_indexes.idx_scan and equivalent columns never  
became nonzero for an SP-GiST index, although the related per-tuple  
counters worked fine.  
  
This fix works a bit differently from other index AMs, in that the  
counter increment occurs in spgrescan not spggettuple/spggetbitmap.  
It looks like this won't make the user-visible semantics noticeably  
different, so I won't go to the trouble of introducing an is-this-  
the-first-call flag just to make the counter bumps happen in the  
same places.  
  
Per bug #17163 from Christian Quest.  Back-patch to all supported  
versions.  
  
Discussion: https://postgr.es/m/17163-b8c5cc88322a5e92@postgresql.org  

commit   : 53597fd6c3cc2042cad9909b962459fa26c26e20    
  
author   : Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Fri, 27 Aug 2021 22:50:19 +0200    
  
committer: Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Fri, 27 Aug 2021 22:50:19 +0200    

Author: Dave Cramer <davecramer@gmail.com>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/CADK3HHLZmqAQZ2ByPDQQ9yhGqax36kksq6sDkV0yYzsxw6ipvQ@mail.gmail.com  

commit   : bc062cb938234d8e815d14fecd8d3b2abff3fe88    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Wed, 25 Aug 2021 08:32:04 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Wed, 25 Aug 2021 08:32:04 -0400    

Pengchengliu reported an assertion failure in a parallel woker while  
performing a parallel scan using an overflowed snapshot. The proximate  
cause is that TransactionXmin was set to an incorrect value.  The  
underlying cause is incorrect snapshot handling in parallel.c.  
  
In particular, InitializeParallelDSM() was unconditionally calling  
GetTransactionSnapshot(), because I (rhaas) mistakenly thought that  
was always retrieving an existing snapshot whereas, at isolation  
levels less than REPEATABLE READ, it's actually taking a new one. So  
instead do this only at higher isolation levels where there actually  
is a single snapshot for the whole transaction.  
  
By itself, this is not a sufficient fix, because we still need to  
guarantee that TransactionXmin gets set properly in the workers. The  
easiest way to do that seems to be to install the leader's active  
snapshot as the transaction snapshot if the leader did not serialize a  
transaction snapshot. This doesn't affect the results of future  
GetTrasnactionSnapshot() calls since those have to take a new snapshot  
anyway; what we care about is the side effect of setting TransactionXmin.  
  
Report by Pengchengliu. Patch by Greg Nancarrow, except for some comment  
text which I supplied.  
  
Discussion: https://postgr.es/m/002f01d748ac$eaa781a0$bff684e0$@tju.edu.cn  

commit   : 794025eff0db181e463cb92d4b1aedd0879c88a6    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Wed, 25 Aug 2021 09:23:27 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Wed, 25 Aug 2021 09:23:27 +0530    

Commit 325f2ec555 introduced pg_class.relwrite to skip operations on  
tables created as part of a heap rewrite during DDL. It links such  
transient heaps to the original relation OID via this new field in  
pg_class but forgot to do anything about toast tables. So, logical  
decoding was not able to skip operations on internally created toast  
tables. This leads to an error when we tried to decode the WAL for the  
next operation for which it appeared that there is a toast data where  
actually it didn't have any toast data.  
  
To fix this, we set pg_class.relwrite for internally created toast tables  
as well which allowed skipping operations on them during logical decoding.  
  
Author: Bertrand Drouvot  
Reviewed-by: David Zhang, Amit Kapila  
Backpatch-through: 11, where it was introduced  
Discussion: https://postgr.es/m/b5146fb1-ad9e-7d6e-f980-98ed68744a7c@amazon.com  

commit   : 7d9026cbfd340a4de6c96ff7c728e53c3791e1cc    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Wed, 25 Aug 2021 11:46:25 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Wed, 25 Aug 2021 11:46:25 +0900    

There are two identical error messages about valid value of modulus for  
hash partition, in PostgreSQL source code. Commit 0e1275fb07 improved  
only one of them so that ambiguous word "positive" was avoided there,  
and forgot to improve the other. This commit improves the other.  
Which would reduce translator burden.  
  
Back-pach to v11 where the error message exists.  
  
Author: Kyotaro Horiguchi  
Reviewed-by: Fujii Masao  
Discussion: https://postgr.es/m/20210819.170315.1413060634876301811.horikyota.ntt@gmail.com  

commit   : 81fa1bce2770ee9c9ffe92baa7c5abae70939c59    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Wed, 25 Aug 2021 11:43:56 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Wed, 25 Aug 2021 11:43:56 +0900    

The distance in phrase operator must be an integer value between zero  
and MAXENTRYPOS inclusive. But previously the error message about  
its valid value included the information about its upper limit  
but not lower limit (i.e., zero). This commit improves the error message  
so that it also includes the information about its lower limit.  
  
Back-patch to v9.6 where full-text phrase search was supported.  
  
Author: Kyotaro Horiguchi  
Reviewed-by: Fujii Masao  
Discussion: https://postgr.es/m/20210819.170315.1413060634876301811.horikyota.ntt@gmail.com  

commit   : 071146184a59de4ac20f5508903fdbc21f963b6c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 24 Aug 2021 16:37:27 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 24 Aug 2021 16:37:27 -0400    

Regexps like "(.){0}...\1" drew an "invalid backreference number".  
That's not unreasonable on its face, since the capture group will  
never be matched if it's iterated zero times.  However, other engines  
such as Perl's don't complain about this, nor do we throw an error for  
related cases such as "(.)|\1", even though that backref can never  
succeed either.  Also, if the zero-iterations case happens at runtime  
rather than compile time --- say, "(x)*...\1" when there's no "x" to  
be found --- that's not an error, we just deem the backref to not  
match.  Making this even less defensible, no error was thrown for  
nested cases such as "((.)){0}...\2"; and to add insult to injury,  
those cases could result in assertion failures instead.  (It seems  
that nothing especially bad happened in non-assert builds, though.)  
  
Let's just fix it so that no error is thrown and instead the backref  
is deemed to never match, so that compile-time detection of no  
iterations behaves the same as run-time detection.  
  
Per report from Mark Dilger.  This appears to be an aboriginal error  
in Spencer's library, so back-patch to all supported versions.  
  
Pre-v14, it turns out to also be necessary to back-patch one aspect of  
commits cb76fbd7e/00116dee5, namely to create capture-node subREs with  
the begin/end states of their subexpressions, not the current lp/rp  
of the outer parseqatom invocation.  Otherwise delsub complains that  
we're trying to disconnect a state from itself.  This is a bit scary  
but code examination shows that it's safe: in the pre-v14 code, if we  
want to wrap iteration around the subexpression, the first thing we do  
is overwrite the atom's begin/end fields with new states.  So the  
bogus values didn't survive long enough to be used for anything, except  
if no iteration is required, in which case it doesn't matter.  
  
Discussion: https://postgr.es/m/A099E4A8-4377-4C64-A98C-3DEDDC075502@enterprisedb.com  

commit   : 9a327179c824712b35eda01a1edef33ad674b188    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 23 Aug 2021 17:41:07 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 23 Aug 2021 17:41:07 -0400    

The recursion in cdissect() was careless about clearing match data  
for capturing parentheses after rejecting a partial match.  This  
could allow a later back-reference to succeed when by rights it  
should fail for lack of a defined referent.  
  
To fix, think a little more rigorously about what the contract  
between different levels of cdissect's recursion needs to be.  
With the right spec, we can fix this using fewer rather than more  
resets of the match data; the key decision being that a failed  
sub-match is now explicitly responsible for clearing any matches  
it may have set.  
  
There are enough other cross-checks and optimizations in the code  
that it's not especially easy to exhibit this problem; usually, the  
match will fail as-expected.  Plus, regexps that are even potentially  
vulnerable are most likely user errors, since there's just not much  
point in writing a back-ref that doesn't always have a referent.  
These facts perhaps explain why the issue hasn't been detected,  
even though it's almost certainly a couple of decades old.  
  
Discussion: https://postgr.es/m/151435.1629733387@sss.pgh.pa.us  

commit   : ad1231171f5d4319024a2f48c52d267bbee43503    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 23 Aug 2021 15:50:35 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 23 Aug 2021 15:50:35 -0400    

WAL records may span multiple segments, but XLogWrite() does not  
wait for the entire record to be written out to disk before  
creating archive status files.  Instead, as soon as the last WAL page of  
the segment is written, the archive status file is created, and the  
archiver may process it.  If PostgreSQL crashes before it is able to  
write and flush the rest of the record (in the next WAL segment), the  
wrong version of the first segment file lingers in the archive, which  
causes operations such as point-in-time restores to fail.  
  
To fix this, keep track of records that span across segments and ensure  
that segments are only marked ready-for-archival once such records have  
been completely written to disk.  
  
This has always been wrong, so backpatch all the way back.  
  
Author: Nathan Bossart <bossartn@amazon.com>  
Reviewed-by: Kyotaro Horiguchi <horikyota.ntt@gmail.com>  
Reviewed-by: Ryo Matsumura <matsumura.ryo@fujitsu.com>  
Reviewed-by: Andrey Borodin <x4mmm@yandex-team.ru>  
Discussion: https://postgr.es/m/CBDDFA01-6E40-46BB-9F98-9340F4379505@amazon.com  

commit   : 29f94232517bb5c5f22d1deebecfe2160711150f    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 23 Aug 2021 11:09:57 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 23 Aug 2021 11:09:57 +0900    

In a backup manifest, WAL-Ranges stores the range of WAL that is  
required for the backup to be valid.  pg_verifybackup would then  
internally use pg_waldump for the checks based on this data.  
  
When the timeline where the backup started was more than 1 with a  
history file looked at for the manifest data generation, the calculation  
of the WAL range for the first timeline to check was incorrect.  The  
previous logic used as start LSN the start position of the first  
timeline, but it needs to use the start LSN of the backup.  This would  
cause failures with pg_verifybackup, or any tools making use of the  
backup manifests.  
  
This commit adds a test based on a logic using a self-promoted node,  
making it rather cheap.  
  
Author: Kyotaro Horiguchi  
Discussion: https://postgr.es/m/20210818.143031.1867083699202617521.horikyota.ntt@gmail.com  
Backpatch-through: 13  

commit   : b30f7f399ea87f0621dfe900547cda401f8da762    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 20 Aug 2021 14:19:04 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 20 Aug 2021 14:19:04 -0400    

After detecting a sub-match "dissect" failure (i.e., a backref match  
failure) in the i'th sub-match of an iteration node, we should proceed  
by adjusting the attempted length of the i'th submatch.  As coded,  
though, these functions changed the attempted length of the *last*  
sub-match, and only after exhausting all possibilities for that would  
they back up to adjust the next-to-last sub-match, and then the  
second-from-last, etc; all of which is wasted effort, since only  
changing the start or length of the i'th sub-match can possibly make  
it succeed.  This oversight creates the possibility for exponentially  
bad performance.  Fortunately the problem is masked in most cases by  
optimizations or constraints applied elsewhere; which explains why  
we'd not noticed it before.  But it is possible to reach the problem  
with fairly simple, if contrived, regexps.  
  
Oversight in my commit 173e29aa5.  That's pretty ancient now,  
so back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/1808998.1629412269@sss.pgh.pa.us  

commit   : 7fa367d96bb1ae25f422d6c2a78424f0f9227b5a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 19 Aug 2021 12:12:35 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 19 Aug 2021 12:12:35 -0400    

transformLockingClause neglected to exclude the pseudo-RTEs for  
OLD/NEW when processing a rule's query.  This led to odd errors  
or even crashes later on.  This bug is very ancient, but it's  
not terribly surprising that nobody noticed, since the use-case  
for SELECT FOR UPDATE in a non-view rule is somewhere between  
thin and non-existent.  Still, crashing is not OK.  
  
Per bug #17151 from Zhiyong Wu.  Thanks to Masahiko Sawada  
for analysis of the problem.  
  
Discussion: https://postgr.es/m/17151-c03a3e6e4ec9aadb@postgresql.org  

commit   : ecd4dd9f1df00ef9e872a4d13bbbe3f3d8d3f966    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 18 Aug 2021 18:12:51 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 18 Aug 2021 18:12:51 -0400    

Recursion into the FILTER clause was mis-implemented, such that a  
relevant Var or Aggref at the very top of the FILTER clause would  
be ignored.  (Of course, that'd have to be a plain boolean Var or  
boolean-returning aggregate.)  The consequence would be  
mis-identification of the correct semantic level of the aggregate,  
which could lead to not-per-spec query behavior.  If the FILTER  
expression is an aggregate, this could also lead to failure to issue  
an expected "aggregate function calls cannot be nested" error, which  
would likely result in a core dump later on, since the planner and  
executor aren't expecting such cases to appear.  
  
The root cause is that commit b560ec1b0 blindly copied some code  
that assumed it's recursing into a List, and thus didn't examine the  
top-level node.  To forestall questions about why this call doesn't  
look like the others, as well as possible future copy-and-paste  
mistakes, let's change all three check_agg_arguments_walker calls in  
check_agg_arguments, even though only the one for the filter clause  
is really broken.  
  
Per bug #17152 from Zhiyong Wu.  This has been wrong since we  
implemented FILTER, so back-patch to all supported versions.  
(Testing suggests that pre-v11 branches manage to avoid crashing  
in the bad-Aggref case, thanks to "redundant" checks in ExecInitAgg.  
But I'm not sure how thorough that protection is, and anyway the  
wrong-behavior issue remains, so fix 9.6 and 10 too.)  
  
Discussion: https://postgr.es/m/17152-c7f906cc1a88e61b@postgresql.org  

commit   : 7b01246e1de94a436c64f1d396674b2dc44dab70    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 17 Aug 2021 14:29:22 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 17 Aug 2021 14:29:22 -0400    

If recordDependencyOnCurrentExtension is invoked on a pre-existing,  
free-standing object during an extension update script, that object  
will become owned by the extension.  In our current code this is  
possible in three cases:  
  
* Replacing a "shell" type or operator.  
* CREATE OR REPLACE overwriting an existing object.  
* ALTER TYPE SET, ALTER DOMAIN SET, and ALTER OPERATOR SET.  
  
The first of these cases is intentional behavior, as noted by the  
existing comments for GenerateTypeDependencies.  It seems like  
appropriate behavior for CREATE OR REPLACE too; at least, the obvious  
alternatives are not better.  However, the fact that it happens during  
ALTER is an artifact of trying to share code (GenerateTypeDependencies  
and makeOperatorDependencies) between the CREATE and ALTER cases.  
Since an extension script would be unlikely to ALTER an object that  
didn't already belong to the extension, this behavior is not very  
troubling for the direct target object ... but ALTER TYPE SET will  
recurse to dependent domains, and it is very uncool for those to  
become owned by the extension if they were not already.  
  
Let's fix this by redefining the ALTER cases to never change extension  
membership, full stop.  We could minimize the behavioral change by  
only changing the behavior when ALTER TYPE SET is recursing to a  
domain, but that would complicate the code and it does not seem like  
a better definition.  
  
Per bug #17144 from Alex Kozhemyakin.  Back-patch to v13 where ALTER  
TYPE SET was added.  (The other cases are older, but since they only  
affect the directly-named object, there's not enough of a problem to  
justify changing the behavior further back.)  
  
Discussion: https://postgr.es/m/17144-e67d7a8f049de9af@postgresql.org  

commit   : e15f32f0edf6e22669e309bd58fbd72b8aa43fd3    
  
author   : Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Tue, 17 Aug 2021 14:27:37 +0200    
  
committer: Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Tue, 17 Aug 2021 14:27:37 +0200    

In OpenSSL there are two types of BIO's (I/O abstractions):  
source/sink and filters. A source/sink BIO is a source and/or  
sink of data, ie one acting on a socket or a file. A filter  
BIO takes a stream of input from another BIO and transforms it.  
In order for BIO_find_type() to be able to traverse the chain  
of BIO's and correctly find all BIO's of a certain type they  
shall have the type bit set accordingly, source/sink BIO's  
(what PostgreSQL implements) use BIO_TYPE_SOURCE_SINK and  
filter BIO's use BIO_TYPE_FILTER. In addition to these, file  
descriptor based BIO's should have the descriptor bit set,  
BIO_TYPE_DESCRIPTOR.  
  
The PostgreSQL implementation didn't set the type bits, which  
went unnoticed for a long time as it's only really relevant  
for code auditing the OpenSSL installation, or doing similar  
tasks. It is required by the API though, so this fixes it.  
  
Backpatch through 9.6 as this has been wrong for a long time.  
  
Author: Itamar Gafni  
Discussion: https://postgr.es/m/SN6PR06MB39665EC10C34BB20956AE4578AF39@SN6PR06MB3966.namprd06.prod.outlook.com  
Backpatch-through: 9.6  

commit   : c9e75c21d8c96c9385fdb3693d35628a2a625630    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 17 Aug 2021 10:00:06 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 17 Aug 2021 10:00:06 +0300    

The backslash sequences, including \123 and \x12 escapes, are interpreted  
after encoding conversion. The docs failed to mention that.  
  
Backpatch to all supported versions.  
  
Reported-by: Andreas Grob  
Discussion: https://www.postgresql.org/message-id/17142-9181542ca1df75ab%40postgresql.org  

commit   : 7f0873f328efe057090071805be3f1ade48ecc8a    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 16 Aug 2021 12:11:53 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 16 Aug 2021 12:11:53 +0900    

This commit ensures that the wait interval in the replay delay loop  
waiting for an amount of time defined by recovery_min_apply_delay is  
correctly handled on reload, recalculating the delay if this GUC value  
is updated, based on the timestamp of the commit record being replayed.  
  
The previous behavior would be problematic for example with replay  
still waiting even if the delay got reduced or just cancelled.  If the  
apply delay was increased to a larger value, the wait would have just  
respected the old value set, finishing earlier.  
  
Author: Soumyadeep Chakraborty, Ashwin Agrawal  
Reviewed-by: Kyotaro Horiguchi, Michael Paquier  
Discussion: https://postgr.es/m/CAE-ML+93zfr-HLN8OuxF0BjpWJ17O5dv1eMvSE5jsj9jpnAXZA@mail.gmail.com  
Backpatch-through: 9.6  

commit   : 48695decc27159275a10cf9e1f31bae51f311305    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 13 Aug 2021 13:58:47 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 13 Aug 2021 13:58:47 -0400    

Like the ARM case, just use gcc's __sync_lock_test_and_set();  
that will compile into AMOSWAP.W.AQ which does what we need.  
  
At some point it might be worth doing some work on atomic ops  
for RISC-V, but this should be enough for a creditable port.  
  
Back-patch to all supported branches, just in case somebody  
wants to try them on RISC-V.  
  
Marek Szuba  
  
Discussion: https://postgr.es/m/dea97b6d-f55f-1f6d-9109-504aa7dfa421@gentoo.org  

commit   : 4873da79da4bbd54f580ca6e5b2f5c46ae6e4bc6    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Fri, 13 Aug 2021 16:42:35 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Fri, 13 Aug 2021 16:42:35 +1200    

This fixes a bug in simplehash.h which caused an incorrect size mask to be  
used when the hash table grew to SH_MAX_SIZE (2^32).  The code was  
incorrectly setting the size mask to 0 when the hash tables reached the  
maximum possible number of buckets.  This would result always trying to  
use the 0th bucket causing an  infinite loop of trying to grow the hash  
table due to there being too many collisions.  
  
Seemingly it's not that common for simplehash tables to ever grow this big  
as this bug dates back to v10 and nobody seems to have noticed it before.  
However, probably the most likely place that people would notice it would  
be doing a large in-memory Hash Aggregate with something close to at least  
2^31 groups.  
  
After this fix, the code now works correctly with up to within 98% of 2^32  
groups and will fail with the following error when trying to insert any  
more items into the hash table:  
  
ERROR:  hash table size exceeded  
  
However, the work_mem (or hash_mem_multiplier in newer versions) settings  
will generally cause Hash Aggregates to spill to disk long before reaching  
that many groups.  The minimal test case I did took a work_mem setting of  
over 192GB to hit the bug.  
  
simplehash hash tables are used in a few other places such as Bitmap Index  
Scans, however, again the size that the hash table can become there is  
also limited to work_mem and it would take a relation of around 16TB  
(2^31) pages and a very large work_mem setting to hit this.  With smaller  
work_mem values the table would become lossy and never grow large enough  
to hit the problem.  
  
Author: Yura Sokolov  
Reviewed-by: David Rowley, Ranier Vilela  
Discussion: https://postgr.es/m/b1f7f32737c3438136f64b26f4852b96@postgrespro.ru  
Backpatch-through: 10, where simplehash.h was added  

commit   : 2c6275423535f86d0d4bc2a4651852d05b3d60c1    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Fri, 13 Aug 2021 10:38:22 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Fri, 13 Aug 2021 10:38:22 +1200    

It's hard to disable ASLR on current macOS releases, for testing with  
-DEXEC_BACKEND.  You could already set the environment variable  
PG_SHMEM_ADDR to something not likely to collide with mappings created  
earlier in process startup.  Let's also provide a default value that  
works on current releases and architectures, for developer convenience.  
  
As noted in the pre-existing comment, this is a horrible hack, but  
-DEXEC_BACKEND is only used by Unix-based PostgreSQL developers for  
testing some otherwise Windows-only code paths, so it seems excusable.  
  
Back-patch to all supported branches.  
  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/20210806032944.m4tz7j2w47mant26%40alap3.anarazel.de  

commit   : 7ba487cf90071717c9c352dc074a9140860eba55    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 10 Aug 2021 18:10:30 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 10 Aug 2021 18:10:30 -0400    

As a result of confusion about whether the "char" type is signed or  
unsigned, scans for index searches like "col < 'x'" or "col <= 'x'"  
would start at the middle of the index not the left end, thus missing  
many or all of the entries they should find.  Fortunately, this  
is not a symptom of index corruption.  It's only the search logic  
that is broken, and we can fix it without unpleasant side-effects.  
  
Per report from Jason Kim.  This has been wrong since btree_gin's  
beginning, so back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/20210810001649.htnltbh7c63re42p@jasonk.me  

commit   : e849f3f1f884ad140b60a24354c6371cbd2efbb6    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Aug 2021 16:49:05 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Aug 2021 16:49:05 -0400    

commit   : 0145ec9be92b2146e7b94f286cb3dab9eb77ef70    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Aug 2021 14:41:00 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Aug 2021 14:41:00 -0400    

Security: CVE-2021-3677  

commit   : dc10035ecc8256d4489eb33ba3026efe9bfba082    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 9 Aug 2021 11:56:40 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 9 Aug 2021 11:56:40 +0200    

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

commit   : bb08e78972b1d0ec9f11f3d0b18903ec7a216855    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Mon, 9 Aug 2021 16:47:25 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Mon, 9 Aug 2021 16:47:25 +1200    

In ec34040af I added a mention that there was no point in setting  
maintenance_work_limit to anything higher than 1GB for vacuum, but that  
was incorrect as ginInsertCleanup() also looks at what  
maintenance_work_mem is set to during VACUUM and that's not limited to  
1GB.  
  
Here I attempt to make it more clear that the limitation is only around  
the number of dead tuple identifiers that we can collect during VACUUM.  
  
I've also added a note to autovacuum_work_mem to mention this limitation.  
I didn't do that in ec34040af as I'd had some wrong-headed ideas about  
just limiting the maximum value for that GUC to 1GB.  
  
Author: David Rowley  
Discussion: https://postgr.es/m/CAApHDvpGwOAvunp-E-bN_rbAs3hmxMoasm5pzkYDbf36h73s7w@mail.gmail.com  
Backpatch-through: 9.6, same as ec34040af  

commit   : ff18b8d1b169b2bf47daab7d92c5376bc19c0748    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Sun, 8 Aug 2021 21:05:46 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Sun, 8 Aug 2021 21:05:46 -0400    

Since commit e462856a7a, pg_upgrade automatically creates a script to  
update extensions, so mention that instead of ALTER EXTENSION.  
  
Backpatch-through: 9.6  

commit   : 410c5a08df4381917cd6da7d94609644e10ca322    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 8 Aug 2021 15:35:30 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 8 Aug 2021 15:35:30 -0400    

Copy-and-pasteo in 665c5855e, evidently.  The 9.6 docs toolchain  
whined about duplicate index entries, though our modern toolchain  
doesn't.  In any case, these GUCs surely are not about the  
default settings of these values.  

commit   : 6432cf92658307688be4e241eb16fc9c41a8c0cf    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 8 Aug 2021 14:35:19 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 8 Aug 2021 14:35:19 -0400    

commit   : ba9f665a4413f855bbf4b544481db326f7b9bd73    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 7 Aug 2021 13:29:32 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 7 Aug 2021 13:29:32 -0400    

Rather than trying to pick table aliases that won't conflict with  
any possible user-defined matview column name, adjust the queries'  
syntax so that the aliases are only used in places where they can't be  
mistaken for column names.  Mostly this consists of writing "alias.*"  
not just "alias", which adds clarity for humans as well as machines.  
We do have the issue that "SELECT alias.*" acts differently from  
"SELECT alias", but we can use the same hack ruleutils.c uses for  
whole-row variables in SELECT lists: write "alias.*::compositetype".  
  
We might as well revert to the original aliases after doing this;  
they're a bit easier to read.  
  
Like 75d66d10e, back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/2488325.1628261320@sss.pgh.pa.us  

commit   : da188b993450c824b03e7dca18c27e9f4c04754f    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Fri, 6 Aug 2021 21:31:20 +0100    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Fri, 6 Aug 2021 21:31:20 +0100    

Formerly, the numeric code tested whether an integer value of a larger  
type would fit in a smaller type by casting it to the smaller type and  
then testing if the reverse conversion produced the original value.  
That's perfectly fine, except that it caused a test failure on  
buildfarm animal castoroides, most likely due to a compiler bug.  
  
Instead, do these tests by comparing against PG_INT16/32_MIN/MAX. That  
matches existing code in other places, such as int84(), which is more  
widely tested, and so is less likely to go wrong.  
  
While at it, add regression tests covering the numeric-to-int8/4/2  
conversions, and adjust the recently added tests to the style of  
434ddfb79a (on the v11 branch) to make failures easier to diagnose.  
  
Per buildfarm via Tom Lane, reviewed by Tom Lane.  
  
Discussion: https://postgr.es/m/2394813.1628179479%40sss.pgh.pa.us  

commit   : d3ad6566a130988af7693267bc8605b86772618c    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 6 Aug 2021 20:55:59 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 6 Aug 2021 20:55:59 +0200    

commit   : 2f38ec6a157b60291ece1deb072bfff84f317334    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 6 Aug 2021 14:54:59 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 6 Aug 2021 14:54:59 -0400    

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

commit   : 388a81bf4df4fc86a947368d94094e5276c2f255    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Thu, 5 Aug 2021 20:00:02 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Thu, 5 Aug 2021 20:00:02 +0900    

postgres_fdw imported generated columns from the remote tables as plain  
columns, and caused failures like "ERROR: cannot insert a non-DEFAULT  
value into column "foo"" when inserting into the foreign tables, as it  
tried to insert values into the generated columns.  To fix, we do the  
following under the assumption that generated columns in a postgres_fdw  
foreign table are defined so that they represent generated columns in  
the underlying remote table:  
  
* Send DEFAULT for the generated columns to the foreign server on insert  
  or update, not generated column values computed on the local server.  
* Add to postgresImportForeignSchema() an option "import_generated" to  
  include column generated expressions in the definitions of foreign  
  tables imported from a foreign server.  The option is true by default.  
  
The assumption seems reasonable, because that would make a query of the  
postgres_fdw foreign table return values for the generated columns that  
are consistent with the generated expression.  
  
While here, fix another issue in postgresImportForeignSchema(): it tried  
to include column generated expressions as column default expressions in  
the foreign table definitions when the import_default option was enabled.  
  
Per bug #16631 from Daniel Cherniy.  Back-patch to v12 where generated  
columns were added.  
  
Discussion: https://postgr.es/m/16631-e929fe9db0ffc7cf%40postgresql.org  

commit   : a72ad63154256bd3adf1c885f8c3371e9e8ce67a    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Thu, 5 Aug 2021 09:29:13 +0100    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Thu, 5 Aug 2021 09:29:13 +0100    

This fixes a long-standing bug when using to_char() to format a  
numeric value in scientific notation -- if the value's exponent is  
less than -NUMERIC_MAX_DISPLAY_SCALE-1 (-1001), it produced a  
division-by-zero error.  
  
The reason for this error was that get_str_from_var_sci() divides its  
input by 10^exp, which it produced using power_var_int(). However, the  
underflow test in power_var_int() causes it to return zero if the  
result scale is too small. That's not a problem for power_var_int()'s  
only other caller, power_var(), since that limits the rscale to 1000,  
but in get_str_from_var_sci() the exponent can be much smaller,  
requiring a much larger rscale. Fix by introducing a new function to  
compute 10^exp directly, with no rscale limit. This also allows 10^exp  
to be computed more efficiently, without any numeric multiplication,  
division or rounding.  
  
Discussion: https://postgr.es/m/CAEZATCWhojfH4whaqgUKBe8D5jNHB8ytzemL-PnRx+KCTyMXmg@mail.gmail.com  

commit   : 47a573d9113e18864dcb637b72ee3ac1a9ec6b5e    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 3 Aug 2021 12:26:08 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 3 Aug 2021 12:26:08 -0400    

Reported-by: Justin Pryzby  
  
Discussion: https://postgr.es/m/20210803161345.GZ12533@telsasoft.com  
  
Backpatch-through: 9.6  

commit   : 1dd84002060cc2cdc20b6cebd0f6bb2b56c7b35b    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 3 Aug 2021 12:17:58 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 3 Aug 2021 12:17:58 -0400    

Units are _truncated_ to months, but only in back branches since the  
recent commit.  
  
Reported-by: Bryn Llewellyn  
  
Discussion: https://postgr.es/m/BDAE4B56-3337-45A2-AC8A-30593849D6C0@yugabyte.com  
  
Backpatch-through: 9.6 to 14  

commit   : a81c71e3a830aecdfea7a53ae75781e50ba66018    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 3 Aug 2021 11:58:15 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 3 Aug 2021 11:58:15 -0400    

Also create a script that can be run to update them.  
  
Reported-by: Dave Cramer  
  
Discussion: https://postgr.es/m/CADK3HHKawwbOcGwMGnDuAf3-U8YfvTcS8jqDv3UM=niijs3MMA@mail.gmail.com  
  
Backpatch-through: 9.6  

commit   : 0e6cf3c6f43453f848b41a4f87434d2d9c627a34    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 3 Aug 2021 11:27:33 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 3 Aug 2021 11:27:33 -0400    

The previous wording was unclear about the steps needed to upgrade  
extensions, and how to update them after pg_upgrade.  
  
Reported-by: Dave Cramer  
  
Discussion: https://postgr.es/m/CADK3HHKawwbOcGwMGnDuAf3-U8YfvTcS8jqDv3UM=niijs3MMA@mail.gmail.com  
  
Backpatch-through: 9.6  

commit   : 7134b8cacca445115df7115615c063f5cc119b06    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 3 Aug 2021 11:11:51 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 3 Aug 2021 11:11:51 -0400    

Previously tableoid was not mentioned in the partition doc section.  We  
only had a link to the "all the normal rules" of inheritance section.  
  
Reported-by: michal.palenik@freemap.sk  
  
Discussion: https://postgr.es/m/162627031219.693.11508199541771263335@wrigleys.postgresql.org  
  
Backpatch-through: 10  

commit   : 073069075f227f27342e4d935d937141a2ba3910    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 3 Aug 2021 10:57:32 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 3 Aug 2021 10:57:32 -0400    

This is only possible with GNU split, not other versions like BSD split.  
  
Reported-by: jim@jdoherty.net  
  
Discussion: https://postgr.es/m/162653459215.701.6323855956817776386@wrigleys.postgresql.org  
  
Backpatch-through: 9.6  

commit   : 93f99693f9c2a8e0662d847c4ba2abed1628c1d8    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 31 Jul 2021 11:50:14 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 31 Jul 2021 11:50:14 -0400    

As of commit 84f5c2908, executing SQL commands (via SPI or otherwise)  
requires having either an active Portal, or a caller-established  
active snapshot.  We were simply Assert'ing that that's the case.  
But we've now had a couple different reports of people testing  
extensions that didn't meet this requirement, and were confused by  
the resulting crash.  Let's convert the Assert to a test-and-elog,  
in hopes of making the issue clearer for extension authors.  
  
Per gripes from Liu Huailing and RekGRpth.  Back-patch to v11,  
like the prior commit.  
  
Discussion: https://postgr.es/m/OSZPR01MB6215671E3C5956A034A080DFBEEC9@OSZPR01MB6215.jpnprd01.prod.outlook.com  
Discussion: https://postgr.es/m/17035-14607d308ac8643c@postgresql.org  

commit   : 053ec4e0c4e8027bc084d25a846e35ba84ae966c    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Sat, 31 Jul 2021 11:25:39 +0100    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Sat, 31 Jul 2021 11:25:39 +0100    

This fixes a couple of related problems that arise when raising  
numbers to very large powers.  
  
Firstly, when raising a negative number to a very large integer power,  
the result should be well-defined, but the previous code would only  
cope if the exponent was small enough to go through power_var_int().  
Otherwise it would throw an internal error, attempting to take the  
logarithm of a negative number. Fix this by adding suitable handling  
to the general case in power_var() to cope with negative bases,  
checking for integer powers there.  
  
Next, when raising a (positive or negative) number whose absolute  
value is slightly less than 1 to a very large power, the result should  
approach zero as the power is increased. However, in some cases, for  
sufficiently large powers, this would lose all precision and return 1  
instead of 0. This was due to the way that the local_rscale was being  
calculated for the final full-precision calculation:  
  
  local_rscale = rscale + (int) val - ln_dweight + 8  
  
The first two terms on the right hand side are meant to give the  
number of significant digits required in the result ("val" being the  
estimated result weight). However, this failed to account for the fact  
that rscale is clipped to a maximum of NUMERIC_MAX_DISPLAY_SCALE  
(1000), and the result weight might be less then -1000, causing their  
sum to be negative, leading to a loss of precision. Fix this by  
forcing the number of significant digits calculated to be nonnegative.  
It's OK for it to be zero (when the result weight is less than -1000),  
since the local_rscale value then includes a few extra digits to  
ensure an accurate result.  
  
Finally, add additional underflow checks to exp_var() and power_var(),  
so that they consistently return zero for cases like this where the  
result is indistinguishable from zero. Some paths through this code  
already returned zero in such cases, but others were throwing overflow  
errors.  
  
Dean Rasheed, reviewed by Yugo Nagata.  
  
Discussion: http://postgr.es/m/CAEZATCW6Dvq7+3wN3tt5jLj-FyOcUgT5xNoOqce5=6Su0bCR0w@mail.gmail.com  

commit   : 171bf1cea579ce11bc7f0b2986f052022f2b6be1    
  
author   : John Naylor <john.naylor@postgresql.org>    
date     : Fri, 30 Jul 2021 13:50:23 -0400    
  
committer: John Naylor <john.naylor@postgresql.org>    
date     : Fri, 30 Jul 2021 13:50:23 -0400    

The previous coding guarded against -INT_MAX instead of INT_MIN,  
leading to -2147483648 being rejected as out of range.  
  
Per bug #17128 from Kevin Sweet  
  
Discussion: https://www.postgresql.org/message-id/flat/17128-55a8a879727a3e3a%40postgresql.org  
Reviewed-by: Tom Lane  
Backpatch to all supported branches  

commit   : 41d27ee7b870c1a1213704d3c020a01eb55799b0    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 29 Jul 2021 17:26:25 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 29 Jul 2021 17:26:25 -0400    

Buildfarm shows that this test has a further failure mode when a  
checkpoint starts earlier than expected, so we detect a "checkpoint  
completed" line that's not the one we want.  Change the config to try  
and prevent this.  
  
Per buildfarm  
  
Author: Kyotaro Horiguchi <horikyota.ntt@gmail.com>  
Discussion: https://postgr.es/m/20210729.162038.534808353849568395.horikyota.ntt@gmail.com  

commit   : efe169c90090684d2a4ffb0810a0cf2c9b72e19d    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 29 Jul 2021 11:00:00 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 29 Jul 2021 11:00:00 +0900    

pg_verifybackup needs by default pg_waldump to check after a range of  
WAL segments required for a backup, except if --no-parse-wal is  
specified.  The code checked for the presence of the binary pg_waldump  
in an installation and reported an error, but it forgot to properly  
exit().  This could lead to confusing errors reported.  
  
Reviewed-by: Robert Haas, Fabien Coelho  
Discussion: https://postgr.es/m/YQDMdB+B68yePFeT@paquier.xyz  
Backpatch-through: 13  

commit   : a66b05b422d74111f2a6407108f4ba7bdddbb6a0    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Thu, 29 Jul 2021 01:34:13 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Thu, 29 Jul 2021 01:34:13 +0900    

If a file is truncated, we must update minRecoveryPoint. Once a file is  
truncated, there's no going back; it would not be safe to stop recovery  
at a point earlier than that anymore.  
  
Commit 7bffc9b7bf changed xact_redo_commit() so that it updates  
minRecoveryPoint on truncation, but forgot to change xact_redo_abort().  
  
Back-patch to all supported versions.  
  
Reported-by: mengjuan.cmj@alibaba-inc.com  
Author: Fujii Masao  
Reviewed-by: Heikki Linnakangas  
Discussion: https://postgr.es/m/b029fce3-4fac-4265-968e-16f36ff4d075.mengjuan.cmj@alibaba-inc.com  

commit   : aa1e9211ecf7ef410b4313f0e061de087aed0aa2    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Wed, 28 Jul 2021 15:01:40 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Wed, 28 Jul 2021 15:01:40 +1200    

It wasn't all that clear which lock levels, if any, would be held on the  
DEFAULT partition during an ATTACH PARTITION operation.  
  
Also, clarify which locks will be taken if the DEFAULT partition or the  
table being attached are themselves partitioned tables.  
  
Here I'm only backpatching to v12 as before then we obtained an ACCESS  
EXCLUSIVE lock on the partitioned table.  It seems much less relevant to  
mention which locks are taken on other tables when the partitioned table  
itself is locked with an ACCESS EXCLUSIVE lock.  
  
Author: Matthias van de Meent, David Rowley  
Discussion: https://postgr.es/m/CAEze2WiTB6iwrV8W_J=fnrnZ7fowW3qu-8iQ8zCHP3FiQ6+o-A@mail.gmail.com  
Backpatch-through: 12  

commit   : b8f91d7f926368115c27b978c939174c96df1a5f    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 27 Jul 2021 15:44:12 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 27 Jul 2021 15:44:12 -0400    

This changes the behavior of examining the pg_file_settings view after  
changing a config option that requires restart.  The user needs to know  
that any change of such options does not take effect until a restart,  
and this worked correctly if the line is edited without removing it.  
However, for the case where the line is removed altogether, the flag  
doesn't get set, because a flag was only set in set_config_option, but  
that's not called for lines removed.  Repair.  
  
(Ref.: commits 62d16c7fc561 and a486e35706ea)  
  
Author: Álvaro Herrera <alvherre@alvh.no-ip.org>  
Reviewed-by: Daniel Gustafsson <daniel@yesql.se>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/202107262302.xsfdfc5sb7sh@alvherre.pgsql  

commit   : 92913fc290f3adb3fe937485474a11ac6708e4b0    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Wed, 28 Jul 2021 01:21:52 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Wed, 28 Jul 2021 01:21:52 +0900    

The error messages using the word "non-negative" are confusing  
because it's ambiguous about whether it accepts zero or not.  
This commit improves those error messages by replacing it with  
less ambiguous word like "greater than zero" or  
"greater than or equal to zero".  
  
Also this commit added the note about the word "non-negative" to  
the error message style guide, to help writing the new error messages.  
  
When postgres_fdw option fetch_size was set to zero, previously  
the error message "fetch_size requires a non-negative integer value"  
was reported. This error message was outright buggy. Therefore  
back-patch to all supported versions where such buggy error message  
could be thrown.  
  
Reported-by: Hou Zhijie  
Author: Bharath Rupireddy  
Reviewed-by: Kyotaro Horiguchi, Fujii Masao  
Discussion: https://postgr.es/m/OS0PR01MB5716415335A06B489F1B3A8194569@OS0PR01MB5716.jpnprd01.prod.outlook.com  

commit   : d629fcf4b36ca8c1e4e9677745ff7d725433ee19    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 26 Jul 2021 22:54:35 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 26 Jul 2021 22:54:35 -0400    

Reported-by: troy@frericks.us  
  
Discussion: https://postgr.es/m/162614304115.701.2392941350859387646@wrigleys.postgresql.org  
  
Backpatch-through: 13  

commit   : 0a5e708e2bd87adb0779d7c8758e5743cc1c0adf    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 26 Jul 2021 22:38:14 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 26 Jul 2021 22:38:14 -0400    

Add pg_resetxlog -u option to set the oldest xid in pg_control.  
Previously -x set this value be -2 billion less than the -x value.  
However, this causes the server to immediately scan all relation's  
relfrozenxid so it can advance pg_control's oldest xid to be inside the  
autovacuum_freeze_max_age range, which is inefficient and might disrupt  
diagnostic recovery.  pg_upgrade will use this option to better create  
the new cluster to match the old cluster.  
  
Reported-by: Jason Harvey, Floris Van Nee  
  
Discussion: https://postgr.es/m/20190615183759.GB239428@rfd.leadboat.com, 87da83168c644fd9aae38f546cc70295@opammb0562.comp.optiver.com  
  
Author: Bertrand Drouvot  
  
Backpatch-through: 9.6  

commit   : 882d15144bbb21856676ff046faee1e9a580e3e4    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 25 Jul 2021 23:25:15 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 25 Jul 2021 23:25:15 -0400    

Turns out the buildfarm hasn't been testing this, which will soon change.  
  
Julien Rouhaud, per report from me  
  
Discussion: https://postgr.es/m/42557.1627229005@sss.pgh.pa.us  

commit   : 2c7395aad7e849235faac4ead5f69700cfd3c21b    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 26 Jul 2021 11:14:11 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 26 Jul 2021 11:14:11 +0900    

These have been introduced by 7fbe0c8, and could happen for  
pg_basebackup and pg_receivewal.  
  
Per report from Coverity for the ones in walmethods.c, I have spotted  
the ones in receivelog.c after more review.  
  
Backpatch-through: 10  

commit   : 2b8f3f5a7c0ede24903782fcffe2553fec01bfbe    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 25 Jul 2021 14:02:27 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 25 Jul 2021 14:02:27 -0400    

The point of introducing the hash_mem_multiplier GUC was to let users  
reproduce the old behavior of hash aggregation, i.e. that it could use  
more than work_mem at need.  However, the implementation failed to get  
the job done on Win64, where work_mem is clamped to 2GB to protect  
various places that calculate memory sizes using "long int".  As  
written, the same clamp was applied to hash_mem.  This resulted in  
severe performance regressions for queries requiring a bit more than  
2GB for hash aggregation, as they now spill to disk and there's no  
way to stop that.  
  
Getting rid of the work_mem restriction seems like a good idea, but  
it's a big job and could not conceivably be back-patched.  However,  
there's only a fairly small number of places that are concerned with  
the hash_mem value, and it turns out to be possible to remove the  
restriction there without too much code churn or any ABI breaks.  
So, let's do that for now to fix the regression, and leave the  
larger task for another day.  
  
This patch does introduce a bit more infrastructure that should help  
with the larger task, namely pg_bitutils.h support for working with  
size_t values.  
  
Per gripe from Laurent Hasson.  Back-patch to v13 where the  
behavior change came in.  
  
Discussion: https://postgr.es/m/997817.1627074924@sss.pgh.pa.us  
Discussion: https://postgr.es/m/MN2PR15MB25601E80A9B6D1BA6F592B1985E39@MN2PR15MB2560.namprd15.prod.outlook.com  

commit   : 8d091922ffcc27323ffe2127e228e302b9f153f4    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Mon, 16 Nov 2020 18:27:51 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Mon, 16 Nov 2020 18:27:51 +0900    

This commit changes the startup process in the standby server so that  
it handles the interrupt signals after waiting for wal_retrieve_retry_interval  
on the latch and resetting it, before entering another wait on the latch.  
This change causes the standby server to promptly handle interrupt signals.  
  
Otherwise, previously, there was the case where the standby needs to  
wait extra five seconds to shutdown when the shutdown request arrived  
while the startup process was waiting for wal_retrieve_retry_interval  
on the latch.  
  
Author: Fujii Masao, but implementation idea is from Soumyadeep Chakraborty  
Reviewed-by: Soumyadeep Chakraborty  
Discussion: https://postgr.es/m/9d7e6ab0-8a53-ddb9-63cd-289bcb25fe0e@oss.nttdata.com  
  
Per discussion of BUG #17073, back-patch to all supported versions.  
Discussion: https://postgr.es/m/17073-1a5fdaed0fa5d4d0@postgresql.org  

commit   : f47408cdc19c2bbe357703afd81037b6d12ed3ba    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 24 Jul 2021 18:35:52 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 24 Jul 2021 18:35:52 -0400    

We have an implementation restriction that PREPARE TRANSACTION can't  
handle cases where both session-lifespan and transaction-lifespan locks  
are held on the same lockable object.  (That's because we'd otherwise  
need to acquire a new PROCLOCK entry during post-prepare cleanup, which  
is an operation that might fail.  The situation can only arise with odd  
usages of advisory locks, so removing the restriction is probably not  
worth the amount of effort it would take.)  AtPrepare_Locks attempted  
to enforce this, but its logic was many bricks shy of a load, because  
it only detected cases where the session and transaction locks had the  
same lockmode.  Locks of different modes on the same object would lead  
to the rather unhelpful message "PANIC: we seem to have dropped a bit  
somewhere".  
  
To fix, build a transient hashtable with one entry per locktag,  
not one per locktag + mode, and use that to detect conflicts.  
  
Per bug #17122 from Alexander Pyhalov.  This bug is ancient,  
so back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/17122-04f3c32098a62233@postgresql.org  

commit   : c0a6f83deba9c55459e52ad4475207f62354a1f1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 24 Jul 2021 13:41:17 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 24 Jul 2021 13:41:17 -0400    

We previously took a hard-line attitude that callers should never print  
a null string pointer, and doing so is worthy of an assertion failure  
or crash.  However, we've long since flushed out any easy-to-find bugs  
of that nature.  What remains is a lot of code that perhaps could fail  
that way in hard-to-reach corner cases.  For example, in something as  
simple as  
    ereport(ERROR,  
            (errcode(ERRCODE_UNDEFINED_OBJECT),  
             errmsg("constraint \"%s\" for table \"%s\" does not exist",  
                    conname, get_rel_name(relid))));  
one must wonder whether it's completely guaranteed that get_rel_name  
cannot return NULL in this context.  If such a situation did occur,  
the existing policy converts what might be a pretty minor bug into  
a server crash condition.  This is not good for robustness.  
  
Hence, let's follow the lead of glibc and print "(null)" instead  
of failing.  We should, of course, still consider it a bug if that  
behavior is reachable in ordinary use; but crashing seems less  
desirable than not crashing.  
  
This fix works across-the-board in v12 and up, where we always use  
src/port/snprintf.c.  Before that, on most platforms we're at the mercy  
of the local libc, but it appears that Solaris 10 is the only supported  
platform where we'd still get a crash.  Most other platforms such as  
*BSD, macOS, and Solaris 11 have adopted glibc's behavior at some  
point.  (AIX and HPUX just print "" not "(null)", but that's close  
enough.)  I've not checked what Windows' native printf would do, but  
it doesn't matter because we've long used snprintf.c on that platform.  
  
In v12 and up, also const-ify related code so that we're not casting  
away const on the constant string.  This is just neatnik-ism, since  
next to no compilers will warn about that.  
  
Discussion: https://postgr.es/m/17098-b960f3616c861f83@postgresql.org  

commit   : 1cfc9f2ef61df81fa54a697081e372672c23e980    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Thu, 22 Jul 2021 14:11:17 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Thu, 22 Jul 2021 14:11:17 +1200    

Code inlined by LLVM can crash or fail with "Relocation type not  
implemented yet!" if it tries to access thread local variables.  Don't  
inline such code.  
  
Back-patch to 11, where LLVM arrived.  Bug #16696.  
  
Author: Dmitry Marakasov <amdmi3@amdmi3.ru>  
Reviewed-by: Andres Freund <andres@anarazel.de>  
Discussion: https://postgr.es/m/16696-29d944a33801fbfe@postgresql.org  

commit   : 8344979d5bbc63aa8fb8c804bd933c887a2abb58    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 21 Jul 2021 18:03:33 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 21 Jul 2021 18:03:33 -0400    

Now that we're not having to wedge this into the straitjacket of  
the old operator table format, we can add another example to  
clarify the point about left-to-right associativity.  
  
Per suggestion from mdione at grulic.org.ar.  
  
https://postgr.es/m/162661954599.693.13700316547731859171@wrigleys.postgresql.org  

commit   : 0b5dc1f171c4c7433cff2949d7bf64aa912765b3    
  
author   : John Naylor <john.naylor@postgresql.org>    
date     : Wed, 21 Jul 2021 10:17:07 -0400    
  
committer: John Naylor <john.naylor@postgresql.org>    
date     : Wed, 21 Jul 2021 10:17:07 -0400    

In postgresql.conf, memory and file size GUCs can be specified with "B"  
(bytes) as of b06d8e58b. Likewise, time GUCs can be specified with "us"  
(microseconds) as of caf626b2c. Update postgres.conf.sample to reflect  
that fact.  
  
Pavel Luzanov  
  
Backpatch to v12, which is the earliest version that allows both of  
these units. A separate commit will document the "B" case for v11.  
  
Discussion: https://www.postgresql.org/message-id/flat/f10d16fc-8fa0-1b3c-7371-cb3a35a13b7a%40postgrespro.ru  

commit   : df3264e73f6fa99fd04b97905d53050de011f035    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Wed, 21 Jul 2021 13:52:37 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Wed, 21 Jul 2021 13:52:37 +0900    

Back-patch to v10 where pg_import_system_collations() was added.  
  
Author: Atsushi Torikoshi  
Reviewed-by: Fujii Masao  
Discussion: https://postgr.es/m/b7f484692a3e283710032e68b7f40617@oss.nttdata.com  

commit   : 0fce76b99d21e2c359d8355a9e3bfe4c3e3f17c9    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 20 Jul 2021 13:01:48 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 20 Jul 2021 13:01:48 -0400    

If an error was raised during our initial attempt to check whether  
a successfully-compiled expression is "simple", subsequent calls of  
exec_stmt_execsql would suppose that stmt->mod_stmt was already computed  
when it had not been.  This could lead to assertion failures in debug  
builds; in production builds the effect would typically be to act as  
if INTO STRICT had been specified even when it had not been.  Of course  
that only matters if the subsequent attempt to execute the expression  
succeeds, so that the problem can only be reached by fixing a failure  
in some referenced, inline-able SQL function and then retrying the  
calling plpgsql function in the same session.  
  
(There might be even-more-obscure ways to change the expression's  
behavior without changing the plpgsql function, but that one seems  
like the only one people would be likely to hit in practice.)  
  
The most foolproof way to fix this would be to arrange for  
exec_prepare_plan to not set expr->plan until we've finished the  
subsidiary simple-expression check.  But it seems hard to do that  
without creating reference-count leak issues.  So settle for documenting  
the hazard in a comment and fixing exec_stmt_execsql to test separately  
for whether it's computed stmt->mod_stmt.  (That adds a test-and-branch  
per execution, but hopefully that's negligible in context.)  In v11 and  
up, also fix exec_stmt_call which had a variant of the same issue.  
  
Per bug #17113 from Alexander Lakhin.  Back-patch to all  
supported branches.  
  
Discussion: https://postgr.es/m/17113-077605ce00e0e7ec@postgresql.org  

commit   : fb2b86015a9f3e2e59ddbb59e18cda98363cbd7b    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 20 Jul 2021 12:12:51 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 20 Jul 2021 12:12:51 +0900    

The logic handling the opening of new WAL segments was fuzzy when using  
--compress if a partial, non-compressed, segment with the same base name  
existed in the repository storing those files.  In this case, using  
--compress would cause the code to first check for the existence and the  
size of a non-compressed segment, followed by the opening of a new  
compressed, partial, segment.  The code was accidentally working  
correctly on most platforms as the buildfarm has proved, except  
bowerbird where gzflush() could fail in this code path.  It is wrong  
anyway to take the code path used pre-padding when creating a new  
partial, non-compressed, segment, so let's fix it.  
  
Note that this issue exists when users mix successive runs of  
pg_receivewal with or without compression, as discovered with the tests  
introduced by ffc9dda.  
  
While on it, this refactors the code so as code paths that need to know  
about the ".gz" suffix are down from four to one in walmethods.c, easing  
a bit the introduction of new compression methods.  This addresses a  
second issue where log messages generated for an unexpected failure  
would not show the compressed segment name involved, which was  
confusing, printing instead the name of the non-compressed equivalent.  
  
Reported-by: Georgios Kokolatos  
Discussion: https://postgr.es/m/YPDLz2x3o1aX2wRh@paquier.xyz  
Backpatch-through: 10  

commit   : ce413eba411633c5c5c9e326d6d0313c9764c711    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 19 Jul 2021 17:21:07 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 19 Jul 2021 17:21:07 -0400    

Further fix the test code in ead9e51e8236, this time by waiting until  
the checkpoint has completed before moving on; this ensures that the  
WAL segment removal has already happened when we create the next slot.  
  
Author: Kyotaro Horiguchi <horikyota.ntt@gmail.com>  
Discussion: https://postgr.es/m/20210719.111318.2042379313472032754.horikyota.ntt@gmail.com  

commit   : bfa2a926daf812bbda2038aec073344693954f16    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Mon, 19 Jul 2021 11:04:21 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Mon, 19 Jul 2021 11:04:21 +0530    

We don't allow to create replication slot_name as an empty string ('') via  
SQL API pg_create_logical_replication_slot() but it is allowed to be set  
via Alter Subscription command. This will lead to apply worker repeatedly  
keep trying to stream data via slot_name '' and the user is not allowed to  
create the slot with that name.  
  
Author: Japin Li  
Reviewed-By: Ranier Vilela, Amit Kapila  
Backpatch-through: 10, where it was introduced  
Discussion: https://postgr.es/m/MEYP282MB1669CBD98E721C77CA696499B61A9@MEYP282MB1669.AUSP282.PROD.OUTLOOK.COM  

commit   : e159368027e342468bb7f9db0d8d42a76dc42f23    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 19 Jul 2021 12:39:53 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 19 Jul 2021 12:39:53 +0900    

This grammar has no effect as there are no dependencies on statistics,  
but it is supported by the parser.  This is more consistent with the  
other DROP commands.  
  
Author: Vignesh C  
Discussion: https://postgr.es/m/CALDaNm1LA=yNmzcSfy+0oe6CEAgsxXRf_-UutE3ZncFi8QkFNQ@mail.gmail.com  
Backpatch-through: 10  

commit   : 7099ba0580356bb455d75de4f6cd0faa046e1a10    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Sat, 17 Jul 2021 13:19:17 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Sat, 17 Jul 2021 13:19:17 -0400    

The new test code added in ead9e51e8236 is racy -- it hinges on  
shared-memory state, which changes before the WARNING message is logged.  
Put it the other way around.  
  
Backpatch to 13.  
  
Author: Álvaro Herrera <alvherre@alvh.no-ip.org>  
Discussion: https://postgr.es/m/202107161809.zclasccpfcg3@alvherre.pgsql  

commit   : 35e9d26a1bfe0d4fb726edc5c03b8e4fcc0a9869    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 17 Jul 2021 11:52:54 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 17 Jul 2021 11:52:54 -0400    

We had documentation of default_transaction_isolation et al,  
but for some reason not of transaction_isolation et al.  
AFAICS this is just an ancient oversight, so repair.  
  
Per bug #17077 from Yanliang Lei.  
  
Discussion: https://postgr.es/m/17077-ade8e166a01e1374@postgresql.org  

commit   : cc340af3345370c7faf0ceba7dece97b40312cb2    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 16 Jul 2021 17:29:22 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 16 Jul 2021 17:29:22 -0400    

pg_dump failed to preserve the 'enabled' flag (which can be not only  
disabled, but also REPLICA or ALWAYS) for partitions which had it  
changed from their respective parents.  Attempt to handle that by  
including a definition for such triggers in the dump, but replace the  
standard CREATE TRIGGER line with an ALTER TRIGGER line.  
  
Backpatch to 11, where these triggers can exist.  In branches 11 and 12,  
pick up a few test lines from commit b9b408c48724 to verify that  
pg_upgrade is okay with these arrangements.  
  
Co-authored-by: Justin Pryzby <pryzby@telsasoft.com>  
Co-authored-by: Álvaro Herrera <alvherre@alvh.no-ip.org>  
Discussion: https://postgr.es/m/20200930223450.GA14848@telsasoft.com  

commit   : c31516ae5b43d8a1a99e8e43abc84d791ce15ef1    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 16 Jul 2021 13:01:43 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 16 Jul 2021 13:01:43 -0400    

When triggers are cloned from partitioned tables to their partitions,  
the 'tgenabled' flag (origin/replica/always/disable) was not propagated.  
Make it so that the flag on the trigger on partition is initially set to  
the same value as on the partitioned table.  
  
Add a test case to verify the behavior.  
  
Backpatch to 11, where this appeared in commit 86f575948c77.  
  
Author: Álvaro Herrera <alvherre@alvh.no-ip.org>  
Reported-by: Justin Pryzby <pryzby@telsasoft.com>  
Discussion: https://postgr.es/m/20200930223450.GA14848@telsasoft.com  

commit   : 866237a6fa01a128325df41ad39b41ea3363c9a9    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 16 Jul 2021 12:07:30 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 16 Jul 2021 12:07:30 -0400    

When some slots are invalidated due to the max_slot_wal_keep_size limit,  
the old segment horizon should move forward to stay within the limit.  
However, in commit c6550776394e we forgot to call KeepLogSeg again to  
recompute the horizon after invalidating replication slots.  In cases  
where other slots remained, the limits would be recomputed eventually  
for other reasons, but if all slots were invalidated, the limits would  
not move at all afterwards.  Repair.  
  
Backpatch to 13 where the feature was introduced.  
  
Author: Kyotaro Horiguchi <horikyota.ntt@gmail.com>  
Reported-by: Marcin Krupowicz <mk@071.ovh>  
Discussion: https://postgr.es/m/17103-004130e8f27782c9@postgresql.org  

commit   : 91a1651057b15809058acb174fead131ef8efab8    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 15 Jul 2021 11:00:43 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 15 Jul 2021 11:00:43 -0400    

Autoconf's AC_CHECK_DECLS() always defines HAVE_DECL_whatever  
as 1 or 0, but some of the entries in msvc/Solution.pm showed  
such symbols as "undef" instead of 0.  Fix that for consistency.  
There's no live bug in current usages AFAICS, but it's not hard  
to imagine one creeping in if more-complex #if tests get added.  
  
Back-patch to v13, which is as far back as Solution.pm contains  
this data.  The inconsistency still exists in the manually-filled  
pg_config_ext.h.win32 files of older branches; but as long as the  
problem is only latent, it doesn't seem worth the trouble to  
clean things up there.  
  
Discussion: https://postgr.es/m/3185430.1626133592@sss.pgh.pa.us  

commit   : 5226243459f11e0029c803674aabfb3bc25192f7    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 14 Jul 2021 17:15:18 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 14 Jul 2021 17:15:18 +0900    

Some commands of ALTER TABLE could fail with the following error:  
ERROR:  "tab" is of the wrong type  
  
This error is unexpected, as all the code paths leading to  
ATWrongRelkindError() should use a supported set of relkinds to generate  
correct error messages.  This commit closes the gap with such mistakes,  
by adding all the missing relkind combinations.  Tests are added to  
check all the problems found.  Note that some combinations are not used,  
but these are left around as it could have an impact on applications  
relying on this code.  
  
2ed532e has done a much larger refactoring on HEAD to make such error  
messages easier to manage in the long-term, so nothing is needed there.  
  
Author: Kyotaro Horiguchi  
Reviewed-by: Peter Eisentraut, Ahsan Hadi, Michael Paquier  
Discussion: https://postgr.es/m/20210216.181415.368926598204753659.horikyota.ntt@gmail.com  
Backpatch-through: 11  

commit   : 2fde8e49a24706773d0573d3b8888a76353094fc    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Tue, 13 Jul 2021 13:28:19 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Tue, 13 Jul 2021 13:28:19 +1200    

41469253e went to the trouble of removing a theoretical bug from  
free_sort_tuple by checking if the tuple was NULL before freeing it. Let's  
make this a little more robust by also setting the tuple to NULL so that  
should we be called again we won't end up doing a pfree on the already  
pfree'd tuple. Per advice from Tom Lane.  
  
Discussion: https://postgr.es/m/3188192.1626136953@sss.pgh.pa.us  
Backpatch-through: 9.6, same as 41469253e  

commit   : 204f646a22f294a359ec463c128d01e1bc9117c5    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Tue, 13 Jul 2021 12:42:43 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Tue, 13 Jul 2021 12:42:43 +1200    

This fixes a theoretical bug in tuplesort.c which, if a bounded sort was  
used in combination with a byval Datum sort (tuplesort_begin_datum), when  
switching the sort to a bounded heap in make_bounded_heap(), we'd call  
free_sort_tuple().  The problem was that when sorting Datums of a byval  
type, the tuple is NULL and free_sort_tuple() would free the memory for it  
regardless of that.  This would result in a crash.  
  
Here we fix that simply by adding a check to see if the tuple is NULL  
before trying to disassociate and free any memory belonging to it.  
  
The reason this bug is only theoretical is that nowhere in the current  
code base do we do tuplesort_set_bound() when performing a Datum sort.  
However, let's backpatch a fix for this as if any extension uses the code  
in this way then it's likely to cause problems.  
  
Author: Ronan Dunklau  
Discussion: https://postgr.es/m/CAApHDvpdoqNC5FjDb3KUTSMs5dg6f+XxH4Bg_dVcLi8UYAG3EQ@mail.gmail.com  
Backpatch-through: 9.6, oldest supported version  

commit   : 0455f35fd4ecff99df49ee7137a53ba2b6b3c24b    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 12 Jul 2021 22:07:35 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 12 Jul 2021 22:07:35 +0200    

commit   : 2c27cc26592a3f4f6ad1300d976073a256c57c9b    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 12 Jul 2021 11:13:33 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 12 Jul 2021 11:13:33 +0300    

This should have been removed in commit 7e30c186da, which split the loop  
into two. Only the first loop uses the 'from' variable; updating it in  
the second loop is bogus. It was never read after the first loop, so this  
was harmless and surely optimized away by the compiler, but let's be tidy.  
  
Backpatch to all supported versions.  
  
Author: Ranier Vilela  
Discussion: https://www.postgresql.org/message-id/CAEudQAoWq%2BAL3BnELHu7gms2GN07k-np6yLbukGaxJ1vY-zeiQ%40mail.gmail.com  

commit   : 1c612bc98ec363e2464cce66526b75a0d08d657e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 11 Jul 2021 12:54:24 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 11 Jul 2021 12:54:24 -0400    

Although we were careful to lock the object being added or dropped,  
we failed to get any sort of lock on the extension itself.  This  
allowed the ALTER to proceed in parallel with a DROP EXTENSION,  
which is problematic for a couple of reasons.  If both commands  
succeeded we'd be left with a dangling link in pg_depend, which  
would cause problems later.  Also, if the ALTER failed for some  
reason, it might try to print the extension's name, and that could  
result in a crash or (in older branches) a silly error message  
complaining about extension "(null)".  
  
Per bug #17098 from Alexander Lakhin.  Back-patch to all  
supported branches.  
  
Discussion: https://postgr.es/m/17098-b960f3616c861f83@postgresql.org  

commit   : edd9a2bf741be95aa771b9fcacb2ce7378fb9121    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Fri, 9 Jul 2021 14:15:48 -0700    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Fri, 9 Jul 2021 14:15:48 -0700    

If an error occurred in the wrong place, it was possible to leave an  
unintialized entry in the hash table, leading to a crash. Fixed.  
  
Also, be more careful about the order of operations so that an  
allocation error doesn't leak memory in CacheMemoryContext or  
unnecessarily advance NextRecordTypmod.  
  
Backpatch through version 11. Earlier versions (prior to 35ea75632a5)  
do not exhibit the problem, because an uninitialized hash entry  
contains a valid empty list.  
  
Author: Sait Talha Nisanci <Sait.Nisanci@microsoft.com>  
Reviewed-by: Andres Freund  
Discussion: https://postgr.es/m/HE1PR8303MB009069D476225B9A9E194B8891779@HE1PR8303MB0090.EURPRD83.prod.outlook.com  
Backpatch-through: 11  

commit   : 9fca23c1d6de2664aa447e4ef72b9bf60d3bdf35    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 10 Jul 2021 13:19:31 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 10 Jul 2021 13:19:31 -0400    

Sigh ... I was expecting AC_CHECK_LIB to do something it didn't,  
namely update LIBS.  This led to not finding ldap_initialize.  
Fix by moving the probe for ldap_initialize.  In some sense this  
is more correct anyway, since (at least for now) we care about  
whether ldap_initialize exists in libldap not libldap_r.  
  
Per buildfarm member elver and local testing.  
  
Discussion: https://postgr.es/m/17083-a19190d9591946a7@postgresql.org  

commit   : f23a9b8a49af1ef89dd65399867ca21318ae6b8e    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Sat, 10 Jul 2021 12:46:13 +0100    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Sat, 10 Jul 2021 12:46:13 +0100    

This fixes an overflow error when using the numeric * operator if the  
result has more than 16383 digits after the decimal point by rounding  
the result. Overflow errors should only occur if the result has too  
many digits *before* the decimal point.  
  
Discussion: https://postgr.es/m/CAEZATCUmeFWCrq2dNzZpRj5+6LfN85jYiDoqm+ucSXhb9U2TbA@mail.gmail.com  

commit   : 32d0bdbfcf2f1f024f24797eda14a250c13fa62e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 9 Jul 2021 16:59:07 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 9 Jul 2021 16:59:07 -0400    

I incorrectly diagnosed the reason why hoverfly is unhappy.  
Looking closer, it appears that it fails to link libldap  
unless libssl is also present; so the problem was my  
idea of clearing LIBS before making the check.  Revert  
to essentially the original coding, except that instead  
of failing when libldap_r isn't there, use libldap.  
  
Per buildfarm member hoverfly.  
  
Discussion: https://postgr.es/m/17083-a19190d9591946a7@postgresql.org  

commit   : cbcf5ffb180ad18fcebe8b21ab1ec1e90d3a3b14    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 9 Jul 2021 14:15:41 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 9 Jul 2021 14:15:41 -0400    

In commit d0a02bdb8, I'd supposed that uniformly probing for  
ldap_bind would make the intent clearer.  However, that seems  
not to work on AIX, for obscure reasons (maybe it's a macro  
there?).  Revert to the former behavior of probing  
ldap_simple_bind for thread-safe cases and ldap_bind otherwise.  
  
Per buildfarm member hoverfly.  
  
Discussion: https://postgr.es/m/17083-a19190d9591946a7@postgresql.org  

commit   : 9807b9aedc6e8b8a497db161b3d2d9f83648ea5b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 9 Jul 2021 13:38:24 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 9 Jul 2021 13:38:24 -0400    

Commit 7266d0997 added code to pull up simple constant function  
results, converting the RTE_FUNCTION RTE to a dummy RTE_RESULT  
RTE since it no longer need be scanned.  But I forgot to clear  
the LATERAL flag if the RTE has it set.  If the function reduced  
to a constant, it surely contains no lateral references so this  
simplification is logically OK.  It's needed because various other  
places will Assert that RESULT RTEs aren't LATERAL.  
  
Per bug #17097 from Yaoguang Chen.  Back-patch to v13 where the  
faulty code came in.  
  
Discussion: https://postgr.es/m/17097-3372ef9f798fc94f@postgresql.org  

commit   : 55cccdfdf1ee63fd8e818c2aa885f4d357773adc    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 9 Jul 2021 12:38:55 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 9 Jul 2021 12:38:55 -0400    

The separate libldap_r is gone and libldap itself is now always  
thread-safe.  Unfortunately there seems no easy way to tell by  
inspection whether libldap is thread-safe, so we have to take  
it on faith that libldap is thread-safe if there's no libldap_r.  
That should be okay, as it appears that libldap_r was a standard  
part of the installation going back at least 20 years.  
  
Report and patch by Adrian Ho.  Back-patch to all supported  
branches, since people might try to build any of them with  
a newer OpenLDAP.  
  
Discussion: https://postgr.es/m/17083-a19190d9591946a7@postgresql.org  

commit   : 6edccac166fa55065e88dcc82fc5ed6751485c42    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 9 Jul 2021 11:02:26 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 9 Jul 2021 11:02:26 -0400    

Since the executor can't cope with a utility statement appearing  
as a node of a plan tree, we can't support cases where a rewrite  
rule inserts a NOTIFY into an INSERT/UPDATE/DELETE command appearing  
in a WITH clause of a larger query.  (One can imagine ways around  
that, but it'd be a new feature not a bug fix, and so far there's  
been no demand for it.)  RewriteQuery checked for this, but it  
missed the case where the DML command rewrites to *only* a NOTIFY.  
That'd lead to crashes later on in planning.  Add the missed check,  
and improve the level of testing of this area.  
  
Per bug #17094 from Yaoguang Chen.  It's been busted since WITH  
was introduced, so back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/17094-bf15dff55eaf2e28@postgresql.org  

commit   : 7dd2379df7099a13b04f3977dd78b498cdc437e5    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Fri, 9 Jul 2021 17:51:48 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Fri, 9 Jul 2021 17:51:48 +1200    

Commit 6753333f stopped using semaphores as the sleep/wake mechanism for  
heavyweight locks, but some obsolete references to that scheme remained  
in comments.  As with similar commit 25b93a29, back-patch all the way.  
  
Reviewed-by: Daniel Gustafsson <daniel@yesql.se>  
Discussion: https://postgr.es/m/CA%2BhUKGLafjB1uzXcy%3D%3D2L3cy7rjHkqOVn7qRYGBjk%3D%3DtMJE7Yg%40mail.gmail.com  

commit   : 87103002c89a80411a96068da2d643d0bc2804e9    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Fri, 9 Jul 2021 15:12:31 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Fri, 9 Jul 2021 15:12:31 +1200    

I accidentally missed adding this when adjusting 55fe60938 for back  
patching.  This adjustment was made for 9.6 to 13. 14 and master are not  
affected.  
  
Discussion: https://postgr.es/m/CAApHDvp=twCsGAGQG=A=cqOaj4mpknPBW-EZB-sd+5ZS5gCTtA@mail.gmail.com  

commit   : 6f88b68ff4adfe17a80c0befdf9bb8b0a8218def    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Fri, 9 Jul 2021 14:04:49 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Fri, 9 Jul 2021 14:04:49 +1200    

Due to how pg_size_pretty(bigint) was implemented, it's possible that when  
given a negative number of bytes that the returning value would not match  
the equivalent positive return value when given the equivalent positive  
number of bytes.  This was due to two separate issues.  
  
1. The function used bit shifting to convert the number of bytes into  
larger units.  The rounding performed by bit shifting is not the same as  
dividing.  For example -3 >> 1 = -2, but -3 / 2 = -1.  These two  
operations are only equivalent with positive numbers.  
  
2. The half_rounded() macro rounded towards positive infinity.  This meant  
that negative numbers rounded towards zero and positive numbers rounded  
away from zero.  
  
Here we fix #1 by dividing the values instead of bit shifting.  We fix #2  
by adjusting the half_rounded macro always to round away from zero.  
  
Additionally, adjust the pg_size_pretty(numeric) function to be more  
explicit that it's using division rather than bit shifting.  A casual  
observer might have believed bit shifting was used due to a static  
function being named numeric_shift_right.  However, that function was  
calculating the divisor from the number of bits and performed division.  
Here we make that more clear.  This change is just cosmetic and does not  
affect the return value of the numeric version of the function.  
  
Here we also add a set of regression tests both versions of  
pg_size_pretty() which test the values directly before and after the  
function switches to the next unit.  
  
This bug was introduced in 8a1fab36a. Prior to that negative values were  
always displayed in bytes.  
  
Author: Dean Rasheed, David Rowley  
Discussion: https://postgr.es/m/CAEZATCXnNW4HsmZnxhfezR5FuiGgp+mkY4AzcL5eRGO4fuadWg@mail.gmail.com  
Backpatch-through: 9.6, where the bug was introduced.  

commit   : 306c5e05e20fe37fcfe7dcde3ce4677b05a25285    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Wed, 7 Jul 2021 21:54:47 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Wed, 7 Jul 2021 21:54:47 +0900    

This commit fixes wrong wording like "a fewer kinds"  
in the description about track_planning option.  
  
Back-patch to v13 where pg_stat_statements.track_planning was added.  
  
Author: Justin Pryzby  
Reviewed-by: Julien Rouhaud, Fujii Masao  
Discussion: https://postgr.es/m/20210418233615.GB7256@telsasoft.com  

commit   : bee18616a6508d054da65902bfded41117113cb3    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 6 Jul 2021 12:36:13 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 6 Jul 2021 12:36:13 -0400    

As in 50371df26, this is a bad idea since the callback can't really  
know what error is being thrown and thus whether or not it is safe  
to attempt catalog accesses.  Rather than pushing said accesses into  
the mainline code where they'd usually be a waste of cycles, we can  
look at the query's rangetable instead.  
  
This change does mean that we'll be printing query aliases (if any  
were used) rather than the table or column's true name.  But that  
doesn't seem like a bad thing: it's certainly a more useful definition  
in self-join cases, for instance.  In any case, it seems unlikely that  
any applications would be depending on this detail, so it seems safe  
to change.  
  
Patch by me.  Original complaint by Andres Freund; Bharath Rupireddy  
noted the connection to conversion_error_callback.  
  
Discussion: https://postgr.es/m/20210106020229.ne5xnuu6wlondjpe@alap3.anarazel.de  

commit   : fa44348105983fb8a20a1eb145ca036e77807ba0    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 6 Jul 2021 10:34:51 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 6 Jul 2021 10:34:51 -0400    

Our code has supported fractional-minute UTC offsets for ages, but  
there was no mention of the possibility in the main docs, and only  
a very indirect reference in Appendix B.  Improve that.  
  
Discussion: https://postgr.es/m/162543102827.697.5755498651217979813@wrigleys.postgresql.org  

commit   : 2f487116e9988615d05a6c380c3ff8fa8a4286f8    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 5 Jul 2021 16:51:57 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 5 Jul 2021 16:51:57 -0400    

Commit 03ffc4d6d added logic to bypass all caching behavior in  
LookupOpclassInfo when CLOBBER_CACHE_ALWAYS is enabled.  It doesn't  
look like I stopped to think much about what that would cost, but  
recent investigation shows that the cost is enormous: it roughly  
doubles the time needed for cache-clobber test runs.  
  
There does seem to be value in this behavior when trying to test  
the opclass-cache loading logic itself, but for other purposes the  
cost is excessive.  Hence, let's back off to doing this only when  
debug_invalidate_system_caches_always is at least 3; or in older  
branches, when CLOBBER_CACHE_RECURSIVELY is defined.  
  
While here, clean up some other minor issues in LookupOpclassInfo.  
Re-order the code so we aren't left with broken cache entries (leading  
to later core dumps) in the unlikely case that we suffer OOM while  
trying to allocate space for a new entry.  (That seems to be my  
oversight in 03ffc4d6d.)  Also, in >= v13, stop allocating one array  
entry too many.  That's evidently left over from sloppy reversion in  
851b14b0c.  
  
Back-patch to all supported branches, mainly to reduce the runtime  
of cache-clobbering buildfarm animals.  
  
Discussion: https://postgr.es/m/1370856.1625428625@sss.pgh.pa.us  

commit   : 27621cc55526fc5acb58bc6c023e79fba3a92672    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Mon, 5 Jul 2021 09:52:05 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Mon, 5 Jul 2021 09:52:05 +0530    

A new chapter for Hash Indexes, designed to help users understand how  
they work and when to use them.  
  
Backpatch-through 10 where we have made hash indexes durable.  
  
Author: Simon Riggs  
Reviewed-By: Justin Pryzby, Amit Kapila  
Discussion: https://postgr.es/m/CANbhV-HRjNPYgHo--P1ewBrFJ-GpZPb9_25P7=Wgu7s7hy_sLQ@mail.gmail.com  

commit   : 39a21ce06baa6734d52566c300aa55c2934f94de    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sun, 4 Jul 2021 20:59:14 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sun, 4 Jul 2021 20:59:14 +0900    

Author: Greg Sabino Mullane  
Discussion: https://postgr.es/m/CAKAnmmJYH2FBn_+Vwd2FD5SaKn8hjhAXOCHpZc6n4wXaUaW_SA@mail.gmail.com  
Backpatch-through: 9.6  

commit   : 409d9390e8e944eab2ea4b98984cc5781d70e7d1    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Sun, 4 Jul 2021 22:29:57 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Sun, 4 Jul 2021 22:29:57 +1200    

Document that setting maintenance_work_mem to values over 1GB has no  
effect on VACUUM.  
  
Reported-by: Martín Marqués  
Author: Laurenz Albe  
Discussion: https://postgr.es/m/CABeG9LsZ2ozUMcqtqWu_-GiFKB17ih3p8wBHXcpfnHqhCnsc7A%40mail.gmail.com  
Backpatch-through: 9.6, oldest supported release  

commit   : 650e6359018a54287d99fcd9640fb24fa7209467    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Fri, 2 Jul 2021 20:42:46 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Fri, 2 Jul 2021 20:42:46 -0400    

Reported-by: tom@crystae.net  
  
Discussion: https://postgr.es/m/162345756191.14472.9754568432103008703@wrigleys.postgresql.org  
  
Backpatch-through: 9.6  

commit   : 7fc97752d566735cdab17a4cc4ac3305413ee54e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 2 Jul 2021 16:04:54 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 2 Jul 2021 16:04:54 -0400    

The existing code tried to do syscache lookups in an already-failed  
transaction, which is problematic to say the least.  After some  
consideration of alternatives, the best fix seems to be to just drop  
type names from the error message altogether.  The table and column  
names seem like sufficient localization.  If the user is unsure what  
types are involved, she can check the local and remote table  
definitions.  
  
Having done that, we can also discard the LogicalRepTypMap hash  
table, which had no other use.  Arguably, LOGICAL_REP_MSG_TYPE  
replication messages are now obsolete as well; but we should  
probably keep them in case some other use emerges.  (The complexity  
of removing something from the replication protocol would likely  
outweigh any savings anyhow.)  
  
Masahiko Sawada and Bharath Rupireddy, per complaint from Andres  
Freund.  Back-patch to v10 where this code originated.  
  
Discussion: https://postgr.es/m/20210106020229.ne5xnuu6wlondjpe@alap3.anarazel.de  

commit   : 8d2be1402833a8cf0876282165bc8eae224a9c2e    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Thu, 1 Jul 2021 15:38:06 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Thu, 1 Jul 2021 15:38:06 -0400    

commit   : bd0be7f7a42fa84fd9fb770117c9f7c1238a05b1    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Thu, 1 Jul 2021 14:21:09 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Thu, 1 Jul 2021 14:21:09 -0400    

These are the same as world and install-world respectively, but without  
building or installing the documentation. There are many reasons for  
wanting to be able to do this, including speed, lack of documentation  
building tools, and wanting to build other formats of the documentation.  
Plans for simplifying the buildfarm client code include using these  
targets.  
  
Backpatch to all live branches.  
  
Discussion: https://postgr.es/m/6a421136-d462-b043-a8eb-e75b2861f3df@dunslane.net  

commit   : a8b564b0c9c39e8bdd6cde4245c3340f72c28899    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Thu, 1 Jul 2021 08:29:10 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Thu, 1 Jul 2021 08:29:10 -0400    

The prove_installcheck recipe in src/Makefile.global.in was emitting  
bogus paths for a couple of elements when used with PGXS. Here we create  
a separate recipe for the PGXS case that does it correctly. We also take  
the opportunity to make the make the file more readable by breaking up  
the prove_installcheck and prove_check recipes across several lines, and  
to remove the setting for REGRESS_SHLIB to src/test/recovery/Makefile,  
which is the only set of tests that actually need it.  
  
Backpatch to all live branches  
  
Discussion: https://postgr.es/m/f2401388-936b-f4ef-a07c-a0bcc49b3300@dunslane.net  

commit   : 41edb2db1b9161fe5c100d3806e08c63a9f89196    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 30 Jun 2021 11:49:16 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 30 Jun 2021 11:49:16 +0900    

Reaching PITR on such a transaction would cause the generation of a LOG  
message mentioning a transaction committed, not aborted.  
  
Oversight in 4f1b890.  
  
Author: Simon Riggs  
Discussion: https://postgr.es/m/CANbhV-GJ6KijeCgdOrxqMCQ+C8QiK657EMhCy4csjrPcEUFv_Q@mail.gmail.com  
Backpatch-through: 9.6  

commit   : 1603deca34ef403fc40d471ba6512d9f170ba7b5    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 28 Jun 2021 14:17:42 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 28 Jun 2021 14:17:42 -0400    

Causing a core dump on out-of-memory seems pretty unfriendly,  
and surely is far outside the expected behavior of a general-purpose  
library.  Just print an error message (as we did already) and return.  
These functions unfortunately don't have an error return convention,  
but code using them is probably just looking for a quick-n-dirty  
print method and wouldn't bother to check anyway.  
  
Although these functions are semi-deprecated, it still seems  
appropriate to back-patch this.  In passing, also back-patch  
b90e6cef1, just to reduce cosmetic differences between the  
branches.  
  
Discussion: https://postgr.es/m/3122443.1624735363@sss.pgh.pa.us  

commit   : be567deb3ac952e41edc81b8c08a0dc6115c5f62    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 28 Jun 2021 12:40:37 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 28 Jun 2021 12:40:37 -0400    

Instead use the common/int.h functions to check for integer overflow  
in a more C-standard-compliant fashion.  This is motivated by recent  
failures on buildfarm member moonjelly, where it appears that  
development-tip gcc is optimizing without regard to the -fwrapv  
switch.  Presumably that's a gcc bug that will be fixed soon, but  
we might as well install cleaner coding here rather than wait.  
  
(This does not address the question of whether we'll ever be able  
to get rid of using -fwrapv.  Testing shows that this spot is the  
only place where doing so creates visible regression test failures,  
but unfortunately that proves very little.)  
  
Back-patch to v12.  The common/int.h functions exist in v11, but  
that branch doesn't use them in any client-side code.  I judge  
that this case isn't interesting enough in the real world to take  
even a small risk of issues from being the first such use.  
  
Tom Lane and Fabien Coelho  
  
Discussion: https://postgr.es/m/73927.1624815543@sss.pgh.pa.us  

commit   : 741deb2603c758c67f199c9129d2e92bd80cec2e    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Mon, 28 Jun 2021 08:42:48 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Mon, 28 Jun 2021 08:42:48 +0530    

When we cannot immediately acquire XactSLRULock in exclusive mode at  
commit time, we add ourselves to a list of processes that need their XIDs  
status update. We do this if the clog page where we need to update the  
current transaction status is the same as the group leader's clog page,  
otherwise, we allow the caller to clear it by itself. Now, when we can't  
add ourselves to any group, we were not clearing the current proc if it  
has already become a member of some group which was leading to an  
assertion failure when the same proc was assigned to another backend after  
the current backend exits.  
  
Reported-by: Alexander Lakhin  
Bug: 17072  
Author: Amit Kapila  
Tested-By: Alexander Lakhin  
Backpatch-through: 11, where it was introduced  
Discussion: https://postgr.es/m/17072-2f8764857ef2c92a@postgresql.org  

commit   : fd7bc10ab4c6a88846d1b8a35d16cfe0b8f5a487    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 28 Jun 2021 11:17:12 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 28 Jun 2021 11:17:12 +0900    

83158f7 has improved index_set_state_flags() so as it is possible to use  
transactional updates when updating pg_index state flags, but there was  
not really a test case which stressed directly the possibility it fixed.  
This commit adds such a test, using a predicate that looks valid in  
appearance but calls a stable function.  
  
Author: Andrey Lepikhov  
Discussion: https://postgr.es/m/9b905019-5297-7372-0ad2-e1a4bb66a719@postgrespro.ru  
Backpatch-through: 9.6  

commit   : acb60edf0254e2b0f0be753c31c877daf4012582    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 28 Jun 2021 10:39:09 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 28 Jun 2021 10:39:09 +0900    

3c84046 is the original commit that introduced index_set_state_flags(),  
where the presence of SnapshotNow made necessary the use of an in-place  
update.  SnapshotNow has been removed in 813fb03, so there is no actual  
reasons to not make this operation transactional.  
  
As reported by Andrey, it is possible to trigger the assertion of this  
routine expecting no transactional updates when switching the pg_index  
state flags, using a predicate mark as immutable but calling stable or  
volatile functions.  83158f7 has been around for a couple of months on  
HEAD now with no issues found related to it, so it looks safe enough for  
a backpatch.  
  
Reported-by: Andrey Lepikhov  
Author: Michael Paquier  
Reviewed-by: Anastasia Lubennikova  
Discussion: https://postgr.es/m/20200903080440.GA8559@paquier.xyz  
Discussion: https://postgr.es/m/9b905019-5297-7372-0ad2-e1a4bb66a719@postgrespro.ru  
Backpatch-through: 9.6  

commit   : 2d094486541acd8baee3af7579d4606f78256165    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 27 Jun 2021 12:45:04 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 27 Jun 2021 12:45:04 -0400    

specscanner.l leaked a kilobyte of memory per token of the spec file.  
Apparently somebody thought that the introductory code block would be  
executed once; but it's once per yylex() call.  
  
A couple of functions in isolationtester.c leaked small amounts of  
memory due to not bothering to free one-time allocations.  Might  
as well improve these so that valgrind gives this program a clean  
bill of health.  Also get rid of an ugly static variable.  
  
Coverity complained about one of the one-time leaks, which led me  
to try valgrind'ing isolationtester, which led to discovery of the  
larger leak.  

commit   : 88274a7a314eb521b1ee924f2872872fce289fdf    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sat, 26 Jun 2021 13:52:54 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sat, 26 Jun 2021 13:52:54 +0900    

The version string is grabbed from PACKAGE_VERSION in pg_config.h in the  
MSVC build since 8f4fb4c6, but an error message referenced a variable  
that existed before that.  This had no consequences except if one messes  
up enough with the version number of the build.  
  
Author: Anton Voloshin  
Discussion: https://postgr.es/m/af79ee1b-9962-b299-98e1-f90a289e19e6@postgrespro.ru  
Backpatch-through: 13  

commit   : 0455b7ccce3cba6a85a85aa6524c48d58eb1c93e    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sat, 26 Jun 2021 12:40:03 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sat, 26 Jun 2021 12:40:03 +0900    

002_pgbench_no_server was printing some array pointers instead of the  
actual contents of those arrays for the expected outputs of stdout and  
stderr for a tested command.  This does not add any new information that  
can help with debugging as the test names allow to track failure  
locations, if any.  
  
This commit simply removes those logs as the rest of the printed  
information is redundant with command_checks_all().  
  
Per discussion with Andrew Dunstan and Álvaro Herrera.  
  
Discussion: https://postgr.es/m/YNXNFaG7IgkzZanD@paquier.xyz  
Backpatch-through: 11  

commit   : ba815f00a0ce4c9b7696be6d841733b1b481a1f8    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 25 Jun 2021 13:59:38 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 25 Jun 2021 13:59:38 -0400    

It's not really necessary for this function to open or lock the  
relation associated with the pg_policy entry it's modifying.  The  
error checks it's making on the rel are if anything counterproductive  
(e.g., if we don't want to allow installation of policies on system  
catalogs, here is not the place to prevent that).  In particular, it  
seems just wrong to insist on an ownership check.  That has the net  
effect of forcing people to use superuser for DROP OWNED BY, which  
surely is not an effect we want.  Also there is no point in rebuilding  
the dependencies of the policy expressions, which aren't being  
changed.  Lastly, locking the table also seems counterproductive; it's  
not helping to prevent race conditions, since we failed to re-read the  
pg_policy row after acquiring the lock.  That means that concurrent  
DDL would likely result in "tuple concurrently updated/deleted"  
errors; which is the same behavior this code will produce, with less  
overhead.  
  
Per discussion of bug #17062.  Back-patch to all supported versions,  
as the failure cases this eliminates seem just as undesirable in 9.6  
as in HEAD.  
  
Discussion: https://postgr.es/m/1573181.1624220108@sss.pgh.pa.us  

commit   : 4a20de9d9ed3e45e41cd0860573387e95132314d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 25 Jun 2021 10:46:10 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 25 Jun 2021 10:46:10 -0400    

A walsender process that has executed a SQL command left the text of  
that command in pg_stat_activity.query indefinitely, which is quite  
confusing if it's in RUNNING state but not doing that query.  An easy  
and useful fix is to treat replication commands as if they were SQL  
queries, and show them in pg_stat_activity according to the same rules  
as for regular queries.  While we're at it, it seems also sensible to  
set debug_query_string, allowing error logging and debugging to see  
the replication command.  
  
While here, clean up assorted silliness in exec_replication_command:  
* Clean up SQLCmd code path, and fix its only-accidentally-not-buggy  
  memory management.  
* Remove useless duplicate call of SnapBuildClearExportedSnapshot().  
* replication_scanner_finish() was never called.  
  
Back-patch of commit f560209c6 into v10-v13.  I'd originally felt  
that this didn't merit back-patching, but subsequent confusion  
while debugging walsender problems suggests that it'll be useful.  
Also, the original commit has now aged long enough to provide some  
comfort that it won't cause problems.  
  
Discussion: https://postgr.es/m/2673480.1624557299@sss.pgh.pa.us  
Discussion: https://postgr.es/m/880181.1600026471@sss.pgh.pa.us  

commit   : af2e67b47afe56627c6ced8cd5741d345fc64da9    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 25 Jun 2021 20:15:31 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 25 Jun 2021 20:15:31 +0900    

This fixes a couple of problems within the so-said code of this commit  
subject:  
- Replace the use of open() with slurp_file(), fixing an issue reported  
by buildfarm member fairywren whose perl installation keep around CRLF  
characters, causing the matching patterns for the logs to fail.  
- Remove the eval block, which is not really necessary.  
  
This set of issues has come into light after fixing a different issue  
with c13585fe, and this is wrong since this code has been introduced.  
  
Reported-by: Andrew Dunstan, and buildfarm member fairywren  
Author: Michael Paquier  
Reviewed-by: Andrew Dunstan  
Discussion: https://postgr.es/m/0f49303e-7784-b3ee-200b-cbf67be2eb9e@dunslane.net  
Backpatch-through: 11  

commit   : 372a2806ebc28f79de929a7c763b441e35a9c362    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 25 Jun 2021 08:11:10 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 25 Jun 2021 08:11:10 +0200    

Use "floating point" rather than "float4", like everywhere else in  
this context.  
  
Author: Shinya11.Kato@nttdata.com  
Discussion: https://www.postgresql.org/message-id/flat/TYAPR01MB28965989AF84B57FC351B97BC40F9@TYAPR01MB2896.jpnprd01.prod.outlook.com  

commit   : d9c05a9ec49399a45d30acacac748625922cbe40    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Fri, 25 Jun 2021 09:55:26 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Fri, 25 Jun 2021 09:55:26 +1200    

LLVM 13 (due out in September) has changed the semantics of  
LLVMOrcAbsoluteSymbols(), so we need to bump some reference counts to  
avoid a double-free that causes crashes and bad query results.  
  
A proactive change seems necessary to avoid having a window of time  
where our respective latest releases would interact badly.  It's  
possible that the situation could change before then, though.  
  
Thanks to Fabien Coelho for monitoring bleeding edge LLVM and Andres  
Freund for tracking down the change.  
  
Back-patch to 11, where the JIT code arrived.  
  
Discussion: https://postgr.es/m/CA%2BhUKGLEy8mgtN7BNp0ooFAjUedDTJj5dME7NxLU-m91b85siA%40mail.gmail.com  

commit   : 7a9eaf111ac0a3ceba24fe15e5402bb2a17891f5    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 25 Jun 2021 06:52:47 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 25 Jun 2021 06:52:47 +0900    

The logic checking for the format of per-thread logs used grep() with  
directly "$re", which would cause the test to consider all the logs as  
a match without caring about their format at all.  Using "/$re/" makes  
grep() perform a regex test, which is what we want here.  
  
While on it, improve some of the tests to be more picky with the  
patterns expected and add more comments to describe the tests.  
  
Issue discovered while digging into a separate patch.  
  
Author: Fabien Coelho, Michael Paquier  
Discussion: https://postgr.es/m/YNPsPAUoVDCpPOGk@paquier.xyz  
Backpatch-through: 11  

commit   : 56e366f6757d24b07cc7c2de2e5151dc372d059e    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Thu, 24 Jun 2021 14:38:45 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Thu, 24 Jun 2021 14:38:45 +0530    

Move the newly defined enum value REORDER_BUFFER_CHANGE_INTERNAL_SPEC_ABORT  
at the end to avoid ABI break in the back branches. We need to back-patch  
this till v11 because before that it is already at the end.  
  
Reported-by: Tomas Vondra  
Backpatch-through: 11  
Discussion: https://postgr.es/m/CAExHW5sPKF-Oovx_qZe4p5oM6Dvof7_P+XgsNAViug15Fm99jA@mail.gmail.com  

commit   : 6fb377e5f74b09ac0b36034da65b179c567228b8    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 24 Jun 2021 11:19:03 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 24 Jun 2021 11:19:03 +0300    

In previous commit, I missed that relmap_redo() was also not acquiring the  
RelationMappingLock. Thanks to Thomas Munro for pointing that out.  
  
Backpatch-through: 9.6, like previous commit.  
Discussion: https://www.postgresql.org/message-id/CA%2BhUKGLev%3DPpOSaL3WRZgOvgk217et%2BbxeJcRr4eR-NttP1F6Q%40mail.gmail.com  

commit   : 2a0ab13f8dd1346d03b00a737734aeca036514f9    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 24 Jun 2021 10:45:23 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 24 Jun 2021 10:45:23 +0300    

Contrary to the comment here, POSIX does not guarantee atomicity of a  
read(), if another process calls write() concurrently. Or at least Linux  
does not. Add locking to load_relmap_file() to avoid the race condition.  
  
Fixes bug #17064. Thanks to Alexander Lakhin for the report and test case.  
  
Backpatch-through: 9.6, all supported versions.  
Discussion: https://www.postgresql.org/message-id/17064-bb0d7904ef72add3@postgresql.org  

commit   : 7a4ecefe9d77b7bb09caa5d82de433494e017363    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Thu, 24 Jun 2021 09:31:51 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Thu, 24 Jun 2021 09:31:51 +0530    

Reported-by: Simon Riggs  
Author: Takamichi Osumi  
Reviewed-by: Amit Kapila  
Backpatch-through: 9.6  
Discussion: https://www.postgresql.org/message-id/20210222222847.tpnb6eg3yiykzpky@alap3.anarazel.de  

commit   : 5179a1ab773c9305192b0261fbb1f9e223d94a3d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 23 Jun 2021 18:41:39 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 23 Jun 2021 18:41:39 -0400    

For no obvious reason, isolationtester has always insisted that  
session and step names be written with double quotes.  This is  
fairly tedious and does little for test readability, especially  
since the names that people actually choose almost always look  
like normal identifiers.  Hence, let's tweak the lexer to allow  
SQL-like identifiers not only double-quoted strings.  
  
(They're SQL-like, not exactly SQL, because I didn't add any  
case-folding logic.  Also there's no provision for U&"..." names,  
not that anyone's likely to care.)  
  
There is one incompatibility introduced by this change: if you write  
"foo""bar" with no space, that used to be taken as two identifiers,  
but now it's just one identifier with an embedded quote mark.  
  
I converted all the src/test/isolation/ specfiles to remove  
unnecessary double quotes, but stopped there because my  
eyes were glazing over already.  
  
Like 741d7f104, back-patch to all supported branches, so that this  
isn't a stumbling block for back-patching isolation test changes.  
  
Discussion: https://postgr.es/m/759113.1623861959@sss.pgh.pa.us  

commit   : 9aa06956eaf16d94c591ff7aca660c3e39d55591    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 23 Jun 2021 14:27:13 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 23 Jun 2021 14:27:13 -0400    

The syntax summaries for CREATE FUNCTION and allied commands  
made it look like LEAKPROOF is an alternative to  
IMMUTABLE/STABLE/VOLATILE, when of course it is an orthogonal  
option.  Improve that.  
  
Per gripe from aazamrafeeque0.  Thanks to David Johnston for  
suggestions.  
  
Discussion: https://postgr.es/m/162444349581.694.5818572718530259025@wrigleys.postgresql.org  

commit   : 13f3655683bac3cb8dc32f84f15b8141592ab281    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 23 Jun 2021 14:01:32 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 23 Jun 2021 14:01:32 -0400    

Our uses of gss_display_status() and gss_display_name() assumed  
that the gss_buffer_desc strings returned by those functions are  
null-terminated.  It appears that they generally are, given the  
lack of field complaints up to now.  However, the available  
documentation does not promise this, and some man pages  
for gss_display_status() show examples that rely on the  
gss_buffer_desc.length field instead of expecting null  
termination.  Also, we now have a report that on some  
implementations, clang's address sanitizer is of the opinion  
that the byte after the specified length is undefined.  
  
Hence, change the code to rely on the length field instead.  
  
This might well be cosmetic rather than fixing any real bug, but  
it's hard to be sure, so back-patch to all supported branches.  
While here, also back-patch the v12 changes that made pg_GSS_error  
deal honestly with multiple messages available from  
gss_display_status.  
  
Per report from Sudheer H R.  
  
Discussion: https://postgr.es/m/5372B6D4-8276-42C0-B8FB-BD0918826FC3@tekenlight.com  

commit   : b961bdfe1664f2d699ebcfbca15b1ef288b9790c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 23 Jun 2021 11:12:31 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 23 Jun 2021 11:12:31 -0400    

Previously, isolationtester displayed SQL query results using some  
ad-hoc code that clearly hadn't had much effort expended on it.  
Field values longer than 14 characters weren't separated from  
the next field, and usually caused misalignment of the columns  
too.  Also there was no visual separation of a query's result  
from subsequent isolationtester output.  This made test result  
files confusing and hard to read.  
  
To improve matters, let's use libpq's PQprint() function.  Although  
that's long since unused by psql, it's still plenty good enough  
for the purpose here.  
  
Like 741d7f104, back-patch to all supported branches, so that this  
isn't a stumbling block for back-patching isolation test changes.  
  
Discussion: https://postgr.es/m/582362.1623798221@sss.pgh.pa.us  

commit   : e2cde85ef2c38ab9cc1ff7190ded7433f637b014    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 22 Jun 2021 21:43:12 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 22 Jun 2021 21:43:12 -0400    

We've long contended with isolation test results that aren't entirely  
stable.  Some test scripts insert long delays to try to force stable  
results, which is not terribly desirable; but other erratic failure  
modes remain, causing unrepeatable buildfarm failures.  I've spent a  
fair amount of time trying to solve this by improving the server-side  
support code, without much success: that way is fundamentally unable  
to cope with diffs that stem from chance ordering of arrival of  
messages from different server processes.  
  
We can improve matters on the client side, however, by annotating  
the test scripts themselves to show the desired reporting order  
of events that might occur in different orders.  This patch adds  
three types of annotations to deal with (a) test steps that might or  
might not complete their waits before the isolationtester can see them  
waiting; (b) test steps in different sessions that can legitimately  
complete in either order; and (c) NOTIFY messages that might arrive  
before or after the completion of a step in another session.  We might  
need more annotation types later, but this seems to be enough to deal  
with the instabilities we've seen in the buildfarm.  It also lets us  
get rid of all the long delays that were previously used, cutting more  
than a minute off the runtime of the isolation tests.  
  
Back-patch to all supported branches, because the buildfarm  
instabilities affect all the branches, and because it seems desirable  
to keep isolationtester's capabilities the same across all branches  
to simplify possible future back-patching of tests.  
  
Discussion: https://postgr.es/m/327948.1623725828@sss.pgh.pa.us  

commit   : 6f1321d5ae8e0db1500def46f12eadf94521f5ee    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 22 Jun 2021 17:48:39 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 22 Jun 2021 17:48:39 -0400    

Commits 84f5c2908 et al missed the need to cover plpgsql's "simple  
expression" code path.  If the first thing we execute after a  
COMMIT/ROLLBACK is one of those, rather than a full-fledged SPI command,  
we must explicitly do EnsurePortalSnapshotExists() to make sure we have  
an outer snapshot.  Note that it wouldn't be good enough to just push a  
snapshot for the duration of the expression execution: what comes back  
might be toasted, so we'd better have a snapshot protecting it.  
  
The test case demonstrating this fact cheats a bit by marking a SQL  
function immutable even though it fetches from a table.  That's  
nothing that users haven't been seen to do, though.  
  
Per report from Jim Nasby.  Back-patch to v11, like the previous fix.  
  
Discussion: https://postgr.es/m/378885e4-f85f-fc28-6c91-c4d1c080bf26@amazon.com  

commit   : 6dcb185bfc38c93c550d7229ab8bc41bfe80f800    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Wed, 4 Nov 2020 14:58:34 +1300    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Wed, 4 Nov 2020 14:58:34 +1300    

If users provide old style pre-standardized Windows locale names in a  
CREATE COLLATION command, the OS is unable to provide version  
information.  Continue without capturing version information, rather  
than exposing an OS error.  
  
This was originally done in commit 9f12a3b9 for 14 only, to support  
future features that might encounter old style names from initdb's  
default.  It wasn't done in 13 because I didn't consider that users  
might actually want to use the old format explicitly (something we  
should consider blocking in a future release with a better error  
message, but that's not a policy we've decided on yet).  
  
Back-patch to 13, based on the field complaint in pgsql-bugs #17058.  
  
Reported-by: Yasushi Yamashita <developer@yamashi-ta.jp>  
Discussion: https://postgr.es/m/17058-b49f5793c912c5aa%40postgresql.org  

commit   : 33af10c598e2bff55be46eb79f7c785440aa13c5    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 18 Jun 2021 18:00:09 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 18 Jun 2021 18:00:09 -0400    

Ordinarily, a pg_policy.polroles array wouldn't list the same role  
more than once; but CREATE POLICY does not prevent that.  If we  
perform DROP OWNED BY on a role that is listed more than once,  
RemoveRoleFromObjectPolicy either suffered an assertion failure  
or encountered a tuple-updated-by-self error.  Rewrite it to cope  
correctly with duplicate entries, and add a CommandCounterIncrement  
call to prevent the other problem.  
  
Per discussion, there's other cleanup that ought to happen here,  
but this seems like the minimum essential fix.  
  
Per bug #17062 from Alexander Lakhin.  It's been broken all along,  
so back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/17062-11f471ae3199ca23@postgresql.org  

commit   : 102f31a208b85aec542fc93f73a222d98d551694    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 18 Jun 2021 12:09:22 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 18 Jun 2021 12:09:22 -0400    

This works fine in the "simple Query" code path; but if the  
statement is in the plan cache then it's corrupted for future  
re-execution.  Apply copyObject() to protect the original  
tree from modification, as we've done elsewhere.  
  
This narrow fix is applied only to the back branches.  In HEAD,  
the problem was fixed more generally by commit 7c337b6b5; but  
that changed ProcessUtility's API, so it's infeasible to  
back-patch.  
  
Per bug #17053 from Charles Samborski.  
  
Discussion: https://postgr.es/m/931771.1623893989@sss.pgh.pa.us  
Discussion: https://postgr.es/m/17053-3ca3f501bbc212b4@postgresql.org  

commit   : 5b6b5e5ee598ced2dc8e1d08a34d499860a4d15b    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 18 Jun 2021 07:44:58 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 18 Jun 2021 07:44:58 -0400    

The fast default code added in Release 11 omitted to check that the  
table a fast default was being added to was a plain table. Thus one  
could be added to a foreign table, which predicably blows up. Here we  
perform that check.  
  
In addition, on the back branches, since some of these might have  
escaped into the wild, if we encounter a missing value for  
an attribute of something other than a plain table we ignore it.  
  
Fixes bug #17056  
  
Backpatch to release 11,  
  
Reviewed by: Andres Freund, Álvaro Herrera and Tom Lane  

commit   : 357cb8f07f95665ea533ff534821c22c35b01288    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Fri, 18 Jun 2021 08:51:18 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Fri, 18 Jun 2021 08:51:18 +0530    

We use a tuple conversion map for partitions when replicating using an  
ancestor's schema to convert tuples from partition's type to the  
ancestor's. Before this map got initialized, we were processing  
invalidation messages which access this map.  
  
This issue happens only in version 13 as in HEAD we already have a code  
that initializes each relation entry before we can process any  
invalidation message. This issue is introduced by commit d250568121 in  
version 13.  
  
Reported-by: Tom Lane, as per buildfarm meber skink  
Author: Amit Langote  
Reviewed-by: Dilip Kumar, Amit Kapila  
Discussion: https://www.postgresql.org/message-id/648020.1623854904@sss.pgh.pa.us  

commit   : 42f782be916807121fcce20811892c0bad95fca3    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 17 Jun 2021 14:50:42 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 17 Jun 2021 14:50:42 +0300    

One of the error paths left *members uninitialized. That's not a live  
bug, because most callers don't look at *members when the function  
returns -1, but let's be tidy. One caller, in heap_lock_tuple(), does  
"if (members != NULL) pfree(members)", but AFAICS it never passes an  
invalid 'multi' value so it should not reach that error case.  
  
The callers are also a bit inconsistent in their expectations.  
heap_lock_tuple() pfrees the 'members' array if it's not-NULL, others  
pfree() it if "nmembers >= 0", and others if "nmembers > 0". That's  
not a live bug either, because the function should never return 0, but  
add an Assert for that to make it more clear. I left the callers alone  
for now.  
  
I also moved the line where we set *nmembers. It wasn't wrong before,  
but I like to do that right next to the 'return' statement, to make it  
clear that it's always set on return.  
  
Also remove one unreachable return statement after ereport(ERROR), for  
brevity and for consistency with the similar if-block right after it.  
  
Author: Greg Nancarrow with the additional changes by me  
Backpatch-through: 9.6, all supported versions  

commit   : 3989f8fb9dd84afda7e27de04bf83e31903d46ba    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 5 Jun 2021 07:16:34 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 5 Jun 2021 07:16:34 +0200    

Starting with Python 3.10, the stacktrace looks differently:  
  -  PL/Python function "subtransaction_exit_subtransaction_in_with", line 3, in <module>  
  -    s.__exit__(None, None, None)  
  +  PL/Python function "subtransaction_exit_subtransaction_in_with", line 2, in <module>  
  +    with plpy.subtransaction() as s:  
Using try/except specifically makes the error look always the same.  
  
(See https://github.com/python/cpython/pull/25719 for the discussion  
of this change in Python.)  
  
Author: Honza Horak <hhorak@redhat.com>  
Discussion: https://www.postgresql.org/message-id/flat/853083.1620749597%40sss.pgh.pa.us  
RHBZ: https://bugzilla.redhat.com/show_bug.cgi?id=1959080  

commit   : 9f7bba2629cf3413638936d0376bb50403144332    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Thu, 17 Jun 2021 10:17:13 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Thu, 17 Jun 2021 10:17:13 +0530    

In a synchronous logical setup, locking [user] catalog tables can cause  
deadlock. This is because logical decoding of transactions can lock  
catalog tables to access them so exclusively locking those in transactions  
can lead to deadlock. To avoid this users must refrain from having  
exclusive locks on catalog tables.  
  
Author: Takamichi Osumi  
Reviewed-by: Vignesh C, Amit Kapila  
Backpatch-through: 9.6  
Discussion: https://www.postgresql.org/message-id/20210222222847.tpnb6eg3yiykzpky%40alap3.anarazel.de  

commit   : d03a41d1c860ffc97bda40a3673698d4044f5c88    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 16 Jun 2021 19:30:17 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 16 Jun 2021 19:30:17 -0400    

When stuffing a plan from the plancache into a Portal, one is  
not supposed to risk throwing an error between GetCachedPlan and  
PortalDefineQuery; if that happens, the plan refcount incremented  
by GetCachedPlan will be leaked.  I managed to break this rule  
while refactoring code in 9dbf2b7d7.  There is no visible  
consequence other than some memory leakage, and since nobody is  
very likely to trigger the relevant error conditions many times  
in a row, it's not surprising we haven't noticed.  Nonetheless,  
it's a bug, so rearrange the order of operations to remove the  
hazard.  
  
Noted on the way to looking for a better fix for bug #17053.  
This mistake is pretty old, so back-patch to all supported  
branches.  

commit   : e89a8e30e0a50e7882ab5a6896a11872bec969e3    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 16 Jun 2021 12:34:32 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 16 Jun 2021 12:34:32 +0300    

Since commit c24dcd0cfd, we have been using pg_pread() to read the WAL  
file, which doesn't change the seek position (unless we fall back to  
the implementation in src/port/pread.c). Update comment accordingly.  
  
Backpatch-through: 12, where we started to use pg_pread()  

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

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

commit   : 602a32a685e4ca715a996f899d906e5f24308b51    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Tue, 15 Jun 2021 08:41:16 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Tue, 15 Jun 2021 08:41:16 +0530    

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

commit   : 2da5ddf8340f285453fbdcc57e7c40388953fafb    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 14 Jun 2021 21:58:26 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 14 Jun 2021 21:58:26 -0400    

This should have been updated in d2d8a229b, but it was overlooked.  
According to 31a877f18 which added it, this file is meant to show the  
results you get under default_transaction_isolation = serializable.  
We've largely lost track of that goal in other isolation tests, but  
as long as we've got this one, it should be right.  
  
Noted while fooling about with the isolationtester.  

commit   : 0483ae7c513bf2604443fa681811b4a5113c6799    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 14 Jun 2021 21:28:21 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 14 Jun 2021 21:28:21 -0400    

This should have been removed in 43e084197, which removed the  
corresponding spec file.  Noted while fooling about with the  
isolationtester.  

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

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

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

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

commit   : 545aa6a59357f7fb8e341a6a5b4c85e322e78697    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sun, 13 Jun 2021 20:07:45 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sun, 13 Jun 2021 20:07:45 +0900    

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

commit   : 94e21021cdf25e50e28be3e4f3147ed56796433a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 12 Jun 2021 15:12:10 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 12 Jun 2021 15:12:10 -0400    

Several TAP tests use poll_query_until() to wait for the postmaster  
to restart.  They were checking to see if a trivial query  
(e.g. "SELECT 1") succeeds.  However, that's problematic in the wake  
of commit 11e9caff8, because now that we feed said query to psql  
via stdin, we risk IPC::Run whining about a SIGPIPE failure if psql  
quits before reading the query.  Hence, we can't use a nonempty  
query in cases where we need to wait for connection failures to  
stop happening.  
  
Per the precedent of commits c757a3da0 and 6d41dd045, we can pass  
"undef" as the query in such cases to ensure that IPC::Run has  
nothing to write.  However, then we have to say that the expected  
output is empty, and this exposes a deficiency in poll_query_until:  
if psql fails altogether and returns empty stdout, poll_query_until  
will treat that as a success!  That's because, contrary to its  
documentation, it makes no actual check for psql failure, looking  
neither at the exit status nor at stderr.  
  
To fix that, adjust poll_query_until to insist on empty stderr as  
well as a stdout match.  (I experimented with checking exit status  
instead, but it seems that psql often does exit(1) in cases that we  
need to consider successes.  That might be something to fix someday,  
but it would be a non-back-patchable behavior change.)  
  
Back-patch to v10.  The test cases needing this exist only as far  
back as v11, but it seems wise to keep poll_query_until's behavior  
the same in v10, in case we back-patch another such test case in  
future.  (9.6 does not currently need this change, because in that  
branch poll_query_until can't be told to accept empty stdout as  
a success case.)  
  
Per assorted buildfarm failures, mostly on hoverfly.  
  
Discussion: https://postgr.es/m/CAA4eK1+zM6L4QSA1XMvXY_qqWwdUmqkOS1+hWvL8QcYEBGA1Uw@mail.gmail.com  

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

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

commit   : 8b5055812cadd00a86a438fc0d8bafeba3c4d874    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 12 Jun 2021 12:59:15 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 12 Jun 2021 12:59:15 -0400    

Using an Assert to check the validity of incoming messages is an  
extremely poor decision.  In a debug build, it should not be that easy  
for a broken or malicious remote client to crash the logrep worker.  
The consequences could be even worse in non-debug builds, which will  
fail to make such checks at all, leading to who-knows-what misbehavior.  
Hence, promote every Assert that could possibly be triggered by wrong  
or out-of-order replication messages to a full test-and-ereport.  
  
To avoid bloating the set of messages the translation team has to cope  
with, establish a policy that replication protocol violation error  
reports don't need to be translated.  Hence, all the new messages here  
use errmsg_internal().  A couple of old messages are changed likewise  
for consistency.  
  
Along the way, fix some non-idiomatic or outright wrong uses of  
hash_search().  
  
Most of these mistakes are new with the "streaming replication"  
patch (commit 464824323), but a couple go back a long way.  
Back-patch as appropriate.  
  
Discussion: https://postgr.es/m/1719083.1623351052@sss.pgh.pa.us  

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

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

commit   : fad9c8e93a65f087033312cd655511a28d07ab51    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sat, 12 Jun 2021 15:30:00 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sat, 12 Jun 2021 15:30:00 +0900    

ab55d74 has introduced some tests with rows found as missing in logical  
replication subscriptions for partitioned tables, relying on a logic  
with a lookup of the logs generated, scanning the whole file.  This  
commit makes the logic more precise, by scanning the logs only from the  
position before the key queries are run to the position where we check  
for the logs.  This will reduce the risk of issues with log patterns  
overlapping with each other if those tests get more complicated in the  
future.  
  
Per discussion with Tom Lane.  
  
Discussion: https://postgr.es/m/YMP+Gx2S8meYYHW4@paquier.xyz  
Backpatch-through: 13  

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

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

commit   : 065ce069ae4fe5f59251435ebfe13e14a2d5874c    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 11 Jun 2021 19:07:32 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 11 Jun 2021 19:07:32 -0400    

We were already reporting it, but only after the parallel workers were  
finished, which is visibly much later than what happens in a serial  
build.  
  
With this change we report it when the leader starts its own sort phase  
when participating in the build (the normal case).  Now this might  
happen a little later than when the workers start their sorting phases,  
but a) communicating the actual phase start from workers is likely to be  
a hassle, and b) the sort phase start is pretty fuzzy anyway, since  
sorting per se is actually initiated by tuplesort.c internally earlier  
than tuplesort_performsort() is called.  
  
Backpatch to pg12, where the progress reporting code for CREATE INDEX  
went in.  
  
Reported-by: Tomas Vondra <tomas.vondra@enterprisedb.com>  
Author: Matthias van de Meent <boekewurm+postgres@gmail.com>  
Reviewed-by: Greg Nancarrow <gregn4422@gmail.com>  
Reviewed-by: Álvaro Herrera <alvherre@alvh.no-ip.org>  
Discussion: https://postgr.es/m/1128176d-1eee-55d4-37ca-e63644422adb  

commit   : b270713fd44b1378cebc3177e092add0155b55b6    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 11 Jun 2021 16:12:36 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 11 Jun 2021 16:12:36 -0400    

apply_handle_tuple_routing(), having detected and reported that  
the tuple it needed to update didn't exist, tried to update that  
tuple anyway, leading to a null-pointer dereference.  
  
logicalrep_partition_open() failed to ensure that the  
LogicalRepPartMapEntry it built for a partition was fully  
independent of that for the partition root, leading to  
trouble if the root entry was later freed or rebuilt.  
  
Meanwhile, on the publisher's side, pgoutput_change() sometimes  
attempted to apply execute_attr_map_tuple() to a NULL tuple.  
  
The first of these was reported by Sergey Bernikov in bug #17055;  
I found the other two while developing some test cases for this  
sadly under-tested code.  
  
Diagnosis and patch for the first issue by Amit Langote; patches  
for the others by me; new test cases by me.  Back-patch to v13  
where this logic came in.  
  
Discussion: https://postgr.es/m/17055-9ba800ec8522668b@postgresql.org  

commit   : 218b101008b533156d7e5832fe143d1e04a01301    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 11 Jun 2021 12:16:14 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 11 Jun 2021 12:16:14 -0400    

The code added to mark replication slots invalid in commit c6550776394e  
had the race condition that a slot can be dropped or advanced  
concurrently with checkpointer trying to invalidate it.  Rewrite the  
code to close those races.  
  
The changes to ReplicationSlotAcquire's API added with c6550776394e are  
not necessary anymore.  To avoid an ABI break in released branches, this  
commit leaves that unchanged; it'll be changed in a master-only commit  
separately.  
  
Backpatch to 13, where this code first appeared.  
  
Reported-by: Andres Freund <andres@anarazel.de>  
Author: Andres Freund <andres@anarazel.de>  
Author: Álvaro Herrera <alvherre@alvh.no-ip.org>  
Discussion: https://postgr.es/m/20210408001037.wfmk6jud36auhfqm@alap3.anarazel.de  

commit   : 6e43f1c2df3da18b9d7087edddaf72dec84cfaf4    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 10 Jun 2021 12:27:27 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 10 Jun 2021 12:27:27 -0400    

It turns out that worker.c's code path for TRUNCATE was also  
careless about establishing a snapshot while executing user-defined  
code, allowing the checks added by commit 84f5c2908 to fail when  
a trigger is fired in that context.  
  
We could just wrap Push/PopActiveSnapshot around the truncate call,  
but it seems better to establish a policy of holding a snapshot  
throughout execution of a replication step.  To help with that and  
possible future requirements, replace the previous ensure_transaction  
calls with pairs of begin/end_replication_step calls.  
  
Per report from Mark Dilger.  Back-patch to v11, like the previous  
changes.  
  
Discussion: https://postgr.es/m/B4A3AF82-79ED-4F4C-A4E5-CD2622098972@enterprisedb.com  

commit   : 3465328aa19e363f3248839bea4521793940ad34    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Thu, 10 Jun 2021 09:08:30 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Thu, 10 Jun 2021 09:08:30 -0400    

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

commit   : 0826564292156762d32c183c6708c94564fcad1c    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Wed, 9 Jun 2021 16:17:13 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Wed, 9 Jun 2021 16:17:13 -0400    

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

commit   : 99a0a2ada8c584e7d7796190a5966600f44c037f    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Wed, 9 Jun 2021 12:28:39 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Wed, 9 Jun 2021 12:28:39 -0400    

Partial back-port of commit 081876d75ea15c3bd2ee5ba64a794fd8ea46d794.  
A test case for a pending bug fix needs this capability, but the code  
on 9.6 is significantly different, so I'm only back-patching this  
change as far as v10. We'll have to work around the problem another  
way in v9.6.  
  
Discussion: http://postgr.es/m/CAFiTN-tcivNvL0Rg6rD7_CErNfE75H7+gh9WbMxjbgsattja1Q@mail.gmail.com  

commit   : 6bfcc7d0d19a32fe44a8671aa5ecca9e5b39221a    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 9 Jun 2021 16:25:49 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 9 Jun 2021 16:25:49 +0900    

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

commit   : c5b28184132d30ce7f77b24b0e7f302a8f37f407    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 8 Jun 2021 18:40:06 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 8 Jun 2021 18:40:06 -0400    

Further thought about bug #17050 suggests that it's a good idea  
to use CURSOR_OPT_NO_SCROLL for the implicit cursor opened by  
a plpgsql FOR-over-query loop.  This ensures that, if somebody  
commits inside the loop, PersistHoldablePortal won't try to  
rewind and re-read the cursor.  While we'd have selected NO_SCROLL  
anyway if FOR UPDATE/SHARE appears in the query, there are other  
hazards with volatile functions; and in any case, it's silly to  
expend effort storing rows that we know for certain won't be needed.  
  
(While here, improve the comment in exec_run_select, which was a bit  
confused about the rationale for when we can use parallel mode.  
Cursor operations aren't a hazard for nameless portals.)  
  
This wasn't an issue until v11, which introduced the possibility  
of persisting such cursors.  Hence, back-patch to v11.  
  
Per bug #17050 from Алексей Булгаков.  
  
Discussion: https://postgr.es/m/17050-f77aa827dc85247c@postgresql.org  

commit   : c1fd756fd23f60fcac120c9cd36de2921144e3bd    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 8 Jun 2021 17:50:15 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 8 Jun 2021 17:50:15 -0400    

PersistHoldablePortal has long assumed that it should store the  
entire output of the query-to-be-persisted, which requires rewinding  
and re-reading the output.  This is problematic if the query is not  
stable: we might get different row contents, or even a different  
number of rows, which'd confuse the cursor state mightily.  
  
In the case where the cursor is NO SCROLL, this is very easy to  
solve: just store the remaining query output, without any rewinding,  
and tweak the portal's cursor state to match.  Aside from removing  
the semantic problem, this could be significantly more efficient  
than storing the whole output.  
  
If the cursor is scrollable, there's not much we can do, but it  
was already the case that scrolling a volatile query's result was  
pretty unsafe.  We can just document more clearly that getting  
correct results from that is not guaranteed.  
  
There are already prohibitions in place on using SCROLL with  
FOR UPDATE/SHARE, which is one way for a SELECT query to have  
non-stable results.  We could imagine prohibiting SCROLL when  
the query contains volatile functions, but that would be  
expensive to enforce.  Moreover, it could break applications  
that work just fine, if they have functions that are in fact  
stable but the user neglected to mark them so.  So settle for  
documenting the hazard.  
  
While this problem has existed in some guise for a long time,  
it got a lot worse in v11, which introduced the possibility  
of persisting plpgsql cursors (perhaps implicit ones) even  
when they violate the rules for what can be marked WITH HOLD.  
Hence, I've chosen to back-patch to v11 but not further.  
  
Per bug #17050 from Алексей Булгаков.  
  
Discussion: https://postgr.es/m/17050-f77aa827dc85247c@postgresql.org  

commit   : 949e32ee5d5990ff94579abc34d7b2c39b134965    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 8 Jun 2021 13:40:03 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 8 Jun 2021 13:40:03 +0900    

Mis-merge introduced by e2f21ff, where pgwin32_setenv() was listed but  
not defined in win32env.c.  This had no consequences as this routine  
does not exist in this branch.  
  
Only REL_12_STABLE and REL_13_STABLE got that wrong.  
  
Backpatch-through: 12  

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

If autovacuum comes along just after we fill table test_seg with  
some data, it will update the stats to the point where we prefer  
a plain indexscan over a bitmap scan, breaking the expected  
output (as well as the point of the test case).  To fix, just  
force a bitmap scan to be chosen here.  
  
This has evidently been wrong since commit de1d042f5.  It's not  
clear why we just recently saw any buildfarm failures due to it;  
but prairiedog has failed twice on this test in the past week.  
Hence, backpatch to v11 where this test case came in.  

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

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

commit   : b4c027b5f52f029ac85d5743a5df85a955dd1ffe    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 3 Jun 2021 21:07:12 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 3 Jun 2021 21:07:12 -0400    

The siglen parameter is provided by gist__intbig_ops not  
gist__int_ops.  
  
Simon Norris  
  
Discussion: https://postgr.es/m/11BF2AA9-17AE-432A-AFE1-584FB9FB079D@hillcrestgeo.ca  

commit   : 6131cb144f8483fdc2223c1e06ce80e7c4ddf056    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 4 Jun 2021 09:33:22 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 4 Jun 2021 09:33:22 +0900    

The link was pointing to the minimum protocol version.  Incorrect as of  
ff8ca5f.  
  
Author: Daniel Gustafsson  
Discussion: https://postgr.es/m/F893F184-C645-4C21-A2BA-583441B7288F@yesql.se  
Backpatch-through: 13  

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

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

commit   : 75d66d10e0e35529a80d3442081150fcf501bb7d    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 3 Jun 2021 15:28:37 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 3 Jun 2021 15:28:37 +0900    

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

commit   : 9d660670541ccc803e1d48576b4a6d02a19321b0    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 3 Jun 2021 11:51:05 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 3 Jun 2021 11:51:05 +0900    

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

commit   : 6753a5b7e86cd9bb1eed580b1f9001d5ea1bbdb3    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 2 Jun 2021 14:38:14 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 2 Jun 2021 14:38:14 -0400    

Commit 428b260f8 broke planning of cases where row marks are needed  
(SELECT FOR UPDATE, etc) and one of the query's tables is a foreign  
table that has regular table(s) as inheritance children.  We got the  
reverse case right, but apparently were thinking that foreign tables  
couldn't be inheritance parents.  Not so; so we need to be able to  
add a CTID junk column while adding a new child, not only a wholerow  
junk column.  
  
Back-patch to v12 where the faulty code came in.  
  
Amit Langote  
  
Discussion: https://postgr.es/m/CA+HiwqEmo3FV1LAQ4TVyS2h1WM=kMkZUmbNuZSCnfHvMcUcPeA@mail.gmail.com  

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

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

commit   : d2505681211b4803cae916e9f4c2331943f851dc    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Tue, 1 Jun 2021 14:25:19 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Tue, 1 Jun 2021 14:25:19 +0530    

Release memory allocated when creating the tuple-conversion map and its  
component TupleDescs when its owning sync entry is invalidated.  
TupleDescs must also be freed when no map is deemed necessary, to begin  
with.  
  
Reported-by: Andres Freund  
Author: Amit Langote  
Reviewed-by: Takamichi Osumi, Amit Kapila  
Backpatch-through: 13, where it was introduced  
Discussion: https://postgr.es/m/MEYP282MB166933B1AB02B4FE56E82453B64D9@MEYP282MB1669.AUSP282.PROD.OUTLOOK.COM  

commit   : e2f21ff606dae2f7f7a9e323a88c99b464d2f787    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 1 Jun 2021 09:27:25 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 1 Jun 2021 09:27:25 +0900    

This fixes the code compilation on Windows with MSVC and Kerberos, as  
a missing implementation of setenv() causes a compilation failure of the  
GSSAPI code.  This was only reproducible when building the code with  
Kerberos, something that buildfarm animal hamerkop has fixed recently.  
  
This issue only happens on 12 and 13, as this code has been introduced  
in b0b39f7.  HEAD is already able to compile properly thanks to  
7ca37fb0, and this commit is a minimal cherry-pick of it.  
  
Thanks to Tom Lane for the discussion.  
  
Discussion: https://postgr.es/m/YLDtm5WGjPxm6ua4@paquier.xyz  
Backpatch-through: 12  

commit   : fe6f63286a00a49d0f82ac73fc252a3ad40d73b4    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 31 May 2021 12:03:00 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 31 May 2021 12:03:00 -0400    

create_projection_plan contains a hidden assumption (here made  
explicit by an Assert) that a projection-capable Path will yield a  
projection-capable Plan.  Unfortunately, that assumption is violated  
only a few lines away, by create_projection_plan itself.  This means  
that two stacked ProjectionPaths can yield an outcome where we try to  
jam the upper path's tlist into a non-projection-capable child node,  
resulting in an invalid plan.  
  
There isn't any good reason to have stacked ProjectionPaths; indeed the  
whole concept is faulty, since the set of Vars/Aggs/etc needed by the  
upper one wouldn't necessarily be available in the output of the lower  
one, nor could the lower one create such values if they weren't  
available from its input.  Hence, we can fix this by adjusting  
create_projection_path to strip any top-level ProjectionPath from the  
subpath it's given.  (This amounts to saying "oh, we changed our  
minds about what we need to project here".)  
  
The test case added here only fails in v13 and HEAD; before that, we  
don't attempt to shove the Sort into the parallel part of the plan,  
for reasons that aren't entirely clear to me.  However, all the  
directly-related code looks generally the same as far back as v11,  
where the hazard was introduced (by d7c19e62a).  So I've got no faith  
that the same type of bug doesn't exist in v11 and v12, given the  
right test case.  Hence, back-patch the code changes, but not the  
irrelevant test case, into those branches.  
  
Per report from Bas Poot.  
  
Discussion: https://postgr.es/m/534fca83789c4a378c7de379e9067d4f@politie.nl  

commit   : 23059a0457c0c19c149c964490a5ca95fe0625e0    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Mon, 31 May 2021 00:29:58 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 31 May 2021 00:29:58 -0700    

Per buildfarm member hornet.  Also, update Pod documentation showing the  
lower value.  Back-patch to v10, where the test first appeared.  

commit   : d41fda6aa3c1016ef5aedb4bf393ead81f6e3a8f    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Sat, 29 May 2021 14:48:15 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Sat, 29 May 2021 14:48:15 +1200    

Parallel query processes that called BlessTupleDesc() for identical  
tuple descriptors at the same moment could crash.  There was code to  
handle that rare case, but it dereferenced a bogus DSA pointer.  Repair.  
  
Back-patch to 11, where commit cc5f8136 added support for sharing tuple  
descriptors in parallel queries.  
  
Reported-by: Eric Thinnes <e.thinnes@gmx.de>  
Discussion: https://postgr.es/m/99aaa2eb-e194-bf07-c29a-1a76b4f2bcf9%40gmx.de  

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

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

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

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

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

commit   : 0ab64ab318f23259210ff4d430ff1e7690ca3c08    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 27 May 2021 14:58:09 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 27 May 2021 14:58:09 +0900    

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

commit   : 9012e5594c6ff803abb6d51e164797e3810845c1    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Tue, 25 May 2021 09:40:16 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Tue, 25 May 2021 09:40:16 +0530    

The error messages, docs, and one of the options were using  
'parallel degree' to indicate parallelism used by vacuum command. We  
normally use 'parallel workers' at other places so change it for parallel  
vacuum accordingly.  
  
Author: Bharath Rupireddy  
Reviewed-by: Dilip Kumar, Amit Kapila  
Backpatch-through: 13  
Discussion: https://postgr.es/m/CALj2ACWz=PYrrFXVsEKb9J1aiX4raA+UBe02hdRp_zqDkrWUiw@mail.gmail.com  

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

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

commit   : 5b4791b4580e95a1230e89c11c08058f18b92225    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 22 May 2021 21:24:48 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 22 May 2021 21:24:48 -0400    

If we redirected a replicated tuple operation into a partition child  
table, and then tried to fire AFTER triggers for that event, the  
relation cache entry for the child table was already closed.  This has  
no visible ill effects as long as the entry is still there and still  
valid, but an unluckily-timed cache flush could result in a crash or  
other misbehavior.  
  
To fix, postpone the ExecCleanupTupleRouting call (which is what  
closes the child table) until after we've fired triggers.  This  
requires a bit of refactoring so that the cleanup function can  
have access to the necessary state.  
  
In HEAD, I took the opportunity to simplify some of worker.c's  
function APIs based on use of the new ApplyExecutionData struct.  
However, it doesn't seem safe/practical to back-patch that aspect,  
at least not without a lot of analysis of possible interactions  
with a04daa97a.  
  
In passing, add an Assert to afterTriggerInvokeEvents to catch  
such cases.  This seems worthwhile because we've grown a number  
of fairly unstructured ways of calling AfterTriggerEndQuery.  
  
Back-patch to v13, where worker.c grew the ability to deal with  
partitioned target tables.  
  
Discussion: https://postgr.es/m/3382681.1621381328@sss.pgh.pa.us  

commit   : 849c7971d1abe39d9105a768918c110414029e48    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 21 May 2021 15:12:08 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 21 May 2021 15:12:08 -0400    

This was previously allowed, but I think that was just an oversight.  
It's a clear violation of the rule that a generated column cannot  
depend on itself or other generated columns.  Moreover, because the  
code was relying on the assumption that no such cross-references  
exist, it was pretty easy to crash ALTER TABLE and perhaps other  
places.  Even if you managed not to crash, you got quite unstable,  
implementation-dependent results.  
  
Per report from Vitaly Ustinov.  
Back-patch to v12 where GENERATED came in.  
  
Discussion: https://postgr.es/m/CAM_DEiWR2DPT6U4xb-Ehigozzd3n3G37ZB1+867zbsEVtYoJww@mail.gmail.com  

commit   : 77e3204ecbf15ab5dfd295bbc66eeeec4d9ade19    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 21 May 2021 15:02:07 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 21 May 2021 15:02:07 -0400    

We consider this supported (though I've got my doubts that it's a  
good idea, because tableoid is not immutable).  However, several  
code paths failed to fill the field in soon enough, causing such  
a GENERATED expression to see zero or the wrong value.  This  
occurred when ALTER TABLE adds a new GENERATED column to a table  
with existing rows, and during regular INSERT or UPDATE on a  
foreign table with GENERATED columns.  
  
Noted during investigation of a report from Vitaly Ustinov.  
Back-patch to v12 where GENERATED came in.  
  
Discussion: https://postgr.es/m/CAM_DEiWR2DPT6U4xb-Ehigozzd3n3G37ZB1+867zbsEVtYoJww@mail.gmail.com  

commit   : d18ee6f92d9a22b4fae57f515797b2196bf385c7    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 21 May 2021 14:03:53 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 21 May 2021 14:03:53 -0400    

COMMIT/ROLLBACK necessarily destroys all snapshots within the session.  
The original implementation of intra-procedure transactions just  
cavalierly did that, ignoring the fact that this left us executing in  
a rather different environment than normal.  In particular, it turns  
out that handling of toasted datums depends rather critically on there  
being an outer ActiveSnapshot: otherwise, when SPI or the core  
executor pop whatever snapshot they used and return, it's unsafe to  
dereference any toasted datums that may appear in the query result.  
It's possible to demonstrate "no known snapshots" and "missing chunk  
number N for toast value" errors as a result of this oversight.  
  
Historically this outer snapshot has been held by the Portal code,  
and that seems like a good plan to preserve.  So add infrastructure  
to pquery.c to allow re-establishing the Portal-owned snapshot if it's  
not there anymore, and add enough bookkeeping support that we can tell  
whether it is or not.  
  
We can't, however, just re-establish the Portal snapshot as part of  
COMMIT/ROLLBACK.  As in normal transaction start, acquiring the first  
snapshot should wait until after SET and LOCK commands.  Hence, teach  
spi.c about doing this at the right time.  (Note that this patch  
doesn't fix the problem for any PLs that try to run intra-procedure  
transactions without using SPI to execute SQL commands.)  
  
This makes SPI's no_snapshots parameter rather a misnomer, so in HEAD,  
rename that to allow_nonatomic.  
  
replication/logical/worker.c also needs some fixes, because it wasn't  
careful to hold a snapshot open around AFTER trigger execution.  
That code doesn't use a Portal, which I suspect someday we're gonna  
have to fix.  But for now, just rearrange the order of operations.  
This includes back-patching the recent addition of finish_estate()  
to centralize the cleanup logic there.  
  
This also back-patches commit 2ecfeda3e into v13, to improve the  
test coverage for worker.c (it was that test that exposed that  
worker.c's snapshot management is wrong).  
  
Per bug #15990 from Andreas Wicht.  Back-patch to v11 where  
intra-procedure COMMIT was added.  
  
Discussion: https://postgr.es/m/15990-eee2ac466b11293d@postgresql.org  

commit   : c83c0257e4c3ec3503f8d72698d70829af979803    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Fri, 21 May 2021 08:03:38 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Fri, 21 May 2021 08:03:38 +0530    

While applying the truncate change, the logical apply worker acquires  
RowExclusiveLock on the relation being truncated. This allowed truncate on  
the relation at a time by two apply workers which lead to a deadlock. The  
reason was that one of the workers after updating the pg_class tuple tries  
to acquire SHARE lock on the relation and started to wait for the second  
worker which has acquired RowExclusiveLock on the relation. And when the  
second worker tries to update the pg_class tuple, it starts to wait for  
the first worker which leads to a deadlock. Fix it by acquiring  
AccessExclusiveLock on the relation before applying the truncate change as  
we do for normal truncate operation.  
  
Author: Peter Smith, test case by Haiying Tang  
Reviewed-by: Dilip Kumar, Amit Kapila  
Backpatch-through: 11  
Discussion: https://postgr.es/m/CAHut+PsNm43p0jM+idTvWwiGZPcP0hGrHMPK9TOAkc+a4UpUqw@mail.gmail.com  

commit   : c64183f234e8e185347edf8820b3459e802b5354    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 20 May 2021 18:32:37 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 20 May 2021 18:32:37 -0400    

exec_for_query() normally tries to prefetch a few rows at a time  
from the query being iterated over, so as to reduce executor  
entry/exit overhead.  Unfortunately this is unsafe if we have  
COMMIT or ROLLBACK within the loop, because there might be  
TOAST references in the data that we prefetched but haven't  
yet examined.  Immediately after the COMMIT/ROLLBACK, we have  
no snapshots in the session, meaning that VACUUM is at liberty  
to remove recently-deleted TOAST rows.  
  
This was originally reported as a case triggering the "no known  
snapshots" error in init_toast_snapshot(), but even if you miss  
hitting that, you can get "missing toast chunk", as illustrated  
by the added isolation test case.  
  
To fix, just disable prefetching in non-atomic contexts.  Maybe  
there will be performance complaints prompting us to work harder  
later, but it's not clear at the moment that this really costs  
much, and I doubt we'd want to back-patch any complicated fix.  
  
In passing, adjust that error message in init_toast_snapshot()  
to be a little clearer about the likely cause of the problem.  
  
Patch by me, based on earlier investigation by Konstantin Knizhnik.  
  
Per bug #15990 from Andreas Wicht.  Back-patch to v11 where  
intra-procedure COMMIT was added.  
  
Discussion: https://postgr.es/m/15990-eee2ac466b11293d@postgresql.org  

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

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

commit   : 010429eb1f77a6221f6c89b21b6b0c7820446201    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Tue, 18 May 2021 09:55:54 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Tue, 18 May 2021 09:55:54 +1200    

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

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

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

commit   : fa675af59fc828d0b71bd9139042d71456640a28    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Fri, 14 May 2021 15:08:00 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Fri, 14 May 2021 15:08:00 -0700    

Add a defensive "can't happen" error to code that handles nbtree posting  
list splits (promote an existing assertion).  This avoids a segfault in  
the event of an insertion of a newitem that is somehow identical to an  
existing non-pivot tuple in the index.  An nbtree index should never  
have two index tuples with identical TIDs.  
  
This scenario is not particular unlikely in the event of any kind of  
corruption that leaves the index in an inconsistent state relative to  
the heap relation that is indexed.  There are two known reports of  
preventable hard crashes.  Doing nothing seems unacceptable given the  
general expectation that nbtree will cope reasonably well with corrupt  
data.  
  
Discussion: https://postgr.es/m/CAH2-Wz=Jr_d-dOYEEmwz0-ifojVNWho01eAqewfQXgKfoe114w@mail.gmail.com  
Backpatch: 13-, where nbtree deduplication was introduced.  

commit   : 6a4c07156802fa2efee75c273a7d5d9ae81bda28    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 14 May 2021 17:36:20 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 14 May 2021 17:36:20 -0400    

The patch to disallow a NULL specification in combination with  
GENERATED ... AS IDENTITY applied to both ALWAYS and BY DEFAULT  
variants of that clause, not only the former.  
  
Noted by Shay Rojansky.  
  
Discussion: https://postgr.es/m/CADT4RqAwD3A=RvGiQU9AiTK-6VeuXcycwPHmJPv_OBCJFYOEww@mail.gmail.com  

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

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

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

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

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

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

commit   : ff91d3a22b9a5ab9511f8ed8bffc895a991529f5    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Thu, 13 May 2021 16:10:21 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Thu, 13 May 2021 16:10:21 +0300    

Make sample like_regex match string values of the root object instead of the  
whole document.  The corrected example seems to represent a more relevant  
use case.  
  
Backpatch to 12, when jsonpath was introduced.  
  
Discussion: https://postgr.es/m/13440f8b-4c1f-5875-c8e3-f3f65606af2f%40xs4all.nl  
Author: Erik Rijkers  
Reviewed-by: Michael Paquier, Alexander Korotkov  
Backpatch-through: 12  

commit   : e5c071bc0f93c9c47821c876e36459580e08a68c    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 12 May 2021 19:13:54 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 12 May 2021 19:13:54 -0400    

The worker.c global wrconn is only meant to be used by logical apply/  
tablesync workers, but there are other variables with the same name. To  
reduce future confusion rename the global from "wrconn" to  
"LogRepWorkerWalRcvConn".  
  
While this is just cosmetic, it seems better to backpatch it all the way  
back to 10 where this code appeared, to avoid future backpatching  
issues.  
  
Author: Peter Smith <smithpb2250@gmail.com>  
Discussion: https://postgr.es/m/CAHut+Pu7Jv9L2BOEx_Z0UtJxfDevQSAUW2mJqWU+CtmDrEZVAg@mail.gmail.com  

commit   : 834d9284b4fee413c74de3a143a072eb21c05772    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 11 May 2021 20:59:45 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 11 May 2021 20:59:45 -0400    

Several queries in the privileges regression test cause the planner  
to apply the plpgsql function "leak()" to every element of the  
histogram for atest12.b.  Since commit 0c882e52a increased the size  
of that histogram to 10000 entries, the test invokes that function  
over 100000 times, which takes an absolutely unreasonable amount of  
time in clobber-cache-always mode.  
  
However, there's no real reason why that has to be a plpgsql  
function: for the purposes of this test, all that matters is that  
it not be marked leakproof.  So we can replace the plpgsql  
implementation with a direct call of int4lt, which has the same  
behavior and is orders of magnitude faster.  This is expected to  
cut several hours off the buildfarm cycle time for CCA animals.  
It has some positive impact in normal builds too, though that's  
probably lost in the noise.  
  
Back-patch to v13 where 0c882e52a came in.  
  
Discussion: https://postgr.es/m/575884.1620626638@sss.pgh.pa.us  

commit   : 272d82ec6febb97ab25fd7c67e9c84f4660b16ac    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 May 2021 16:41:42 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 May 2021 16:41:42 -0400    

commit   : 9b93a33f455579ee8953c32721c03ff9163b7f96    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 May 2021 13:10:29 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 May 2021 13:10:29 -0400    

Security: CVE-2021-32027, CVE-2021-32028, CVE-2021-32029  

commit   : 4a8656a7ee0c155b0249376af58eb3fc3a90415f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 May 2021 11:02:29 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 May 2021 11:02:29 -0400    

It's unusual to have any resjunk columns in an ON CONFLICT ... UPDATE  
list, but it can happen when MULTIEXPR_SUBLINK SubPlans are present.  
If it happens, the ON CONFLICT UPDATE code path would end up storing  
tuples that include the values of the extra resjunk columns.  That's  
fairly harmless in the short run, but if new columns are added to  
the table then the values would become accessible, possibly leading  
to malfunctions if they don't match the datatypes of the new columns.  
  
This had escaped notice through a confluence of missing sanity checks,  
including  
  
* There's no cross-check that a tuple presented to heap_insert or  
heap_update matches the table rowtype.  While it's difficult to  
check that fully at reasonable cost, we can easily add assertions  
that there aren't too many columns.  
  
* The output-column-assignment cases in execExprInterp.c lacked  
any sanity checks on the output column numbers, which seems like  
an oversight considering there are plenty of assertion checks on  
input column numbers.  Add assertions there too.  
  
* We failed to apply nodeModifyTable's ExecCheckPlanOutput() to  
the ON CONFLICT UPDATE tlist.  That wouldn't have caught this  
specific error, since that function is chartered to ignore resjunk  
columns; but it sure seems like a bad omission now that we've seen  
this bug.  
  
In HEAD, the right way to fix this is to make the processing of  
ON CONFLICT UPDATE tlists work the same as regular UPDATE tlists  
now do, that is don't add "SET x = x" entries, and use  
ExecBuildUpdateProjection to evaluate the tlist and combine it with  
old values of the not-set columns.  This adds a little complication  
to ExecBuildUpdateProjection, but allows removal of a comparable  
amount of now-dead code from the planner.  
  
In the back branches, the most expedient solution seems to be to  
(a) use an output slot for the ON CONFLICT UPDATE projection that  
actually matches the target table, and then (b) invent a variant of  
ExecBuildProjectionInfo that can be told to not store values resulting  
from resjunk columns, so it doesn't try to store into nonexistent  
columns of the output slot.  (We can't simply ignore the resjunk columns  
altogether; they have to be evaluated for MULTIEXPR_SUBLINK to work.)  
This works back to v10.  In 9.6, projections work much differently and  
we can't cheaply give them such an option.  The 9.6 version of this  
patch works by inserting a JunkFilter when it's necessary to get rid  
of resjunk columns.  
  
In addition, v11 and up have the reverse problem when trying to  
perform ON CONFLICT UPDATE on a partitioned table.  Through a  
further oversight, adjust_partition_tlist() discarded resjunk columns  
when re-ordering the ON CONFLICT UPDATE tlist to match a partition.  
This accidentally prevented the storing-bogus-tuples problem, but  
at the cost that MULTIEXPR_SUBLINK cases didn't work, typically  
crashing if more than one row has to be updated.  Fix by preserving  
resjunk columns in that routine.  (I failed to resist the temptation  
to add more assertions there too, and to do some minor code  
beautification.)  
  
Per report from Andres Freund.  Back-patch to all supported branches.  
  
Security: CVE-2021-32028  

commit   : 467395bfdf33f1ccf67ca388ffdcc927271544cb    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 May 2021 10:44:38 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 May 2021 10:44:38 -0400    

While we were (mostly) careful about ensuring that the dimensions of  
arrays aren't large enough to cause integer overflow, the lower bound  
values were generally not checked.  This allows situations where  
lower_bound + dimension overflows an integer.  It seems that that's  
harmless so far as array reading is concerned, except that array  
elements with subscripts notionally exceeding INT_MAX are inaccessible.  
However, it confuses various array-assignment logic, resulting in a  
potential for memory stomps.  
  
Fix by adding checks that array lower bounds aren't large enough to  
cause lower_bound + dimension to overflow.  (Note: this results in  
disallowing cases where the last subscript position would be exactly  
INT_MAX.  In principle we could probably allow that, but there's a lot  
of code that computes lower_bound + dimension and would need adjustment.  
It seems doubtful that it's worth the trouble/risk to allow it.)  
  
Somewhat independently of that, array_set_element() was careless  
about possible overflow when checking the subscript of a fixed-length  
array, creating a different route to memory stomps.  Fix that too.  
  
Security: CVE-2021-32027  

commit   : 4c7ba553bad0254aaaf525668cc1cdb2eb8fcc92    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 10 May 2021 14:32:18 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 10 May 2021 14:32:18 +0200    

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

commit   : 0d204a4b09f74f2c2ca0d099d5a44ce422d6978d    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 10 May 2021 11:36:26 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 10 May 2021 11:36:26 +0200    

When building without --enable-dtrace, emit dummy  
  
    do {} while (0)  
  
statements for the stubbed-out TRACE_POSTGRESQL_foo() macros  
instead of empty macros that totally elide the original probe  
statement.  
  
This fixes the  
  
    warning: suggest braces around empty body in an ‘if’ statement [-Wempty-body]  
  
introduced by b94409a02f.  
  
Author: Craig Ringer <craig.ringer@2ndquadrant.com>  
Discussion: https://www.postgresql.org/message-id/flat/20210504221531.cfvpmmdfsou6eitb%40alap3.anarazel.de  

commit   : 55fe672a92e3fab20d5126c05c35dfbc8d2b94a8    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 9 May 2021 13:31:40 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 9 May 2021 13:31:40 -0400    

commit   : 7f4bab7f4a0e42ee9fa14707f726017b7869386b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 7 May 2021 12:19:30 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 7 May 2021 12:19:30 -0400    

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

commit   : ef70b6f8e28dae452d2bdb379204db234c930d26    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 7 May 2021 11:46:37 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 7 May 2021 11:46:37 -0400    

This patch replaces use of the global "wrconn" variable in  
AlterSubscription_refresh with a local variable of the same name, making  
it consistent with other functions in subscriptioncmds.c (e.g.  
DropSubscription).  
  
The global wrconn is only meant to be used for logical apply/tablesync worker.  
Abusing it this way is known to cause trouble if an apply worker  
manages to do a subscription refresh, such as reported by Jeremy Finzel  
and diagnosed by Andres Freund back in November 2020, at  
https://www.postgresql.org/message-id/20201111215820.qihhrz7fayu6myfi@alap3.anarazel.de  
  
Backpatch to 10.  In branch master, also move the connection establishment  
to occur outside the PG_TRY block; this way we can remove a test for NULL in  
PG_FINALLY, and it also makes the code more consistent with similar code in  
the same file.  
  
Author: Peter Smith <peter.b.smith@fujitsu.com>  
Reviewed-by: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>  
Reviewed-by: Japin Li <japinli@hotmail.com>  
Discussion: https://postgr.es/m/CAHut+Pu7Jv9L2BOEx_Z0UtJxfDevQSAUW2mJqWU+CtmDrEZVAg@mail.gmail.com  

commit   : f518c3df4eb0acc9ad6cb49f98c56f392b76c9c1    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 6 May 2021 17:17:56 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 6 May 2021 17:17:56 -0400    

Backpatch all the way back to 9.6.  
  
Author: Simon Riggs <simon.riggs@enterprisedb.com>  
Discussion: https://postgr.es/m/CANbhV-EwxvdhHuOLdfG2ciYrHOHXV=mm6=fD5aMhqcH09Li3Tg@mail.gmail.com  

commit   : 082d9d6b576b5bf9f1292dc7150167acfd5e94a5    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Wed, 5 May 2021 22:07:40 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Wed, 5 May 2021 22:07:40 -0700    

Reported-By: Erik Rijkers <er@xs4all.nl>  
Discussion: https://postgr.es/m/833107370.1313189.1619647621213@webmailclassic.xs4all.nl  
Backpatch: 13, where b059d2f45685 introduced the issue.  

commit   : 923c13520f1b01a5563ec272de5a0a59b343f892    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 5 May 2021 12:14:21 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 5 May 2021 12:14:21 -0400    

When ALTER TABLE .. ALTER CONSTRAINT changes deferrability properties  
changed in a partitioned table, we failed to propagate those changes  
correctly to partitions and to triggers.  Repair by adding a recursion  
mechanism to affect all derived constraints and all derived triggers.  
(In particular, recurse to partitions even if their respective parents  
are already in the desired state: it is possible for the partitions to  
have been altered individually.)  Because foreign keys involve tables in  
two sides, we cannot use the standard ALTER TABLE recursion mechanism,  
so we invent our own by following pg_constraint.conparentid down.  
  
When ALTER TABLE .. ALTER CONSTRAINT is invoked on the derived  
pg_constraint object that's automaticaly created in a partition as a  
result of a constraint added to its parent, raise an error instead of  
pretending to work and then failing to modify all the affected triggers.  
Before this commit such a command would be allowed but failed to affect  
all triggers, so it would silently misbehave.  (Restoring dumps of  
existing databases is not affected, because pg_dump does not produce  
anything for such a derived constraint anyway.)  
  
Add some tests for the case.  
  
Backpatch to 11, where foreign key support was added to partitioned  
tables by commit 3de241dba86f.  (A related change is commit f56f8f8da6af  
in pg12 which added support for FKs *referencing* partitioned tables;  
this is what forces us to use an ad-hoc recursion mechanism for this.)  
  
Diagnosed by Tom Lane from bug report from Ron L Johnson.  As of this  
writing, no reviews were offered.  
  
Discussion: https://postgr.es/m/75fe0761-a291-86a9-c8d8-4906da077469@gmail.com  
Discussion: https://postgr.es/m/3144850.1607369633@sss.pgh.pa.us  

commit   : 91a6b3862fef95c3075d9bea945b6d974433389f    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 4 May 2021 10:09:11 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 4 May 2021 10:09:11 -0400    

The OID of the constraint is used instead of the OID of the trigger --  
an easy mistake to make.  Apparently the object-alter hooks are not very  
well tested :-(  
  
Backpatch to 12, where this typo was introduced by 578b229718e8  
  
Discussion: https://postgr.es/m/20210503231633.GA6994@alvherre.pgsql  

commit   : a6a3a274abd1368a0104fe2cfc7227c9a7e95970    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 4 May 2021 14:03:54 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 4 May 2021 14:03:54 +0200    

The previous fix for dumping of inherited generated columns  
(0bf83648a52df96f7c8677edbbdf141bfa0cf32b) must not be applied to  
partitions, since, unlike normal inherited tables, they are always  
dumped separately and reattached.  
  
Reported-by: Santosh Udupi <email@hitha.net>  
Discussion: https://www.postgresql.org/message-id/flat/CACLRvHZ4a-%2BSM_159%2BtcrHdEqxFrG%3DW4gwTRnwf7Oj0UNj5R2A%40mail.gmail.com  

commit   : 64190d65f2995203df401738b77adc5ebd4d2fce    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 4 May 2021 11:45:37 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 4 May 2021 11:45:37 +0200    

When running ALTER TABLE t2 INHERIT t1, we must check that columns in  
t2 that correspond to a generated column in t1 are also generated and  
have the same generation expression.  Otherwise, this would allow  
creating setups that a normal CREATE TABLE sequence would not allow.  
  
Discussion: https://www.postgresql.org/message-id/22de27f6-7096-8d96-4619-7b882932ca25@2ndquadrant.com  

commit   : e48ce7ef0ef8de3d8e9e56be4d23d7830681b18b    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 3 May 2021 12:11:33 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 3 May 2021 12:11:33 +0200    

If dtrace is compiled in but disabled, the lwlock dtrace probes still  
evaluate their arguments.  Since PostgreSQL 13, T_NAME(lock) does  
nontrivial work, so it should be avoided if not needed.  To fix, make  
these calls conditional on the *_ENABLED() macro corresponding to each  
probe.  
  
Reviewed-by: Craig Ringer <craig.ringer@enterprisedb.com>  
Discussion: https://www.postgresql.org/message-id/CAGRY4nwxKUS_RvXFW-ugrZBYxPFFM5kjwKT5O+0+Stuga5b4+Q@mail.gmail.com  

commit   : 3eeadc425ccf30d5738bb1204adb2e50a8bea8c1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 30 Apr 2021 15:37:56 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 30 Apr 2021 15:37:56 -0400    

While we've always allowed such cases, the documentation didn't  
say you could do it.  
  
Discussion: https://postgr.es/m/161969805833.690.13680986983883602407@wrigleys.postgresql.org  

commit   : 7c810bd028a7be3ce32beb438db072bd02592869    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 30 Apr 2021 15:10:06 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 30 Apr 2021 15:10:06 -0400    

Mention specifically that you can't call aggregates, window functions,  
or procedures this way (the inability to call SRFs was already  
mentioned).  
  
Also, the claim that PQfn doesn't support NULL arguments or results  
has been a lie since we invented protocol 3.0.  Not sure why this  
text was never updated for that, but do it now.  
  
Discussion: https://postgr.es/m/2039442.1615317309@sss.pgh.pa.us  

commit   : 4d225ba0e6da73ddcbf207d2d91fc26537cfc5e1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 30 Apr 2021 14:10:26 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 30 Apr 2021 14:10:26 -0400    

Reject aggregates, window functions, and procedures.  Aggregates  
failed anyway, though with a somewhat obscure error message.  
Window functions would hit an Assert or null-pointer dereference.  
Procedures seemed to work as long as you didn't try to do  
transaction control, but (a) transaction control is sort of the  
point of a procedure, and (b) it's not entirely clear that no  
bugs lurk in that path.  Given the lack of testing of this area,  
it seems safest to be conservative in what we support.  
  
Also reject proretset functions, as the fastpath protocol can't  
support returning a set.  
  
Also remove an easily-triggered assertion that the given OID  
isn't 0; the subsequent lookups can handle that case themselves.  
  
Per report from Theodor-Arsenij Larionov-Trichkin.  
Back-patch to all supported branches.  (The procedure angle  
only applies in v11+, of course.)  
  
Discussion: https://postgr.es/m/2039442.1615317309@sss.pgh.pa.us  

commit   : bbcfee0e56a2a563a4907b116da72081a408eadf    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 29 Apr 2021 15:24:37 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 29 Apr 2021 15:24:37 -0400    

Commits 29aeda6e4 et al closed up some oversights involving not checking  
for non-upgradable types within container types, such as arrays and  
ranges.  However, I only looked at version.c, failing to notice that  
there were substantially-equivalent tests in check.c.  (The division  
of responsibility between those files is less than clear...)  
  
In addition, because genbki.pl does not guarantee that auto-generated  
rowtype OIDs will hold still across versions, we need to consider that  
the composite type associated with a system catalog or view is  
non-upgradable.  It seems unlikely that someone would have a user  
column declared that way, but if they did, trying to read it in another  
PG version would likely draw "no such pg_type OID" failures, thanks  
to the type OID embedded in composite Datums.  
  
To support the composite and reg*-type cases, extend the recursive  
query that does the search to allow any base query that returns  
a column of pg_type OIDs, rather than limiting it to exactly one  
starting type.  
  
As before, back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/2798740.1619622555@sss.pgh.pa.us  

commit   : 896cedc7d578b9fd9c966f87a32ec628ee6c01aa    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 29 Apr 2021 11:31:24 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 29 Apr 2021 11:31:24 -0400    

Backpatch to 12, where 87259588d0ab introduced the current behavior.  
  
Per note from Justin Pryzby.  
  
Co-authored-by: Justin Pryzby <pryzby@telsasoft.com>  
Discussion: https://postgr.es/m/20210416143135.GI3315@telsasoft.com  

commit   : 7bbcfb4d584d0eac4a1f68af09f4e15334236e13    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 28 Apr 2021 10:03:28 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 28 Apr 2021 10:03:28 -0400    

Somehow I'd convinced myself that rotating to UTC-12 was the way  
to do this, but upon further review, it's definitely UTC+12.  
  
Discussion: https://postgr.es/m/1197050.1619123213@sss.pgh.pa.us  

commit   : a928297bc6f135f299ded2888283e73a35f4ade8    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 28 Apr 2021 11:58:43 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 28 Apr 2021 11:58:43 +0900    

Spotted by buildfarm member prion, with -DRELCACHE_FORCE_RELEASE.  
  
Introduced in f7aab36.  
  
Discussion: https://postgr.es/m/2759018.1619577848@sss.pgh.pa.us  
Backpatch-through: 9.6  

commit   : f3c4537876843bea9a9d35d9643d347750961848    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 28 Apr 2021 11:18:17 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 28 Apr 2021 11:18:17 +0900    

Attempting to use this function with event triggers failed, as, since  
its introduction in a676201, this code has never associated an object  
name with event triggers.  This addresses the failure by adding the  
event trigger name to the set defining its object address.  
  
Note that regression tests are added within event_trigger and not  
object_address to avoid issues with concurrent connections in parallel  
schedules.  
  
Author: Joel Jacobson  
Discussion: https://postgr.es/m/3c905e77-a026-46ae-8835-c3f6cd1d24c8@www.fastmail.com  
Backpatch-through: 9.6  

commit   : ec5bab9217cddfda134abf1131904ec1958caadb    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 26 Apr 2021 11:50:35 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 26 Apr 2021 11:50:35 -0400    

For some reason, the "julian" option for extract()/date_part() has  
never gotten listed in the manual.  Also, while Appendix B mentioned  
in passing that we don't conform to the usual astronomical definition  
that a Julian date starts at noon UTC, it was kind of vague about what  
we do instead.  Clarify that, and add an example showing how to get  
the astronomical definition if you want it.  
  
It's been like this for ages, so back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/1197050.1619123213@sss.pgh.pa.us  

commit   : 8019fcb00f8832e3b0d787e078f28dbb853f3151    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Fri, 23 Apr 2021 15:45:46 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Fri, 23 Apr 2021 15:45:46 +0900    

Previously it was documented that if using "-X none" option there was  
no guarantee that all required WAL files were archived at the end of  
pg_basebackup when taking a backup from the standby. But this limitation  
was removed by commit 52f8a59dd9. Now, even when taking a backup  
from the standby, pg_basebackup can wait for all required WAL files  
to be archived. Therefore this commit removes such obsolete  
description from the docs.  
  
Also this commit adds new description about the limitation when  
taking a backup from the standby, into the docs. The limitation is that  
pg_basebackup cannot force the standbfy to switch to a new WAL file  
at the end of backup, which may cause pg_basebackup to wait a long  
time for the last required WAL file to be switched and archived,  
especially when write activity on the primary is low.  
  
Back-patch to v10 where the issue was introduced.  
  
Reported-by: Kyotaro Horiguchi  
Author: Kyotaro Horiguchi, Fujii Masao  
Reviewed-by: Kyotaro Horiguchi, Fujii Masao  
Discussion: https://postgr.es/m/20210420.133235.1342729068750553399.horikyota.ntt@gmail.com  

commit   : 2602ee4689c7691196568c59656662acf3be4e87    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 22 Apr 2021 17:30:42 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 22 Apr 2021 17:30:42 -0400    

Adopt a more consistent policy about what slot-type-specific  
getsysattr functions should do when system attributes are not  
available.  To wit, they should all throw the same user-oriented  
error, rather than variously crashing or emitting developer-oriented  
messages.  
  
This closes a identifiable problem in commits a71cfc56b and  
3fb93103a (in v13 and v12), so back-patch into those branches,  
along with a test case to try to ensure we don't break it again.  
It is not known that any of the former crash cases are reachable  
in HEAD, but this seems like a good safety improvement in any case.  
  
Discussion: https://postgr.es/m/141051591267657@mail.yandex.ru  

commit   : 00037d8d004031d80d276da543262004ed6bff48    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 22 Apr 2021 14:47:26 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 22 Apr 2021 14:47:26 -0400    

Back-patch to v13; the table layout in older branches is unfriendly  
to adding such details.  
  
Laurenz Albe  
  
Discussion: https://postgr.es/m/161881920775.685.12293798764864559341@wrigleys.postgresql.org  

commit   : a71cfc56bf6013e3ea1d673acaf73fe7ebbd6bf3    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 22 Apr 2021 11:46:41 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 22 Apr 2021 11:46:41 -0400    

If the source and destination partitions don't have identical  
rowtypes (for example, one has dropped columns the other lacks),  
then the planSlot contents will be different because of that.  
If the query has a RETURNING list that tries to return resjunk  
columns out of the planSlot, that is columns from tables that  
were joined to the target table, we'd get errors or wrong answers.  
That's because we used the RETURNING list generated for the  
destination partition, which expects a planSlot matching that  
partition's subplan.  
  
The most practical fix seems to be to convert the updated destination  
tuple back to the source partition's rowtype, and then apply the  
RETURNING list generated for the source partition.  This avoids making  
fragile assumptions about whether the per-subpartition subplans  
generated all the resjunk columns in the same order.  
  
This has been broken since v11 introduced cross-partition UPDATE.  
The lack of field complaints shows that non-identical partitions  
aren't a common case; therefore, don't stress too hard about  
making the conversion efficient.  
  
There's no such bug in HEAD, because commit 86dc90056 got rid of  
per-target-relation variance in the contents of the planSlot.  
Hence, patch v11-v13 only.  
  
Amit Langote and Etsuro Fujita, small changes by me  
  
Discussion: https://postgr.es/m/CA+HiwqE_UK1jTSNrjb8mpTdivzd3dum6mK--xqKq0Y9VmfwWQA@mail.gmail.com  

commit   : 574a1b8fb42a9a74b84137a7600d561b4b2d48a4    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Wed, 21 Apr 2021 11:12:04 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Wed, 21 Apr 2021 11:12:04 -0400    

commit   : d31ae9286641b008bd5b100024d0ca4c20645386    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Wed, 21 Apr 2021 10:21:22 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Wed, 21 Apr 2021 10:21:22 -0400    

This has been found to cause hangs where tcp usage is forced.  
  
Alexey Kodratov  
  
Discussion: https://postgr.es/m/82e271a9a11928337fcb5b5e57b423c0@postgrespro.ru  
  
Backpatch to all live branches  

commit   : 7bfba4f1933003716d432d29d4d228bcf28e2e70    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 20 Apr 2021 11:32:02 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 20 Apr 2021 11:32:02 -0400    

An oversight introduced by the incremental-sort patches caused  
"could not find pathkey item to sort" errors in some situations  
where a sort key involves an aggregate or window function.  
  
The basic problem here is that find_em_expr_usable_for_sorting_rel  
isn't properly modeling what prepare_sort_from_pathkeys will do  
later.  Rather than hoping we can keep those functions in sync,  
let's refactor so that they actually share the code for  
identifying a suitable sort expression.  
  
With this refactoring, tlist.c's tlist_member_ignore_relabel  
is unused.  I removed it in HEAD but left it in place in v13,  
in case any extensions are using it.  
  
Per report from Luc Vlaming.  Back-patch to v13 where the  
problem arose.  
  
James Coleman and Tom Lane  
  
Discussion: https://postgr.es/m/91f3ec99-85a4-fa55-ea74-33f85a5c651f@swarm64.com  

commit   : bf5d1f1e0052100b716f7b7b0934aefb28f72e73    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Tue, 20 Apr 2021 14:35:16 +0200    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Tue, 20 Apr 2021 14:35:16 +0200    

Author: Julien Rouhaud  
Backpatch-through: 11  
Discussion: https://postgr.es/m/20210420121659.odjueyd4rpilorn5@nol  

commit   : e480c6dd33f40bf4a2ae561799b08a1cd7c3073b    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 16 Apr 2021 16:54:04 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 16 Apr 2021 16:54:04 -0400    

In order to avoid getting old logfile contents certain functions in  
PostgresNode were doing one of two things. On Windows it rotated the  
logfile and restarted the server, while elsewhere it truncated the log  
file. Both of these are unnecessary. We borrow from the buildfarm which  
does this instead: note the size of the logfile before we start, and  
then when fetching the logfile skip to that position before accumulating  
contents. This is spelled differently on Windows but the effect is the  
same. This is largely centralized in TestLib's slurp_file function,  
which has a new optional parameter, the offset to skip to before  
starting to reading the file. Code in the client becomes much neater.  
  
Backpatch to all live branches.  
  
Michael Paquier, slightly modified by me.  
  
Discussion: https://postgr.es/m/YHajnhcMAI3++pJL@paquier.xyz  

commit   : 0e8acd39ecdf9a68ebdaf9652a56b943f34c9c58    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 16 Apr 2021 16:56:25 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 16 Apr 2021 16:56:25 +0900    

Author: Erik Rijkers  
Discussion: https://postgr.es/m/1219476687.20432.1617452918468@webmailclassic.xs4all.nl  
Backpatch-through: 12  

commit   : c39aa1e878cb9da16ed6bbc32bb1c83ef93595d4    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 13 Apr 2021 15:10:18 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 13 Apr 2021 15:10:18 -0400    

Most GUC check hooks that inspect database state have special checks  
that prevent them from throwing hard errors for state-dependent issues  
when source == PGC_S_TEST.  This allows, for example,  
"ALTER DATABASE d SET default_text_search_config = foo" when the "foo"  
configuration hasn't been created yet.  Without this, we have problems  
during dump/reload or pg_upgrade, because pg_dump has no idea about  
possible dependencies of GUC values and can't ensure a safe restore  
ordering.  
  
However, check_role() and check_session_authorization() hadn't gotten  
the memo about that, and would throw hard errors anyway.  It's not  
entirely clear what is the use-case for "ALTER ROLE x SET role = y",  
but we've now heard two independent complaints about that bollixing  
an upgrade, so apparently some people are doing it.  
  
Hence, fix these two functions to act more like other check hooks  
with similar needs.  (But I did not change their insistence on  
being inside a transaction, as it's still not apparent that setting  
either GUC from the configuration file would be wise.)  
  
Also fix check_temp_buffers, which had a different form of the disease  
of making state-dependent checks without any exception for PGC_S_TEST.  
A cursory survey of other GUC check hooks did not find any more issues  
of this ilk.  (There are a lot of interdependencies among  
PGC_POSTMASTER and PGC_SIGHUP GUCs, which may be a bad idea, but  
they're not relevant to the immediate concern because they can't be  
set via ALTER ROLE/DATABASE.)  
  
Per reports from Charlie Hornsby and Nathan Bossart.  Back-patch  
to all supported branches.  
  
Discussion: https://postgr.es/m/HE1P189MB0523B31598B0C772C908088DB7709@HE1P189MB0523.EURP189.PROD.OUTLOOK.COM  
Discussion: https://postgr.es/m/20160711223641.1426.86096@wrigleys.postgresql.org  

commit   : 97b7ad4688848b38ceac604e1dd2e6af39098229    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 13 Apr 2021 13:37:07 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 13 Apr 2021 13:37:07 -0400    

Previously, get_cached_rowtype() cached a pointer to a reference-counted  
tuple descriptor from the typcache, relying on the ExprContextCallback  
mechanism to release the tupdesc refcount when the expression tree  
using the tupdesc was destroyed.  This worked fine when it was designed,  
but the introduction of within-DO-block COMMITs broke it.  The refcount  
is logged in a transaction-lifespan resource owner, but plpgsql won't  
destroy simple expressions made within the DO block (before its first  
commit) until the DO block is exited.  That results in a warning about  
a leaked tupdesc refcount when the COMMIT destroys the original resource  
owner, and then an error about the active resource owner not holding a  
matching refcount when the expression is destroyed.  
  
To fix, get rid of the need to have a shutdown callback at all, by  
instead caching a pointer to the relevant typcache entry.  Those  
survive for the life of the backend, so we needn't worry about the  
pointer becoming stale.  (For registered RECORD types, we can still  
cache a pointer to the tupdesc, knowing that it won't change for the  
life of the backend.)  This mechanism has been in use in plpgsql  
and expandedrecord.c since commit 4b93f5799, and seems to work well.  
  
This change requires modifying the ExprEvalStep structs used by the  
relevant expression step types, which is slightly worrisome for  
back-patching.  However, there seems no good reason for extensions  
to be familiar with the details of these particular sub-structs.  
  
Per report from Rohit Bhogate.  Back-patch to v11 where within-DO-block  
COMMITs became a thing.  
  
Discussion: https://postgr.es/m/CAAV6ZkQRCVBh8qAY+SZiHnz+U+FqAGBBDaDTjF2yiKa2nJSLKg@mail.gmail.com  

commit   : 37e76546a2ba4cdf1ca14b25b1e729aef7235870    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 13 Apr 2021 12:17:24 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 13 Apr 2021 12:17:24 -0400    

heap_update needs to clear any existing "all visible" flag on  
the old tuple's page (and on the new page too, if different).  
Per coding rules, to do this it must acquire pin on the appropriate  
visibility-map page while not holding exclusive buffer lock;  
which creates a race condition since someone else could set the  
flag whenever we're not holding the buffer lock.  The code is  
supposed to handle that by re-checking the flag after acquiring  
buffer lock and retrying if it became set.  However, one code  
path through heap_update itself, as well as one in its subroutine  
RelationGetBufferForTuple, failed to do this.  The end result,  
in the unlikely event that a concurrent VACUUM did set the flag  
while we're transiently not holding lock, is a non-recurring  
"PANIC: wrong buffer passed to visibilitymap_clear" failure.  
  
This has been seen a few times in the buildfarm since recent VACUUM  
changes that added code paths that could set the all-visible flag  
while holding only exclusive buffer lock.  Previously, the flag  
was (usually?) set only after doing LockBufferForCleanup, which  
would insist on buffer pin count zero, thus preventing the flag  
from becoming set partway through heap_update.  However, it's  
clear that it's heap_update not VACUUM that's at fault here.  
  
What's less clear is whether there is any hazard from these bugs  
in released branches.  heap_update is certainly violating API  
expectations, but if there is no code path that can set all-visible  
without a cleanup lock then it's only a latent bug.  That's not  
100% certain though, besides which we should worry about extensions  
or future back-patch fixes that could introduce such code paths.  
  
I chose to back-patch to v12.  Fixing RelationGetBufferForTuple  
before that would require also back-patching portions of older  
fixes (notably 0d1fe9f74), which is more code churn than seems  
prudent to fix a hypothetical issue.  
  
Discussion: https://postgr.es/m/2247102.1618008027@sss.pgh.pa.us  

commit   : 13881199ee5760ed5e40df1fa749d9715467f43e    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Mon, 12 Apr 2021 19:24:41 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 12 Apr 2021 19:24:41 -0700    

With the Oracle Developer Studio 12.6 compiler, #line directives alter  
the current source file location for purposes of #include "..."  
directives.  Hence, a VPATH build failed with 'cannot find include file:  
"specscanner.c"'.  With two exceptions, parser-containing directories  
already add "-I. -I$(srcdir)"; eliminate the exceptions.  Back-patch to  
9.6 (all supported versions).  

commit   : 766c8fce5281f8a7cf690e1fe2dc3a19c326578f    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Mon, 12 Apr 2021 19:24:21 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 12 Apr 2021 19:24:21 -0700    

It doesn't support "\(foo\)*" like a POSIX "sed" implementation does;  
see the Autoconf manual.  Back-patch to 9.6 (all supported versions).  

commit   : 16175e278763e88618c814b6489c4ae795501282    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Tue, 13 Apr 2021 12:34:25 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Tue, 13 Apr 2021 12:34:25 +1200    

Commit 6f38d4dac38 failed to heed a warning about the stability of the  
value pointed to by "otid".  The caller is allowed to pass in a pointer to  
newtup->t_self, which will be updated during the execution of the  
function.  Instead, the SSI check should use the value we copy into  
oldtup.t_self near the top of the function.  
  
Not a live bug, because newtup->t_self doesn't really get updated until  
a bit later, but it was confusing and broke the rule established by the  
comment.  
  
Back-patch to 13.  
  
Reported-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/2689164.1618160085%40sss.pgh.pa.us  

commit   : 8a7bd1e6cba37170afadcb252da3cf9c5386ef06    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 12 Apr 2021 14:37:22 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 12 Apr 2021 14:37:22 -0400    

There are hacks in parse_coerce.c to push down a requested coercion  
to below any CollateExpr that may appear.  However, we did that even  
if the requested data type is non-collatable, leading to an invalid  
expression tree in which CollateExpr is applied to a non-collatable  
type.  The fix is just to drop the CollateExpr altogether, reasoning  
that it's useless.  
  
This bug is ten years old, dating to the original addition of  
COLLATE support.  The lack of field complaints suggests that there  
aren't a lot of user-visible consequences.  We noticed the problem  
because it would trigger an assertion in DefineVirtualRelation if  
the invalid structure appears as an output column of a view; however,  
in a non-assert build, you don't see a crash just a (subtly incorrect)  
complaint about applying collation to a non-collatable type.  I found  
that by putting the incorrect structure further down in a view, I could  
make a view definition that would fail dump/reload, per the added  
regression test case.  But CollateExpr doesn't do anything at run-time,  
so this likely doesn't lead to any really exciting consequences.  
  
Per report from Yulin Pei.  Back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/HK0PR01MB22744393C474D503E16C8509F4709@HK0PR01MB2274.apcprd01.prod.exchangelabs.com  

commit   : 48d4a8c88ba73c5e68461d1ced9090ac33827028    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Mon, 12 Apr 2021 09:03:16 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Mon, 12 Apr 2021 09:03:16 +0530    

Currently, parallel vacuum workers don't use any buffer access strategy.  
We can fix it either by propagating the access strategy from a leader or  
allow each worker to use BAS_VACUUM access strategy type. We don't see  
much use in propagating this information from leader as both leader and  
workers are supposed to use the same strategy. We might want to use a  
different access strategy for leader and workers but that would be a  
separate optimization not suitable for back-branches. This has been fixed  
in HEAD as commit f6b8f19a08.  
  
Author: Amit Kapila  
Reviewed-by: Sawada Masahiko, Bharath Rupireddy  
Discussion: https://postgr.es/m/CAA4eK1KbmJgRV2W3BbzRnKUSrukN7SbqBBriC4RDB5KBhopkGQ@mail.gmail.com  

commit   : be79debd9688da516f49ba9b825ee2e784d1fab0    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 12 Apr 2021 11:31:26 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 12 Apr 2021 11:31:26 +0900    

Using Roman numbers (via "RM" or "rm") for a conversion to calculate a  
number of months has never considered the case of negative numbers,  
where a conversion could easily cause out-of-bound memory accesses.  The  
conversions in themselves were not completely consistent either, as  
specifying 12 would result in NULL, but it should mean XII.  
  
This commit reworks the conversion calculation to have a more  
consistent behavior:  
- If the number of months and years is 0, return NULL.  
- If the number of months is positive, return the exact month number.  
- If the number of months is negative, do a backward calculation, with  
-1 meaning December, -2 November, etc.  
  
Reported-by: Theodor Arsenij Larionov-Trichkin  
Author: Julien Rouhaud  
Discussion: https://postgr.es/m/16953-f255a18f8c51f1d5@postgresql.org  
backpatch-through: 9.6  

commit   : 19b28d69128a7ca78705be9f4afca5044541beca    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Fri, 9 Apr 2021 12:40:14 +0200    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Fri, 9 Apr 2021 12:40:14 +0200    

Author: Daniel Westermann  
Backpatch-through: 9.6  
Discussion: https://postgr.es/m/GV0P278MB0483A7AA85BAFCC06D90F453D2739@GV0P278MB0483.CHEP278.PROD.OUTLOOK.COM  

commit   : dc6d285c2ef997f3a8d4c9f0e0599b62b0cbd054    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 9 Apr 2021 13:53:17 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 9 Apr 2021 13:53:17 +0900    

Comment fixes are applied on HEAD, and documentation improvements are  
applied on back-branches where needed.  
  
Author: Justin Pryzby  
Discussion: https://postgr.es/m/20210408164008.GJ6592@telsasoft.com  
Backpatch-through: 9.6  

commit   : 1aad1d181d28ede484302188413b07100e12383f    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Wed, 7 Apr 2021 15:58:35 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Wed, 7 Apr 2021 15:58:35 +0200    

The code in bringetbitmap() simply added the whole matching page range  
to the TID bitmap, as determined by pages_per_range, even if some of the  
pages were beyond the end of the heap. The query then might fail with  
an error like this:  
  
  ERROR:  could not open file "base/20176/20228.2" (target block  
          262144): previous segment is only 131021 blocks  
  
In this case, the relation has 262093 pages (131072 and 131021 pages),  
but we're trying to acess block 262144, i.e. first block of the 3rd  
segment. At that point _mdfd_getseg() notices the preceding segment is  
incomplete, and fails.  
  
Hitting this in practice is rather unlikely, because:  
  
* Most indexes use power-of-two ranges, so segments and page ranges  
  align perfectly (segment end is also a page range end).  
  
* The table size has to be just right, with the last segment being  
  almost full - less than one page range from full segment, so that the  
  last page range actually crosses the segment boundary.  
  
* Prefetch has to be enabled. The regular page access checks that  
  pages are not beyond heap end, but prefetch does not. On older  
  releases (before 12) the execution stops after hitting the first  
  non-existent page, so the prefetch distance has to be sufficient  
  to reach the first page in the next segment to trigger the issue.  
  Since 12 it's enough to just have prefetch enabled, the prefetch  
  distance does not matter.  
  
Fixed by not adding non-existent pages to the TID bitmap. Backpatch  
all the way back to 9.6 (BRIN indexes were introduced in 9.5, but that  
release is EOL).  
  
Backpatch-through: 9.6  

commit   : b55619948ea18dbc0f4f8ca823aaa687c0fa2567    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 7 Apr 2021 19:58:54 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 7 Apr 2021 19:58:54 +0900    

Instead of writing a query to psql's stdin, which can cause a failure  
where psql exits before writing, reporting a write failure with a broken  
pipe, this changes the logic to use -c.  This was not seen in the  
buildfarm as no animals with a sensitive environment are running the  
kerberos tests, but let's be safe.  
  
HEAD is able to handle the situation as of 6d41dd0 for all the test  
suites doing connection checks.  f44b9b6 has fixed the same problem for  
the LDAP tests.  
  
Discussion: https://postgr.es/m/YGu7ceWAiSNQDgH5@paquier.xyz  
Backpatch-through: 11  

commit   : e7bcfd717ef31166617e0391d5c132f3cfb30fab    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Tue, 6 Apr 2021 02:25:37 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Tue, 6 Apr 2021 02:25:37 +0900    

Maxim Orlov reported that the shutdown of standby server could result in  
the following assertion failure. The cause of this issue was that,  
when the shutdown caused the startup process to exit, recovery-time  
transaction tracking was not shut down even if it's already initialized,  
and some locks the tracked transactions were holding could not be released.  
At this situation, if other process was invoked and the PGPROC entry that  
the startup process used was assigned to it, it found such unreleased locks  
and caused the assertion failure, during the initialization of it.  
  
    TRAP: FailedAssertion("SHMQueueEmpty(&(MyProc->myProcLocks[i]))"  
  
This commit fixes this issue by making the startup process shut down  
transaction tracking and release all locks, at the exit of it.  
  
Back-patch to all supported branches.  
  
Reported-by: Maxim Orlov  
Author: Fujii Masao  
Reviewed-by: Maxim Orlov  
Discussion: https://postgr.es/m/ad4ce692cc1d89a093b471ab1d969b0b@postgrespro.ru  

commit   : fd91fed3e802c77b1e8a882b9797fd3c17115bbb    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 4 Apr 2021 17:57:07 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 4 Apr 2021 17:57:07 -0400    

spg_box_quad_leaf_consistent unconditionally returned the leaf  
datum as leafValue, even though in its usage for poly_ops that  
value is of completely the wrong type.  
  
In versions before 12, that was harmless because the core code did  
nothing with leafValue in non-index-only scans ... but since commit  
2a6368343, if we were doing a KNN-style scan, spgNewHeapItem would  
unconditionally try to copy the value using the wrong datatype  
parameters.  Said copying is a waste of time and space if we're not  
going to return the data, but it accidentally failed to fail until  
I fixed the datatype confusion in ac9099fc1.  
  
Hence, change spgNewHeapItem to not copy the datum unless we're  
actually going to return it later.  This saves cycles and dodges  
the question of whether lossy opclasses are returning the right  
type.  Also change spg_box_quad_leaf_consistent to not return  
data that might be of the wrong type, as insurance against  
somebody introducing a similar bug into the core code in future.  
  
It seems like a good idea to back-patch these two changes into  
v12 and v13, although I'm afraid to change spgNewHeapItem's  
mistaken idea of which datatype to use in those branches.  
  
Per buildfarm results from ac9099fc1.  
  
Discussion: https://postgr.es/m/3728741.1617381471@sss.pgh.pa.us  

commit   : 45aea47ef430bc942b831932adaca7730c6ae775    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Fri, 2 Apr 2021 16:42:29 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Fri, 2 Apr 2021 16:42:29 -0400    

All other places already use MONTHS_PER_YEAR appropriately.  
  
Backpatch-through: 9.6  

commit   : 4a1b95fcf4710c9578750d1d9ab4672eab3a5a82    
  
author   : Joe Conway <mail@joeconway.com>    
date     : Fri, 2 Apr 2021 13:48:45 -0400    
  
committer: Joe Conway <mail@joeconway.com>    
date     : Fri, 2 Apr 2021 13:48:45 -0400    

Command-line options, or previous "ALTER (ROLE|DATABASE) ...  
SET ROLE ..." commands, can change the value of the default role  
for a session. In the presence of one of these, RESET ROLE will  
change the current user identifier to the default role rather  
than the session user identifier. Fix the documentation to  
reflect this reality. Backpatch to all supported versions.  
  
Author: Nathan Bossart  
Reviewed-By: Laurenz Albe, David G. Johnston, Joe Conway  
Reported by: Nathan Bossart  
Discussion: https://postgr.es/m/flat/925134DB-8212-4F60-8AB1-B1231D750CB4%40amazon.com  
Backpatch-through: 9.6  

commit   : 104164361cb18d7c36d068e1ddd2453b0e4dc1bb    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Sat, 3 Apr 2021 00:07:00 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Sat, 3 Apr 2021 00:07:00 +0900    

pg_checksums uses two counters, total size and current size,  
to calculate the progress. Previously the progress that  
pg_checksums reported could not reach 100% at the end.  
The cause of this issue was that the sizes of only pages excluding  
new ones in each file were counted as the current size  
while the size of each file is counted as the total size.  
That is, the total size of all new pages could be reported  
as the difference between the total size and current size.  
  
This commit fixes this issue by making pg_checksums count  
the sizes of all pages including new ones in each file as  
the current size.  
  
Back-patch to v12 where progress reporting was added to pg_checksums.  
  
Reported-by: Shinya Kato  
Author: Shinya Kato  
Reviewed-by: Fujii Masao  
Discussion: https://postgr.es/m/TYAPR01MB289656B1ACA0A5E7CAD07BE3C47A9@TYAPR01MB2896.jpnprd01.prod.outlook.com  

commit   : f8c2d491234f4e9e2e7c183109250cc7c8bfd148    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 2 Apr 2021 16:37:07 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 2 Apr 2021 16:37:07 +0900    

The current instructions describing how to write the backup_label and  
tablespace_map files are confusing.  For example, opening a file in text  
mode on Windows and copy-pasting the file's contents would result in a  
failure at recovery because of the extra CRLF characters generated.  The  
documentation was not stating that clearly, and per discussion this is  
not considered as a supported scenario.  
  
This commit extends a bit the documentation to mention that it may be  
required to open the file in binary mode before writing its data.  
  
Reported-by: Wang Shenhao  
Author: David Steele  
Reviewed-by: Andrew Dunstan, Magnus Hagander  
Discussion: https://postgr.es/m/8373f61426074f2cb6be92e02f838389@G08CNEXMBPEKD06.g08.fujitsu.local  
Backpatch-through: 9.6  

commit   : 75e66ee690ae24c546f9a7d01d99779dbb9e08f1    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Thu, 1 Apr 2021 21:17:24 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Thu, 1 Apr 2021 21:17:24 -0400    

Also mention that you should read the intervening major releases notes.  
This change was also applied to the website.  
  
Discussion: https://postgr.es/m/20210330144949.GA8259@momjian.us  
  
Backpatch-through: 9.6  

commit   : 89937d001294b39469790e5a583e438af2ca1235    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 2 Apr 2021 09:44:50 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 2 Apr 2021 09:44:50 +0900    

This test has been using a simple VACUUM with pg_relation_size() to  
check if a relation gets physically truncated or not, but forgot the  
fact that some concurrent activity, like checkpoint buffer writes, could  
cause some pages to be skipped.  The second test enabling  
vacuum_truncate could fail, seeing a non-empty relation.  The first test  
would not have failed, but could finish by testing a behavior different  
than the one aimed for.  Both tests gain a FREEZE option, to make the  
vacuums more aggressive and prevent page skips.  
  
This is similar to the issues fixed in c2dc1a7.  
  
Author: Arseny Sher  
Reviewed-by: Masahiko Sawada  
Discussion: https://postgr.es/m/87tuotr2hh.fsf@ars-thinkpad  
backpatch-through: 12  

commit   : 35421a470de16565e5dca87dc4e2b76fa19c7d08    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 1 Apr 2021 13:34:16 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 1 Apr 2021 13:34:16 -0400    

Despite the clear comments pointing out that the duplicative code  
segments in ReadHead() and _discoverArchiveFormat() needed to be  
in sync, they were not: the latter did not bother to apply any of  
the sanity checks in the former.  We'd missed noticing this partly  
because none of those checks would fail in scenarios we customarily  
test, and partly because the oversight would be masked if both  
segments execute, which they would in cases other than needing to  
autodetect the format of a non-seekable stdin source.  However,  
in a case meeting all these requirements --- for example, trying  
to read a newer-than-supported archive format from non-seekable  
stdin --- pg_restore missed applying the version check and would  
likely dump core or otherwise misbehave.  
  
The whole thing is silly anyway, because there seems little reason  
to duplicate the logic beyond the one-line verification that the  
file starts with "PGDMP".  There seems to have been an undocumented  
assumption that multiple major formats (major enough to require  
separate reader modules) would nonetheless share the first half-dozen  
fields of the custom-format header.  This seems unlikely, so let's  
fix it by just nuking the duplicate logic in _discoverArchiveFormat().  
  
Also get rid of the pointless attempt to seek back to the start of  
the file after successful autodetection.  That wastes cycles and  
it means we have four behaviors to verify not two.  
  
Per bug #16951 from Sergey Koposov.  This has been broken for  
decades, so back-patch to all supported versions.  
  
Discussion: https://postgr.es/m/16951-a4dd68cf0de23048@postgresql.org  

commit   : 876ecfba4d829f6d6c70ac4aa5f05b03269fbd95    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 1 Apr 2021 15:28:45 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 1 Apr 2021 15:28:45 +0900    

Some sections of the documentation used "exclusive lock" to describe  
that an ACCESS EXCLUSIVE lock is taken during a given operation.  This  
can be confusing to the reader as ACCESS SHARE is allowed with an  
EXCLUSIVE lock is used, but that would not be the case with what is  
described on those parts of the documentation.  
  
Author: Greg Rychlewski  
Discussion: https://postgr.es/m/CAKemG7VptD=7fNWckFMsMVZL_zzvgDO6v2yVmQ+ZiBfc_06kCQ@mail.gmail.com  
Backpatch-through: 9.6  

commit   : 89e383b30a94d1fb1ebfd63131433a93bcf47625    
  
author   : Stephen Frost <sfrost@snowman.net>    
date     : Wed, 31 Mar 2021 16:23:18 -0400    
  
committer: Stephen Frost <sfrost@snowman.net>    
date     : Wed, 31 Mar 2021 16:23:18 -0400    

The new appendix groups information on renamed or removed settings,  
commands, etc into an out-of-the-way part of the docs.  
  
The original id elements are retained in each subsection to ensure that  
the same filenames are produced for HTML docs. This prevents /current/  
links on the web from breaking, and allows users of the web docs  
to follow links from old version pages to info on the changes in the  
new version. Prior to this change, a link to /current/ for renamed  
sections like the recovery.conf docs would just 404. Similarly if  
someone searched for recovery.conf they would find the pg11 docs,  
but there would be no /12/ or /current/ link, so they couldn't easily  
find out that it was removed in pg12 or how to adapt.  
  
Index entries are also added so that there's a breadcrumb trail for  
users to follow when they know the old name, but not what we changed it  
to. So a user who is trying to find out how to set standby_mode in  
PostgreSQL 12+, or where pg_resetxlog went, now has more chance of  
finding that information.  
  
Craig Ringer and Stephen Frost  
Reviewed-by: Euler Taveira  
Discussion: https://postgr.es/m/CAGRY4nzPNOyYQ_1-pWYToUVqQ0ThqP5jdURnJMZPm539fdizOg%40mail.gmail.com  
Backpatch-through: 10  

commit   : 78f8b0965a224e650b4fc42e5c174256ca0fc929    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Tue, 30 Mar 2021 13:00:02 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Tue, 30 Mar 2021 13:00:02 +0900    

Back-patch to all supported branches.  
  
Author: Etsuro Fujita  
Discussion: https://postgr.es/m/CAPmGK17DwzaSf%2BB71dhL2apXdtG-OmD6u2AL9Cq2ZmAR0%2BzapQ%40mail.gmail.com  

commit   : f50dc2c725fd546b994f228101211ae50e6858e5    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 29 Mar 2021 18:34:39 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 29 Mar 2021 18:34:39 -0300    

We were never doing clearerr() on the output stream, which results in a  
message being printed after each result once an EOF is seen:  
  
could not print result table: Success  
  
This message was added by commit b03436994bcc (in the pg13 era); before  
that, the error indicator would never be examined.  So backpatch only  
that far back, even though the actual bug (to wit: the fact that the  
error indicator is never cleared) is older.  

commit   : 092d3db05d34e2cd122b066cc61c139e7b90d635    
  
author   : Stephen Frost <sfrost@snowman.net>    
date     : Sun, 28 Mar 2021 11:28:12 -0400    
  
committer: Stephen Frost <sfrost@snowman.net>    
date     : Sun, 28 Mar 2021 11:28:12 -0400    

Commit c6763156589 added an acronym reference for "TLS" but the definition  
was never added.  
  
Author: Daniel Gustafsson  
Reviewed-by: Michael Paquier  
Backpatch-through: 9.6  
Discussion: https://postgr.es/m/27109504-82DB-41A8-8E63-C0498314F5B0@yesql.se  

commit   : 67251c82af87865989eb90c7e8f4546cc0d66e6d    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Fri, 26 Mar 2021 22:34:53 +0100    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Fri, 26 Mar 2021 22:34:53 +0100    

When estimating the number of groups using extended statistics, the code  
was discarding information about system attributes. This led to strange  
situation that  
  
    SELECT 1 FROM t GROUP BY ctid;  
  
could have produced higher estimate (equal to pg_class.reltuples) than  
  
    SELECT 1 FROM t GROUP BY a, b, ctid;  
  
with extended statistics on (a,b). Fixed by retaining information about  
the system attribute.  
  
Backpatch all the way to 10, where extended statistics were introduced.  
  
Author: Tomas Vondra  
Backpatch-through: 10  

commit   : c8622999b7fe53741304f2aca73560aade6557d2    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 25 Mar 2021 16:30:22 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 25 Mar 2021 16:30:22 -0300    

On partition detach, we acquire a SHARE lock on all tables that  
reference the partitioned table that we're detaching a partition from,  
but failed to document this fact.  My oversight in commit f56f8f8da6af.  
Repair.  Backpatch to 12.  
  
Author: Álvaro Herrera <alvherre@alvh.no-ip.org>  
Discussion: https://postgr.es/m/20210325180244.GA12738@alvherre.pgsql  

commit   : a00c3068206e6daa236dbff0256cf3ad25ff5ed2    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 25 Mar 2021 10:47:38 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 25 Mar 2021 10:47:38 -0300    

I introduced this duplicate code in commit 8b08f7d4820f for no good  
reason.  Remove it, and backpatch to 11 where it was introduced.  
  
Author: Álvaro Herrera <alvherre@alvh.no-ip.org>  

commit   : 092c077c1321c259f86721ad9319fae3c90c9b8b    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Thu, 25 Mar 2021 11:23:30 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Thu, 25 Mar 2021 11:23:30 +0900    

Previously the WAL replay of COMMIT_TS_SETTS record called  
TransactionTreeSetCommitTsData() with the argument write_xlog=true,  
which generated and wrote new COMMIT_TS_SETTS record.  
This should not be acceptable because it's during recovery.  
  
This commit fixes the WAL replay of COMMIT_TS_SETTS record  
so that it calls TransactionTreeSetCommitTsData() with write_xlog=false  
and doesn't generate new WAL during recovery.  
  
Back-patch to all supported branches.  
  
Reported-by: lx zou <zoulx1982@163.com>  
Author: Fujii Masao  
Reviewed-by: Alvaro Herrera  
Discussion: https://postgr.es/m/16931-620d0f2fdc6108f1@postgresql.org  

commit   : c6eac71a88447d82d5f6d28b6bed2e9c6971d714    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 23 Mar 2021 14:27:50 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 23 Mar 2021 14:27:50 -0400    

Jasen Betts reported yet another unintended side effect of commit  
85c54287a: reconnecting with "\c service=whatever" did not have the  
expected results.  The reason is that starting from the output of  
PQconndefaults() effectively allows environment variables (such  
as PGPORT) to override entries in the service file, whereas the  
normal priority is the other way around.  
  
Not using PQconndefaults at all would require yet a third main code  
path in do_connect's parameter setup, so I don't really want to fix  
it that way.  But we can have the logic effectively ignore all the  
default values for just a couple more lines of code.  
  
This patch doesn't change the behavior for "\c -reuse-previous=on  
service=whatever".  That remains significantly different from before  
85c54287a, because many more parameters will be re-used, and thus  
not be possible for service entries to replace.  But I think this  
is (mostly?) intentional.  In any case, since libpq does not report  
where it got parameter values from, it's hard to do differently.  
  
Per bug #16936 from Jasen Betts.  As with the previous patches,  
back-patch to all supported branches.  (9.5 is unfortunately now  
out of support, so this won't get fixed there.)  
  
Discussion: https://postgr.es/m/16936-3f524322a53a29f0@postgresql.org  

commit   : d4791ac35cb1d7417ea3cff6cc604623463ef0ea    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 23 Mar 2021 11:24:16 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 23 Mar 2021 11:24:16 -0400    

end_heap_rewrite was not careful to ensure that the target relation  
is open at the smgr level before performing its final smgrimmedsync.  
In ordinary cases this is no problem, because it would have been  
opened earlier during the rewrite.  However a crash can be reproduced  
by re-clustering an empty table with CLOBBER_CACHE_ALWAYS enabled.  
  
Although that exact scenario does not crash in v13, I think that's  
a chance result of unrelated planner changes, and the problem is  
likely still reachable with other test cases.  The true proximate  
cause of this failure is commit c6b92041d, which replaced a call to  
heap_sync (which was careful about opening smgr) with a direct call  
to smgrimmedsync.  Hence, back-patch to v13.  
  
Amul Sul, per report from Neha Sharma; cosmetic changes  
and test case by me.  
  
Discussion: https://postgr.es/m/CANiYTQsU7yMFpQYnv=BrcRVqK_3U3mtAzAsJCaqtzsDHfsUbdQ@mail.gmail.com  

commit   : 1faaad260d8f56d4f73af76ab576b85e9013beca    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Tue, 23 Mar 2021 04:45:26 +0100    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Tue, 23 Mar 2021 04:45:26 +0100    

A couple error messages and comments used 'statistic kind', not the  
correct 'statistics kind'. Fix and backpatch all the way back to 10,  
where extended statistics were introduced.  
  
Backpatch-through: 10  

commit   : 34279fd4fabdedba0bc72b05dc32753e1193d599    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Tue, 23 Mar 2021 09:53:08 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Tue, 23 Mar 2021 09:53:08 +0900    

pg_waldump --stats=record identifies a record by a combination  
of the RmgrId and the four bits of the xl_info field of the record.  
But XACT records use the first bit of those four bits for an optional  
flag variable, and the following three bits for the opcode to  
identify a record. So previously the same type of XACT record  
could have different four bits (three bits are the same but the  
first one bit is different), and which could cause  
pg_waldump --stats=record to show two lines of per-record statistics  
for the same XACT record. This is a bug.  
  
This commit changes pg_waldump --stats=record so that it processes  
only XACT record differently, i.e., filters the opcode out of xl_info  
and uses a combination of the RmgrId and those three bits as  
the identifier of a record, only for XACT record. For other records,  
the four bits of the xl_info field are still used.  
  
Back-patch to all supported branches.  
  
Author: Kyotaro Horiguchi  
Reviewed-by: Shinya Kato, Fujii Masao  
Discussion: https://postgr.es/m/2020100913412132258847@highgo.ca  

commit   : 78c24e97dd189f62187a99ef84016d0eb35a7978    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 22 Mar 2021 14:02:36 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 22 Mar 2021 14:02:36 +0900    

This commit is mostly a revert of aaa3aed, that switched the routine  
doing the internal renaming of recycled WAL segments to use on Windows a  
combination of CreateHardLinkA() plus unlink() instead of rename().  As  
reported by several users of Postgres 13, this is causing concurrency  
issues when manipulating WAL segments, mostly in the shape of the  
following error:  
LOG:  could not rename file "pg_wal/000000XX000000YY000000ZZ":  
Permission denied  
  
This moves back to a logic where a single rename() (well, pgrename() for  
Windows) is used.  This issue has proved to be hard to hit when I tested  
it, facing it only once with an archive_command that was not able to do  
its work, so it is environment-sensitive.  The reporters of this issue  
have been able to confirm that the situation improved once we switched  
back to a single rename().  In order to check things, I have provided to  
the reporters a patched build based on 13.2 with aaa3aed reverted, to  
test if the error goes away, and an unpatched build of 13.2 to test if  
the error still showed up (just to make sure that I did not mess up my  
build process).  
  
Extra thanks to Fujii Masao for pointing out what looked like the  
culprit commit, and to all the reporters for taking the time to test  
what I have sent them.  
  
Reported-by: Andrus, Guy Burgess, Yaroslav Pashinsky, Thomas Trenz  
Reviewed-by: Tom Lane, Andres Freund  
Discussion: https://postgr.es/m/3861ff1e-0923-7838-e826-094cc9bef737@hot.ee  
Discussion: https://postgr.es/m/16874-c3eecd319e36a2bf@postgresql.org  
Discussion: https://postgr.es/m/095ccf8d-7f58-d928-427c-b17ace23cae6@burgess.co.nz  
Discussion: https://postgr.es/m/16927-67c570d968c99567%40postgresql.org  
Discussion: https://postgr.es/m/YFBcRbnBiPdGZvfW@paquier.xyz  
Backpatch-through: 13  

commit   : 48664e41688ca113e01b7055d41957c600e565ca    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sun, 21 Mar 2021 19:09:29 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sun, 21 Mar 2021 19:09:29 -0700    

Back-patch to v13, which introduced the test code in question.  

commit   : 7bdc717a5438650c13b7dcde427828eb1743fd8c    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 22 Mar 2021 09:51:14 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 22 Mar 2021 09:51:14 +0900    

The test added by 595b9cb forgot that on Windows it is necessary to set  
up pg_hba.conf (see PostgresNode::set_replication_conf) with a specific  
entry or base backups fail.  Any node that requires to support  
replication just needs to pass down allows_streaming at initialization.  
This updates the test to do so.  Simplify things a bit while on it.  
  
Per buildfarm member fairywren.  Any Windows hosts running this test  
would have failed, and I have reproduced the problem as well.  
  
Backpatch-through: 10  

commit   : 6e5ce888ad1e7b7da5de507d89d03bc83d954923    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 22 Mar 2021 08:31:01 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 22 Mar 2021 08:31:01 +0900    

Any transactions found as still prepared by a checkpoint have their  
state data read from the WAL records generated by PREPARE TRANSACTION  
before being moved into their new location within pg_twophase/.  While  
reading such records, the WAL reader uses the callback  
read_local_xlog_page() to read a page, that is shared across various  
parts of the system.  This callback, since 1148e22a, has introduced an  
update of ThisTimeLineID when reading a record while in recovery, which  
is potentially helpful in the context of cascading WAL senders.  
  
This update of ThisTimeLineID interacts badly with the checkpointer if a  
promotion happens while some 2PC data is read from its record, as, by  
changing ThisTimeLineID, any follow-up WAL records would be written to  
an timeline older than the promoted one.  This results in consistency  
issues.  For instance, a subsequent server restart would cause a failure  
in finding a valid checkpoint record, resulting in a PANIC, for  
instance.  
  
This commit changes the code reading the 2PC data to reset the timeline  
once the 2PC record has been read, to prevent messing up with the static  
state of the checkpointer.  It would be tempting to do the same thing  
directly in read_local_xlog_page().  However, based on the discussion  
that has led to 1148e22a, users may rely on the updates of  
ThisTimeLineID when a WAL record page is read in recovery, so changing  
this callback could break some cases that are working currently.  
  
A TAP test reproducing the issue is added, relying on a PITR to  
precisely trigger a promotion with a prepared transaction still  
tracked.  
  
Per discussion with Heikki Linnakangas, Kyotaro Horiguchi, Fujii Masao  
and myself.  
  
Author: Soumyadeep Chakraborty, Jimmy Yih, Kevin Yeap  
Discussion: https://postgr.es/m/CAE-ML+_EjH_fzfq1F3RJ1=XaaNG=-Jz-i3JqkNhXiLAsM3z-Ew@mail.gmail.com  
Backpatch-through: 10  

commit   : 4b41f6923458ec736ff5d81e48229b88cf39b635    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 20 Mar 2021 12:47:21 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 20 Mar 2021 12:47:21 -0400    

While back-patching e0e569e1d, I noted that there were some other  
places where we ought to be applying DH_free(); namely, where we  
load some DH parameters from a file and then reject them as not  
being sufficiently secure.  While it seems really unlikely that  
anybody would hit these code paths in production, let alone do  
so repeatedly, let's fix it for consistency.  
  
Back-patch to v10 where this code was introduced.  
  
Discussion: https://postgr.es/m/16160-18367e56e9a28264@postgresql.org  

commit   : 12354839e874c1f6ebc5e1e5ebc1c6b5519eeea0    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 18 Mar 2021 22:21:58 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 18 Mar 2021 22:21:58 -0400    

We leaked the error report from PQconninfoParse, when there was  
one.  It seems unlikely that real usage patterns would repeat  
the failure often enough to create serious bloat, but let's  
back-patch anyway to keep the code similar in all branches.  
  
Found via valgrind testing.  
Back-patch to v10 where this code was added.  
  
Discussion: https://postgr.es/m/3816764.1616104288@sss.pgh.pa.us  

commit   : 642b0b69b0638261fe81dfd9ca3b92927496f1cb    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 18 Mar 2021 22:09:41 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 18 Mar 2021 22:09:41 -0400    

Because guc.c prefers to keep all its string values in malloc'd  
not palloc'd storage, it has to be more careful than usual to  
avoid leaks.  Error exits out of string GUC hook checks failed  
to clear the proposed value string, and error exits out of  
ProcessGUCArray() failed to clear the malloc'd results of  
ParseLongOption().  
  
Found via valgrind testing.  
This problem is ancient, so back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/3816764.1616104288@sss.pgh.pa.us  

commit   : eba939551afe5709d15fe7779e7771ae0c8bf830    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 18 Mar 2021 21:44:43 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 18 Mar 2021 21:44:43 -0400    

The text search cache mechanisms assume that we can clean up  
an invalidated dictionary cache entry simply by resetting the  
associated long-lived memory context.  However, that does not work  
for ispell affixes that make use of regular expressions, because  
the regex library deals in plain old malloc.  Hence, we leaked  
compiled regex(es) any time we dropped such a cache entry.  That  
could quickly add up, since even a fairly trivial regex can use up  
tens of kB, and a large one can eat megabytes.  Add a memory context  
callback to ensure that a regex gets freed when its owning cache  
entry is cleared.  
  
Found via valgrind testing.  
This problem is ancient, so back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/3816764.1616104288@sss.pgh.pa.us  

commit   : ea3989f3496c9c6a0c392680842518997d317e38    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 18 Mar 2021 20:50:56 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 18 Mar 2021 20:50:56 -0400    

Some code paths in this function perform syscache lookups, which  
can lead to table accesses and possibly leakage of cruft into  
the caller's context.  If said context is CacheMemoryContext,  
we eventually will have visible bloat.  But fixing this is no  
harder than moving one memory context switch step.  (The other  
callers don't have a problem.)  
  
Andres Freund and I independently found this via valgrind testing.  
Back-patch to v12 where this code was added.  
  
Discussion: https://postgr.es/m/20210317023101.anvejcfotwka6gaa@alap3.anarazel.de  
Discussion: https://postgr.es/m/3816764.1616104288@sss.pgh.pa.us  

commit   : 5368369701447b4f2a767c34cfde1f9f4eb53f7a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 18 Mar 2021 20:37:09 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 18 Mar 2021 20:37:09 -0400    

Although these lists are usually NIL, and even when not empty  
are unlikely to be large, constant relcache update traffic could  
eventually result in visible bloat of CacheMemoryContext.  
  
Found via valgrind testing.  
Back-patch to v10 where this field was added.  
  
Discussion: https://postgr.es/m/3816764.1616104288@sss.pgh.pa.us  

commit   : 0c3079e3ef6956feefc9cc4f62ad1f9acc7c84e9    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Thu, 18 Mar 2021 11:17:42 +0100    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Thu, 18 Mar 2021 11:17:42 +0100    

pg_read_file() is the function that's in core, pg_file_read() is in  
adminpack. But when using pg_file_read() in adminpack it calls the *C*  
level function pg_read_file() in core, which probably threw the original  
author off. But the error hint should be about the SQL function.  
  
Reported-By: Sergei Kornilov  
Backpatch-through: 11  
Discussion: https://postgr.es/m/373021616060475@mail.yandex.ru  

commit   : b77e5d73bcfc0810e7a4eab29cfbc2859adb8db9    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 17 Mar 2021 16:10:37 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 17 Mar 2021 16:10:37 -0400    

Robert Foggia of Trustwave reported that read_tablespace_map()  
fails to prevent an overrun of its on-stack input buffer.  
Since the tablespace map file is presumed trustworthy, this does  
not seem like an interesting security vulnerability, but still  
we should fix it just in the name of robustness.  
  
While here, document that pg_basebackup's --tablespace-mapping option  
doesn't work with tar-format output, because it doesn't.  To make it  
work, we'd have to modify the tablespace_map file within the tarball  
sent by the server, which might be possible but I'm not volunteering.  
(Less-painful solutions would require changing the basebackup protocol  
so that the source server could adjust the map.  That's not very  
appetizing either.)  

commit   : 69739ec317aef5df0ce9258142b3124b6c58b202    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Thu, 18 Mar 2021 01:00:56 +1300    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Thu, 18 Mar 2021 01:00:56 +1300    

This reverts commit 4e0f0995e923948631c4114ab353b256b51b58ad.  
  
Discussion: https://postgr.es/m/CA%2BhUKGJmcqAE3MZeDCLLXa62cWM0AJbKmp2JrJYaJ86bz36LFA%40mail.gmail.com  

commit   : 4e0f0995e923948631c4114ab353b256b51b58ad    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Wed, 17 Mar 2021 17:46:39 +1300    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Wed, 17 Mar 2021 17:46:39 +1300    

With very unlucky timing and parallel_leader_participation off, PHJ  
could attempt to access per-batch state just as it was being freed.  
There was code intended to prevent that by checking for a cleared  
pointer, but it was buggy.  
  
Fix, by introducing an extra barrier phase.  The new phase  
PHJ_BUILD_RUNNING means that it's safe to access the per-batch state to  
find a batch to help with, and PHJ_BUILD_DONE means that it is too late.  
The last to detach will free the array of per-batch state as before, but  
now it will also atomically advance the phase at the same time, so that  
late attachers can avoid the hazard, without the data race.  This  
mirrors the way per-batch hash tables are freed (see phases  
PHJ_BATCH_PROBING and PHJ_BATCH_DONE).  
  
Revealed by a one-off build farm failure, where BarrierAttach() failed a  
sanity check assertion, because the memory had been clobbered by  
dsa_free().  
  
Back-patch to 11, where the code arrived.  
  
Reported-by: Michael Paquier <michael@paquier.xyz>  
Discussion: https://postgr.es/m/20200929061142.GA29096%40paquier.xyz  

commit   : 4d072bf2a031f343ef796dac6d324d9a03121183    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 16 Mar 2021 16:02:49 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 16 Mar 2021 16:02:49 -0400    

After reading the root cert list from the ssl_ca_file, immediately  
install it as client CA list of the new SSL context.  That gives the  
SSL context ownership of the list, so that SSL_CTX_free will free it.  
This avoids a permanent memory leak if we fail further down in  
be_tls_init(), which could happen if bogus CRL data is offered.  
  
The leak could only amount to something if the CRL parameters get  
broken after server start (else we'd just quit) and then the server  
is SIGHUP'd many times without fixing the CRL data.  That's rather  
unlikely perhaps, but it seems worth fixing, if only because the  
code is clearer this way.  
  
While we're here, add some comments about the memory management  
aspects of this logic.  
  
Noted by Jelte Fennema and independently by Andres Freund.  
Back-patch to v10; before commit de41869b6 it doesn't matter,  
since we'd not re-execute this code during SIGHUP.  
  
Discussion: https://postgr.es/m/16160-18367e56e9a28264@postgresql.org  

commit   : 6ed05993310703f2f216142dada48bc1f10868fb    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 12 Mar 2021 12:20:15 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 12 Mar 2021 12:20:15 -0500    

psql's editing commands decide whether the user has edited the file  
by checking for change of modification timestamp.  This is probably  
fine for a pre-existing file, but with a temporary file that is  
created within the command, it's possible for a fast typist to  
save-and-exit in less than the one-second granularity of stat(2)  
timestamps.  On Windows FAT filesystems the granularity is even  
worse, 2 seconds, making the race a bit easier to hit.  
  
To fix, try to set the temp file's mod time to be two seconds ago.  
It's unlikely this would fail, but then again the race condition  
itself is unlikely, so just ignore any error.  
  
Also, we might as well check the file size as well as its mod time.  
  
While this is a difficult bug to hit, it still seems worth  
back-patching, to ensure that users' edits aren't lost.  
  
Laurenz Albe, per gripe from Jacob Champion; based on fix suggestions  
from Jacob and myself  
  
Discussion: https://postgr.es/m/0ba3f2a658bac6546d9934ab6ba63a805d46a49b.camel@cybertec.at  

commit   : 8a2297776667483643823e32fc037a675447d0bb    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 12 Mar 2021 11:08:42 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 12 Mar 2021 11:08:42 -0500    

GENERATED ALWAYS AS IDENTITY implies NOT NULL, but the code failed  
to complain if you overrode that with "GENERATED ALWAYS AS IDENTITY  
NULL".  One might think the old behavior was a feature, but it was  
inconsistent because the outcome varied depending on the order of  
the clauses, so it seems to have been just an oversight.  
  
Per bug #16913 from Pavel Boev.  Back-patch to v10 where identity  
columns were introduced.  
  
Vik Fearing (minor tweaks by me)  
  
Discussion: https://postgr.es/m/16913-3b5198410f67d8c6@postgresql.org  

commit   : 3580b4a0cde03d39e47c70a2078c23d2c0a96c97    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 11 Mar 2021 14:43:45 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 11 Mar 2021 14:43:45 -0500    

Commit 92785dac2 copied some logic related to advancement of inStart  
from pqParseInput3 into getRowDescriptions and getAnotherTuple,  
because it wanted to allow user-defined row processor callbacks to  
potentially longjmp out of the library, and inStart would have to be  
updated before that happened to avoid an infinite loop.  We later  
decided that that API was impossibly fragile and reverted it, but  
we didn't undo all of the related code changes, and this bit of  
messiness survived.  Undo it now so that there's just one place in  
pqParseInput3's processing where inStart is advanced; this will  
simplify addition of better tracing support.  
  
getParamDescriptions had grown similar processing somewhere along  
the way (not in 92785dac2; I didn't track down just when), but it's  
actually buggy because its handling of corrupt-message cases seems to  
have been copied from the v2 logic where we lacked a known message  
length.  The cases where we "goto not_enough_data" should not simply  
return EOF, because then we won't consume the message, potentially  
creating an infinite loop.  That situation now represents a  
definitively corrupt message, and we should report it as such.  
  
Although no field reports of getParamDescriptions getting stuck in  
a loop have been seen, it seems appropriate to back-patch that fix.  
I chose to back-patch all of this to keep the logic looking more alike  
in supported branches.  
  
Discussion: https://postgr.es/m/2217283.1615411989@sss.pgh.pa.us  

commit   : 635048eb92e819d7a24202d74949e449ac5c7ef3    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Wed, 10 Mar 2021 22:10:34 -0800    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Wed, 10 Mar 2021 22:10:34 -0800    

Oversight in commit 9f3665fb.  
  
Backpatch: 13-, just like commit 9f3665fb.  

commit   : 4ecf359fbac5b4da749147ce873e3332a613fe5c    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 10 Mar 2021 20:25:18 -0500    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 10 Mar 2021 20:25:18 -0500    

This is a follow-on patch to 92c12e46d5.  In that patch, we renamed  
"altitude" to "elevation" in the docs, based on these details:  
  
   https://mapscaping.com/blogs/geo-candy/what-is-the-difference-between-elevation-relief-and-altitude  
  
This renames the tutorial SQL files to match the documentation.  
  
Reported-by: max1@inbox.ru  
  
Discussion: https://postgr.es/m/161512392887.1046.3137472627109459518@wrigleys.postgresql.org  
  
Backpatch-through: 9.6  

commit   : 1fc5a57386d11221258efa8af444a90f344a18a2    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Wed, 10 Mar 2021 17:07:55 -0800    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Wed, 10 Mar 2021 17:07:55 -0800    

vacuumlazy.c sometimes fails to update pg_class entries for each index  
(to ensure that pg_class.reltuples is current), even though analyze.c  
assumed that that must have happened during VACUUM ANALYZE.  There are  
at least a couple of reasons for this.  For example, vacuumlazy.c could  
fail to update pg_class when the index AM indicated that its statistics  
are merely an estimate, per the contract for amvacuumcleanup() routines  
established by commit e57345975cf back in 2006.  
  
Stop assuming that pg_class must have been updated with accurate  
statistics within VACUUM ANALYZE -- update pg_class for indexes at the  
same time as the table relation in all cases.  That way VACUUM ANALYZE  
will never fail to keep pg_class.reltuples reasonably accurate.  
  
The only downside of this approach (compared to the old approach) is  
that it might inaccurately set pg_class.reltuples for indexes whose heap  
relation ends up with the same inaccurate value anyway.  This doesn't  
seem too bad.  We already consistently called vac_update_relstats() (to  
update pg_class) for the heap/table relation twice during any VACUUM  
ANALYZE -- once in vacuumlazy.c, and once in analyze.c.  We now make  
sure that we call vac_update_relstats() at least once (though often  
twice) for each index.  
  
This is follow up work to commit 9f3665fb, which dealt with issues in  
btvacuumcleanup().  Technically this fixes an unrelated issue, though.  
btvacuumcleanup() no longer provides an accurate num_index_tuples value  
following commit 9f3665fb (when there was no btbulkdelete() call during  
the VACUUM operation in question), but hashvacuumcleanup() has worked in  
the same way for many years now.  
  
Author: Peter Geoghegan <pg@bowt.ie>  
Reviewed-By: Masahiko Sawada <sawada.mshk@gmail.com>  
Discussion: https://postgr.es/m/CAH2-WzknxdComjhqo4SUxVFk_Q1171GJO2ZgHZ1Y6pion6u8rA@mail.gmail.com  
Backpatch: 13-, just like commit 9f3665fb.  

commit   : 9663d124466f09696170631a2f2c0b40114166c8    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Wed, 10 Mar 2021 16:26:58 -0800    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Wed, 10 Mar 2021 16:26:58 -0800    

Remove the entire idea of "stale stats" within nbtree VACUUM (stop  
caring about stats involving the number of inserted tuples).  Also  
remove the vacuum_cleanup_index_scale_factor GUC/param on the master  
branch (though just disable them on postgres 13).  
  
The vacuum_cleanup_index_scale_factor/stats interface made the nbtree AM  
partially responsible for deciding when pg_class.reltuples stats needed  
to be updated.  This seems contrary to the spirit of the index AM API,  
though -- it is not actually necessary for an index AM's bulk delete and  
cleanup callbacks to provide accurate stats when it happens to be  
inconvenient.  The core code owns that.  (Index AMs have the authority  
to perform or not perform certain kinds of deferred cleanup based on  
their own considerations, such as page deletion and recycling, but that  
has little to do with pg_class.reltuples/num_index_tuples.)  
  
This issue was fairly harmless until the introduction of the  
autovacuum_vacuum_insert_threshold feature by commit b07642db, which had  
an undesirable interaction with the vacuum_cleanup_index_scale_factor  
mechanism: it made insert-driven autovacuums perform full index scans,  
even though there is no real benefit to doing so.  This has been tied to  
a regression with an append-only insert benchmark [1].  
  
Also have remaining cases that perform a full scan of an index during a  
cleanup-only nbtree VACUUM indicate that the final tuple count is only  
an estimate.  This prevents vacuumlazy.c from setting the index's  
pg_class.reltuples in those cases (it will now only update pg_class when  
vacuumlazy.c had TIDs for nbtree to bulk delete).  This arguably fixes  
an oversight in deduplication-related bugfix commit 48e12913.  
  
[1] https://smalldatum.blogspot.com/2021/01/insert-benchmark-postgres-is-still.html  
  
Author: Peter Geoghegan <pg@bowt.ie>  
Reviewed-By: Masahiko Sawada <sawada.mshk@gmail.com>  
Discussion: https://postgr.es/m/CAD21AoA4WHthN5uU6+WScZ7+J_RcEjmcuH94qcoUPuB42ShXzg@mail.gmail.com  
Backpatch: 13-, where autovacuum_vacuum_insert_threshold was added.  

commit   : 9a4e4af42023451944a5beca124d647dd5c2c26f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 10 Mar 2021 11:33:50 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 10 Mar 2021 11:33:50 -0500    

Clarify the discussion in "User-Defined Procedures", by laying out  
the key differences between functions and procedures in a bulleted  
list.  Notably, this avoids burying the lede about procedures being  
able to do transaction control.  Make the back-link in the CREATE  
FUNCTION reference page more prominent, and add one in CREATE  
PROCEDURE.  
  
Per gripe from Guyren Howe.  Thanks to David Johnston for discussion.  
  
Discussion: https://postgr.es/m/BYAPR03MB4903C53A8BB7EFF5EA289674A6949@BYAPR03MB4903.namprd03.prod.outlook.com  

commit   : fe2b5386b2edb7d454fcab36bb3dfbbe272d362f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 8 Mar 2021 18:21:51 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 8 Mar 2021 18:21:51 -0500    

"SELECT pg_import_system_collations(0)" caused an assertion failure.  
With a random nonzero argument --- or indeed with zero, in non-assert  
builds --- it would happily make pg_collation entries with garbage  
values of collnamespace.  These are harmless as far as I can tell  
(unless maybe the OID happens to become used for a schema, later on?).  
In any case this isn't a security issue, since the function is  
superuser-only.  But it seems like a gotcha for unwary DBAs, so let's  
add a check that the given OID belongs to some schema.  
  
Back-patch to v10 where this function was introduced.  

commit   : 21d5a065fd5f0ed71e0f6726a869c64d13716ceb    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Wed, 3 Mar 2021 10:17:47 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Wed, 3 Mar 2021 10:17:47 +0530    

It was not clear in the docs that the max_replication_slots is also used  
to track replication origins on the subscriber side.  
  
Author: Paul Martinez  
Reviewed-by: Amit Kapila  
Backpatch-through: 10 where logical replication was introduced  
Discussion: https://postgr.es/m/CACqFVBZgwCN_pHnW6dMNCrOS7tiHCw6Retf_=U2Vvj3aUSeATw@mail.gmail.com  

commit   : b52fd1e7c76c21298d2e2ecc006c5a2d99b46da9    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 2 Mar 2021 15:39:34 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 2 Mar 2021 15:39:34 -0300    

On Windows, CMD.EXE allegedly does not run a command that uses forward slashes,  
so let's convert the path to use backslashes instead.  
  
Backpatch to 10.  
  
Author: Nitin Jadhav <nitinjadhavpostgres@gmail.com>  
Reviewed-by: Juan José Santamaría Flecha <juanjo.santamaria@gmail.com>  
Discussion: https://postgr.es/m/CAMm1aWaNDuaPYFYMAqDeJrZmPtNvLcJRS++CcZWY8LT6KcoBZw@mail.gmail.com  

commit   : 621e8a603d5668467eac50ff13ce8a9006fd56be    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 2 Mar 2021 13:19:07 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 2 Mar 2021 13:19:07 +0900    

The same test for REINDEX (VERBOSE) was done twice, while it is clear  
that the second test should use --concurrently.  Issue introduced in  
5dc92b8, for what looks like a copy-paste mistake.  
  
Reviewed-by: Mark Dilger  
Discussion: https://postgr.es/m/A7AE97EA-F4B0-4CAB-8FFF-3FECD31F9D63@enterprisedb.com  
Backpatch-through: 12  

commit   : 2688852a49ea52e5663c09f91cdcf43697e10814    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Sat, 27 Feb 2021 18:09:15 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Sat, 27 Feb 2021 18:09:15 -0300    

AfterTriggerSaveEvent() wrongly allocates the slot in execution-span  
memory context, whereas the correct thing is to allocate it in  
a transaction-span context, because that's where the enclosing  
AfterTriggersTableData instance belongs into.  
  
Backpatch to 12 (the test back to 11, where it works well with no code  
changes, and it's good to have to confirm that the case was previously  
well supported); this bug seems introduced by commit ff11e7f4b9ae.  
  
Reported-by: Bertrand Drouvot <bdrouvot@amazon.com>  
Author: Amit Langote <amitlangote09@gmail.com>  
Discussion: https://postgr.es/m/39a71864-b120-5a5c-8cc5-c632b6f16761@amazon.com  

commit   : 57449318307a3eaa02d129869293e887c5b48ab0    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 26 Feb 2021 15:24:00 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 26 Feb 2021 15:24:00 -0500    

Break the synopsis into named parts to make it less confusing.  
Make more than zero effort at applying SGML markup.  Do a bit  
of copy-editing of nearby text.  
  
The synopsis revision is by Alvaro Herrera and Paul Förster,  
the rest is my fault.  Back-patch to v10 where multi-host  
connection strings appeared.  
  
Discussion: https://postgr.es/m/6E752D6B-487C-463E-B6E2-C32E7FB007EA@gmail.com  

commit   : 49076fd3ba6ba7cda2ac16d9aaf554025f0bba2b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 25 Feb 2021 20:47:32 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 25 Feb 2021 20:47:32 -0500    

makeDependencyGraphWalker and checkWellFormedRecursionWalker  
thought they could hold onto a pointer to a list's first  
cons cell while the list was modified by recursive calls.  
That was okay when the cons cell was actually separately  
palloc'd ... but since commit 1cff1b95a, it's quite unsafe,  
leading to core dumps or incorrect complaints of faulty  
WITH nesting.  
  
In the field this'd require at least a seven-deep WITH nest  
to cause an issue, but enabling DEBUG_LIST_MEMORY_USAGE  
allows the bug to be seen with lesser nesting depths.  
  
Per bug #16801 from Alexander Lakhin.  Back-patch to v13.  
  
Michael Paquier and Tom Lane  
  
Discussion: https://postgr.es/m/16801-393c7922143eaa4d@postgresql.org  

commit   : 1f56ae322943e9c9b3be4b2c480891a291861bf7    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 25 Feb 2021 16:07:03 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 25 Feb 2021 16:07:03 +0900    

PGHOST, PGPORT and PGUSER were already mentioned, but not PGDATABASE.  
Like 5aaa584, backpatch down to 12.  
  
Reported-by: Christophe Courtois  
Discussion: https://postgr.es/m/161399398648.21711.15387267201764682579@wrigleys.postgresql.org  
Backpatch-through: 12  

commit   : 9de839fb4ab08aa5e5a640b7b47c5fc9908453d3    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 24 Feb 2021 16:13:56 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 24 Feb 2021 16:13:56 +0900    

The portions fixing the documentation are backpatched where needed.  
  
Author: Justin Pryzby  
Discussion: https://postgr.es/m/20210210235557.GQ20012@telsasoft.com  
backpatch-through: 9.6  

commit   : 28f4b61083b2a5b2bd1b7859d7cb2c6cfcb2b964    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 23 Feb 2021 17:30:21 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 23 Feb 2021 17:30:21 -0300    

Commit 866e24d47db1 added an assert that HEAP_XMAX_LOCK_ONLY and  
HEAP_KEYS_UPDATED cannot appear together, on the faulty assumption that  
the latter necessarily referred to an update and not a tuple lock; but  
that's wrong, because SELECT FOR UPDATE can use precisely that  
combination, as evidenced by the amcheck test case added here.  
  
Remove the Assert(), and also patch amcheck's verify_heapam.c to not  
complain if the combination is found.  Also, out of overabundance of  
caution, update (across all branches) README.tuplock to be more explicit  
about this.  
  
Author: Julien Rouhaud <rjuju123@gmail.com>  
Reviewed-by: Mahendra Singh Thalor <mahi6run@gmail.com>  
Reviewed-by: Dilip Kumar <dilipbalaut@gmail.com>  
Discussion: https://postgr.es/m/20210124061758.GA11756@nol  

commit   : 186f6168b73de6472e8aeb6e96b2ec6c73fd7b89    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Mon, 22 Feb 2021 13:00:54 +0100    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Mon, 22 Feb 2021 13:00:54 +0100    

Building the docs with STYLE=website referenced a stylesheet that long  
longer exists on the website, since we changed it to use versioned  
references.  
  
To make it less likely for this to happen again, point to a single  
stylesheet on the website which will in turn import the required one.  
That puts the process entirely within the scope of the website  
repository, so next time a version is switched that's the only place  
changes have to be made, making them less likely to be missed.  
  
Per (off-list) discussion with Peter Geoghegan and Jonathan Katz.  

commit   : 5190ce845c59727ed7177dadd62626d6450a55bd    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Mon, 22 Feb 2021 14:37:28 +1300    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Mon, 22 Feb 2021 14:37:28 +1300    

Commit b09ff536 left behind some outdated advice in the long_desc field  
of the GUC "effective_io_concurrency".  Remove it.  
  
Back-patch to 13.  
  
Reported-by: Andrew Gierth <andrew@tao11.riddles.org.uk>  
Reviewed-by: Julien Rouhaud <rjuju123@gmail.com>  
Discussion: https://postgr.es/m/CA%2BhUKGJyyWqFBxL9gEj-qtjBThGjhAOBE8GBnF8MUJOJ3vrfag%40mail.gmail.com  

commit   : be7485a1e31122f92b6dd9ad02427c1daa870b63    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Fri, 19 Feb 2021 22:01:25 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Fri, 19 Feb 2021 22:01:25 +0900    

When ON_ERROR_ROLLBACK is enabled, psql releases a temporary savepoint  
if it's idle in a valid transaction block after executing a query. But psql  
doesn't do that after RELEASE or ROLLBACK is executed because a temporary  
savepoint has already been destroyed in that case.  
  
This commit changes psql's ON_ERROR_ROLLBACK so that it doesn't release  
a temporary savepoint also when COMMIT AND CHAIN is executed. A temporary  
savepoint doesn't need to be released in that case because  
COMMIT AND CHAIN also destroys any savepoints defined within the transaction  
to commit. Otherwise psql tries to release the savepoint that  
COMMIT AND CHAIN has already destroyed and cause an error  
"ERROR:  savepoint "pg_psql_temporary_savepoint" does not exist".  
  
Back-patch to v12 where transaction chaining was added.  
  
Reported-by: Arthur Nascimento  
Author: Arthur Nascimento  
Reviewed-by: Fujii Masao, Vik Fearing  
Discussion: https://postgr.es/m/16867-3475744069228158@postgresql.org  

commit   : 422012c98f8d929f9aa2b2e706b29512f61544e1    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Fri, 19 Feb 2021 21:57:52 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Fri, 19 Feb 2021 21:57:52 +0900    

This commit fixes COMMIT AND CHAIN command so that it starts new transaction  
immediately even if savepoints are defined within the transaction to commit.  
Previously COMMIT AND CHAIN command did not in that case because  
commit 280a408b48 forgot to make CommitTransactionCommand() handle  
a transaction chaining when the transaction state was TBLOCK_SUBCOMMIT.  
  
Also this commit adds the regression test for COMMIT AND CHAIN command  
when savepoints are defined.  
  
Back-patch to v12 where transaction chaining was added.  
  
Reported-by: Arthur Nascimento  
Author: Fujii Masao  
Reviewed-by: Arthur Nascimento, Vik Fearing  
Discussion: https://postgr.es/m/16867-3475744069228158@postgresql.org  

commit   : bf9d3a5f847e91154b7cde255da7f24cd129ff35    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 18 Feb 2021 22:38:55 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 18 Feb 2021 22:38:55 -0500    

While poking at the regex code, I happened to notice that the bug  
squashed in commit afcc8772e had a sibling: next() failed to return  
a specific value associated with the '}' token for a "\{m,n\}"  
quantifier when parsing in basic RE mode.  Again, this could result  
in treating the quantifier as non-greedy, which it never should be in  
basic mode.  For that to happen, the last character before "\}" that  
sets "nextvalue" would have to set it to zero, or it'd have to have  
accidentally been zero from the start.  The failure can be provoked  
repeatably with, for example, a bound ending in digit "0".  
  
Like the previous patch, back-patch all the way.  

commit   : d4b667e9353a70c4ee2847603e5ad2e14e20f82e    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Thu, 18 Feb 2021 23:28:58 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Thu, 18 Feb 2021 23:28:58 +0900    

Commit 2c8dd05d6c added the atomic variable writtenUpto into  
walreceiver's shared memory information. It's initialized only  
when walreceiver started up but could be read via pg_stat_wal_receiver  
view anytime, i.e., even before it's initialized. In the server built  
with --disable-atomics and --disable-spinlocks, this uninitialized  
atomic variable read could cause "invalid spinlock number: 0" error.  
  
This commit changed writtenUpto so that it's initialized at  
the postmaster startup, to avoid the uninitialized variable read  
via pg_stat_wal_receiver and fix the error.  
  
Also this commit moved the read of writtenUpto after the release  
of spinlock protecting walreceiver's shared variables. This is  
necessary to prevent new spinlock from being taken by atomic  
variable read while holding another spinlock, and to shorten  
the spinlock duration. This change leads writtenUpto not to be  
consistent with the other walreceiver's shared variables protected  
by a spinlock. But this is OK because writtenUpto should not be  
used for data integrity checks.  
  
Back-patch to v13 where commit 2c8dd05d6c introduced the bug.  
  
Author: Fujii Masao  
Reviewed-by: Michael Paquier, Thomas Munro, Andres Freund  
Discussion: https://postgr.es/m/7ef8708c-5b6b-edd3-2cf2-7783f1c7c175@oss.nttdata.com  

commit   : daf2e708edfbc0741f8a229a0c30fdd0168b525e    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Wed, 17 Feb 2021 13:53:26 +0100    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Wed, 17 Feb 2021 13:53:26 +0100    

Author: Daniel Gustafsson <daniel@yesql.se>  
Discussion: https://postgr.es/m/0CF087FC-BEAD-4010-8BB9-3CDD74DC9060@yesql.se  

commit   : 0d779d22a290a89b6c892137a37280b9588ad0cc    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 16 Feb 2021 12:07:14 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 16 Feb 2021 12:07:14 -0500    

Commit 2f2007fbb did this partially, but there were two remaining  
warts.  checkcondition_gin handled some uncertain cases by setting  
the out-of-band recheck flag, some by returning TS_MAYBE, and some  
by doing both.  Meanwhile, TS_execute arbitrarily converted a  
TS_MAYBE result to TS_YES.  Thus, if checkcondition_gin chose to  
only return TS_MAYBE, the outcome would be TS_YES with no recheck  
flag, potentially resulting in wrong query outputs.  
  
The case where this'd happen is if there were GIN_MAYBE entries  
in the indexscan results passed to gin_tsquery_[tri]consistent,  
which so far as I can see would only happen if the tidbitmap used  
to accumulate indexscan results grew large enough to become lossy.  
  
I initially thought of fixing this by ensuring we always set the  
recheck flag as well as returning TS_MAYBE in uncertain cases.  
But that errs in the other direction, potentially forcing rechecks  
of rows that provably match the query (since the recheck flag  
remains set even if TS_execute later finds that the answer must be  
TS_YES).  Instead, let's get rid of the out-of-band recheck flag  
altogether and rely on returning TS_MAYBE.  This requires exporting  
a version of TS_execute that will actually return the full ternary  
result of the evaluation ... but we likely should have done that  
to start with.  
  
Unfortunately it doesn't seem practical to add a regression test case  
that covers this: the amount of data needed to cause the GIN bitmap to  
become lossy results in a longer runtime than I think we want to have  
in the tests.  (I'm wondering about allowing smaller work_mem settings  
to ameliorate that, but it'd be a matter for a separate patch.)  
  
Per bug #16865 from Dimitri Nüscheler.  Back-patch to v13 where  
the faulty commit came in.  
  
Discussion: https://postgr.es/m/16865-4ffdc3e682e6d75b@postgresql.org  

commit   : 80dc07aa361b9b0028e49bbdf7a947775211b812    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 15 Feb 2021 10:17:58 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 15 Feb 2021 10:17:58 -0500    

The inner loop in switchToPresortedPrefixMode() can be implemented  
as a conventional integer-counter for() loop, removing a couple of  
redundant boolean state variables.  The old logic here was a remnant  
of earlier development, but as things now stand there's no reason  
for extra complexity.  
  
Also, annotate the test case added by 82e0e2930 to explain why it  
manages to hit the corner case fixed in that commit, and add an  
EXPLAIN to verify that it's creating an incremental-sort plan.  
  
Back-patch to v13, like the previous patch.  
  
James Coleman and Tom Lane  
  
Discussion: https://postgr.es/m/16846-ae49f51ac379a4cb@postgresql.org  

commit   : 18cacf89b9fe5523941b57fbd01d408585e70737    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 15 Feb 2021 09:28:08 +0200    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 15 Feb 2021 09:28:08 +0200    

If ExecGetInsertedCols(), ExecGetUpdatedCols() or ExecGetExtraUpdatedCols()  
were called with a ResultRelInfo that's not in the range table and isn't a  
partition routing target, the functions would dereference a NULL pointer,  
relinfo->ri_RootResultRelInfo. Such ResultRelInfos are created when firing  
RI triggers in tables that are not modified directly. None of the current  
callers of these functions pass such relations, so this isn't a live bug,  
but let's make them more robust.  
  
Also update comment in ResultRelInfo; after commit 6214e2b228,  
ri_RangeTableIndex is zero for ResultRelInfos created for partition tuple  
routing.  
  
Noted by Coverity. Backpatch down to v11, like commit 6214e2b228.  
  
Reviewed-by: Tom Lane, Amit Langote  

commit   : 6c23e5ae9ee12ff1f5183573885bfaa4eb97b243    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Mon, 15 Feb 2021 15:43:39 +1300    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Mon, 15 Feb 2021 15:43:39 +1300    

FreeBSD 13 gained O_DSYNC, which would normally cause wal_sync_method to  
choose open_datasync as its default value.  That may not be a good  
choice for all systems, and performs worse than fdatasync in some  
scenarios.  Let's preserve the existing default behavior for now.  
  
Like commit 576477e73c4, which did the same for Linux, back-patch to all  
supported releases.  
  
Discussion: https://postgr.es/m/CA%2BhUKGLsAMXBQrCxCXoW-JsUYmdOL8ALYvaX%3DCrHqWxm-nWbGA%40mail.gmail.com  

commit   : 9fe40913c45dcb78d3271fdc2dcf21ff15bee583    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Mon, 15 Feb 2021 13:32:58 +1300    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Mon, 15 Feb 2021 13:32:58 +1300    

While cleaning up after a parallel query or parallel index creation that  
created temporary files, we could be interrupted by a statement timeout.  
The error handling path would then fail to clean up the files when it  
ran dsm_detach() again, because the callback was already popped off the  
list.  Prevent this hazard by holding interrupts while the cleanup code  
runs.  
  
Thanks to Heikki Linnakangas for this suggestion, and also to Kyotaro  
Horiguchi, Masahiko Sawada, Justin Pryzby and Tom Lane for discussion of  
this and earlier ideas on how to fix the problem.  
  
Back-patch to all supported releases.  
  
Reported-by: Justin Pryzby <pryzby@telsasoft.com>  
Discussion: https://postgr.es/m/20191212180506.GR2082@telsasoft.com  

commit   : c86eae39ce1e5f842bbf75e381d903de43ad4c80    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 13 Feb 2021 17:49:08 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 13 Feb 2021 17:49:08 -0500    

Modern gcc and clang compilers offer alignment sanitizers, which help to detect  
pointer misalignment.  However, our codebase already contains x86-specific  
crc32 computation code, which uses unalignment access.  Thankfully, those  
compilers also support the attribute, which disables alignment sanitizers at  
the function level.  This commit adds pg_attribute_no_sanitize_alignment(),  
which wraps this attribute, and applies it to pg_comp_crc32c_sse42() function.  
  
Back-patch of commits 993bdb9f9 and ad2ad698a, to enable doing  
alignment testing in all supported branches.  
  
Discussion: https://postgr.es/m/CAPpHfdsne3%3DT%3DfMNU45PtxdhSL_J2PjLTeS8rwKnJzUR4YNd4w%40mail.gmail.com  
Discussion: https://postgr.es/m/475514.1612745257%40sss.pgh.pa.us  
Author: Alexander Korotkov, revised by Tom Lane  
Reviewed-by: Tom Lane  

commit   : bcd5e95754bff330151dacbf7db5140d01aabe3a    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sat, 13 Feb 2021 16:06:34 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sat, 13 Feb 2021 16:06:34 +0900    

This grammar flavor has been added by 5fc7039.  
  
Author: Ian Lawrence Barwick  
Discussion: https://postgr.es/m/CAB8KJ=ii6JScodxkA6-DO8bjatsMYU3OcewnL0mdN9geR+tTaw@mail.gmail.com  
Backpatch-through: 13  

commit   : 3a02d68a96edb54d981879b95c28fe4ba79b87f9    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 12 Feb 2021 16:26:47 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 12 Feb 2021 16:26:47 -0500    

Given a regex pattern with a very long fixed prefix (approaching 500  
characters), the result of pow(FIXED_CHAR_SEL, fixed_prefix_len) can  
underflow to zero.  Typically the preceding selectivity calculation  
would have underflowed as well, so that we compute 0/0 and get NaN.  
In released branches this leads to an assertion failure later on.  
That doesn't happen in HEAD, for reasons I've not explored yet,  
but it's surely still a bug.  
  
To fix, just skip the division when the pow() result is zero, so  
that we'll (most likely) return a zero selectivity estimate.  In  
the edge cases where "sel" didn't yet underflow, perhaps this  
isn't desirable, but I'm not sure that the case is worth spending  
a lot of effort on.  The results of regex_selectivity_sub() are  
barely worth the electrons they're written on anyway :-(  
  
Per report from Alexander Lakhin.  Back-patch to all supported versions.  
  
Discussion: https://postgr.es/m/6de0a0c3-ada9-cd0c-3e4e-2fa9964b41e3@gmail.com  

commit   : c6cd20d91ce9b100b89997757b88a415c3e10747    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 10 Feb 2021 16:59:04 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 10 Feb 2021 16:59:04 +0900    

Oversight in bd12080.  
  
Reported-by: Justin Pryzby  
Discussion: https://postgr.es/m/20210210065805.GG20012@telsasoft.com  
Backpatch-through: 12  

commit   : 8493831385814c4f22b1d5b5d8a9227a2eb82712    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 10 Feb 2021 13:09:09 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 10 Feb 2021 13:09:09 +0900    

For an index, attstattarget can be updated using ALTER INDEX SET  
STATISTICS.  This data was lost on the new index after REINDEX  
CONCURRENTLY.  
  
The update of this field is done when the old and new indexes are  
swapped to make the fix back-patchable.  Another approach we could look  
after in the long-term is to change index_create() to pass the wanted  
values of attstattarget when creating the new relation, but, as this  
would cause an ABI breakage this can be done only on HEAD.  
  
Reported-by: Ronan Dunklau  
Author: Michael Paquier  
Reviewed-by: Ronan Dunklau, Tomas Vondra  
Discussion: https://postgr.es/m/16628084.uLZWGnKmhe@laptop-ronand  
Backpatch-through: 12  

commit   : 3fb4c75e857adee3da4386e947ba58a75f3e74b7    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 8 Feb 2021 16:54:11 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 8 Feb 2021 16:54:11 -0500    

commit   : 0f966d56b0d7496663296d56432ac055c8d716b5    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 8 Feb 2021 17:41:32 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 8 Feb 2021 17:41:32 +0100    

Source-Git-URL: https://git.postgresql.org/git/pgtranslation/messages.git  
Source-Git-Hash: 0da38e9f43d2b931a5efb3b64aac53c2beccd3b6  

commit   : cd82d75a9861c871b95683afdb12df6374fa8435    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 8 Feb 2021 11:10:40 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 8 Feb 2021 11:10:40 -0500    

Security: CVE-2021-3393, CVE-2021-20229  

commit   : d525fbcfd167b28818301d0a2d3548ae6a744588    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 8 Feb 2021 10:14:09 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 8 Feb 2021 10:14:09 -0500    

scanNSItemForColumn, expandNSItemAttrs, and ExpandSingleTable would  
pass the wrong RTE to markVarForSelectPriv when dealing with a join  
ParseNamespaceItem: they'd pass the join RTE, when what we need to  
mark is the base table that the join column came from.  The end  
result was to not fill the base table's selectedCols bitmap correctly,  
resulting in an understatement of the set of columns that are read  
by the query.  The executor would still insist on there being at  
least one selectable column; but with a correctly crafted query,  
a user having SELECT privilege on just one column of a table would  
nonetheless be allowed to read all its columns.  
  
To fix, make markRTEForSelectPriv fetch the correct RTE for itself,  
ignoring the possibly-mismatched RTE passed by the caller.  Later,  
we'll get rid of some now-unused RTE arguments, but that risks  
API breaks so we won't do it in released branches.  
  
This problem was introduced by commit 9ce77d75c, so back-patch  
to v13 where that came in.  Thanks to Sven Klemm for reporting  
the problem.  
  
Security: CVE-2021-20229  

commit   : 8e56684d54d44ba4ed737d5847d31fba6fb13763    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 8 Feb 2021 11:01:51 +0200    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 8 Feb 2021 11:01:51 +0200    

If a cross-partition UPDATE violates a constraint on the target partition,  
and the columns in the new partition are in different physical order than  
in the parent, the error message can reveal columns that the user does not  
have SELECT permission on. A similar bug was fixed earlier in commit  
804b6b6db4.  
  
The cause of the bug is that the callers of the  
ExecBuildSlotValueDescription() function got confused when constructing  
the list of modified columns. If the tuple was routed from a parent, we  
converted the tuple to the parent's format, but the list of modified  
columns was grabbed directly from the child's RTE entry.  
  
ExecUpdateLockMode() had a similar issue. That lead to confusion on which  
columns are key columns, leading to wrong tuple lock being taken on tables  
referenced by foreign keys, when a row is updated with INSERT ON CONFLICT  
UPDATE. A new isolation test is added for that corner case.  
  
With this patch, the ri_RangeTableIndex field is no longer set for  
partitions that don't have an entry in the range table. Previously, it was  
set to the RTE entry of the parent relation, but that was confusing.  
  
NOTE: This modifies the ResultRelInfo struct, replacing the  
ri_PartitionRoot field with ri_RootResultRelInfo. That's a bit risky to  
backpatch, because it breaks any extensions accessing the field. The  
change that ri_RangeTableIndex is not set for partitions could potentially  
break extensions, too. The ResultRelInfos are visible to FDWs at least,  
and this patch required small changes to postgres_fdw. Nevertheless, this  
seem like the least bad option. I don't think these fields widely used in  
extensions; I don't think there are FDWs out there that uses the FDW  
"direct update" API, other than postgres_fdw. If there is, you will get a  
compilation error, so hopefully it is caught quickly.  
  
Backpatch to 11, where support for both cross-partition UPDATEs, and unique  
indexes on partitioned tables, were added.  
  
Reviewed-by: Amit Langote  
Security: CVE-2021-3393  

commit   : b4199a94946388c60586b44ad82e77755e1543f4    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 7 Feb 2021 15:46:38 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 7 Feb 2021 15:46:38 -0500    

commit   : ac1df003f253cfeff700558a55274d709340f829    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 7 Feb 2021 12:54:08 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 7 Feb 2021 12:54:08 -0500    

This reverts commit ed290896335414c6c069b9ccae1f3dcdd2fac6ba and  
equivalent back-branch commits.  The issue is subtler than I thought,  
and it's far from new, so just before a release deadline is no time  
to be fooling with it.  We'll consider what to do at a bit more  
leisure.  
  
Discussion: https://postgr.es/m/CAJcOf-fAdj=nDKMsRhQzndm-O13NY4dL6xGcEvdX5Xvbbi0V7g@mail.gmail.com  

commit   : 9c89c4bd8d00742b569e7b0e9a49babc7da519d5    
  
author   : Tatsuo Ishii <ishii@postgresql.org>    
date     : Sun, 7 Feb 2021 13:48:19 +0900    
  
committer: Tatsuo Ishii <ishii@postgresql.org>    
date     : Sun, 7 Feb 2021 13:48:19 +0900    

The manual did not mention whether its return value is (first arg -  
second arg) or (second arg - first arg). The order matters because the  
return value could have a sign. Fix the manual so that it mentions the  
function returns (first arg - second arg).  
  
Patch reviewed by Tom Lane.  
  
Back-patch through v13. Older version's doc format is difficult to add  
more description.  
Discussion: https://postgr.es/m/flat/20210206.151125.960423226279810864.t-ishii%40sraoss.co.jp  

commit   : 739375174ae8adfeee27a681a3dd64f51e46ac4c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 6 Feb 2021 19:28:39 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 6 Feb 2021 19:28:39 -0500    

rewriteRuleAction() neglected this step, although it was careful to  
propagate other similar flags such as hasSubLinks or hasRowSecurity.  
Omitting to transfer hasRecursive is just cosmetic at the moment,  
but omitting hasModifyingCTE is a live bug, since the executor  
certainly looks at that.  
  
The proposed test case only fails back to v10, but since the executor  
examines hasModifyingCTE in 9.x as well, I suspect that a test case  
could be devised that fails in older branches.  Given the nearness  
of the release deadline, though, I'm not going to spend time looking  
for a better test.  
  
Report and patch by Greg Nancarrow, cosmetic changes by me  
  
Discussion: https://postgr.es/m/CAJcOf-fAdj=nDKMsRhQzndm-O13NY4dL6xGcEvdX5Xvbbi0V7g@mail.gmail.com  

commit   : 4353bc878135da7b9b5b416a6986e23a70a3d9b6    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 6 Feb 2021 15:17:01 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 6 Feb 2021 15:17:01 -0500    

Generally, members of inheritance trees must be plain tables (or,  
in more recent versions, foreign tables).  ALTER TABLE INHERIT  
rejects creating an inheritance relationship that has a view at  
either end.  When DefineQueryRewrite attempts to convert a relation  
to a view, it already had checks prohibiting doing so for partitioning  
parents or children as well as traditional-inheritance parents ...  
but it neglected to check that a traditional-inheritance child wasn't  
being converted.  Since the planner assumes that any inheritance  
child is a table, this led to making plans that tried to do a physical  
scan on a view, causing failures (or even crashes, in recent versions).  
  
One could imagine trying to support such a case by expanding the view  
normally, but since the rewriter runs before the planner does  
inheritance expansion, it would take some very fundamental refactoring  
to make that possible.  There are probably a lot of other parts of the  
system that don't cope well with such a situation, too.  For now,  
just forbid it.  
  
Per bug #16856 from Yang Lin.  Back-patch to all supported branches.  
(In versions before v10, this includes back-patching the portion of  
commit 501ed02cf that added has_superclass().  Perhaps the lack of  
that infrastructure partially explains the missing check.)  
  
Discussion: https://postgr.es/m/16856-0363e05c6e1612fd@postgresql.org  

commit   : 805093113df3f09979cb0e55e857976aad77b8af    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 5 Feb 2021 15:05:06 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 5 Feb 2021 15:05:06 -0500    

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

commit   : c87cbd51ee1d8e3486cab9bf8db2f026595bd77d    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 5 Feb 2021 11:14:56 +0200    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 5 Feb 2021 11:14:56 +0200    

If a multi-byte character is escaped with a backslash in TEXT mode input,  
and the encoding is one of the client-only encodings where the bytes after  
the first one can have an ASCII byte "embedded" in the char, we didn't  
skip the character correctly. After a backslash, we only skipped the first  
byte of the next character, so if it was a multi-byte character, we would  
try to process its second byte as if it was a separate character. If it  
was one of the characters with special meaning, like '\n', '\r', or  
another '\\', that would cause trouble.  
  
One such exmple is the byte sequence '\x5ca45c2e666f6f' in Big5 encoding.  
That's supposed to be [backslash][two-byte character][.][f][o][o], but  
because the second byte of the two-byte character is 0x5c, we incorrectly  
treat it as another backslash. And because the next character is a dot, we  
parse it as end-of-copy marker, and throw an "end-of-copy marker corrupt"  
error.  
  
Backpatch to all supported versions.  
  
Reviewed-by: John Naylor, Kyotaro Horiguchi  
Discussion: https://www.postgresql.org/message-id/a897f84f-8dca-8798-3139-07da5bb38728%40iki.fi  

commit   : 984384129bb8a92481d4f7ddd5dede2d781b191f    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Fri, 5 Feb 2021 15:30:02 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Fri, 5 Feb 2021 15:30:02 +0900    

Commit 08d2d58a2 added an assertion assuming that the retrieved_rows  
estimate for a foreign relation, which is re-used to cost pre-sorted  
foreign paths with local stats, is set to at least one row in  
estimate_path_cost_size(), which isn't correct because if the relation  
is a foreign table with tuples=0, the estimate would be set to 0 there  
when not using remote estimates.  
  
Per bug #16807 from Alexander Lakhin.  Back-patch to v13 where the  
aforementioned commit went in.  
  
Author: Etsuro Fujita  
Reviewed-by: Kyotaro Horiguchi  
Discussion: https://postgr.es/m/16807-9fe4e08fbaa5c7ce%40postgresql.org  

commit   : 6467661b6d80122582c9b84f9ae350e5e8073de2    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 4 Feb 2021 23:01:33 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 4 Feb 2021 23:01:33 -0500    

Commit 230230223 taught nodeAgg.c that, when spilling tuples from  
memory in an oversized hash aggregation, it only needed to spill  
input columns referenced in the node's tlist and quals.  Unfortunately,  
that's wrong: we also have to save the grouping columns.  The error  
is masked in common cases because the grouping columns also appear  
in the tlist, but that's not necessarily true.  The main category  
of plans where it's not true seem to come from semijoins ("WHERE  
outercol IN (SELECT innercol FROM innertable)") where the innercol  
needs an implicit promotion to make it comparable to the outercol.  
The grouping column will be "innercol::promotedtype", but that  
expression appears nowhere in the Agg node's own tlist and quals;  
only the bare "innercol" is found in the tlist.  
  
I spent quite a bit of time looking for a suitable regression test  
case for this, without much success.  If the number of distinct  
values of the innercol is large enough to make spilling happen,  
the planner tends to prefer a non-HashAgg plan, at least for  
problem sizes that are reasonable to use in the regression tests.  
So, no new regression test.  However, this patch does demonstrably  
fix the originally-reported test case.  
  
Per report from s.p.e (at) gmx-topmail.de.  Backpatch to v13  
where the troublesome code came in.  
  
Discussion: https://postgr.es/m/trinity-1c565d44-159f-488b-a518-caf13883134f-1611835701633@3c-app-gmx-bap78  

commit   : 10fcb83da6a7c5328f61ca7fb60f78c57db1bd58    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 4 Feb 2021 19:12:09 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 4 Feb 2021 19:12:09 -0500    

switchToPresortedPrefixMode() did the wrong thing if it detected  
a batch boundary just at the last tuple of a fullsort group.  
  
The initially-reported symptom was a "retrieved too many tuples in a  
bounded sort" error, but the test case added here just silently gives  
the wrong answer without this patch.  
  
I (tgl) am not really happy about committing this patch without review  
from the incremental-sort authors, but they seem AWOL and we are hard  
against a release deadline.  This does demonstrably make some cases  
better, anyway.  
  
Per bug #16846 from Yoran Heling.  Back-patch to v13 where incremental  
sort was introduced.  
  
Neil Chen  
  
Discussion: https://postgr.es/m/16846-ae49f51ac379a4cb@postgresql.org  

commit   : 57868d957eb8320f924bc8453372cf9954e9a338    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 3 Feb 2021 19:38:29 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 3 Feb 2021 19:38:29 -0500    

If a portal is used to run a prepared CALL or DO statement that  
contains a ROLLBACK, PortalRunMulti fails because the portal's  
statement list gets cleared by the rollback.  (Since the grammar  
doesn't allow CALL/DO in PREPARE, the only easy way to get to this is  
via extended query protocol, which treats all inputs as prepared  
statements.)  It's difficult to avoid resetting the portal early  
because of resource-management issues, so work around this by teaching  
PortalRunMulti to be wary of portal->stmts having suddenly become NIL.  
  
The crash has only been seen to occur in v13 and HEAD (as a  
consequence of commit 1cff1b95a having added an extra touch of  
portal->stmts).  But even before that, the code involved touching a  
List that the portal no longer has any claim on.  In the test case at  
hand, the List will still exist because of another refcount on the  
cached plan; but I'm far from convinced that it's impossible for the  
cached plan to have been dropped by the time control gets back to  
PortalRunMulti.  Hence, backpatch to v11 where nested transactions  
were added.  
  
Thomas Munro and Tom Lane, per bug #16811 from James Inform  
  
Discussion: https://postgr.es/m/16811-c1b599b2c6c2d622@postgresql.org  

commit   : 1d3ce0223c6a527c2f464fb8e6b3874be4e7332e    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 3 Feb 2021 11:27:13 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 3 Feb 2021 11:27:13 +0100    

Generation expressions of generated columns are always inherited, so  
there is no need to set them separately in child tables, and there is  
no syntax to do so either.  The code previously used the code paths  
for the handling of default values, for which different rules apply;  
in particular it might want to set a default value explicitly for an  
inherited column.  This resulted in unrestorable dumps.  For generated  
columns, just skip them in inherited tables.  
  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://www.postgresql.org/message-id/flat/15830.1575468847%40sss.pgh.pa.us  

commit   : 0fe8b1f7d48ed2d5f50d6583481f70d2ebf2a073    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 2 Feb 2021 14:35:12 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 2 Feb 2021 14:35:12 -0500    

This left gaps in the internal statement numbering, which is not  
terribly harmful (else we'd have noticed sooner), but it's not  
great either.  
  
Oversight in bbd5c207b; backpatch to v12 where that came in.  
  
Pavel Stehule  
  
Discussion: https://postgr.es/m/CAFj8pRDXyQaJmpotNTQVc-t-WxdWZC35V2PnmwOaV1-taidFWA@mail.gmail.com  

commit   : 5868913943441f9d0a5776f1367f3f98268b10a8    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 2 Feb 2021 13:49:08 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 2 Feb 2021 13:49:08 -0500    

The ExecutorEnd hook is invoked in a context that could be quite  
long-lived, not the executor's own per-query context as I think  
we were sort of assuming.  Thus, any cruft generated while producing  
the EXPLAIN output could accumulate over multiple queries.  This can  
result in spectacular leakage if log_nested_statements is on, and  
even without that I'm surprised nobody complained before.  
  
To fix, just switch into the executor's context so that anything we  
allocate will be released when standard_ExecutorEnd frees the executor  
state.  We might as well nuke the code's retail pfree of the explain  
output string, too; that's laughably inadequate to the need.  
  
Japin Li, per report from Jeff Janes.  This bug is old, so  
back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/CAMkU=1wCVtbeRn0s9gt12KwQ7PLXovbpM8eg25SYocKW3BT4hg@mail.gmail.com  

commit   : dae5af6c19f20d954179df5e15afa649fbabb101    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 1 Feb 2021 16:38:52 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 1 Feb 2021 16:38:52 -0500    

Writing unnecessary '.*' at start and end of a POSIX regex doesn't  
do much except confuse the reader about whether that might be  
necessary after all.  Make the examples in table 9.16 a tad more  
realistic, and try to turn the next group of examples into something  
self-contained.  
  
Per gripe from rmzgrimes.  Back-patch to v13 because it's easy.  
  
Discussion: https://postgr.es/m/161215841824.14653.8969016349304314299@wrigleys.postgresql.org  

commit   : d798ea750d22ee4f546c5a4521f957ca610de5b1    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sat, 30 Jan 2021 00:12:18 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sat, 30 Jan 2021 00:12:18 -0800    

Given a permanent relation rewritten in the current transaction, the  
old_snapshot_threshold mechanism assumed the relation had never been  
subject to early pruning.  Hence, a query could fail to report "snapshot  
too old" when the rewrite followed an early truncation.  ALTER TABLE SET  
TABLESPACE is probably the only rewrite mechanism capable of exposing  
this bug.  REINDEX sets indcheckxmin, avoiding the problem.  CLUSTER has  
zeroed page LSNs since before old_snapshot_threshold existed, so  
old_snapshot_threshold has never cooperated with it.  ALTER TABLE  
... SET DATA TYPE makes the table look empty to every past snapshot,  
which is strictly worse.  Back-patch to v13, where commit  
c6b92041d38512a4176ed76ad06f713d2e6c01a8 broke this.  
  
Kyotaro Horiguchi and Noah Misch  
  
Discussion: https://postgr.es/m/20210113.160705.2225256954956139776.horikyota.ntt@gmail.com  

commit   : e8e3e67490f593a3669c762b50b2aa3a11208654    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sat, 30 Jan 2021 00:11:38 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sat, 30 Jan 2021 00:11:38 -0800    

CREATE PUBLICATION has failed spuriously when applied to a permanent  
relation created or rewritten in the current transaction.  Make the same  
change to another site having the same semantic intent; the second  
instance has no user-visible consequences.  Back-patch to v13, where  
commit c6b92041d38512a4176ed76ad06f713d2e6c01a8 broke this.  
  
Kyotaro Horiguchi  
  
Discussion: https://postgr.es/m/20210113.160705.2225256954956139776.horikyota.ntt@gmail.com  

commit   : 86a5b309c9330661fd2c4c46e4dc7f07cca139e1    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sat, 30 Jan 2021 00:00:27 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sat, 30 Jan 2021 00:00:27 -0800    

In a cluster having used CREATE INDEX CONCURRENTLY while having enabled  
prepared transactions, queries that use the resulting index can silently  
fail to find rows.  Fix this for future CREATE INDEX CONCURRENTLY by  
making it wait for prepared transactions like it waits for ordinary  
transactions.  This expands the VirtualTransactionId structure domain to  
admit prepared transactions.  It may be necessary to reindex to recover  
from past occurrences.  Back-patch to 9.5 (all supported versions).  
  
Andrey Borodin, reviewed (in earlier versions) by Tom Lane and Michael  
Paquier.  
  
Discussion: https://postgr.es/m/2E712143-97F7-4890-B470-4A35142ABC82@yandex-team.ru  

commit   : 2a01bc275be1a7d117944b1a58ea1fe5f6c377c6    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 29 Jan 2021 10:46:14 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 29 Jan 2021 10:46:14 -0500    

The corresponding functions set_config and current_setting were  
mostly not hyperlinked.  Clarify their descriptions a tad, too.  
  
Discussion: https://postgr.es/m/161183356250.4077.687338658090583892@wrigleys.postgresql.org  

commit   : 9915fe22969a46f9d06d6c2c53dea7269ec4cc7e    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Fri, 29 Jan 2021 15:27:55 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Fri, 29 Jan 2021 15:27:55 +0300    

When the .** jsonpath accessor handles the array, it selects both array and  
each of its elements.  When using lax mode, subsequent accessors automatically  
unwrap arrays.  So, the content of each array element may be selected twice.  
  
Even though this behavior is counterintuitive, it's correct because everything  
works as designed.  This commit documents it.  
  
Backpatch to 12 where the jsonpath language was introduced.  
  
Reported-by: Thomas Kellerer  
Bug: #16828  
Discussion: https://postgr.es/m/16828-2b0229babfad2d8c%40postgresql.org  
Discussion: https://postgr.es/m/CAPpHfdtS-nNidT%3DEqZbAYOPcnNOWh_sd6skVdu2CAQUGdvpT8Q%40mail.gmail.com  
Author: Alexandex Korotkov, revised by Tom Lane  
Reviewed-by: Alvaro Herrera, Thomas Kellerer, Tom Lane  
Backpatch-through: 12  

commit   : 4a9ce085ab30ad01ffe03eb1743da82b1be280c1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 28 Jan 2021 17:18:23 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 28 Jan 2021 17:18:23 -0500    

Per buildfarm and local experimentation, bleeding-edge gcc isn't  
convinced that the MemSet in reorder_function_arguments() is safe.  
Shut it up by adding an explicit check that pronargs isn't negative,  
and by changing MemSet to memset.  (It appears that either change is  
enough to quiet the warning at -O2, but let's do both to be sure.)  

commit   : 16f69062e599eccda8aea52301009e63fa96bef4    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 28 Jan 2021 16:56:07 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 28 Jan 2021 16:56:07 -0300    

In trying to protect the user from inconsistent behavior, commit  
487e9861d0cf "Enable BEFORE row-level triggers for partitioned tables"  
tried to prevent BEFORE UPDATE FOR EACH ROW triggers from moving the row  
from one partition to another.  However, it turns out that the  
restriction is wrong in two ways: first, it fails spuriously, preventing  
valid situations from working, as in bug #16794; and second, they don't  
protect from any misbehavior, because tuple routing would cope anyway.  
  
Fix by removing that restriction.  
  
We keep the same restriction on BEFORE INSERT FOR EACH ROW triggers,  
though.  It is valid and useful there.  In the future we could remove it  
by having tuple reroute work for inserts as it does for updates.  
  
Backpatch to 13.  
  
Author: Álvaro Herrera <alvherre@alvh.no-ip.org>  
Reported-by: Phillip Menke <pg@pmenke.de>  
Discussion: https://postgr.es/m/16794-350a655580fbb9ae@postgresql.org  

commit   : 7f1921cb922879796f7946273db304922a439a58    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 28 Jan 2021 13:41:55 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 28 Jan 2021 13:41:55 -0500    

perform_pruning_combine_step() was not taught about the number of  
partition indexes used in hash partitioning; more embarrassingly,  
get_matching_hash_bounds() also had it wrong.  These errors are masked  
in the common case where all the partitions have the same modulus  
and no partition is missing.  However, with missing or unequal-size  
partitions, we could erroneously prune some partitions that need  
to be scanned, leading to silently wrong query answers.  
  
While a minimal-footprint fix for this could be to export  
get_partition_bound_num_indexes and make the incorrect functions use it,  
I'm of the opinion that that function should never have existed in the  
first place.  It's not reasonable data structure design that  
PartitionBoundInfoData lacks any explicit record of the length of  
its indexes[] array.  Perhaps that was all right when it could always  
be assumed equal to ndatums, but something should have been done about  
it as soon as that stopped being true.  Putting in an explicit  
"nindexes" field makes both partition_bounds_equal() and  
partition_bounds_copy() simpler, safer, and faster than before,  
and removes explicit knowledge of the number-of-partition-indexes  
rules from some other places too.  
  
This change also makes get_hash_partition_greatest_modulus obsolete.  
I left that in place in case any external code uses it, but no core  
code does anymore.  
  
Per bug #16840 from Michał Albrycht.  Back-patch to v11 where the  
hash partitioning code came in.  (In the back branches, add the new  
field at the end of PartitionBoundInfoData to minimize ABI risks.)  
  
Discussion: https://postgr.es/m/16840-571a22976f829ad4@postgresql.org  

commit   : 1449770d31fd684a078865334a3a155a7ee534ae    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 28 Jan 2021 11:17:13 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 28 Jan 2021 11:17:13 -0500    

We had "short *mdy" in the extern declarations, but "short mdy[3]"  
in the actual function definitions.  Per C99 these are equivalent,  
but recent versions of gcc have started to issue warnings about  
the inconsistency.  Clean it up before the warnings get any more  
widespread.  
  
Back-patch, in case anyone wants to build older PG versions with  
bleeding-edge compilers.  
  
Discussion: https://postgr.es/m/2401575.1611764534@sss.pgh.pa.us  

commit   : ef2a83323c3b5ecbdcd113a61c4eddf968d29508    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 28 Jan 2021 12:50:40 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 28 Jan 2021 12:50:40 -0300    

doConnect() never returns connections in state CONNECTION_BAD, so  
checking for that is pointless.  Remove the code that does.  
  
This code has been dead since ba708ea3dc84, 20 years ago.  
  
Discussion: https://postgr.es/m/20210126195224.GA20361@alvherre.pgsql  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  

commit   : 75e3cca42d6f1121934d982a9f9efd37226e875d    
  
author   : Andrew Gierth <rhodiumtoad@postgresql.org>    
date     : Thu, 28 Jan 2021 10:53:10 +0000    
  
committer: Andrew Gierth <rhodiumtoad@postgresql.org>    
date     : Thu, 28 Jan 2021 10:53:10 +0000    

When building aggregate expression steps, strict checks need a bailout  
jump for when a null value is encountered, so there is a list of steps  
that require later adjustment. Adding entries to that list for steps  
that aren't actually strict would be harmless, except that there is an  
Assert which catches them. This leads to spurious errors on asserts  
builds, for data sets that trigger parallel aggregation of an  
aggregate with a non-strict deserialization function (no such  
aggregates exist in the core system).  
  
Repair by not adding the adjustment entry when it's not needed.  
  
Backpatch back to 11 where the code was introduced.  
  
Per a report from Darafei (Komzpa) of the PostGIS project; analysis  
and patch by me.  
  
Discussion: https://postgr.es/m/87mty7peb3.fsf@news-spur.riddles.org.uk  

commit   : bfda0a02444e204024d83db2874ec884960d24f0    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 27 Jan 2021 12:50:17 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 27 Jan 2021 12:50:17 -0500    

Per a user question, spell out that UNNEST() returns array elements  
in storage order; also provide an example to clarify the behavior for  
multi-dimensional arrays.  
  
While here, also clarify the SELECT reference page's description of  
WITH ORDINALITY.  These details were already given in 7.2.1.4, but  
a reference page should not omit details.  
  
Back-patch to v13; there's not room in the table in older versions.  
  
Discussion: https://postgr.es/m/FF1FB31F-0507-4F18-9559-2DE6E07E3B43@gmail.com  

commit   : 2378d9232ea9a7d8147b17f7d78c14fbb4796c7d    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 27 Jan 2021 13:41:03 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 27 Jan 2021 13:41:03 +0900    

The page about privilege rights mentioned that TRUNCATE could be applied  
to views or even other relation types.  This is confusing as this  
command can be used only on tables and on partitioned tables.  
  
Oversight in afc4a78.  
  
Reported-by: Harisai Hari  
Reviewed-by: Laurenz Albe  
Discussion: https://postgr.es/m/161157636877.14625.15340884663716426087@wrigleys.postgresql.org  
Backpatch-through: 12  

commit   : f17e8f33f781ce156ee73e8e7b6d104fcfa9c811    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 26 Jan 2021 16:42:13 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 26 Jan 2021 16:42:13 -0300    

When reporting connection errors, we might show a database name in the  
message that's not the one we actually tried to connect to, if the  
database was taken from libpq defaults instead of from user parameters.  
Fix such error messages to use PQdb(), which reports the correct name.  
  
(But, per commit 2930c05634bc, make sure not to try to print NULL.)  
  
Apply to branches 9.5 through 13.  Branch master has already been  
changed differently by commit 58cd8dca3de0.  
  
Reported-by: Robert Haas <robertmhaas@gmail.com>  
Discussion: https://postgr.es/m/CA+TgmobssJ6rS22dspWnu-oDxXevGmhMD8VcRBjmj-b9UDqRjw@mail.gmail.com  

commit   : 64bdb6e5f8451a14e7349d3bbdb45dbac447eacc    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 26 Jan 2021 13:04:52 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 26 Jan 2021 13:04:52 -0500    

The loops to identify word boundaries could access past the end of  
the input string.  Likely that would never result in an actual  
crash, but it makes valgrind unhappy.  
  
The logic to try different numbers of words didn't work when the  
input has two words but we only have a match to the first, eg  
"\h with select".  (We must "continue" the pass loop, not "break".)  
  
The logic to compute nl_count was bizarrely managed, and in at  
least two code paths could end up calling PageOutput with  
nl_count = 0, resulting in failing to paginate output that should  
have been fed to the pager.  Also, in v12 and up, the nl_count  
calculation hadn't been updated to account for the addition of a URL.  
  
The PQExpBuffer holding the command syntax details wasn't freed,  
resulting in a session-lifespan memory leak.  
  
While here, improve some comments, choose a more descriptive name  
for a variable, fix inconsistent datatype choice for another variable.  
  
Per bug #16837 from Alexander Lakhin.  This code is very old,  
so back-patch to all supported branches.  
  
Kyotaro Horiguchi and Tom Lane  
  
Discussion: https://postgr.es/m/16837-479bcd56040c71b3@postgresql.org  

commit   : 366d302d14f7b12a911c49d25645da627163e4f1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 25 Jan 2021 14:53:13 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 25 Jan 2021 14:53:13 -0500    

Embarrassing oversight in this test script, which fortunately is not  
run by default.  
  
Report and patch by Jacob Champion.  
  
Discussion: https://postgr.es/m/1fcb175bafef6560f47a8c31229fa7c938486b8d.camel@vmware.com  

commit   : a26194f22bf06733f8065d637f790ee4d4778321    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 25 Jan 2021 13:03:11 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 25 Jan 2021 13:03:11 -0500    

I chanced to notice that this dumped core due to a faulty Assert.  
To add insult to injury, the output has been misformatted since v11.  
Obviously we need some regression testing here.  
  
Discussion: https://postgr.es/m/d1cc628c-3953-4209-957b-29427acc38c8@www.fastmail.com  

commit   : 652f7818bf978b7230e4462535aef0c9d216b99f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 25 Jan 2021 11:20:17 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 25 Jan 2021 11:20:17 -0500    

Add a "references" link pointing to pg_type, as we have for other arrays  
of type OIDs.  Wordsmith the explanation a bit.  
  
Joel Jacobson, additional editing by me  
  
Discussion: https://postgr.es/m/d1cc628c-3953-4209-957b-29427acc38c8@www.fastmail.com  

commit   : 7632ef5a71af0bef8384ceaa44d5486d555d8394    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Mon, 25 Jan 2021 19:52:52 +1300    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Mon, 25 Jan 2021 19:52:52 +1300    

Both heapgettup() and heapgettup_pagemode() incorrectly set the first page  
to scan in a backward scan in which the number of pages to scan was  
specified by heap_setscanlimits().  The code incorrectly started the scan  
at the end of the relation when startBlk was 0, or otherwise at  
startBlk - 1, neither of which is correct when only scanning a subset of  
pages.  
  
The fix here checks if heap_setscanlimits() has changed the number of  
pages to scan and if so we set the first page to scan as the final page in  
the specified range during backward scans.  
  
Proper adjustment of this code was forgotten when heap_setscanlimits() was  
added in 7516f5259 back in 9.5.  However, practice, nowhere in core code  
performs backward scans after having used heap_setscanlimits(), yet, it is  
possible an extension uses the heap functions in this way, hence  
backpatch.  
  
An upcoming patch does use heap_setscanlimits() with backward scans, so  
this must be fixed before that can go in.  
  
Author: David Rowley  
Discussion: https://postgr.es/m/CAApHDvpGc9h0_oVD2CtgBcxCS1N-qDYZSeBRnUh+0CWJA9cMaA@mail.gmail.com  
Backpatch-through: 9.5, all supported versions  

commit   : 58a545344147c870845adccc284443f990a43b65    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 24 Jan 2021 16:29:47 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 24 Jan 2021 16:29:47 -0500    

DST law changes in Russia (Volgograd zone) and South Sudan.  
Historical corrections for Australia, Bahamas, Belize, Bermuda,  
Ghana, Israel, Kenya, Nigeria, Palestine, Seychelles, and Vanuatu.  
Notably, the Australia/Currie zone has been corrected to the point  
where it is identical to Australia/Hobart.  

commit   : 8fe8a5539ec76ec1105e827dc217fb7fb8a03f3d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 22 Jan 2021 18:58:25 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 22 Jan 2021 18:58:25 -0500    

In light of recent discussions, we should instruct people to  
install Apple's command line tools; installing Xcode is secondary.  
  
Also, fix sample command for finding out the default sysroot,  
as we now know that the command originally recommended can give  
a result that doesn't match your OS version.  
  
Also document the workaround to use if you really don't want  
configure to select a sysroot at all.  
  
Discussion: https://postgr.es/m/20210119111625.20435-1-james.hilliard1@gmail.com  

commit   : 35a7eef08a98597417647ee7b6c1292f911d2b82    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 22 Jan 2021 11:29:43 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 22 Jan 2021 11:29:43 -0500    

This text claimed that the reconnection would occur "to the same  
server", but there is no such guarantee in the code, nor would  
insisting on that be an improvement.  
  
Back-patch to v10 where multi-host connection strings were added.  
  
Discussion: https://postgr.es/m/1095901.1611268376@sss.pgh.pa.us  

commit   : 73fc2e5bab1e4bad433d00b2b645cfdd234657db    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 21 Jan 2021 15:37:23 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 21 Jan 2021 15:37:23 -0500    

Previously, pull_varnos() took the relids of a PlaceHolderVar as being  
equal to the relids in its contents, but that fails to account for the  
possibility that we have to postpone evaluation of the PHV due to outer  
joins.  This could result in a malformed plan.  The known cases end up  
triggering the "failed to assign all NestLoopParams to plan nodes"  
sanity check in createplan.c, but other symptoms may be possible.  
  
The right value to use is the join level we actually intend to evaluate  
the PHV at.  We can get that from the ph_eval_at field of the associated  
PlaceHolderInfo.  However, there are some places that call pull_varnos()  
before the PlaceHolderInfos have been created; in that case, fall back  
to the conservative assumption that the PHV will be evaluated at its  
syntactic level.  (In principle this might result in missing some legal  
optimization, but I'm not aware of any cases where it's an issue in  
practice.)  Things are also a bit ticklish for calls occurring during  
deconstruct_jointree(), but AFAICS the ph_eval_at fields should have  
reached their final values by the time we need them.  
  
The main problem in making this work is that pull_varnos() has no  
way to get at the PlaceHolderInfos.  We can fix that easily, if a  
bit tediously, in HEAD by passing it the planner "root" pointer.  
In the back branches that'd cause an unacceptable API/ABI break for  
extensions, so leave the existing entry points alone and add new ones  
with the additional parameter.  (If an old entry point is called and  
encounters a PHV, it'll fall back to using the syntactic level,  
again possibly missing some valid optimization.)  
  
Back-patch to v12.  The computation is surely also wrong before that,  
but it appears that we cannot reach a bad plan thanks to join order  
restrictions imposed on the subquery that the PlaceHolderVar came from.  
The error only became reachable when commit 4be058fe9 allowed trivial  
subqueries to be collapsed out completely, eliminating their join order  
restrictions.  
  
Per report from Stephan Springl.  
  
Discussion: https://postgr.es/m/171041.1610849523@sss.pgh.pa.us  

commit   : 6671e81946266fae44eb812a1c76e21845f2990c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 20 Jan 2021 12:07:23 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 20 Jan 2021 12:07:23 -0500    

It emerges that in some phases of the moon (perhaps to do with  
directory entry order?), xcrun will report that the SDK path is  
  /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk  
which is normally a symlink to a version-numbered sibling directory.  
Our heuristic to skip non-version-numbered pathnames was rejecting  
that, which is the wrong thing to do.  We'd still like to end up  
with a version-numbered PG_SYSROOT value, but we can have that by  
dereferencing the symlink.  
  
Like the previous fix, back-patch to all supported versions.  
  
Discussion: https://postgr.es/m/522433.1611089678@sss.pgh.pa.us  

commit   : a57dbfcda5535da31aedb16c76bc532a72a6e7a5    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 20 Jan 2021 11:49:29 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 20 Jan 2021 11:49:29 -0500    

By default VACUUM will skip pages that it can't immediately get  
exclusive access to, which means that even activities as harmless  
and unpredictable as checkpoint buffer writes might prevent a page  
from being processed.  Ordinarily this is no big deal, but we have  
a small number of test cases that examine the results of VACUUM's  
processing and therefore will fail if the page of interest is skipped.  
This seems to be the explanation for some rare buildfarm failures.  
To fix, add the DISABLE_PAGE_SKIPPING option to the VACUUM commands  
in tests where this could be an issue.  
  
In passing, remove a duplicated query in pageinspect/sql/page.sql.  
  
Back-patch as necessary (some of these cases are as old as v10).  
  
Discussion: https://postgr.es/m/413923.1611006484@sss.pgh.pa.us  

commit   : b8403d140f4e7d753d21116c0fa79dc4ca5ca5cb    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 20 Jan 2021 11:58:03 +0200    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 20 Jan 2021 11:58:03 +0200    

In commit 9eb5607e699, I got the condition on checking for split or  
deleted page wrong: I used && instead of ||. The comment correctly said  
"concurrent split _or_ deletion".  
  
As a result, GiST insertion could miss a concurrent split, and insert to  
wrong page. Duncan Sands demonstrated this with a test script that did a  
lot of concurrent inserts.  
  
Backpatch to v12, where this was introduced. REINDEX is required to fix  
indexes that were affected by this bug.  
  
Backpatch-through: 12  
Reported-by: Duncan Sands  
Discussion: https://www.postgresql.org/message-id/a9690483-6c6c-3c82-c8ba-dc1a40848f11%40deepbluecap.com  

commit   : 31e0f9d76bb0196b92f6870a8e1e3e2a4e5e2b28    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 20 Jan 2021 11:39:14 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 20 Jan 2021 11:39:14 +0900    

Specifying duplicated objects in this command would lead to unique  
constraint violations in pg_default_acl or "tuple already updated by  
self" errors.  Similarly to GRANT/REVOKE, increment the command ID after  
each subcommand processing to allow this case to work transparently.  
  
A regression test is added by tweaking one of the existing queries of  
privileges.sql to stress this case.  
  
Reported-by: Andrus  
Author: Michael Paquier  
Reviewed-by: Álvaro Herrera  
Discussion: https://postgr.es/m/ae2a7dc1-9d71-8cba-3bb9-e4cb7eb1f44e@hot.ee  
Backpatch-through: 9.5  

commit   : 188cd4f440ed6bb2b3120ade9a2277c91d79215c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 19 Jan 2021 13:25:33 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 19 Jan 2021 13:25:33 -0500    

Somebody extended search_plan_tree() to treat MergeAppend exactly  
like Append, which is 100% wrong, because unlike Append we can't  
assume that only one input node is actively returning tuples.  
Hence a cursor using a MergeAppend across a UNION ALL or inheritance  
tree could falsely match a WHERE CURRENT OF query at a row that  
isn't actually the cursor's current output row, but coincidentally  
has the same TID (in a different table) as the current output row.  
  
Delete the faulty code; this means that such a case will now return  
an error like 'cursor "foo" is not a simply updatable scan of table  
"bar"', instead of silently misbehaving.  Users should not find that  
surprising though, as the same cursor query could have failed that way  
already depending on the chosen plan.  (It would fail like that if the  
sort were done with an explicit Sort node instead of MergeAppend.)  
  
Expand the clearly-inadequate commentary to be more explicit about  
what this code is doing, in hopes of forestalling future mistakes.  
  
It's been like this for awhile, so back-patch to all supported  
branches.  
  
Discussion: https://postgr.es/m/482865.1611075182@sss.pgh.pa.us  

commit   : 6c183aff1817d86397aa9c54cd06c286e1876bc7    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 18 Jan 2021 18:48:25 -0500    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 18 Jan 2021 18:48:25 -0500    

Backpatch-through: 10  

commit   : f0f53195b51a10e5093e0070bb24ef1f574ee725    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 18 Jan 2021 18:32:30 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 18 Jan 2021 18:32:30 -0500    

execCurrent.c's search_plan_tree() assumed that ForeignScanStates  
and CustomScanStates necessarily have a valid ss_currentRelation.  
This is demonstrably untrue for postgres_fdw's remote join and  
remote aggregation plans, and non-leaf custom scans might not have  
an identifiable scan relation either.  Avoid crashing by ignoring  
such nodes when the field is null.  
  
This solution will lead to errors like 'cursor "foo" is not a  
simply updatable scan of table "bar"' in cases where maybe we  
could have allowed WHERE CURRENT OF to work.  That's not an issue  
for postgres_fdw's usages, since joins or aggregations would render  
WHERE CURRENT OF invalid anyway.  But an otherwise-transparent  
upper level custom scan node might find this annoying.  When and if  
someone cares to expend work on such a scenario, we could invent a  
custom-scan-provider callback to determine what's safe.  
  
Report and patch by David Geier, commentary by me.  It's been like  
this for awhile, so back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/0253344d-9bdd-11c4-7f0d-d88c02cd7991@swarm64.com  

commit   : b8daf894f0d3440dd79131e12221c30b114e4b3e    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sat, 16 Jan 2021 12:21:35 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sat, 16 Jan 2021 12:21:35 -0800    

The context is an object that no longer bears some aclitem that it bore  
initially.  (A user issued REVOKE or GRANT statements upon the object.)  
pg_dump is forming SQL to reproduce the object ACL.  Since initdb  
creates no ACL bearing GRANT OPTION, reaching this bug requires an  
extension where the creation script establishes such an ACL.  No PGXN  
extension does that.  If an installation did reach the bug, pg_dump  
would have omitted a semicolon, causing a REVOKE and the next SQL  
statement to fail.  Separately, since the affected code exists to  
eliminate an entire aclitem, it wants plain REVOKE, not REVOKE GRANT  
OPTION FOR.  Back-patch to 9.6, where commit  
23f34fa4ba358671adab16773e79c17c92cbc870 first appeared.  
  
Discussion: https://postgr.es/m/20210109102423.GA160022@rfd.leadboat.com  

commit   : 6eb3fc7fcd89258c2f4bb3dde03e41e6ede2be5f    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sat, 16 Jan 2021 12:21:35 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sat, 16 Jan 2021 12:21:35 -0800    

Every core SLRU wraps around.  With the exception of pg_notify, the wrap  
point can fall in the middle of a page.  Account for this in the  
PagePrecedes callback specification and in SimpleLruTruncate()'s use of  
said callback.  Update each callback implementation to fit the new  
specification.  This changes SerialPagePrecedesLogically() from the  
style of asyncQueuePagePrecedes() to the style of CLOGPagePrecedes().  
(Whereas pg_clog and pg_serial share a key space, pg_serial is nothing  
like pg_notify.)  The bug fixed here has the same symptoms and user  
followup steps as 592a589a04bd456410b853d86bd05faa9432cbbb.  Back-patch  
to 9.5 (all supported versions).  
  
Reviewed by Andrey Borodin and (in earlier versions) by Tom Lane.  
  
Discussion: https://postgr.es/m/20190202083822.GC32531@gust.leadboat.com  

commit   : d26d4c717dbfb24cc9dfd83044b5c9a377dc954a    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Fri, 15 Jan 2021 23:24:19 +0100    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Fri, 15 Jan 2021 23:24:19 +0100    

Add a check that CREATE STATISTICS does not add extended statistics on  
system catalogs, similarly to indexes etc.  It can be overriden using  
the allow_system_table_mods GUC.  
  
This bug exists since 7b504eb282c, adding the extended statistics, so  
backpatch all the way back to PostgreSQL 10.  
  
Author: Tomas Vondra  
Reported-by: Dean Rasheed  
Backpatch-through: 10  
Discussion: https://postgr.es/m/CAEZATCXAPrrOKwEsyZKQ4uzzJQWBCt6QAvOcgqRGdWwT1zb%2BrQ%40mail.gmail.com  

commit   : f44ae4db5feccb8012c1b2df169bf87576ce760e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 15 Jan 2021 11:28:51 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 15 Jan 2021 11:28:51 -0500    

In cases where Xcode is newer than the underlying macOS version,  
asking xcodebuild for the SDK path will produce a pointer to the  
SDK shipped with Xcode, which may end up building code that does  
not work on the underlying macOS version.  It appears that in  
such cases, xcodebuild's answer also fails to match the default  
behavior of Apple's compiler: assuming one has installed Xcode's  
"command line tools", there will be an SDK for the OS's own version  
in /Library/Developer/CommandLineTools, and the compiler will  
default to using that.  This is all pretty poorly documented,  
but experimentation suggests that "xcrun --show-sdk-path" gives  
the sysroot path that the compiler is actually using, at least  
in some cases.  Hence, try that first, but revert to xcodebuild  
if xcrun fails (in very old Xcode, it is missing or lacks the  
--show-sdk-path switch).  
  
Also, "xcrun --show-sdk-path" may give a path that is valid but lacks  
any OS version identifier.  We don't really want that, since most  
of the motivation for wiring -isysroot into the build flags at all  
is to ensure that all parts of a PG installation are built against  
the same SDK, even when considering extensions built later and/or on  
a different machine.  Insist on finding "N.N" in the directory name  
before accepting the result.  (Adding "--sdk macosx" to the xcrun  
call seems to produce the same answer as xcodebuild, but usually  
more quickly because it's cached, so we also try that as a fallback.)  
  
The core reason why we don't want to use Xcode's default SDK in cases  
like this is that Apple's technology for introducing new syscalls  
does not play nice with Autoconf: for example, configure will think  
that preadv/pwritev exist when using a Big Sur SDK, even when building  
on an older macOS version where they don't exist.  It'd be nice to  
have a better solution to that problem, but this patch doesn't attempt  
to fix that.  
  
Per report from Sergey Shinderuk.  Back-patch to all supported versions.  
  
Discussion: https://postgr.es/m/ed3b8e5d-0da8-6ebd-fd1c-e0ac80a4b204@postgrespro.ru  

commit   : 60369db86f6cc9432626df5a5ccdd9eb3338798e    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Fri, 15 Jan 2021 12:44:17 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Fri, 15 Jan 2021 12:44:17 +0900    

Commit ac883ac453 refactored shm_toc_estimate() but changed its calculation  
of shared memory size for TOC incorrectly. Previously this could cause too  
large memory to be allocated.  
  
Back-patch to v11 where the bug was introduced.  
  
Author: Takayuki Tsunakawa  
Discussion: https://postgr.es/m/TYAPR01MB2990BFB73170E2C4921E2C4DFEA80@TYAPR01MB2990.jpnprd01.prod.outlook.com  

commit   : 79d3ac72f690b45e2b278be746f858a1f6311310    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 14 Jan 2021 16:19:38 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 14 Jan 2021 16:19:38 -0500    

This is the same fix as commit 9eabfe300 applied to INDEX ATTACH  
entries, but for table-to-publication attachments.  As in that  
case, even though the backend doesn't record "ownership" of the  
attachment, we still ought to label it in the dump archive with  
the role name that should run the ALTER PUBLICATION command.  
The existing behavior causes the ALTER to be done by the original  
role that started the restore; that will usually work fine, but  
there may be corner cases where it fails.  
  
The bulk of the patch is concerned with changing struct  
PublicationRelInfo to include a pointer to the associated  
PublicationInfo object, so that we can get the owner's name  
out of that when the time comes.  While at it, I rewrote  
getPublicationTables() to do just one query of pg_publication_rel,  
not one per table.  
  
Back-patch to v10 where this code was introduced.  
  
Discussion: https://postgr.es/m/1165710.1610473242@sss.pgh.pa.us  

commit   : 5b01a6f13ff7669f37339a9e2416baa02b7429b2    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 14 Jan 2021 15:32:14 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 14 Jan 2021 15:32:14 -0300    

When a tablespace is used in a partitioned relation (per commits  
ca4103025dfe in pg12 for tables and 33e6c34c3267 in pg11 for indexes),  
it is possible to drop the tablespace, potentially causing various  
problems.  One such was reported in bug #16577, where a rewriting ALTER  
TABLE causes a server crash.  
  
Protect against this by using pg_shdepend to keep track of tablespaces  
when used for relations that don't keep physical files; we now abort a  
tablespace if we see that the tablespace is referenced from any  
partitioned relations.  
  
Backpatch this to 11, where this problem has been latent all along.  We  
don't try to create pg_shdepend entries for existing partitioned  
indexes/tables, but any ones that are modified going forward will be  
protected.  
  
Note slight behavior change: when trying to drop a tablespace that  
contains both regular tables as well as partitioned ones, you'd  
previously get ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE and now you'll  
get ERRCODE_DEPENDENT_OBJECTS_STILL_EXIST.  Arguably, the latter is more  
correct.  
  
It is possible to add protecting pg_shdepend entries for existing  
tables/indexes, by doing  
  ALTER TABLE ONLY some_partitioned_table SET TABLESPACE pg_default;  
  ALTER TABLE ONLY some_partitioned_table SET TABLESPACE original_tablespace;  
for each partitioned table/index that is not in the database default  
tablespace.  Because these partitioned objects do not have storage, no  
file needs to be actually moved, so it shouldn't take more time than  
what's required to acquire locks.  
  
This query can be used to search for such relations:  
SELECT ... FROM pg_class WHERE relkind IN ('p', 'I') AND reltablespace <> 0  
  
Reported-by: Alexander Lakhin <exclusion@gmail.com>  
Discussion: https://postgr.es/m/16577-881633a9f9894fd5@postgresql.org  
Author: Álvaro Herrera <alvherre@alvh.no-ip.org>  
Reviewed-by: Michael Paquier <michael@paquier.xyz>  

commit   : 8523a0971ba6490919c8e04bc7f7229aa38c789b    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Thu, 14 Jan 2021 14:37:01 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Thu, 14 Jan 2021 14:37:01 +0900    

Commit fef5b47f6b added the regression test to check whether a standby is  
able to follow a primary on a newer timeline when WAL archiving is enabled.  
But the buildfarm member florican reported that this test failed because  
the requested WAL segment was removed and replication failed. This is a  
timing issue. Since neither replication slot is used nor wal_keep_size is set  
in the test, checkpoint could remove the WAL segment that's still necessary  
for replication.  
  
This commit stabilizes the test by setting wal_keep_size.  
  
Back-patch to v13 where the regression test that this commit stabilizes  
was added.  
  
Author: Fujii Masao  
Discussion: https://postgr.es/m/X//PsenxcC50jDzX@paquier.xyz  

commit   : 94f52929a0c4e92c271c5a03bae782ddb0b086bd    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Thu, 14 Jan 2021 12:28:47 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Thu, 14 Jan 2021 12:28:47 +0900    

Commit 709d003fbd refactored WAL-reading code, but accidentally caused  
WalSndSegmentOpen() to fail to follow a timeline switch while reading from  
a historic timeline. This issue caused a standby to fail to follow a primary  
on a newer timeline when WAL archiving is enabled.  
  
If there is a timeline switch within the segment, WalSndSegmentOpen() should  
read from the WAL segment belonging to the new timeline. But previously  
since it failed to follow a timeline switch, it tried to read the WAL segment  
with old timeline. When WAL archiving is enabled, that WAL segment with  
old timeline doesn't exist because it's renamed to .partial. This leads  
a primary to have tried to read non-existent WAL segment, and which caused  
replication to faill with the error "ERROR:  requested WAL segment ... has  
 already been removed".  
  
This commit fixes WalSndSegmentOpen() so that it's able to follow a timeline  
switch, to ensure that a standby is able to follow a primary on a newer  
timeline even when WAL archiving is enabled.  
  
This commit also adds the regression test to check whether a standby is  
able to follow a primary on a newer timeline when WAL archiving is enabled.  
  
Back-patch to v13 where the bug was introduced.  
  
Reported-by: Kyotaro Horiguchi  
Author: Kyotaro Horiguchi, tweaked by Fujii Masao  
Reviewed-by:  Alvaro Herrera, Fujii Masao  
Discussion: https://postgr.es/m/20201209.174314.282492377848029776.horikyota.ntt@gmail.com  

commit   : c285a244f6d36073c6a8c9852e17492568664211    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 13 Jan 2021 17:55:41 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 13 Jan 2021 17:55:41 -0300    

Backpatch to pg12, which is as far as it goes without conflicts.  
  
Author: James Coleman <jtc331@gmail.com>  
Reviewed-by: "David G. Johnston" <david.g.johnston@gmail.com>  
Discussion: https://postgr.es/m/CAAaqYe9oEfbz7AxXq7OX+FFVi5w5p1e_Of8ON8ZnKO9QqBfmjg@mail.gmail.com  

commit   : 6b045ca6cce01f1512af3438a8d4db4dc83b2d07    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 13 Jan 2021 14:52:49 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 13 Jan 2021 14:52:49 -0500    

The point of this restriction is to avoid trying to substitute variables  
into timestamp literal values, which may contain strings like '12:34'.  
  
There is a good deal more that should be done to reduce pgbench's  
tendency to substitute where it shouldn't.  But this is sufficient to  
solve the case complained of by Jaime Soler, and it's simple enough  
to back-patch.  
  
Back-patch to v11; before commit 9d36a3866, pgbench had a slightly  
different definition of what a variable name is, and anyway it seems  
unwise to change long-stable branches for this.  
  
Fabien Coelho  
  
Discussion: https://postgr.es/m/alpine.DEB.2.22.394.2006291740420.805678@pseudo  

commit   : c77f31171c8349d9ae4d6328be1922f06c5d590f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 13 Jan 2021 13:30:04 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 13 Jan 2021 13:30:04 -0500    

Options that change how the archive data is converted to SQL text  
are ignored when dumping to archive formats.  The documentation  
previously said "not meaningful", which is not helpful.  
  
Discussion: https://postgr.es/m/161052021249.12228.9598689907884726185@wrigleys.postgresql.org  

commit   : bff8d0fe3bff0ce52c0343d81afa8f1745d0209e    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Wed, 13 Jan 2021 11:07:37 +0100    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Wed, 13 Jan 2021 11:07:37 +0100    

Seems 737d69ffc3c made a copy/paste or automation error resulting in two  
extra right-parenthesis.  
  
Reported-By: Michael Vastola  
Backpatch-through: 13  
Discussion: https://postgr.es/m/161051035421.12224.1741822783166533529@wrigleys.postgresql.org  

commit   : 0685c5c1b9225352bbaf4fe81c550f09508379ce    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Wed, 13 Jan 2021 08:31:45 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Wed, 13 Jan 2021 08:31:45 +0530    

The memory for the snapshot was leaked while serializing it to disk during  
logical decoding. This memory will be freed only once walsender stops  
streaming the changes. This can lead to a huge memory increase when master  
logs Standby Snapshot too frequently say when the user is trying to create  
many replication slots.  
  
Reported-by: funnyxj.fxj@alibaba-inc.com  
Diagnosed-by: funnyxj.fxj@alibaba-inc.com  
Author: Amit Kapila  
Backpatch-through: 9.5  
Discussion: https://postgr.es/m/033ab54c-6393-42ee-8ec9-2b399b5d8cde.funnyxj.fxj@alibaba-inc.com  

commit   : 0011c5a0fdacc5991b996e0081c218fbea4461a8    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 12 Jan 2021 13:37:38 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 12 Jan 2021 13:37:38 -0500    

Although a partitioned index's attachment to its parent doesn't  
have separate ownership, the ArchiveEntry for it needs to be  
marked with an owner anyway, to ensure that the ALTER command  
is run by the appropriate role when restoring with  
--use-set-session-authorization.  Without this, the ALTER will  
be run by the role that started the restore session, which will  
usually work but it's formally the wrong thing.  
  
Back-patch to v11 where this type of ArchiveEntry was added.  
In HEAD, add equivalent commentary to the just-added TABLE ATTACH  
case, which I'd made do the right thing already.  
  
Discussion: https://postgr.es/m/1094034.1610418498@sss.pgh.pa.us  

commit   : 0725bf3aac643b077b031139a61d2a9b298cc0fe    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 12 Jan 2021 12:52:14 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 12 Jan 2021 12:52:14 -0500    

Adding a table to a publication requires ownership of the table  
(in addition to ownership of the publication).  This was mentioned  
nowhere.  

commit   : ee69833e6e5667b5396c4b843ef88a688a27bd1f    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 12 Jan 2021 11:48:45 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 12 Jan 2021 11:48:45 -0300    

This comment has been wrong since its introduction in commit  
2c03216d8311.  
  
Author: Masahiko Sawada <sawada.mshk@gmail.com>  
Discussion: https://postgr.es/m/CAD21AoAzz6qipFJBbGEaHmyWxvvNDp8httbwLR9tUQWaTjUs2Q@mail.gmail.com  

commit   : decf3fe61ca2b707e8ac7ef996b16ace8df1d165    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Tue, 12 Jan 2021 08:30:16 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Tue, 12 Jan 2021 08:30:16 +0530    

We missed closing the relation descriptor while sending changes via the  
root of partitioned relations during logical replication.  
  
Author: Amit Langote and Mark Zhao  
Reviewed-by: Amit Kapila and Ashutosh Bapat  
Backpatch-through: 13, where it was introduced  
Discussion: https://postgr.es/m/tencent_41FEA657C206F19AB4F406BE9252A0F69C06@qq.com  
Discussion: https://postgr.es/m/tencent_6E296D2F7D70AFC90D83353B69187C3AA507@qq.com  

commit   : 14a608aef41b35ed4c2599493aaafe496fec3b3c    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Sat, 9 Jan 2021 12:11:16 -0500    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Sat, 9 Jan 2021 12:11:16 -0500    

The previous description of how the executor processes non-SELECT  
queries was very dense, causing lack of clarity.  This expanded text  
spells it out more simply.  
  
Reported-by: fotis.koutoupas@gmail.com  
  
Discussion: https://postgr.es/m/160912275508.676.17469511338925622905@wrigleys.postgresql.org  
  
Backpatch-through: 9.5  

commit   : 49c928c0c067a8ec0882eeea5c03ccbd1b1b1a62    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 8 Jan 2021 12:16:00 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 8 Jan 2021 12:16:00 -0500    

brenext(), when parsing a '*' quantifier, forgot to return any "value"  
for the token; per the equivalent case in next(), it should return  
value 1 to indicate that greedy rather than non-greedy behavior is  
wanted.  The result is that the compiled regexp could behave like 'x*?'  
rather than the intended 'x*', if we were unlucky enough to have  
a zero in v->nextvalue at this point.  That seems to happen with some  
reliability if we have '.*' at the beginning of a BRE-mode regexp,  
although that depends on the initial contents of a stack-allocated  
struct, so it's not guaranteed to fail.  
  
Found by Alexander Lakhin using valgrind testing.  This bug seems  
to be aboriginal in Spencer's code, so back-patch all the way.  
  
Discussion: https://postgr.es/m/16814-6c5e3edd2bdf0d50@postgresql.org  

commit   : 5ba046948ed49c326d124261ae354bd9fae96489    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 7 Jan 2021 20:36:09 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 7 Jan 2021 20:36:09 -0500    

We found last February that the error-case tests added by commit  
008cf0409 failed on OpenBSD, because that platform doesn't really  
check locale names.  At the time it seemed that that was only an issue  
for LC_CTYPE, but testing on a more recent version of OpenBSD shows  
that it's now equally lax about LC_COLLATE.  
  
Rather than dropping the LC_COLLATE test too, put back LC_CTYPE  
(reverting c4b0edb07), and adjust these tests to accept the different  
error message that we get if setlocale() doesn't reject a bogus locale  
name.  The point of these tests is not really what the backend does  
with the locale name, but to show that createdb quotes funny locale  
names safely; so we're not losing test reliability this way.  
  
Back-patch as appropriate.  
  
Discussion: https://postgr.es/m/231373.1610058324@sss.pgh.pa.us  

commit   : 5db4fdc22472919f97ce83d276fb34b47c794d1f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 7 Jan 2021 11:45:09 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 7 Jan 2021 11:45:09 -0500    

On reflection, the order of operations in PostgresMain() is wrong.  
These timeouts ought to be shut down before, not after, we do the  
post-command-read CHECK_FOR_INTERRUPTS, to guarantee that any  
timeout error will be detected there rather than at some ill-defined  
later point (possibly after having wasted a lot of work).  
  
This is really an error in the original idle_in_transaction_timeout  
patch, so back-patch to 9.6 where that was introduced.  

commit   : 0f8977b3f2536c91a0a97e2395c297d3acf1f491    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Wed, 6 Jan 2021 12:29:43 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Wed, 6 Jan 2021 12:29:43 +0900    

The deadlocks that the recovery conflict on lock is involved in can  
happen between hot-standby backends and the startup process.  
If a backend takes an access exclusive lock on the table and which  
finally triggers the deadlock, that deadlock can be detected  
as expected. On the other hand, previously, if the startup process  
took an access exclusive lock and which finally triggered the deadlock,  
that deadlock could not be detected and could remain even after  
deadlock_timeout passed. This is a bug.  
  
The cause of this bug was that the code for handling the recovery  
conflict on lock didn't take care of deadlock case at all. It assumed  
that deadlocks involving the startup process and backends were able  
to be detected by the deadlock detector invoked within backends.  
But this assumption was incorrect. The startup process also should  
have invoked the deadlock detector if necessary.  
  
To fix this bug, this commit makes the startup process invoke  
the deadlock detector if deadlock_timeout is reached while handling  
the recovery conflict on lock. Specifically, in that case, the startup  
process requests all the backends holding the conflicting locks to  
check themselves for deadlocks.  
  
Back-patch to v9.6. v9.5 has also this bug, but per discussion we decided  
not to back-patch the fix to v9.5. Because v9.5 doesn't have some  
infrastructure codes (e.g., 37c54863cf) that this bug fix patch depends on.  
We can apply those codes for the back-patch, but since the next minor  
version release is the final one for v9.5, it's risky to do that. If we  
unexpectedly introduce new bug to v9.5 by the back-patch, there is no  
chance to fix that. We determined that the back-patch to v9.5 would give  
more risk than gain.  
  
Author: Fujii Masao  
Reviewed-by: Bertrand Drouvot, Masahiko Sawada, Kyotaro Horiguchi  
Discussion: https://postgr.es/m/4041d6b6-cf24-a120-36fa-1294220f8243@oss.nttdata.com  

commit   : b1ebec2d800d676ffd3374945efc18eefe9ac4a8    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Wed, 6 Jan 2021 11:58:23 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Wed, 6 Jan 2021 11:58:23 +0900    

The default value of recovery_target_timeline was changed in v12,  
but the description about the default behavior of that was not updated.  
  
Back-patch to v12 where the default behavior of recovery_target_timeline  
was changed.  
  
Author: Benoit Lobréau  
Reviewed-by: Fujii Masao  
Discussion: https://postgr.es/m/CAPE8EZ7c3aruEmM24GYkj8y8WmHKD1m9TtPtgCF0nQ3zw4LCkQ@mail.gmail.com  

commit   : b266a406877b46ab0197d3c7da8c457c305f29be    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 5 Jan 2021 14:26:37 -0500    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 5 Jan 2021 14:26:37 -0500    

Reported-by: "Tang, Haiying"  
  
Discussion: https://postgr.es/m/bbbccf7a3c2d436e85d45869d612fd6b@G08CNEXMBPEKD05.g08.fujitsu.local  
  
Author: "Tang, Haiying"  
  
Backpatch-through: 9.5  

commit   : 5777b6ea29a581f073c80ae48931adadcbc268d4    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Tue, 5 Jan 2021 11:51:21 +0000    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Tue, 5 Jan 2021 11:51:21 +0000    

Commit bc43b7c2c0 used fabs() directly on an int variable, which  
apparently requires an explicit cast on some platforms.  
  
Per buildfarm.  

commit   : e15c384d7acaa2d7d967f2d8feb6bb0d3b793b3d    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Tue, 5 Jan 2021 11:08:59 +0000    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Tue, 5 Jan 2021 11:08:59 +0000    

In power_var_int(), the computation of the number of significant  
digits to use in the computation used log(Abs(exp)), which isn't safe  
because Abs(exp) returns INT_MIN when exp is INT_MIN. Use fabs()  
instead of Abs(), so that the exponent is cast to a double before the  
absolute value is taken.  
  
Back-patch to 9.6, where this was introduced (by 7d9a4737c2).  
  
Discussion: https://postgr.es/m/CAEZATCVd6pMkz=BrZEgBKyqqJrt2xghr=fNc8+Z=5xC6cgWrWA@mail.gmail.com  

commit   : 9e7d87ca84b91b0c6d8cb052bb6193881f6861fb    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 4 Jan 2021 18:32:40 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 4 Jan 2021 18:32:40 -0500    

If the substring start index and length overflow when added together,  
substring() misbehaved, either throwing a bogus "negative substring  
length" error on a case that should succeed, or failing to complain that  
a negative length is negative (and instead returning the whole string,  
in most cases).  Unsurprisingly, the text, bytea, and bit variants of  
the function all had this issue.  Rearrange the logic to ensure that  
negative lengths are always rejected, and add an overflow check to  
handle the other case.  
  
Also install similar guards into detoast_attr_slice() (nee  
heap_tuple_untoast_attr_slice()), since it's far from clear that  
no other code paths leading to that function could pass it values  
that would overflow.  
  
Patch by myself and Pavel Stehule, per bug #16804 from Rafi Shamim.  
  
Back-patch to v11.  While these bugs are old, the common/int.h  
infrastructure for overflow-detecting arithmetic didn't exist before  
commit 4d6ad3125, and it doesn't seem like these misbehaviors are bad  
enough to justify developing a standalone fix for the older branches.  
  
Discussion: https://postgr.es/m/16804-f4eeeb6c11ba71d4@postgresql.org  

commit   : c09f6882d6f78bde26fcc1e1a3da11c274de596a    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Sat, 2 Jan 2021 13:06:24 -0500    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Sat, 2 Jan 2021 13:06:24 -0500    

Backpatch-through: 9.5  

commit   : 4750d92ce82fa70dfee890161576743c151c422a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 1 Jan 2021 15:51:09 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 1 Jan 2021 15:51:09 -0500    

Try to be clearer about what computation is actually happening here.  
  
Per bug #16797 from Dana Burd.  
  
Discussion: https://postgr.es/m/16797-f264b0b980b53b8b@postgresql.org  

commit   : 55e5352266b1edc943a2a57a5d349aac73bac1a2    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Wed, 30 Dec 2020 17:21:41 -0800    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Wed, 30 Dec 2020 17:21:41 -0800    

On further reflection it seems better to call PageGetMaxOffsetNumber()  
after acquiring a buffer lock on the page.  This shouldn't really  
matter, but doing it this way is cleaner.  
  
Follow-up to commit 42288174.  
  
Backpatch: 12-, just like commit 42288174  

commit   : 7a57960ba6a7ae74d0830d0c766c275c288ed51a    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Wed, 30 Dec 2020 16:29:03 -0800    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Wed, 30 Dec 2020 16:29:03 -0800    

The logic for determining the latest removed XID for the purposes of  
generating recovery conflicts in REDO routines was subtly broken.  It  
failed to follow links from HOT chains, and so failed to consider all  
relevant heap tuple headers in some cases.  
  
To fix, expand the loop that deals with LP_REDIRECT line pointers to  
also deal with HOT chains.  The new version of the loop is loosely based  
on a similar loop from heap_prune_chain().  
  
The impact of this bug is probably quite limited, since the horizon code  
necessarily deals with heap tuples that are pointed to by LP_DEAD-set  
index tuples.  The process of setting LP_DEAD index tuples (e.g. within  
the kill_prior_tuple mechanism) is highly correlated with opportunistic  
pruning of pointed-to heap tuples.  Plus the question of generating a  
recovery conflict usually comes up some time after index tuple LP_DEAD  
bits were initially set, unlike heap pruning, where a latestRemovedXid  
is generated at the point of the pruning operation (heap pruning has no  
deferred "would-be page split" style processing that produces conflicts  
lazily).  
  
Only backpatch to Postgres 12, the first version where this logic runs  
during original execution (following commit 558a9165e08).  The index  
latestRemovedXid mechanism has had the same bug since it first appeared  
over 10 years ago (in commit a760893d), but backpatching to all  
supported versions now seems like a bad idea on balance.  Running the  
new improved code during recovery seems risky, especially given the lack  
of complaints from the field.  
  
Author: Peter Geoghegan <pg@bowt.ie>  
Discussion: https://postgr.es/m/CAH2-Wz=Eib393+HHcERK_9MtgNS7Ew1HY=RDC_g6GL46zM5C6Q@mail.gmail.com  
Backpatch: 12-  

commit   : 624fd9e56b455d89d2d6faca73be16442c784190    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 30 Dec 2020 17:48:43 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 30 Dec 2020 17:48:43 -0500    

The behavior of cross-type comparisons among date/time data types was  
not really explained anywhere.  You could probably infer it if you  
recognized the applicability of comments elsewhere about datatype  
conversions, but it seems worthy of explicit documentation.  
  
Per bug #16797 from Dana Burd.  
  
Discussion: https://postgr.es/m/16797-f264b0b980b53b8b@postgresql.org  

commit   : 861e967176e99da9122bb19bc2312c2ecdf6673c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 30 Dec 2020 11:38:42 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 30 Dec 2020 11:38:42 -0500    

secure_open_gssapi() installed the krb_server_keyfile setting as  
KRB5_KTNAME unconditionally, so long as it's not empty.  However,  
pg_GSS_recvauth() only installed it if KRB5_KTNAME wasn't set already,  
leading to a troubling inconsistency: in theory, clients could see  
different sets of server principal names depending on whether they  
use GSSAPI encryption.  Always using krb_server_keyfile seems like  
the right thing, so make both places do that.  Also fix up  
secure_open_gssapi()'s lack of a check for setenv() failure ---  
it's unlikely, surely, but security-critical actions are no place  
to be sloppy.  
  
Also improve the associated documentation.  
  
This patch does nothing about secure_open_gssapi()'s use of setenv(),  
and indeed causes pg_GSS_recvauth() to use it too.  That's nominally  
against project portability rules, but since this code is only built  
with --with-gssapi, I do not feel a need to do something about this  
in the back branches.  A fix will be forthcoming for HEAD though.  
  
Back-patch to v12 where GSSAPI encryption was introduced.  The  
dubious behavior in pg_GSS_recvauth() goes back further, but it  
didn't have anything to be inconsistent with, so let it be.  
  
Discussion: https://postgr.es/m/2187460.1609263156@sss.pgh.pa.us  

commit   : 239213684d01a64f82dfa6263cccc8bf68aeddd3    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Wed, 30 Dec 2020 01:43:43 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Wed, 30 Dec 2020 01:43:43 -0800    

This suffices for testing v12 -> v13; some other version pairs need more  
changes.  Back-patch to v10, which removed the function.  

commit   : 5253906fac5a2f3669f7867bcb5507f6f0ea891c    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 29 Dec 2020 18:18:59 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 29 Dec 2020 18:18:59 +0900    

90fbf7c has taken care of that for HEAD.  This includes the portion of  
the fixes that applies to the documentation, where needed depending on  
the branch.  
  
Author: Justin Pryzby  
Discussion: https://postgr.es/m/20201227202604.GC26311@telsasoft.com  
Backpatch-through: 9.5  

commit   : d05e14d786acacfdf0bd7f3202c543fffaf832ca    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 28 Dec 2020 17:58:58 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 28 Dec 2020 17:58:58 -0500    

Include details on whether GSS encryption has been activated;  
since we added "hostgssenc" type HBA entries, that's relevant info.  
  
Kyotaro Horiguchi and Tom Lane.  Back-patch to v12 where  
GSS encryption was introduced.  
  
Discussion: https://postgr.es/m/e5b0b6ed05764324a2f3fe7acfc766d5@smhi.se  

commit   : c1c88bf03e1eb85d5ca04bc7cfe2630154ec70d3    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 28 Dec 2020 17:44:17 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 28 Dec 2020 17:44:17 -0500    

Unrecoverable errors detected by GSSAPI encryption can't just be  
reported with elog(ERROR) or elog(FATAL), because attempting to  
send the error report to the client is likely to lead to infinite  
recursion or loss of protocol sync.  Instead make this code do what  
the SSL encryption code has long done, which is to just report any  
such failure to the server log (with elevel COMMERROR), then pretend  
we've lost the connection by returning errno = ECONNRESET.  
  
Along the way, fix confusion about whether message translation is done  
by pg_GSS_error() or its callers (the latter should do it), and make  
the backend version of that function work more like the frontend  
version.  
  
Avoid allocating the port->gss struct until it's needed; we surely  
don't need to allocate it in the postmaster.  
  
Improve logging of "connection authorized" messages with GSS enabled.  
(As part of this, I back-patched the code changes from dc11f31a1.)  
  
Make BackendStatusShmemSize() account for the GSS-related space that  
will be allocated by CreateSharedBackendStatus().  This omission  
could possibly cause out-of-shared-memory problems with very high  
max_connections settings.  
  
Remove arbitrary, pointless restriction that only GSS authentication  
can be used on a GSS-encrypted connection.  
  
Improve documentation; notably, document the fact that libpq now  
prefers GSS encryption over SSL encryption if both are possible.  
  
Per report from Mikael Gustavsson.  Back-patch to v12 where  
this code was introduced.  
  
Discussion: https://postgr.es/m/e5b0b6ed05764324a2f3fe7acfc766d5@smhi.se  

commit   : 06b844c2b8d3e7743b9ff7734893815df1fb68f0    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 28 Dec 2020 15:43:44 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 28 Dec 2020 15:43:44 -0500    

The critical issue fixed here is that if a GSSAPI-encrypted connection  
is successfully made, pqsecure_open_gss() cleared conn->allow_ssl_try,  
as an admittedly-hacky way of preventing us from then trying to tunnel  
SSL encryption over the already-encrypted connection.  The problem  
with that is that if we abandon the GSSAPI connection because of a  
failure during authentication, we would not attempt SSL encryption  
in the next try with the same server.  This can lead to unexpected  
connection failure, or silently getting a non-encrypted connection  
where an encrypted one is expected.  
  
Fortunately, we'd only manage to make a GSSAPI-encrypted connection  
if both client and server hold valid tickets in the same Kerberos  
infrastructure, which is a relatively uncommon environment.  
Nonetheless this is a very nasty bug with potential security  
consequences.  To fix, don't reset the flag, instead adding a  
check for conn->gssenc being already true when deciding whether  
to try to initiate SSL.  
  
While here, fix some lesser issues in libpq's GSSAPI code:  
  
* Use the need_new_connection stanza when dropping an attempted  
GSSAPI connection, instead of partially duplicating that code.  
The consequences of this are pretty minor: AFAICS it could only  
lead to auth_req_received or password_needed remaining set when  
they shouldn't, which is not too harmful.  
  
* Fix pg_GSS_error() to not repeat the "mprefix" it's given multiple  
times, and to notice any failure return from gss_display_status().  
  
* Avoid gratuitous dependency on NI_MAXHOST in  
pg_GSS_load_servicename().  
  
Per report from Mikael Gustavsson.  Back-patch to v12 where  
this code was introduced.  
  
Discussion: https://postgr.es/m/e5b0b6ed05764324a2f3fe7acfc766d5@smhi.se  

commit   : 31d2b11b94416ba94624ab07bcc1cb4a47c58c2e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 28 Dec 2020 12:13:40 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 28 Dec 2020 12:13:40 -0500    

If there's a static default value for a connection option,  
it should be shown in the PQconninfoOptions array.  
  
Daniele Varrazzo  
  
Discussion: https://postgr.es/m/CA+mi_8Zo8Rgn7p+6ZRY7QdDu+23ukT9AvoHNyPbgKACxwgGhZA@mail.gmail.com  

commit   : 63d78d106d2f69768f9b4c66ff849d95a83205f7    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 28 Dec 2020 11:55:23 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 28 Dec 2020 11:55:23 -0500    

There's a second call of get_eval_mcontext() that should also be  
get_stmt_mcontext().  This is actually dead code, since no  
interesting allocations happen before switching back to the  
original context, but we should keep it in sync with the other  
call to forestall possible future bugs.  
  
Discussion: https://postgr.es/m/f075f7be-c654-9aa8-3ffc-e9214622f02a@enterprisedb.com  

commit   : 0ea25ed108d8344ac17012e62790e7e9ef7f1a7a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 28 Dec 2020 11:41:25 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 28 Dec 2020 11:41:25 -0500    

Commit a6b1f5365 intended to place the transient "target" list of  
a CALL statement in the function's statement-lifespan context,  
but I fat-fingered that and used get_eval_mcontext() instead of  
get_stmt_mcontext().  The eval_mcontext belongs to the "simple  
expression" infrastructure, which is destroyed at transaction end.  
The net effect is that a CALL in a procedure to another procedure  
that has OUT or INOUT parameters would fail if the called procedure  
did a COMMIT.  
  
Per report from Peter Eisentraut.  Back-patch to v11, like the  
prior patch.  
  
Discussion: https://postgr.es/m/f075f7be-c654-9aa8-3ffc-e9214622f02a@enterprisedb.com  

commit   : 30803bd1cd6c4c9a0dc3362b02b6aa549b876d77    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 28 Dec 2020 22:16:57 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 28 Dec 2020 22:16:57 +0900    

The code in charge of processing a single invalidation message has been  
using since 568d413 the structure for relation mapping messages.  This  
had fortunately no consequence as both locate the database ID at the  
same location, but it could become a problem in the future if this area  
of the code changes.  
  
Author: Konstantin Knizhnik  
Discussion: https://postgr.es/m/8044c223-4d3a-2cdb-42bf-29940840ce94@postgrespro.ru  
Backpatch-through: 9.5  

commit   : 546f143740a07c4d9798f5870af8dad73ae057b5    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Mon, 28 Dec 2020 19:57:51 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Mon, 28 Dec 2020 19:57:51 +0900    

In postgres_fdw, the cached connections to foreign servers will not be  
closed until the local session exits if the user mappings or foreign servers  
that those connections depend on are dropped. Those connections can be  
leaked.  
  
To fix that connection leak issue, after a change to a pg_foreign_server  
or pg_user_mapping catalog entry, this commit makes postgres_fdw close  
the connections depending on that entry immediately if current  
transaction has not used those connections yet. Otherwise, mark those  
connections as invalid and then close them at the end of current transaction,  
since they cannot be closed in the midst of the transaction using them.  
Closed connections will be remade at the next opportunity if necessary.  
  
Back-patch to all supported branches.  
  
Author: Bharath Rupireddy  
Reviewed-by: Zhihong Yu, Zhijie Hou, Fujii Masao  
Discussion: https://postgr.es/m/CALj2ACVNcGH_6qLY-4_tXz8JLvA+4yeBThRfxMz7Oxbk1aHcpQ@mail.gmail.com  

commit   : cd7d8cde75063a85ee8c5fd27713061e56a8684d    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Sun, 27 Dec 2020 12:09:00 -0800    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Sun, 27 Dec 2020 12:09:00 -0800    

Removing the EXPLAIN test to stabilize the buildfarm. The execution  
test should still be effective to catch the bug even if the plan is  
slightly different on different platforms.  

commit   : 6669cc769c44b691510c14be12acd9148c74d4d1    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Sun, 27 Dec 2020 09:47:23 -0800    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Sun, 27 Dec 2020 09:47:23 -0800    

In passing, make the capitalization match the rest of the file.  
  
Reported-by: Tom Lane  

commit   : 7b8692eaf113a56933c77cf4c3993716ab37e763    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Sat, 26 Dec 2020 17:25:30 -0800    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Sat, 26 Dec 2020 17:25:30 -0800    

Before processing tuples, agg_refill_hash_table() was setting all  
pergroup pointers to NULL to signal to advance_aggregates() that it  
should not attempt to advance groups that had spilled.  
  
The problem was that it also set the pergroups for sorted grouping  
sets to NULL, which caused rescanning to fail.  
  
Instead, change agg_refill_hash_table() to only set the pergroups for  
hashed grouping sets to NULL; and when compiling the expression, pass  
doSort=false.  
  
Reported-by: Alexander Lakhin  
Discussion: https://postgr.es/m/16784-7ff169bf2c3d1588%40postgresql.org  
Backpatch-through: 13  

commit   : 9f8a48bb2c0e5d6557d78d7cce34444b249fbead    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Fri, 25 Dec 2020 10:41:59 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Fri, 25 Dec 2020 10:41:59 -0800    

This makes existing sessions reflect "ALTER ROLE ... [NO]INHERIT" as  
quickly as they have been reflecting "GRANT role_name".  Back-patch to  
9.5 (all supported versions).  
  
Reviewed by Nathan Bossart.  
  
Discussion: https://postgr.es/m/20201221095028.GB3777719@rfd.leadboat.com  

commit   : 6f7e972e2f44912b15d4a8884534745b1d5f492b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 24 Dec 2020 21:37:46 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 24 Dec 2020 21:37:46 -0500    

Buildfarm members pogona and petalura have shown a failure when  
pg_ctl/t/004_logrotate.pl starts just before local midnight.  
The default rotate-at-midnight behavior occurs just before the  
Perl script examines current_logfiles, so it figures that the  
rotation it's already requested has occurred ... but in reality,  
that rotation happens just after it looks, so the expected new  
log data goes into a different file than the one it's examining.  
  
In HEAD, src/test/kerberos/t/001_auth.pl has acquired similar code  
that evidently has a related failure mode.  Besides being quite new,  
few buildfarm critters run that test, so it's unsurprising that  
we've not yet seen a failure there.  
  
Fix both cases by setting log_rotation_age = 0 so that no time-based  
rotation can occur.  Also absorb 004_logrotate.pl's decision to  
set lc_messages = 'C' into the kerberos test, in hopes that it will  
work in non-English prevailing locales.  
  
Report: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=pogona&dt=2020-12-24%2022%3A10%3A04  
Report: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=petalura&dt=2020-02-01%2022%3A20%3A04  

commit   : 0217ad806637fed6b3bce759169724f31b66256d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 24 Dec 2020 17:00:43 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 24 Dec 2020 17:00:43 -0500    

If a database shutdown (smart or fast) is commanded between the time  
some process decides to request a new background worker and the time  
that the postmaster can launch that worker, then nothing happens  
because the postmaster won't launch any bgworkers once it's exited  
PM_RUN state.  This is fine ... unless the requesting process is  
waiting for that worker to finish (or even for it to start); in that  
case the requestor is stuck, and only manual intervention will get us  
to the point of being able to shut down.  
  
To fix, cancel pending requests for workers when the postmaster sends  
shutdown (SIGTERM) signals, and similarly cancel any new requests that  
arrive after that point.  (We can optimize things slightly by only  
doing the cancellation for workers that have waiters.)  To fit within  
the existing bgworker APIs, the "cancel" is made to look like the  
worker was started and immediately stopped, causing deregistration of  
the bgworker entry.  Waiting processes would have to deal with  
premature worker exit anyway, so this should introduce no bugs that  
weren't there before.  We do have a side effect that registration  
records for restartable bgworkers might disappear when theoretically  
they should have remained in place; but since we're shutting down,  
that shouldn't matter.  
  
Back-patch to v10.  There might be value in putting this into 9.6  
as well, but the management of bgworkers is a bit different there  
(notably see 8ff518699) and I'm not convinced it's worth the effort  
to validate the patch for that branch.  
  
Discussion: https://postgr.es/m/661570.1608673226@sss.pgh.pa.us  

commit   : d420ae74a7b97ab7a44f381f8c0ef401f74c9d38    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 23 Dec 2020 09:37:38 -0500    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 23 Dec 2020 09:37:38 -0500    

This was missed when the feature was added.  
  
Reported-by: Daniel Westermann  
  
Discussion: https://postgr.es/m/160624532969.25818.4767632047905006142@wrigleys.postgresql.org  
  
Backpatch-through: 11  

commit   : 1e54664eee4b3be0591841f50a9cac5b421c3401    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 23 Dec 2020 12:51:35 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 23 Dec 2020 12:51:35 +0900    

The parsing of this parameter has been using strtoul(), which is not  
portable across platforms.  On most Unix platforms, unsigned long has a  
size of 64 bits, while on Windows it is 32 bits.  It is common in  
recovery scenarios to rely on the output of txid_current() or even the  
newer pg_current_xact_id() to get a transaction ID for setting up  
recovery_target_xid.  The value returned by those functions includes the  
epoch in the computed result, which would cause strtoul() to fail where  
unsigned long has a size of 32 bits once the epoch is incremented.  
  
WAL records and 2PC data include only information about 32-bit XIDs and  
it is not possible to have XIDs across more than one epoch, so  
discarding the high bits from the transaction ID set has no impact on  
recovery.  On the contrary, the use of strtoul() prevents a consistent  
behavior across platforms depending on the size of unsigned long.  
  
This commit changes the parsing of recovery_target_xid to use  
pg_strtouint64() instead, available down to 9.6.  There is one TAP test  
stressing recovery with recovery_target_xid, where a tweak based on  
pg_reset{xlog,wal} is added to bump the XID epoch so as this change gets  
tested, as per an idea from Alexander Lakhin.  
  
Reported-by: Alexander Lakhin  
Discussion: https://postgr.es/m/16780-107fd0c0385b1035@postgresql.org  
Backpatch-through: 9.6  

commit   : 4b0292253cfca558b76c7a869ba0930a5e6d82fe    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 22 Dec 2020 13:23:49 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 22 Dec 2020 13:23:49 -0500    

Bad things happen if the DBA issues "pg_ctl stop -m fast" before  
autoprewarm finishes loading its list of blocks to prewarm.  
The current worker process successfully terminates early, but  
(if this wasn't the last database with blocks to prewarm) the  
leader process will just try to launch another worker for the  
next database.  Since the postmaster is now in PM_WAIT_BACKENDS  
state, it ignores the launch request, and the leader just sits  
until it's killed manually.  
  
This is mostly the fault of our half-baked design for launching  
background workers, but a proper fix for that is likely to be  
too invasive to be back-patchable.  To ameliorate the situation,  
fix apw_load_buffers() to check whether SIGTERM has arrived  
just before trying to launch another worker.  That leaves us with  
only a very narrow window in each worker launch where SIGTERM  
could occur between the launch request and successful worker start.  
  
Another issue is that if the leader process does manage to exit,  
it unconditionally rewrites autoprewarm.blocks with only the  
blocks currently in shared buffers, thus forgetting any blocks  
that we hadn't reached yet while prewarming.  This seems quite  
unhelpful, since the next database start will then not have the  
expected prewarming benefit.  Fix it to not modify the file if  
we shut down before the initial load attempt is complete.  
  
Per bug #16785 from John Thompson.  Back-patch to v11 where  
the autoprewarm code was introduced.  
  
Discussion: https://postgr.es/m/16785-c0207d8c67fb5f25@postgresql.org  

commit   : 336879f5557e6bb1f6c8d7837fd8b87158441078    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Tue, 22 Dec 2020 02:00:39 +0100    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Tue, 22 Dec 2020 02:00:39 +0100    

Clarify the relationship between find_em_expr_usable_for_sorting_rel and  
prepare_sort_from_pathkeys, i.e. what restrictions need to be shared  
between those two places.  
  
Author: James Coleman  
Reviewed-by: Tomas Vondra  
Backpatch-through: 13  
Discussion: https://postgr.es/m/CAAaqYe8cK3g5CfLC4w7bs%3DhC0mSksZC%3DH5M8LSchj5e5OxpTAg%40mail.gmail.com  

commit   : aa97890b6ec2ad07700c6e4825022ae3979ece7f    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Mon, 21 Dec 2020 19:37:14 +0100    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Mon, 21 Dec 2020 19:37:14 +0100    

While prepare_sort_from_pathkeys has to be concerned about matching up  
a volatile expression to the proper tlist entry, we don't need to do  
that in find_em_expr_usable_for_sorting_rel becausee such a sort will  
have to be postponed anyway.  
  
Author: James Coleman  
Reviewed-by: Tomas Vondra  
Backpatch-through: 13  
Discussion: https://postgr.es/m/CAAaqYe8cK3g5CfLC4w7bs%3DhC0mSksZC%3DH5M8LSchj5e5OxpTAg%40mail.gmail.com  

commit   : d0167631e8b7388b78203c6798621f98beed93d5    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Mon, 21 Dec 2020 18:58:32 +0100    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Mon, 21 Dec 2020 18:58:32 +0100    

While we do allow SRFs in ORDER BY, scan/join processing should not  
consider such cases - such sorts should only happen via final Sort atop  
a ProjectSet. So make sure we don't try adding such sorts below Gather  
Merge, just like we do for expressions that are volatile and/or not  
parallel safe.  
  
Backpatch to PostgreSQL 13, where this code was introduced as part of  
the Incremental Sort patch.  
  
Author: James Coleman  
Reviewed-by: Tomas Vondra  
Backpatch-through: 13  
Discussion: https://postgr.es/m/CAAaqYe8cK3g5CfLC4w7bs=hC0mSksZC=H5M8LSchj5e5OxpTAg@mail.gmail.com  
Discussion: https://postgr.es/m/295524.1606246314%40sss.pgh.pa.us  

commit   : 38d30a14b05e0cc2996fd311d94d7ae4fe2122aa    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 21 Dec 2020 13:11:29 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 21 Dec 2020 13:11:29 -0500    

The jsonb || jsonb operator arbitrarily rejected certain combinations  
of scalar and non-scalar inputs, while being willing to concatenate  
other combinations.  This was of course quite undocumented.  Rather  
than trying to document it, let's just remove the restriction,  
creating a uniform rule that unless we are handling an object-to-object  
concatenation, non-array inputs are converted to one-element arrays,  
resulting in an array-to-array concatenation.  (This does not change  
the behavior for any case that didn't throw an error before.)  
  
Per complaint from Joel Jacobson.  Back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/163099.1608312033@sss.pgh.pa.us  

commit   : be9c3cd186ba86b9bc3df7ecc64b81ce4726810d    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Mon, 21 Dec 2020 18:29:46 +0100    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Mon, 21 Dec 2020 18:29:46 +0100    

Commit ebb7ae839d ensured we ignore pathkeys with volatile expressions  
when considering adding a sort below a Gather Merge. Turns out we need  
to care about parallel safety of the pathkeys too, otherwise we might