PostgreSQL 13.0 (upcoming) commit log

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  
try sorting e.g. on results of a correlated subquery (as demonstrated  
by a report from Luis Roberto).  
  
Initial investigation by Tom Lane, patch by James Coleman. Backpatch  
to 13, where the code was instroduced (as part of Incremental Sort).  
  
Reported-by: Luis Roberto  
Author: James Coleman  
Reviewed-by: Tomas Vondra  
Backpatch-through: 13  
Discussion: https://postgr.es/m/622580997.37108180.1604080457319.JavaMail.zimbra%40siscobra.com.br  
Discussion: https://postgr.es/m/CAAaqYe8cK3g5CfLC4w7bs=hC0mSksZC=H5M8LSchj5e5OxpTAg@mail.gmail.com  

commit   : ea190ed14b4b75b38a490707d5d08231dcacfb8c    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Mon, 21 Dec 2020 18:16:16 +0100    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Mon, 21 Dec 2020 18:16:16 +0100    

generate_useful_gather_paths used to skip unsorted paths (without any  
pathkeys), but that is unnecessary - the later code actually can handle  
such paths just fine by adding a Sort node. This is clearly a thinko,  
preventing construction of useful plans.  
  
Backpatch to 13, where Incremental Sort was introduced.  
  
Author: James Coleman  
Reviewed-by: Tomas Vondra  
Backpatch-through: 13  
Discussion: https://postgr.es/m/CAAaqYe8cK3g5CfLC4w7bs=hC0mSksZC=H5M8LSchj5e5OxpTAg@mail.gmail.com  

commit   : bd6939a4e22ff5cc4ed77eec2c3c2d4c58ea2143    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 20 Dec 2020 15:28:22 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 20 Dec 2020 15:28:22 -0500    

The separate "cd" command before invoking psql made sense (or at least  
I thought so) when it was added in commit ed1939332.  But 4e3a61635  
removed the supporting text that explained when to use it, making it  
just confusing.  So drop it.  
  
Also switch from four-dot to three-dot filler for the unsupplied  
part of the path, since at least one person has read the four-dot  
filler as a typo for "../..".  And fix these/those inconsistency.  
  
Discussion: https://postgr.es/m/160837647714.673.5195186835607800484@wrigleys.postgresql.org  

commit   : 22d1569af95d6b409363a6c58ac347a3eb5878dc    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 20 Dec 2020 13:37:25 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 20 Dec 2020 13:37:25 -0500    

Point out the workaround to be used if you want to write a script  
file name that includes "@".  Clean up the text a little.  
  
Fabien Coelho, additional wordsmithing by me  
  
Discussion: https://postgr.es/m/1c4e81550d214741827a03292222db8d@G08CNEXMBPEKD06.g08.fujitsu.local  

commit   : 722eb325b9511e9d0a8669112c636edebe2cb01b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 18 Dec 2020 15:46:44 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 18 Dec 2020 15:46:44 -0500    

A narrow reading of the C standard says that memcpy(x,x,n) is undefined,  
although it's hard to envision an implementation that would really  
misbehave.  However, analysis tools such as valgrind might whine about  
this; accordingly, let's band-aid relmapper.c to not do it.  
  
See also 5b630501e, d3f4e8a8a, ad7b48ea0, and other similar fixes.  
Apparently, none of those folk tried valgrinding initdb?  This has been  
like this for long enough that I'm surprised it hasn't been reported  
before.  
  
Back-patch, just in case anybody wants to use a back branch on a platform  
that complains about this; we back-patched those earlier fixes too.  
  
Discussion: https://postgr.es/m/161790.1608310142@sss.pgh.pa.us  

commit   : d28a14d2d4009cec91f9d0f0ceaa60f06c6e289c    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 16 Dec 2020 10:39:29 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 16 Dec 2020 10:39:29 +0900    

Offsets are shown as NULL only for anonymous allocations.  
  
Author: Benoit Lobréau  
Reviewed-by: Kyotaro Horiguchi  
Discussion: https://postgr.es/m/CAPE8EZ5Lnoyqoz7aZpvQM0E8sW+hw+k6G2NULe+m4arFRrA1aA@mail.gmail.com  
Backpatch-through: 13  

commit   : de7b034dafd3847cddcd5f96cca1efce6f7ace8a    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 15 Dec 2020 19:20:15 -0500    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 15 Dec 2020 19:20:15 -0500    

It was not clear how COPY TO behaved with partitioning/inheritance  
because the paragraphs were so far apart.  Also reword to simplify.  
  
Discussion: https://postgr.es/m/20201203211723.GR24052@telsasoft.com  
  
Author: Justin Pryzby  
  
Backpatch-through: 10  

commit   : fde5f130c9c30e75c7a8ee33095a6a7e79d5b626    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Mon, 14 Dec 2020 23:48:44 -0800    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Mon, 14 Dec 2020 23:48:44 -0800    

This reverts commit 3a9e64aa0d96c8ffb6c682b082d0f72b1d373327.  
  
Commit 4bad60e3 fixed the root of the problem that 3a9e64aa worked  
around.  
  
This enables proper pipelining of commands after terminating  
replication, eliminating an undocumented limitation.  
  
Discussion: https://postgr.es/m/3d57bc29-4459-578b-79cb-7641baf53c57%40iki.fi  
Backpatch-through: 9.5  

commit   : 787d06a206b24138c06393b4737c6f116aaf30e6    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Sat, 12 Dec 2020 12:59:09 -0500    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Sat, 12 Dec 2020 12:59:09 -0500    

Backpatch-through: 9.5  

commit   : 38bcd4340f5a7d618961d185f79776f5802336e0    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Sat, 12 Dec 2020 12:51:16 -0500    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Sat, 12 Dec 2020 12:51:16 -0500    

Backpatch-through: 9.5  

commit   : c0549cee07ea3b6b0260a3c08c5f44807999a983    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 8 Dec 2020 17:50:54 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 8 Dec 2020 17:50:54 -0500    

array_get_element and array_get_slice qualify as leakproof, since  
they will silently return NULL for bogus subscripts.  But  
array_set_element and array_set_slice throw errors for such cases,  
making them clearly not leakproof.  contain_leaked_vars was evidently  
written with only the former case in mind, as it gave the wrong answer  
for assignment SubscriptingRefs (nee ArrayRefs).  
  
This would be a live security bug, were it not that assignment  
SubscriptingRefs can only occur in INSERT and UPDATE target lists,  
while we only care about leakproofness for qual expressions; so the  
wrong answer can't occur in practice.  Still, that's a rather shaky  
answer for a security-related question; and maybe in future somebody  
will want to ask about leakproofness of a tlist.  So it seems wise to  
fix and even back-patch this correction.  
  
(We would need some change here anyway for the upcoming  
generic-subscripting patch, since extensions might make different  
tradeoffs about whether to throw errors.  Commit 558d77f20 attempted  
to lay groundwork for that by asking check_functions_in_node whether a  
SubscriptingRef contains leaky functions; but that idea fails now that  
the implementation methods of a SubscriptingRef are not SQL-visible  
functions that could be marked leakproof or not.)  
  
Back-patch to 9.6.  While 9.5 has the same issue, the code's a bit  
different.  It seems quite unlikely that we'd introduce any actual bug  
in the short time 9.5 has left to live, so the work/risk/reward balance  
isn't attractive for changing 9.5.  
  
Discussion: https://postgr.es/m/3143742.1607368115@sss.pgh.pa.us  

commit   : c6f8d17d04d1bf1ddcbe0f2293d8f1462a1379f4    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 8 Dec 2020 13:09:47 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 8 Dec 2020 13:09:47 -0500    

The SQL standard says that redundant unique constraints are disallowed,  
but we long ago decided that throwing an error would be too  
user-unfriendly, so we just drop redundant ones.  The docs weren't very  
clear about that though, as this behavior was only explained for PRIMARY  
KEY vs UNIQUE, not UNIQUE vs UNIQUE.  
  
While here, I couldn't resist doing some copy-editing and markup-fixing  
on the adjacent text about INCLUDE options.  
  
Per bug #16767 from Matthias vd Meent.  
  
Discussion: https://postgr.es/m/16767-1714a2056ca516d0@postgresql.org  

commit   : c5ba66077054e05f07f4e1c80d588f3f3c374b1c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 8 Dec 2020 12:06:19 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 8 Dec 2020 12:06:19 -0500    

This restriction was mentioned in connection with string literals,  
but it wasn't made clear that it's a general restriction not just  
a syntactic limitation in query strings.  
  
Per unsigned documentation comment.  
  
Discussion: https://postgr.es/m/160720552914.710.16625261471128631268@wrigleys.postgresql.org  

commit   : dfd8bf2b9255f361d5541260a83ce634216c40f3    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 8 Dec 2020 15:22:38 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 8 Dec 2020 15:22:38 +0900    

The following routines are called within pgcrypto when handling digests  
but there were no checks for failures:  
- EVP_MD_CTX_size (can fail with -1 as of 3.0.0)  
- EVP_MD_CTX_block_size (can fail with -1 as of 3.0.0)  
- EVP_DigestInit_ex  
- EVP_DigestUpdate  
- EVP_DigestFinal_ex  
  
A set of elog(ERROR) is added by this commit to detect such failures,  
that should never happen except in the event of a processing failure  
internal to OpenSSL.  
  
Note that it would be possible to use ERR_reason_error_string() to get  
more context about such errors, but these refer mainly to the internals  
of OpenSSL, so it is not really obvious how useful that would be.  This  
is left out for simplicity.  
  
Per report from Coverity.  Thanks to Tom Lane for the discussion.  
  
Backpatch-through: 9.5  

commit   : 01c6370a32e5875a63400c6e465de775a51ef1b8    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 7 Dec 2020 18:21:06 -0800    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Mon, 7 Dec 2020 18:21:06 -0800    

clang only uses the 'i1' type for scalar booleans, not for pointers to  
booleans (as the pointer might be pointing into a larger memory  
allocation). Therefore a pointer-to-bool needs to the "storage" boolean.  
  
There's no known case of wrong code generation due to this, but it seems quite  
possible that it could cause problems (see e.g. 72559438f92).  
  
Author: Andres Freund  
Discussion: https://postgr.es/m/20201207212142.wz5tnbk2jsaqzogb@alap3.anarazel.de  
Backpatch: 11-, where jit support was added  

commit   : 4f64daf73af76cbf32a01c7cba1c3a6fccf3062a    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 7 Dec 2020 18:12:23 -0800    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Mon, 7 Dec 2020 18:12:23 -0800    

Until recently 'native' was implicitly included via 'orcjit', but a change  
included in LLVM 11 (not yet released) removed a number of such indirect  
component references.  
  
Reported-By: Fabien COELHO <coelho@cri.ensmp.fr>  
Reported-By: Andres Freund <andres@anarazel.de>  
Reported-By: Thomas Munro <thomas.munro@gmail.com>  
Author: Andres Freund <andres@anarazel.de>  
Discussion: https://postgr.es/m/20201201064949.mex6kvi2kygby3ni@alap3.anarazel.de  
Backpatch: 11-, where jit support was added  

commit   : 6a192c77d21b5eafc7f431cbf5e7ecdd6c8b5462    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 9 Nov 2020 20:01:33 -0800    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Mon, 9 Nov 2020 20:01:33 -0800    

As there haven't been problem on the buildfarm due to this change,  
backpatch 6c57f2ed16e now.  
  
Author: Andres Freund  
Discussion: https://postgr.es/m/20201016011244.pmyvr3ee2gbzplq4@alap3.anarazel.de  
Backpatch: 11-, where jit support was added  

commit   : e6dc04d436f1c5f173fc8b6e2f722f2d53719a92    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 7 Dec 2020 14:44:34 +0200    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 7 Dec 2020 14:44:34 +0200    

pg_rewind looks at the control file to check what timeline a server is on.  
But promotion doesn't immediately write a checkpoint, it merely writes  
an end-of-recovery WAL record. If pg_rewind runs immediately after  
promotion, before the checkpoint has completed, it will think think that  
the server is still on the earlier timeline. We ran into this issue a long  
time ago already, see commit 484a848a73f.  
  
It's a bit bogus that pg_rewind doesn't determine the timeline correctly  
until the end-of-recovery checkpoint has completed. We probably should  
fix that. But for now work around it by waiting for the checkpoint  
to complete before running pg_rewind, like we did in commit 484a848a73f.  
  
In the passing, tidy up the new test a little bit. Rerder the INSERTs so  
that the comments make more sense, remove a spurious CHECKPOINT call after  
pg_rewind has already run, and add --debug option, so that if this fails  
again, we'll have more data.  
  
Per buildfarm failure at https://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=rorqual&dt=2020-12-06%2018%3A32%3A19&stg=pg_rewind-check.  
Backpatch to all supported versions.  
  
Discussion: https://www.postgresql.org/message-id/1713707e-e318-761c-d287-5b6a4aa807e8@iki.fi  

commit   : 7d43b76f6ed97b3b27f30114636f7b116009ef61    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 5 Dec 2020 16:16:13 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 5 Dec 2020 16:16:13 -0500    

Commit 4be058fe9 forgot that the append_rel_list would already be  
populated at the time we remove useless result RTEs, and it might contain  
PlaceHolderVars that need to be adjusted like the ones in the main parse  
tree.  This could lead to "no relation entry for relid N" failures later  
on, when the planner tries to do something with an unadjusted PHV.  
  
Per report from Tom Ellis.  Back-patch to v12 where the bug came in.  
  
Discussion: https://postgr.es/m/20201205173056.GF30712@cloudinit-builder  

commit   : e41a2efbca10438fa0a506d4158edd1a1964aacf    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 4 Dec 2020 18:20:18 +0200    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 4 Dec 2020 18:20:18 +0200    

Buildfarm has been failing sporadically on the new test.  I was able to  
reproduce this by adding a random 0-10 s delay in the walreceiver, just  
before it connects to the primary. There's a race condition where node_3  
is promoted before it has fully caught up with node_1, leading to diverged  
timelines. When node_1 is later reconfigured as standby following node_3,  
it fails to catch up:  
  
LOG:  primary server contains no more WAL on requested timeline 1  
LOG:  new timeline 2 forked off current database system timeline 1 before current recovery point 0/30000A0  
  
That's the situation where you'd need to use pg_rewind, but in this case  
it happens already when we are just setting up the actual pg_rewind  
scenario we want to test, so change the test so that it waits until  
node_3 is connected and fully caught up before promoting it, so that you  
get a clean, controlled failover.  
  
Also rewrite some of the comments, for clarity. The existing comments  
detailed what each step in the test did, but didn't give a good overview  
of the situation the steps were trying to create.  
  
For reasons I don't understand, the test setup had to be written slightly  
differently in 9.6 and 9.5 than in later versions. The 9.5/9.6 version  
needed node 1 to be reinitialized from backup, whereas in later versions  
it could be shut down and reconfigured to be a standby. But even 9.5 should  
support "clean switchover", where primary makes sure that pending WAL is  
replicated to standby on shutdown. It would be nice to figure out what's  
going on there, but that's independent of pg_rewind and the scenario that  
this test tests.  
  
Discussion: https://www.postgresql.org/message-id/b0a3b95b-82d2-6089-6892-40570f8c5e60%40iki.fi  

commit   : 7b0bd08a325fd4f21269dbc9a6dd82809342644d    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Thu, 3 Dec 2020 11:33:24 -0500    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Thu, 3 Dec 2020 11:33:24 -0500    

Backpatch-through: 11  

commit   : 610e9f5b361e19f160fa27747e47d5495eb0f2ba    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Thu, 3 Dec 2020 10:28:58 -0500    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Thu, 3 Dec 2020 10:28:58 -0500    

In a few places, the long-version options were listed before the  
single-letter ones in the command summary of a few commands.  This  
didn't match other commands, and didn't match the option ordering later  
in the same reference page.  
  
Backpatch-through: 9.5  

commit   : abd0abfb749d39f46682fe84a1c6f973d2d8ddc2    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 3 Dec 2020 15:57:48 +0200    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 3 Dec 2020 15:57:48 +0200    

If the target is a standby server, its WAL doesn't end at the last  
checkpoint record, but at minRecoveryPoint. We must scan all the  
WAL from the last common checkpoint all the way up to minRecoveryPoint  
for modified pages, and also consider that portion when determining  
whether the server needs rewinding.  
  
Backpatch to all supported versions.  
  
Author: Ian Barwick and me  
Discussion: https://www.postgresql.org/message-id/CABvVfJU-LDWvoz4-Yow3Ay5LZYTuPD7eSjjE4kGyNZpXC6FrVQ%40mail.gmail.com  

commit   : eec90ffbf86f77102e0238b39591a26667cab0db    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 1 Dec 2020 20:27:06 -0500    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 1 Dec 2020 20:27:06 -0500    

While the previous behavior didn't generate a warning, we might as well  
use an accurate *printf specification.  
  
Backpatch-through: 12  

commit   : dffc82a5b9d48bded63e1beed718b24bbf58c6a4    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 1 Dec 2020 14:02:27 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 1 Dec 2020 14:02:27 -0500    

As it stood, expandTableLikeClause() re-did the same relation_openrv  
call that transformTableLikeClause() had done.  However there are  
scenarios where this would not find the same table as expected.  
We hold lock on the LIKE source table, so it can't be renamed or  
dropped, but another table could appear before it in the search path.  
This explains the odd behavior reported in bug #16758 when cloning a  
table as a temp table of the same name.  This case worked as expected  
before commit 502898192 introduced the need to open the source table  
twice, so we should fix it.  
  
To make really sure we get the same table, let's re-open it by OID not  
name.  That requires adding an OID field to struct TableLikeClause,  
which is a little nervous-making from an ABI standpoint, but as long  
as it's at the end I don't think there's any serious risk.  
  
Per bug #16758 from Marc Boeren.  Like the previous patch,  
back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/16758-840e84a6cfab276d@postgresql.org  

commit   : 5a1d1b9540a4f5bf4ee6761a17b21ad7c0012b49    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 1 Dec 2020 11:46:56 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 1 Dec 2020 11:46:56 -0300    

When memcpy() is called on a pointer, the compiler is entitled to assume  
that the pointer is not null, which can lead to optimizing nearby code  
in potentially undesirable ways.  We still want such optimizations  
(gcc's -fdelete-null-pointer-checks) in cases where they're valid.  
  
Related: commit 13bba02271dc.  
  
Backpatch to pg11, where this particular instance appeared.  
  
Reported-by: Ranier Vilela <ranier.vf@gmail.com>  
Reported-by: Zhihong Yu <zyu@yugabyte.com>  
Discussion: https://postgr.es/m/CAEudQApUndmQkr5fLrCKXQ7+ib44i7S+Kk93pyVThS85PnG3bQ@mail.gmail.com  
Discussion: https://postgr.es/m/CALNJ-vSdhwSM5f4tnNn1cdLHvXMVe_S+V3nR5GwNrmCPNB2VtQ@mail.gmail.com  

commit   : fd3a75d820a4fee3e25b699f1ccc043469afc55c    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Tue, 1 Dec 2020 13:21:03 +1300    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Tue, 1 Dec 2020 13:21:03 +1300    

When committing a transaction that dropped a relation, we previously  
truncated only the first segment file to free up disk space (the one  
that won't be unlinked until the next checkpoint).  
  
Truncate higher numbered segments too, even though we unlink them on  
commit.  This frees the disk space immediately, even if other backends  
have open file descriptors and might take a long time to get around to  
handling shared invalidation events and closing them.  Also extend the  
same behavior to the first segment, in recovery.  
  
Back-patch to all supported releases.  
  
Bug: #16663  
Reported-by: Denis Patron <denis.patron@previnet.it>  
Reviewed-by: Pavel Borisov <pashkin.elfe@gmail.com>  
Reviewed-by: Neil Chen <carpenter.nail.cz@gmail.com>  
Reviewed-by: David Zhang <david.zhang@highgo.ca>  
Discussion: https://postgr.es/m/16663-fe97ccf9932fc800%40postgresql.org  

commit   : a095e04f63a47ef02ec98577cc1fc4e4542e5ddd    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 30 Nov 2020 16:32:56 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 30 Nov 2020 16:32:56 -0500    

For debugging purposes, Path nodes are supposed to have outfuncs  
support, but this was overlooked in the original incremental sort patch.  
  
While at it, clean up a couple other minor oversights, as well as  
bizarre choice of return type for create_incremental_sort_path().  
(All the existing callers just cast it to "Path *" immediately, so  
they don't care, but some future caller might care.)  
  
outfuncs.c fix by Zhijie Hou, the rest by me  
  
Discussion: https://postgr.es/m/324c4d81d8134117972a5b1f6cdf9560@G08CNEXMBPEKD05.g08.fujitsu.local  

commit   : 3fe0e7c3fa27de80419de9ce66be2767d2ddae57    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 30 Nov 2020 18:24:55 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 30 Nov 2020 18:24:55 -0300    

Because regular CREATE INDEX commands are independent, and there's no  
logical data dependency, it's not immediately obvious that transactions  
held by concurrent index builds on one table will block the second phase  
of concurrent index creation on an unrelated table, so document this  
caveat.  
  
Backpatch this all the way back.  In branch master, mention that only  
some indexes are involved.  
  
Author: James Coleman <jtc331@gmail.com>  
Reviewed-by: David Johnston <david.g.johnston@gmail.com>  
Discussion: https://postgr.es/m/CAAaqYe994=PUrn8CJZ4UEo_S-FfRr_3ogERyhtdgHAb2WG_Ufg@mail.gmail.com  

commit   : d34916fee5c29098af17c2ef3fe29444d7f0f112    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 30 Nov 2020 15:24:13 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 30 Nov 2020 15:24:13 -0500    

Checking for DocBook being installed was valuable when we were on the  
OpenSP docs toolchain, because that was rather hard to get installed  
fully.  Nowadays, as long as you have xmllint and xsltproc installed,  
you're good, because those programs will fetch the DocBook files off  
the net at need.  Moreover, testing this at configure time means that  
a network access may well occur whether or not you have any interest  
in building the docs later.  That can be slow (typically 2 or 3  
seconds, though much higher delays have been reported), and it seems  
not very nice to be doing an off-machine access without warning, too.  
  
Hence, drop the PGAC_CHECK_DOCBOOK probe, and adjust related  
documentation.  Without that macro, there's not much left of  
config/docbook.m4 at all, so I just removed it.  
  
Back-patch to v11, where we started to use xmllint in the  
PGAC_CHECK_DOCBOOK probe.  
  
Discussion: https://postgr.es/m/E2EE6B76-2D96-408A-B961-CAE47D1A86F0@yesql.se  
Discussion: https://postgr.es/m/A55A7FC9-FA60-47FE-98B5-139CDC57CE6E@gmail.com  

commit   : fac31b2cd4470124d7d68a7eebdb13cfff8b3d3d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 30 Nov 2020 14:38:00 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 30 Nov 2020 14:38:00 -0500    

This can't work if there's no postmaster, and indeed the code got an  
assertion failure trying.  There should be a check on IsUnderPostmaster  
gating the use of parallelism, as the planner has for ordinary  
parallel queries.  
  
Commit 40d964ec9 got this right, so follow its model of checking  
IsUnderPostmaster at the same place where we check for  
max_parallel_maintenance_workers == 0.  In general, new code  
implementing parallel utility operations should do the same.  
  
Report and patch by Yulin Pei, cosmetically adjusted by me.  
Back-patch to v11 where this code came in.  
  
Discussion: https://postgr.es/m/HK0PR01MB22747D839F77142D7E76A45DF4F50@HK0PR01MB2274.apcprd01.prod.exchangelabs.com  

commit   : 666a4de939bf78df7295c35899a5f2e89eaea382    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 30 Nov 2020 12:22:43 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 30 Nov 2020 12:22:43 -0500    

If a PlaceHolderVar is to be evaluated at a join relation, but  
its value is only needed there and not at higher levels, we neglected  
to update the joinrel's direct_lateral_relids to include the PHV's  
source rel.  This causes problems because join_is_legal() then won't  
allow joining the joinrel to the PHV's source rel at all, leading  
to "failed to build any N-way joins" planner failures.  
  
Per report from Andreas Seltenreich.  Back-patch to 9.5  
where the problem originated.  
  
Discussion: https://postgr.es/m/87blfgqa4t.fsf@aurora.ydns.eu  

commit   : 74d6fb0a037a7453693418e1069718a7f08ba31e    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 30 Nov 2020 10:26:43 +0200    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 30 Nov 2020 10:26:43 +0200    

Author: Amit Langote  
Discussion: https://www.postgresql.org/message-id/CA%2BHiwqGaRoF3XrhPW-Y7P%2BG7bKo84Z_h%3DkQHvMh-80%3Dav3wmOw%40mail.gmail.com  

commit   : 72b930f5045ee5a44e222cee1ceb76d4c341d4b3    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 29 Nov 2020 15:22:04 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 29 Nov 2020 15:22:04 -0500    

Through my misreading of what the existing code actually did,  
commits 85c54287a et al. broke psql's behavior for the case where  
"\c connstring" provides a password in the connstring.  We should  
use that password in such a case, but as of 85c54287a we ignored it  
(and instead, prompted for a password).  
  
Commit 94929f1cf fixed that in HEAD, but since I thought it was  
cleaning up a longstanding misbehavior and not one I'd just created,  
I didn't back-patch it.  
  
Hence, back-patch the portions of 94929f1cf having to do with  
password management.  In addition to fixing the introduced bug,  
this means that "\c -reuse-previous=on connstring" will allow  
re-use of an existing connection's password if the connstring  
doesn't change user/host/port.  That didn't happen before, but  
it seems like a bug fix, and anyway I'm loath to have significant  
differences in this code across versions.  
  
Also fix an error with the same root cause about whether or not to  
override a connstring's setting of client_encoding.  As of 85c54287a  
we always did so; restore the previous behavior of overriding only  
when stdin/stdout are a terminal and there's no environment setting  
of PGCLIENTENCODING.  (I find that definition a bit surprising, but  
right now doesn't seem like the time to revisit it.)  
  
Per bug #16746 from Krzysztof Gradek.  As with the previous patch,  
back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/16746-44b30e2edf4335d4@postgresql.org  

commit   : 1eb499a8a5e6aa06f5bd8d53f2119e74efdd3db7    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 29 Nov 2020 13:58:30 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 29 Nov 2020 13:58:30 -0500    

The documentation omitted the critical tidbit that a keyword-array entry  
is simply ignored if its corresponding value-array entry is NULL or an  
empty string; it will *not* override any previously-obtained value for  
the parameter.  (See conninfo_array_parse().)  I'd supposed that would  
force the setting back to default, which is what led me into bug #16746;  
but it doesn't.  
  
While here, I couldn't resist the temptation to do some copy-editing,  
both in the description of PQconnectdbParams() and in the section  
about connection URI syntax.  
  
Discussion: https://postgr.es/m/931505.1606618746@sss.pgh.pa.us  

commit   : 9a02dbdd03e8eadbe5331311c122548fac156f56    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sat, 28 Nov 2020 21:52:27 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sat, 28 Nov 2020 21:52:27 -0800    

Buildfarm member topminnow failed when the test script attempted this  
before the syslogger would have created the file.  Back-patch to v12,  
which introduced the test.  

commit   : f5de090cc175072b9ececcf48f55ffc502c06add    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 28 Nov 2020 14:03:40 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 28 Nov 2020 14:03:40 -0500    

Commit 566372b3d fixed some race conditions involving concurrent  
SimpleLruTruncate calls, but it introduced new ones in async.c.  
A newly-listening backend could attempt to read Notify SLRU pages that  
were in process of being truncated, possibly causing an error.  Also,  
the QUEUE_TAIL pointer could become set to a value that's not equal to  
the queue position of any backend.  While that's fairly harmless in  
v13 and up (thanks to commit 51004c717), in older branches it resulted  
in near-permanent disabling of the queue truncation logic, so that  
continued use of NOTIFY led to queue-fill warnings and eventual  
inability to send any more notifies.  (A server restart is enough to  
make that go away, but it's still pretty unpleasant.)  
  
The core of the problem is confusion about whether QUEUE_TAIL  
represents the "logical" tail of the queue (i.e., the oldest  
still-interesting data) or the "physical" tail (the oldest data we've  
not yet truncated away).  To fix, split that into two variables.  
QUEUE_TAIL regains its definition as the logical tail, and we  
introduce a new variable to track the oldest un-truncated page.  
  
Per report from Mikael Gustavsson.  Like the previous patch,  
back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/1b8561412e8a4f038d7a491c8b922788@smhi.se  

commit   : dcc20946a8fc192a71cedcaae25c996973747ff5    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Fri, 27 Nov 2020 20:16:44 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Fri, 27 Nov 2020 20:16:44 +0900    

Previously pg_stat_progress_cluster view reported the current block  
number in heap scan as the number of heap blocks scanned (i.e.,  
heap_blks_scanned). This reported number could be incorrect when  
synchronize_seqscans is enabled, because it allowed the heap scan to  
start at block in middle. This could result in wraparounds in the  
heap_blks_scanned column when the heap scan wrapped around.  
This commit fixes the bug by calculating the number of blocks from  
the block that the heap scan starts at to the current block in scan,  
and reporting that number in the heap_blks_scanned column.  
  
Also, in pg_stat_progress_cluster view, previously heap_blks_scanned  
could not reach heap_blks_total at the end of heap scan phase  
if the last pages scanned were empty. This commit fixes the bug by  
manually updating heap_blks_scanned to the same value as  
heap_blks_total when the heap scan phase finishes.  
  
Back-patch to v12 where pg_stat_progress_cluster view was introduced.  
  
Reported-by: Matthias van de Meent  
Author: Matthias van de Meent  
Reviewed-by: Fujii Masao  
Discussion: https://postgr.es/m/CAEze2WjCBWSGkVfYag001Rc4+-nNLDpWM7QbyD6yPvuhKs-gYQ@mail.gmail.com  

commit   : a0ef0817204dbbcb326b14071e827bf181cfa2cb    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 25 Nov 2020 16:19:25 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 25 Nov 2020 16:19:25 -0500    

Historically, psql has truncated the text of a column's default  
expression at 128 characters.  This is unlike any other behavior  
in describe.c, and it's become particularly confusing now that  
the limit is only applied to the expression proper and not to  
the "generated always as (...) stored" text that may get wrapped  
around it.  
  
Excavation in our git history suggests that the original motivation  
for this limit was not really to limit the display width (as I'd long  
supposed), but to make it safe to use a fixed-width output buffer to  
store the result.  That implementation restriction is long gone of  
course, but the limit remained.  Let's just get rid of it.  
  
While here, rearrange the logic about when to free the output string  
so that it's not so dependent on unstated assumptions about the  
possible values of attidentity and attgenerated.  
  
Per bug #16743 from David Turon.  Back-patch to v12 where GENERATED  
came in.  (Arguably we could take it back further, but I'm hesitant  
to change the behavior of long-stable branches for this.)  
  
Discussion: https://postgr.es/m/16743-7b1bacc4af76e7ad@postgresql.org  

commit   : 7ef52b5d5de42cdd7d29f6bce7d7a07a9d4c6345    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 25 Nov 2020 09:49:00 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 25 Nov 2020 09:49:00 +0100    

Author: Justin Pryzby <pryzby@telsasoft.com>  
Discussion: https://www.postgresql.org/message-id/20201121194105.GO24784@telsasoft.com  

commit   : 5f734acd70dc202a58b9de5992dd5ef401120e88    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Wed, 25 Nov 2020 09:21:33 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Wed, 25 Nov 2020 09:21:33 +0530    

Commit 5b7ba75f7f removed the unused parameter but forgot to update the  
nearby comments.  
  
Author: Li Japin  
Backpatch-through: 13, where it was introduced  
Discussion: https://postgr.es/m/0E2F62A2-B2F1-4052-83AE-F0BEC8A75789@hotmail.com  

commit   : 6dda057043df4a56683e8fa31a74737b63da4c47    
  
author   : Andrew Gierth <rhodiumtoad@postgresql.org>    
date     : Tue, 24 Nov 2020 20:58:32 +0000    
  
committer: Andrew Gierth <rhodiumtoad@postgresql.org>    
date     : Tue, 24 Nov 2020 20:58:32 +0000    

Previously this code assumed that all IndexScan nodes supported  
mark/restore, which is not true since it depends on optional index AM  
support functions. This could lead to errors about missing support  
functions in rare edge cases of mergejoins with no sort keys, where an  
unordered non-btree index scan was placed on the inner path without a  
protecting Materialize node. (Normally, the fact that merge join  
requires ordered input would avoid this error.)  
  
Backpatch all the way since this bug is ancient.  
  
Per report from Eugen Konkov on irc.  
  
Discussion: https://postgr.es/m/87o8jn50be.fsf@news-spur.riddles.org.uk  

commit   : 340ae3cfb8f38a49664c0da3ff033346e92f0450    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 20 Nov 2020 14:41:14 +0200    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 20 Nov 2020 14:41:14 +0200    

This is a backpatch of commit 2cccb627f1, backpatched due to popular  
demand. Backpatch to all supported versions.  
  
Author: Alexey Bashtanov  
Discussion: https://www.postgresql.org/message-id/36823f65-050d-ae24-aa4d-a37726998240%40imap.cc  

commit   : 9e9a31bd009663bcdd5e676d6012ee691d8944b6    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 20 Nov 2020 00:58:26 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 20 Nov 2020 00:58:26 -0500    

We previously put the -isysroot switch only into CPPFLAGS, theorizing  
that it was only needed to find the right copies of include files.  
However, it seems that we also need to use it while linking programs,  
to find the right stub ".tbd" files for libraries.  We got away  
without that up to now, but apparently that was mostly luck.  It may  
also be that failures are only observed when the Xcode version is  
noticeably out of sync with the host macOS version; the case that's  
prompting action right now is that builds fail when using latest Xcode  
(12.2) on macOS Catalina, even though it's fine on Big Sur.  
  
Hence, add -isysroot to LDFLAGS as well.  (It seems that the more  
common practice is to put it in CFLAGS, whence it'd be included at  
both compile and link steps.  However, we can't mess with CFLAGS in  
the platform template file without confusing configure's logic for  
choosing default CFLAGS.)  
  
Back-patch of 49407dc32 into all supported branches.  
  
Report and patch by James Hilliard (some cosmetic mods by me)  
  
Discussion: https://postgr.es/m/20201120003314.20560-1-james.hilliard1@gmail.com  

commit   : 98f3f1d5c1bff02a25a0af7dcf3a4676dddf58e1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 19 Nov 2020 15:03:17 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 19 Nov 2020 15:03:17 -0500    

Commit 502898192 was too careless about the order of execution of the  
additional ALTER TABLE operations generated by expandTableLikeClause.  
It just stuck them all at the end, which seems okay for most purposes.  
But it falls down in the case where LIKE is importing a primary key  
or unique index and the outer CREATE TABLE includes a FOREIGN KEY  
constraint that needs to depend on that index.  Weird as that is,  
it used to work, so we ought to keep it working.  
  
To fix, make parse_utilcmd.c insert LIKE clauses between index-creation  
and FK-creation commands in the transformed list of commands, and change  
utility.c so that the commands generated by expandTableLikeClause are  
executed immediately not at the end.  One could imagine scenarios where  
this wouldn't work either; but currently expandTableLikeClause only  
makes column default expressions, CHECK constraints, and indexes, and  
this ordering seems fine for those.  
  
Per bug #16730 from Sofoklis Papasofokli.  Like the previous patch,  
back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/16730-b902f7e6e0276b30@postgresql.org  

commit   : 95d39547d83999aff728806e36fd740ee97bd86a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 16 Nov 2020 20:32:35 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 16 Nov 2020 20:32:35 -0500    

Otherwise, if FDDEBUG is enabled, the debugging output fails because  
it tries to read the fileName, which isn't set up yet (and should in  
fact always be NULL).  
  
AFAICT, this has been wrong since Berkeley.  Before 96bf88d52,  
it would accidentally fail to crash on platforms where snprintf()  
is forgiving about being passed a NULL pointer for %s; but the  
file name intended to be included in the debug output wouldn't  
ever have shown up.  
  
Report and fix by Greg Nancarrow.  Although this is only visibly  
broken in custom-made builds, it still seems worth back-patching  
to all supported branches, as the FDDEBUG code is pretty useless  
as it stands.  
  
Discussion: https://postgr.es/m/CAJcOf-cUDgm9qYtC_B6XrC6MktMPNRby2p61EtSGZKnfotMArw@mail.gmail.com  

commit   : fea5960fafb0002ea2a80bed1dc03e3a4f85fa1d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 16 Nov 2020 16:39:59 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 16 Nov 2020 16:39:59 -0500    

Since this function is used as a CHECK constraint condition,  
returning NULL is tantamount to returning TRUE, which would have the  
effect of letting in a row that doesn't satisfy the hash condition.  
Admittedly, the cases for which this is done should be unreachable  
in practice, but that doesn't make it any less a bad idea.  It also  
seems like a dartboard was used to decide which error cases should  
throw errors as opposed to returning NULL.  
  
For the checks for NULL input values, I just switched it to returning  
false.  There's some argument that an error would be better; but the  
case really should be can't-happen in a generated hash constraint,  
so it's likely not worth more code for.  
  
For the parent-relation-open-failure case, it seems like we might  
as well let relation_open throw an error, instead of having an  
impossible-to-diagnose constraint failure.  
  
Back-patch to v11 where this code came in.  
  
Discussion: https://postgr.es/m/24067.1605134819@sss.pgh.pa.us  

commit   : 53c7b4f6221be2800ba49840ce29cb1b5c0b1ab7    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 16 Nov 2020 15:16:39 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 16 Nov 2020 15:16:39 -0500    

This was evidently missed in commit 6337865f3, which generally did  
s/TRUE/true/ everywhere.  It escaped notice up to now because ICU  
versions before ICU 68 provided definitions of "TRUE" and "FALSE"  
regardless.  With ICU 68, it fails to compile.  
  
Per report from Condor.  Back-patch to v11 where 6337865f3 came in.  
(I've not tested v10, where this call originated, but I imagine  
it's fine since we defined TRUE in c.h back then.)  
  
Discussion: https://postgr.es/m/7a6f3336165bfe3ca66abcda7966f9d0@stz-bg.com  

commit   : b7fc2593233f5bd1e651852c6d7780cef561a797    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 16 Nov 2020 13:13:43 -0500    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 16 Nov 2020 13:13:43 -0500    

This clarifies exactly what the bgwriter does, which should help with  
tuning.  
  
Reported-by: Chris Wilson  
  
Discussion: https://postgr.es/m/160399562040.7809.7335281028960123489@wrigleys.postgresql.org  
  
Backpatch-through: 9.5  

commit   : f75a7bb6c2c99d6759a823785f379691403ec9b2    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 16 Nov 2020 12:36:17 -0500    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 16 Nov 2020 12:36:17 -0500    

Followup to patch 152ed04799.  
  
Reported-by: Alvaro Herrera  
  
Discussion: https://postgr.es/m/20201112202900.GA28098@alvherre.pgsql  
  
Backpatch-through: 9.5  

commit   : d8395970ea9b46354f009b384ac9b9ff66c4410c    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 16 Nov 2020 10:26:17 -0500    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 16 Nov 2020 10:26:17 -0500    

This is a followup commit on 3370207986.  
  
Reported-by: Justin Pryzby  
  
Discussion: https://postgr.es/m/20201112211143.GL30691@telsasoft.com  
  
Backpatch-through: 9.5  

commit   : 89e0ee9a7bada0101e1dff175cd002d16a364f94    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 16 Nov 2020 10:54:11 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 16 Nov 2020 10:54:11 -0300    

Introduced in 90fdc259866e; backpatch to 12.  
  
Author: Erik Rijkers <er@xs4all.nl>  
Discussion: https://postgr.es/m/e92b3fba98a0c0f7afc0a2a37e765954@xs4all.nl  

commit   : 7c89246d0bb233be7d6670f0a8f024e99423e8cc    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 15 Nov 2020 16:10:48 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 15 Nov 2020 16:10:48 -0500    

These flags should be independent: in particular an index AM should  
be able to say that it supports include columns without necessarily  
supporting multiple key columns.  The included-columns patch got  
this wrong, possibly aided by the fact that it didn't bother to  
update the documentation.  
  
While here, clarify some text about amcanreturn, which was a little  
vague about what should happen when amcanreturn reports that only  
some of the index columns are returnable.  
  
Noted while reviewing the SP-GiST included-columns patch, which  
quite incorrectly (and unsafely) changed SP-GiST to claim  
amcanmulticol = true as a workaround for this bug.  
  
Backpatch to v11 where included columns were introduced.  

commit   : 0e0e71abdcaeb8a3887094de078b77cb35bd03ba    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 14 Nov 2020 13:09:53 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 14 Nov 2020 13:09:53 -0500    

This started with the intent to explain that range upper bounds  
are exclusive, which previously you could only find out by reading  
the CREATE TABLE man page.  But I soon found that section 5.11  
really could stand a fair amount of editorial attention.  It's  
apparently been revised several times without much concern for  
overall flow, nor careful copy-editing.  
  
Back-patch to v11, which is as far as the patch goes easily.  
  
Per gripe from Edson Richter.  Thanks to David Johnston for review.  
  
Discussion: https://postgr.es/m/DM6PR13MB3988736CF8F5DC5720440231CFE60@DM6PR13MB3988.namprd13.prod.outlook.com  

commit   : 3f93b3431f8b9539eb2147f29029de50d3d43ec7    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Thu, 12 Nov 2020 15:13:01 -0500    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Thu, 12 Nov 2020 15:13:01 -0500    

These files are in compiled directories and install directories.  
  
Reported-by: e.indrupskaya@postgrespro.ru  
  
Discussion: https://postgr.es/m/160379609706.24746.7506163279454026608@wrigleys.postgresql.org  
  
Backpatch-through: 9.5  

commit   : e4b5e5f7fdedda5092065c546a8c92bf1355464e    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Thu, 12 Nov 2020 15:00:44 -0500    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Thu, 12 Nov 2020 15:00:44 -0500    

Expression indexes can't benefit from pre-computed statistics on  
columns.  
  
Reported-by: Nikolay Samokhvalov  
  
Discussion: https://postgr.es/m/CANNMO++5rw9RDA=p40iMVbMNPaW6O=S0AFzTU=KpYHRpCd1voA@mail.gmail.com  
  
Author: Nikolay Samokhvalov, modified  
  
Backpatch-through: 9.5  

commit   : 52003bf3c4b4f7e6d6a3aeb4fff0f6aca210b3df    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Thu, 12 Nov 2020 14:33:28 -0500    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Thu, 12 Nov 2020 14:33:28 -0500    

Document that though the history file content is marked as bytea, it is  
the same a text, and neither is btyea-escaped or encoding converted.  
  
Reported-by: Brar Piening  
  
Discussion: https://postgr.es/m/6a1b9cd9-17e3-df67-be55-86102af6bdf5@gmx.de  
  
Backpatch-through: 13 - 9.5 (not master)  

commit   : 48ab1fa304fe51d563bea11f1334572a7f2832b1    
  
author   : Andrew Gierth <rhodiumtoad@postgresql.org>    
date     : Thu, 12 Nov 2020 14:34:37 +0000    
  
committer: Andrew Gierth <rhodiumtoad@postgresql.org>    
date     : Thu, 12 Nov 2020 14:34:37 +0000    

Whether from size overflow in gistSplit or from secondary splits,  
picksplit is (rarely) called with exactly two items to split.  
  
Formerly, due to special-case handling of the last item, this would  
lead to access to an uninitialized cache entry; prior to PG 13 this  
might have been harmless or at worst led to an incorrect union datum,  
but in 13 onwards it can cause a backend crash from using an  
uninitialized pointer.  
  
Repair by removing the special case, which was deemed not to have been  
appropriate anyway. Backpatch all the way, because this bug has  
existed since pg_trgm was added.  
  
Per report on IRC from user "ftzdomino". Analysis and testing by me,  
patch from Alexander Korotkov.  
  
Discussion: https://postgr.es/m/87k0usfdxg.fsf@news-spur.riddles.org.uk  

commit   : 6058f22324c8781b1914551ab4da431224c3a7dd    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Thu, 12 Nov 2020 08:55:09 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Thu, 12 Nov 2020 08:55:09 +0300    

Backpatch-through: 13  

commit   : 065683bbdbab7fe51c59a479f4136328577bbecd    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Thu, 12 Nov 2020 06:19:16 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Thu, 12 Nov 2020 06:19:16 +0300    

911e702077 has introduced the opclass parameters including signature length  
for a set of GiST opclasses.  Due to copy-pasting, macro for getting the  
signature length in trgm_gist.c was named LTREE_GET_ASIGLEN().  Fix that by  
renaming this macro to just GET_SIGLEN().  
  
Backpatch-through: 13  

commit   : 9a94b925317ec963befffaa7e5edc38a62c2b88f    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 12 Nov 2020 10:56:40 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 12 Nov 2020 10:56:40 +0900    

Attempting to take a base backup with Postgres linking to a build of  
OpenSSL with FIPS enabled currently fails with or even without a backup  
manifest requested because of this mandatory SHA256 initialization used  
for the manifest file itself.  However, there is no need to do this  
initialization at all if backup manifests are not needed because there  
is no data to append to the manifest.  
  
Note that being able to use backup manifests with OpenSSL+FIPS requires  
a switch of the SHA2 implementation to use EVP, which would cause an ABI  
breakage so this cannot be backpatched to 13 as it has been already  
released, but at least avoiding this SHA256 initialization gives users  
the possibility to take a base backup even when specifying --no-manifest  
with pg_basebackup.  
  
Author: Michael Paquier  
Discussion: https://postgr.es/m/20201110020014.GE1887@paquier.xyz  
Backpatch-through: 13  

commit   : c885e4a2f93cff543a7e0ccaaf82b8148fc53401    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Wed, 11 Nov 2020 18:37:36 +0100    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Wed, 11 Nov 2020 18:37:36 +0100    

Commit 8bf74967dab moved some of the code from brin_new_memtuple to  
brin_memtuple_initialize, but this resulted in some of the code being  
duplicate. Fix by removing the duplicate lines and backpatch to 10.  
  
Author: Tomas Vondra  
Backpatch-through: 10  
Discussion: https://postgr.es/m/5eb50c97-9a8e-b691-8c40-1b2a55611c4c%40enterprisedb.com  

commit   : afce7908d7062d94ac60fd4de5f98aaed134c2c7    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 10 Nov 2020 22:51:19 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 10 Nov 2020 22:51:19 -0500    

Introduce TimestampDifferenceMilliseconds() to simplify callers  
that would rather have the difference in milliseconds, instead of  
the select()-oriented seconds-and-microseconds format.  This gets  
rid of at least one integer division per call, and it eliminates  
some apparently-easy-to-mess-up arithmetic.  
  
Two of these call sites were in fact wrong:  
  
* pg_prewarm's autoprewarm_main() forgot to multiply the seconds  
by 1000, thus ending up with a delay 1000X shorter than intended.  
That doesn't quite make it a busy-wait, but close.  
  
* postgres_fdw's pgfdw_get_cleanup_result() thought it needed to compute  
microseconds not milliseconds, thus ending up with a delay 1000X longer  
than intended.  Somebody along the way had noticed this problem but  
misdiagnosed the cause, and imposed an ad-hoc 60-second limit rather  
than fixing the units.  This was relatively harmless in context, because  
we don't care that much about exactly how long this delay is; still,  
it's wrong.  
  
There are a few more callers of TimestampDifference() that don't  
have a direct need for seconds-and-microseconds, but can't use  
TimestampDifferenceMilliseconds() either because they do need  
microsecond precision or because they might possibly deal with  
intervals long enough to overflow 32-bit milliseconds.  It might be  
worth inventing another API to improve that, but that seems outside  
the scope of this patch; so those callers are untouched here.  
  
Given the fact that we are fixing some bugs, and the likelihood  
that future patches might want to back-patch code that uses this  
new API, back-patch to all supported branches.  
  
Alexey Kondratov and Tom Lane  
  
Discussion: https://postgr.es/m/3b1c053a21c07c1ed5e00be3b2b855ef@postgrespro.ru  

commit   : 19fd4f20b6a75058ca5be8037da529bb8cd55898    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 10 Nov 2020 19:18:35 -0500    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 10 Nov 2020 19:18:35 -0500    

Was wrong in commit 1a9388bd0f.  
  
Reported-by: Tom Lane, Justin Pryzby  
  
Discussion: https://postgr.es/m/20201102063333.GE22691@telsasoft.com  
  
Backpatch-through: 9.5  

commit   : 5c456d30807136e47ea936d67946cfada3f0e71c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 10 Nov 2020 18:32:36 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 10 Nov 2020 18:32:36 -0500    

Summarily changing the STYPE of regression-test aggregates that  
depend on array_append or array_cat is an issue for the buildfarm's  
cross-version-upgrade tests, because those aggregates (as defined  
in the back branches) now won't load into HEAD.  Although this seems  
like only a minimal risk for genuine user-defined aggregates, we  
need to do something for the buildfarm.  Hence, adjust the aggregate  
definitions, in both HEAD and the back branches.  
  
Discussion: https://postgr.es/m/1401824.1604537031@sss.pgh.pa.us  
Discussion: https://postgr.es/m/E1kaQ2c-0005lx-Eg@gemulon.postgresql.org  

commit   : 6daf725a9c66e880fd76d25279ce00710535e030    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Nov 2020 17:24:30 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Nov 2020 17:24:30 -0500    

commit   : 90cf59c8c8c66c8b0b4c719b6f7ba8fce60b87e1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Nov 2020 13:02:13 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Nov 2020 13:02:13 -0500    

Security: CVE-2020-25694, CVE-2020-25695, CVE-2020-25696  

commit   : f47841fbad8a7f6dd579db68d782857697ad25c6    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Nov 2020 12:02:24 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Nov 2020 12:02:24 -0500    

After studying the code, NULLIF is a lot more subtle than you might  
have guessed.  
  
Discussion: https://postgr.es/m/160486028730.25500.15740897403028593550@wrigleys.postgresql.org  

commit   : 67029845b08d93108d53f572e2d58334c850126f    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2020 07:32:09 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2020 07:32:09 -0800    

If an interactive psql session used \gset when querying a compromised  
server, the attacker could execute arbitrary code as the operating  
system account running psql.  Using a prefix not found among specially  
treated variables, e.g. every lowercase string, precluded the attack.  
Fix by issuing a warning and setting no variable for the column in  
question.  Users wanting the old behavior can use a prefix and then a  
meta-command like "\set HISTSIZE :prefix_HISTSIZE".  Back-patch to 9.5  
(all supported versions).  
  
Reviewed by Robert Haas.  Reported by Nick Cleaton.  
  
Security: CVE-2020-25696  

commit   : c90c84b3f797a54a40ebc6795fbd743bdf44adad    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2020 07:32:09 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Nov 2020 07:32:09 -0800    

Specifically, this blocks DECLARE ... WITH HOLD and firing of deferred  
triggers within index expressions and materialized view queries.  An  
attacker having permission to create non-temp objects in at least one  
schema could execute arbitrary SQL functions under the identity of the  
bootstrap superuser.  One can work around the vulnerability by disabling  
autovacuum and not manually running ANALYZE, CLUSTER, REINDEX, CREATE  
INDEX, VACUUM FULL, or REFRESH MATERIALIZED VIEW.  (Don't restore from  
pg_dump, since it runs some of those commands.)  Plain VACUUM (without  
FULL) is safe, and all commands are fine when a trusted user owns the  
target object.  Performance may degrade quickly under this workaround,  
however.  Back-patch to 9.5 (all supported versions).  
  
Reviewed by Robert Haas.  Reported by Etienne Stalmans.  
  
Security: CVE-2020-25695  

commit   : 62e7ae75f441e7c91f446b05f5b206fe01e34f0c    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 9 Nov 2020 12:34:05 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 9 Nov 2020 12:34:05 +0100    

Source-Git-URL: https://git.postgresql.org/git/pgtranslation/messages.git  
Source-Git-Hash: 2ffedf5ea37677f39cdc1eb92a1e78762cd3fb0e  

commit   : 7d94c017b94577548a0656b2aef7ce8be18fbc1b    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Mon, 9 Nov 2020 10:36:49 +0100    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Mon, 9 Nov 2020 10:36:49 +0100    

Appears to have been a copy/paste error in the original commit that  
moved the messages to fe_utils/.  
  
Author: Tang, Haiying <tanghy.fnst@cn.fujitsu.com>  
Backpatch-through: 13  
Discussion: https://postgr.es/m/3321cbcea76d4d2c8320a05c19b9304a@G08CNEXMBPEKD05.g08.fujitsu.local  

commit   : 213774a45b9259ea797cd6b5e1e9a74bd7d12d28    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 8 Nov 2020 15:16:12 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 8 Nov 2020 15:16:12 -0500    

commit   : 7aeb6404f0aa250e75b7156d21ebe12d0ec2d1c8    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 8 Nov 2020 13:08:36 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 8 Nov 2020 13:08:36 -0500    

This back-patches commit 20d3fe900 into the v12 and v13 branches.  
At the time I thought that commit was not fixing any observable  
bug, but Bertrand Drouvot showed otherwise: adding a dropped column  
to the previously-considered scenario crashes v12 and v13, unless the  
dropped column happens to be an integer.  That is, of course, because  
the tupdesc we derive from the plan output tlist fails to describe  
the dropped column accurately, so that we'll do the wrong thing with  
a tuple in which that column isn't NULL.  
  
There is no bug in pre-v12 branches because they already did use  
the table's real tuple descriptor for any trigger-returned tuple.  
It seems that this set of bugs can be blamed on the changes that  
removed es_trig_tuple_slot, though I've not attempted to pin that  
down precisely.  
  
Although there's no code change needed in HEAD, update the test case  
to include a dropped column there too.  
  
Discussion: https://postgr.es/m/db5d97c8-f48a-51e2-7b08-b73d5434d425@amazon.com  
Discussion: https://postgr.es/m/16644-5da7ef98a7ac4545@postgresql.org  

commit   : 5ca6f685b834518187b15926d196c5dbb086efe7    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 8 Nov 2020 07:49:07 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 8 Nov 2020 07:49:07 +0100    

fix for f3ad4fddfaf71e8f6f037cd627f398ba43625ca1  

commit   : 99f9384ea91761cdb957d051b0ca64179320b2ed    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Sat, 7 Nov 2020 19:33:43 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Sat, 7 Nov 2020 19:33:43 -0300    

* Avoid pointlessly highlighting that an index vacuum was executed by a  
  parallel worker; user doesn't care.  
  
* Don't give the impression that a non-concurrent reindex of an invalid  
  index on a TOAST table would work, because it wouldn't.  
  
* Add a "translator:" comment for a mysterious message.  
  
Discussion: https://postgr.es/m/20201107034943.GA16596@alvherre.pgsql  
Reviewed-by: Michael Paquier <michael@paquier.xyz>  

commit   : f3ad4fddfaf71e8f6f037cd627f398ba43625ca1    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 7 Nov 2020 22:15:52 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 7 Nov 2020 22:15:52 +0100    

A few client tools duplicate error messages already provided by libpq.  
  
Discussion: https://www.postgresql.org/message-id/flat/3e937641-88a1-e697-612e-99bba4b8e5e4%40enterprisedb.com  

commit   : 3459f4169ba9665fbc7965165ec4ef83170b748b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 7 Nov 2020 16:25:42 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 7 Nov 2020 16:25:42 -0500    

The buildfarm thinks this leads to memory stomps, though annoyingly  
I can't duplicate that here.  The existing code in strings.pgc is  
doing something that doesn't seem to be sanctioned at all really  
by the documentation, but I'm disinclined to try to make that nicer  
right now.  Let's just declare some more output variables in hopes  
of working around it.  

commit   : 7fb326e04b5c367f03b2ebb85348e79a722afef9    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 7 Nov 2020 15:27:36 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 7 Nov 2020 15:27:36 -0500    

Add items committed in the last 24 hours.  Also correct my failure  
to credit Nikita Glukhov for 52ad1e659, which did all the heavy  
lifting for 3db322eaa.  

commit   : 1bccb159af5813b8f34fd177acdbdb2ad82cd596    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 7 Nov 2020 15:03:44 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 7 Nov 2020 15:03:44 -0500    

These were broken in multiple ways:  
  
* The xbstart and xhstart lexer actions neglected to set  
"state_before_str_start" before transitioning to the xb/xh states,  
thus possibly resulting in "internal error: unreachable state" later.  
  
* The test for valid string contents at the end of xb state was flat out  
wrong, as it accounted incorrectly for the "b" prefix that the xbstart  
action had injected.  Meanwhile, the xh state had no such check at all.  
  
* The generated literal value failed to include any quote marks.  
  
* The grammar did the wrong thing anyway, typically ignoring the  
literal value and emitting something else, since BCONST and XCONST  
tokens were handled randomly differently from SCONST tokens.  
  
The first of these problems is evidently an oversight in commit  
7f380c59f, but the others seem to be very ancient.  The lack of  
complaints shows that ECPG users aren't using these syntaxes much  
(although I do vaguely remember one previous complaint).  
  
As written, this patch is dependent on 7f380c59f, so it can't go  
back further than v13.  Given the shortage of complaints, I'm not  
excited about adapting the patch to prior branches.  
  
Report and patch by Shenhao Wang (test case adjusted by me)  
  
Discussion: https://postgr.es/m/d6402f1bacb74ecba22ef715dbba17fd@G08CNEXMBPEKD06.g08.fujitsu.local  

commit   : d94d37f8c0c77cf1b9c5ae924bb6cfc12f4bc692    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 6 Nov 2020 22:52:15 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 6 Nov 2020 22:52:15 -0300    

The list of indexes was being leaked when asked for an index that  
doesn't have an index partition in the table partition.  Not a common  
case admittedly --and in most cases where it occurs, caller throws an  
error anyway-- but worth fixing for cleanliness and in case any  
third-party code is calling this function.  
  
While at it, remove use of lfirst_oid() to obtain a value we already  
have.  
  
Author: Justin Pryzby <pryzby@telsasoft.com>  
Reviewed-by: Michael Paquier <michael@paquier.xyz>  
Discussion: https://postgr.es/m/20201105203606.GF22691@telsasoft.com  

commit   : 6a7b55f3716fad9c40ecb960cb7b7d616d5b02fd    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Sat, 7 Nov 2020 00:40:06 +0100    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Sat, 7 Nov 2020 00:40:06 +0100    

brin_form_tuple failed to consider the values may be toasted, inserting  
the toast pointer into the index. This may easily result in index  
corruption, as the toast data may be deleted and cleaned up by vacuum.  
The cleanup however does not care about indexes, leaving invalid toast  
pointers behind, which triggers errors like this:  
  
  ERROR:  missing chunk number 0 for toast value 16433 in pg_toast_16426  
  
A less severe consequence are inconsistent failures due to the index row  
being too large, depending on whether brin_form_tuple operated on plain  
or toasted version of the row. For example  
  
    CREATE TABLE t (val TEXT);  
    INSERT INTO t VALUES ('... long value ...')  
    CREATE INDEX idx ON t USING brin (val);  
  
would likely succeed, as the row would likely include toast pointer.  
Switching the order of INSERT and CREATE INDEX would likely fail:  
  
    ERROR:  index row size 8712 exceeds maximum 8152 for index "idx"  
  
because this happens before the row values are toasted.  
  
The bug exists since PostgreSQL 9.5 where BRIN indexes were introduced.  
So backpatch all the way back.  
  
Author: Tomas Vondra  
Reviewed-by: Alvaro Herrera  
Backpatch-through: 9.5  
Discussion: https://postgr.es/m/20201001184133.oq5uq75sb45pu3aw@development  
Discussion: https://postgr.es/m/20201104010544.zexj52mlldagzowv%40development  

commit   : c66a3225e07b5098a796f24588a6b81bfdedd2fd    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 6 Nov 2020 17:05:43 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 6 Nov 2020 17:05:43 -0500    

As usual, the release notes for other branches will be made by cutting  
these down, but put them up for community review first.  
  
Also as usual for a .1 release, there are some entries here that  
are not really relevant for v13 because they already appeared in 13.0.  
Those'll be removed later.  

commit   : 4352c2394a547e5797c512cbaf0d0b7ca824747a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 6 Nov 2020 16:17:56 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 6 Nov 2020 16:17:56 -0500    

Revert 59ab4ac32, as well as the followup fix 33862cb9c, in all  
branches.  We need to think a bit harder about what the behavior  
of LOCK TABLE on views should be, and there's no time for that  
before next week's releases.  We'll take another crack at this  
later.  
  
Discussion: https://postgr.es/m/16703-e348f58aab3cf6cc@postgresql.org  

commit   : fa3840c8800f290b8352c5c81714a4439d2e1f46    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 6 Nov 2020 15:48:21 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 6 Nov 2020 15:48:21 -0500    

Revert 403a3d91c, as well as the followup fix 7f4235032, in all  
branches.  We need to think a bit harder about what the behavior  
of LOCK TABLE on views should be, and there's no time for that  
before next week's releases.  We'll take another crack at this  
later.  
  
Discussion: https://postgr.es/m/16703-e348f58aab3cf6cc@postgresql.org  

commit   : 44b973b91029cb5aecf09d589bdf3f05cfddaa60    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 5 Nov 2020 11:44:32 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 5 Nov 2020 11:44:32 -0500    

LOCK TABLE has complained about "infinite recursion" when applied  
to a self-referential view, ever since we made it recurse into views  
in v11.  However, that breaks pg_dump's new assumption that it's  
okay to lock every relation.  There doesn't seem to be any good  
reason to throw an error: if we just abandon the recursion, we've  
still satisfied the requirement of locking every referenced relation.  
  
Per bug #16703 from Andrew Bille (via Alexander Lakhin).  
  
Discussion: https://postgr.es/m/16703-e348f58aab3cf6cc@postgresql.org  

commit   : 02c9386ca4f706364904be2720e2d09916e2b619    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Wed, 4 Nov 2020 18:42:24 -0800    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Wed, 4 Nov 2020 18:42:24 -0800    

Logic for counting heap TIDs from posting list tuples (added by commit  
0d861bbb) was faulty.  It didn't count any TIDs/index tuples in the  
event of no callback being set.  This meant that we incorrectly counted  
no index tuples in clean-up only VACUUMs, which could lead to  
pg_class.reltuples being spuriously set to 0 in affected indexes.  
  
To fix, go back to counting items from the page in cases where there is  
no callback.  This approach isn't very accurate, but it works well  
enough in practice while avoiding the expense of accessing every index  
tuple during cleanup-only VACUUMs.  
  
Author: Peter Geoghegan <pg@bowt.ie>  
Reported-By: Jehan-Guillaume de Rorthais <jgdr@dalibo.com>  
https://postgr.es/m/20201023174451.69e358f1@firost  
Backpatch: 13-, where nbtree deduplication was introduced  

commit   : 82d4a2a7d63e79f6a6724f366cfaa4beed6b8326    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 4 Nov 2020 07:47:06 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 4 Nov 2020 07:47:06 +0100    

hash_array_extended() needs to pass PG_GET_COLLATION() to the hash  
function of the element type.  Otherwise, the hash function of a  
collation-aware data type such as text will error out, since the  
introduction of nondeterministic collation made hash functions require  
a collation, too.  
  
The consequence of this is that before this change, hash partitioning  
using an array over text in the partition key would not work.  
  
Reviewed-by: Heikki Linnakangas <hlinnaka@iki.fi>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Reviewed-by: Michael Paquier <michael@paquier.xyz>  
Discussion: https://www.postgresql.org/message-id/flat/32c1fdae-95c6-5dc6-058a-a90330a3b621%40enterprisedb.com  

commit   : 7d39586a59c6f5816a068bd38e1e4887d4c984ff    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Tue, 3 Nov 2020 20:43:12 +0100    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Tue, 3 Nov 2020 20:43:12 +0100    

Commit 6ee3b5fb99 cleaned up most of the long/int64 confusion related to  
incremental sort, but the sort debug messages were still using %ld for  
int64 variables. So fix that.  
  
Author: Haiying Tang  
Backpatch-through: 13, where the incremental sort code was added  
Discussion: https://postgr.es/m/4250be9d350c4992abb722a76e288aef%40G08CNEXMBPEKD05.g08.fujitsu.local  

commit   : 2d26c4ac703447a002a02124c1edd01e70a5d1ee    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Tue, 3 Nov 2020 20:07:23 +0100    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Tue, 3 Nov 2020 20:07:23 +0100    

When considering Incremental Sort below a Gather Merge, we need to be  
a bit more careful when matching pathkeys to EC members. It's not enough  
to find a member whose Vars are all in the current relation's target;  
volatile expressions in particular need to be contained in the target,  
otherwise it's too early to use the pathkey.  
  
Reported-by: Jaime Casanova  
Author: James Coleman  
Reviewed-by: Tomas Vondra  
Backpatch-through: 13, where the incremental sort code was added  
Discussion: https://postgr.es/m/CAJGNTeNaxpXgBVcRhJX%2B2vSbq%2BF2kJqGBcvompmpvXb7pq%2BoFA%40mail.gmail.com  

commit   : 936043c9eacb9e9c7356a8190a410d2c4e4ea03a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 3 Nov 2020 16:16:36 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 3 Nov 2020 16:16:36 -0500    

If the planner erroneously puts a non-parallel-safe SubPlan into  
a parallelized portion of the query tree, nodeSubplan.c will fail  
in the worker processes because it finds a null in es_subplanstates,  
which it's unable to cope with.  It seems worth a test-and-elog to  
make that an error case rather than a core dump case.  
  
This probably should have been included in commit 16ebab688, which  
was responsible for allowing nulls to appear in es_subplanstates  
to begin with.  So, back-patch to v10 where that came in.  
  
Discussion: https://postgr.es/m/924226.1604422326@sss.pgh.pa.us  

commit   : 768dbef0d49826c2e404ceb1567b3cc9e2bbc30a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 3 Nov 2020 15:41:32 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 3 Nov 2020 15:41:32 -0500    

The intention in commit 491c029db was to require superuserness to  
change the BYPASSRLS property, but the actual effect of the coding  
in AlterRole() was to require superuserness to change anything at all  
about a BYPASSRLS role.  Other properties of a BYPASSRLS role should  
be changeable under the same rules as for a normal role, though.  
  
Fix that, and also take care of some documentation omissions related  
to BYPASSRLS and REPLICATION role properties.  
  
Tom Lane and Stephen Frost, per bug report from Wolfgang Walther.  
Back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/a5548a9f-89ee-3167-129d-162b5985fcf8@technowledgy.de  

commit   : 53977598174652dcb06bc2b26674c29b9ae601cc    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 3 Nov 2020 15:14:50 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 3 Nov 2020 15:14:50 +0100    

The current implementation cannot handle this correctly, so just  
forbid it for now.  
  
GENERATED clauses must be attached to the column definition and cannot  
be added later like DEFAULT, so if a child table has a generation  
expression that the parent does not have, the child column will  
necessarily be an attlocal column.  So to implement ALTER TABLE ONLY /  
DROP EXPRESSION, we'd need extra code to update attislocal of the  
direct child tables, somewhat similar to how DROP COLUMN does it, so  
that the resulting state can be properly dumped and restored.  
  
Discussion: https://www.postgresql.org/message-id/flat/15830.1575468847%40sss.pgh.pa.us  

commit   : a58a631b4af0c027c07ea7cc4110a60b5f279ddf    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 2 Nov 2020 21:11:50 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 2 Nov 2020 21:11:50 -0500    

fill_hba_line() thought it could get away with passing sizeof(struct  
sockaddr_storage) rather than the actual addrlen previously returned  
by getaddrinfo().  While that appears to work on many platforms,  
it does not work on FreeBSD 11: you get back a failure, which leads  
to the view showing NULL for the address and netmask columns in all  
rows.  The POSIX spec for getnameinfo() is pretty clearly on  
FreeBSD's side here: you should pass the actual address length.  
So it seems plausible that there are other platforms where this  
coding also fails, and we just hadn't noticed.  
  
Also, IMO the fact that getnameinfo() failure leads to a NULL output  
is pretty bogus in itself.  Our pg_getnameinfo_all() wrapper is  
careful to emit "???" on failure, and we should use that in such  
cases.  NULL should only be emitted in rows that don't have IP  
addresses.  
  
Per bug #16695 from Peter Vandivier.  Back-patch to v10 where this  
code was added.  
  
Discussion: https://postgr.es/m/16695-a665558e2f630be7@postgresql.org  

commit   : 7957e75c588c0b17210d4379afb50ea2673b0d20    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 2 Nov 2020 11:25:18 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 2 Nov 2020 11:25:18 -0500    

On detecting a corrupted match tag, pglz_decompress() should just  
summarily return -1.  Breaking out of the loop, as I did in dfc797730,  
doesn't quite guarantee that will happen.  Also, we can use  
unlikely() on that check, just in case it helps.  
  
Backpatch to v13, like the previous patch.  

commit   : 57fae192f8f7d094159c913f10fcfd11cd827332    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Mon, 2 Nov 2020 15:20:19 +0100    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Mon, 2 Nov 2020 15:20:19 +0100    

commit   : 796885a0713374f7bdcc3edec136e0527fcafafa    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 2 Nov 2020 15:15:20 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 2 Nov 2020 15:15:20 +0900    

The documentation fixes are backpatched down to where they apply.  
  
Author: Justin Pryzby  
Discussion: https://postgr.es/m/20201031020801.GD3080@telsasoft.com  
Backpatch-through: 9.6  

commit   : 017e78a3edc261143c7d791cafca5a5ad326a679    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 2 Nov 2020 10:41:23 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 2 Nov 2020 10:41:23 +0900    

This is useful for checks of relation pages without having to load the  
pages into the shared buffers, and two cases can make use of that: page  
verification in base backups and the online, lock-safe, flavor.  
  
Compatibility is kept with past versions using a routine that calls the  
new extended routine with the set of options compatible with the  
original version.  Contrary to d401c576, a macro cannot be used as there  
may be external code relying on the presence of the original routine.  
  
This is applied down to 11, where this will be used by a follow-up  
commit addressing a set of issues with page verification in base  
backups.  
  
Extracted from a larger patch by the same author.  
  
Author: Anastasia Lubennikova  
Reviewed-by: Michael Paquier, Julien Rouhaud  
Discussion: https://postgr.es/m/608f3476-0598-2514-2c03-e05c7d2b0cbd@postgrespro.ru  
Backpatch-through: 11  

commit   : 2330f4d3a87ac43b6ecd31bfd698384888ed03cb    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 1 Nov 2020 18:38:42 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 1 Nov 2020 18:38:42 -0500    

pglz_maximum_compressed_size() potentially underestimated the amount  
of compressed data required to produce N bytes of decompressed data;  
this is a fault in commit 11a078cf8.  
  
Separately from that, pglz_decompress() failed to protect itself  
against corrupt compressed data, particularly off == 0 in a match  
tag.  Commit c60e520f6 turned such a situation into an infinite loop,  
where before it'd just have resulted in garbage output.  
  
The combination of these two bugs seems like it may explain bug #16694  
from Tom Vijlbrief, though it's impossible to be quite sure without  
direct inspection of the failing session.  (One needs to assume that  
the pglz_maximum_compressed_size() bug caused us to fail to fetch the  
second byte of a match tag, and what happened to be there instead was  
a zero.  The reported infinite loop is hard to explain without off == 0,  
though.)  
  
Aside from fixing the bugs, rewrite associated comments for more  
clarity.  
  
Back-patch to v13 where both these commits landed.  
  
Discussion: https://postgr.es/m/16694-f107871e499ec114@postgresql.org  

commit   : 0041941f5bbe48ff3a05942efc6aa65f4f389efc    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 1 Nov 2020 11:26:16 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 1 Nov 2020 11:26:16 -0500    

Although error results received from the backend should always have  
a SQLSTATE field, ones generated by libpq won't, making this code  
vulnerable to a crash after, say, untimely loss of connection.  
Noted by Coverity.  
  
Oversight in commit 403a3d91c.  Back-patch to 9.5, as that was.  

commit   : bb62df46bcaa109d5eb1907392034024dde0886e    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sun, 1 Nov 2020 21:24:10 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sun, 1 Nov 2020 21:24:10 +0900    

Statistics associated to an index got lost after running REINDEX  
CONCURRENTLY, while the non-concurrent case preserves these correctly.  
The concurrent and non-concurrent operations need to be consistent for  
the end-user, and missing statistics would force to wait for a new  
analyze to happen, which could take some time depending on the activity  
of the existing autovacuum workers.  This issue is fixed by copying any  
existing entries in pg_statistic associated to the old index to the new  
one.  Note that this copy is already done with the data of the index in  
the stats collector.  
  
Reported-by: Fabrízio de Royes Mello  
Author: Michael Paquier, Fabrízio de Royes Mello  
Reviewed-by: Justin Pryzby  
Discussion: https://postgr.es/m/CAFcNs+qpFPmiHd1oTXvcPdvAHicJDA9qBUSujgAhUMJyUMb+SA@mail.gmail.com  
Backpatch-through: 12  

commit   : ab2e2ce466683b6af5ec956106cd905380d3d349    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sat, 31 Oct 2020 08:43:28 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sat, 31 Oct 2020 08:43:28 -0700    

Certain background workers initiate parallel queries while  
debug_query_string==NULL, at which point they attempted strlen(NULL) and  
died to SIGSEGV.  Older debug_query_string observers allow NULL, so do  
likewise in these newer ones.  Back-patch to v11, where commit  
7de4a1bcc56f494acbd0d6e70781df877dc8ecb5 introduced the first of these.  
  
Discussion: https://postgr.es/m/20201014022636.GA1962668@rfd.leadboat.com  

commit   : ee03baad267dd83fa66a0ca4c1a7635f549fc1a6    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 29 Oct 2020 15:28:14 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 29 Oct 2020 15:28:14 -0400    

The timetz test cases I added in commit a9632830b were unintentionally  
sensitive to whether or not DST is active in the PST8PDT time zone.  
Thus, they'll start failing this coming weekend, as reported by  
Bernhard M. Wiedemann in bug #16689.  Fortunately, DST-awareness is  
not significant to the purpose of these test cases, so we can just  
force them all to PDT (DST hours) to preserve stability of the  
results.  
  
Back-patch to v10, as the prior patch was.  
  
Discussion: https://postgr.es/m/16689-57701daa23b377bf@postgresql.org  

commit   : ba4f5413e357faac2f33cd5d22db2a21c0be7727    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 28 Oct 2020 14:35:53 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 28 Oct 2020 14:35:53 -0400    

In almost all other places, we use plain "r" or "w" mode in popen()  
calls (the exceptions being for COPY data).  This one has been  
overlooked (possibly because it's buried in a ".l" flex file?),  
but it's using PG_BINARY_R.  
  
Kensuke Okamura complained in bug #16688 that we fail to strip \r  
when stripping the trailing newline from a backtick result string.  
That's true enough, but we'd also fail to convert embedded \r\n  
cleanly, which also seems undesirable.  Fixing the popen() mode  
seems like the best way to deal with this.  
  
It's been like this for a long time, so back-patch to all supported  
branches.  
  
Discussion: https://postgr.es/m/16688-c649c7b69cd7e6f8@postgresql.org  

commit   : 70492195be5e0283cf134c3c531ca0a23fdf9919    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 28 Oct 2020 13:47:02 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 28 Oct 2020 13:47:02 -0400    

It's unsafe to do this at parse time because addition of generated  
columns to a table would not invalidate stored rules containing  
UPDATEs on the table ... but there might now be dependent generated  
columns that were not there when the rule was made.  This also fixes  
an oversight that rewriteTargetView failed to update extraUpdatedCols  
when transforming an UPDATE on an updatable view.  (Since the new  
calculation is downstream of that, rewriteTargetView doesn't actually  
need to do anything; but before, there was a demonstrable bug there.)  
  
In v13 and HEAD, this leads to easily-visible bugs because (since  
commit c6679e4fc) we won't recalculate generated columns that aren't  
listed in extraUpdatedCols.  In v12 this bitmap is mostly just used  
for trigger-firing decisions, so you'd only notice a problem if a  
trigger cared whether a generated column had been updated.  
  
I'd complained about this back in May, but then forgot about it  
until bug #16671 from Michael Paul Killian revived the issue.  
  
Back-patch to v12 where this field was introduced.  If existing  
stored rules contain any extraUpdatedCols values, they'll be  
ignored because the rewriter will overwrite them, so the bug will  
be fixed even for existing rules.  (But note that if someone were  
to update to 13.1 or 12.5, store some rules with UPDATEs on tables  
having generated columns, and then downgrade to a prior minor version,  
they might observe issues similar to what this patch fixes.  That  
seems unlikely enough to not be worth going to a lot of effort to fix.)  
  
Discussion: https://postgr.es/m/10206.1588964727@sss.pgh.pa.us  
Discussion: https://postgr.es/m/16671-2fa55851859fb166@postgresql.org  

commit   : b4395cc87ed5c49e0b9bfd0770383d4086fd9f12    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 27 Oct 2020 14:00:38 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 27 Oct 2020 14:00:38 -0400    

You can't compile thread_test alone anymore, and the location moved too.  
  
Reported-by: Tom Lane  
  
Discussion: https://postgr.es/m/1062278.1603819969@sss.pgh.pa.us  
  
Backpatch-through: 9.5  

commit   : 64fc3e03495162154797f7d01e871462b1f42979    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 27 Oct 2020 14:31:37 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 27 Oct 2020 14:31:37 -0300    

Now that LOCK TABLE can take any relation type, acquire lock on all  
relations that are to be dumped.  This prevents schema changes or  
deadlock errors that could cause a dump to fail after expending much  
effort.  The server is tested to have the capability and the feature  
disabled if it doesn't, so that a patched pg_dump doesn't fail when  
connecting to an unpatched server.  
  
Backpatch to 9.5.  
  
Author: Álvaro Herrera <alvherre@alvh.no-ip.org>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Reported-by: Wells Oliver <wells.oliver@gmail.com>  
Discussion: https://postgr.es/m/20201021200659.GA32358@alvherre.pgsql  

commit   : 272bff6a35ef85b0226ac536c58ca24881c3c8d2    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 27 Oct 2020 13:49:19 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 27 Oct 2020 13:49:19 -0300    

The restriction that only tables and views can be locked by LOCK TABLE  
is quite arbitrary, since the underlying mechanism can lock any relation  
type.  Drop the restriction so that programs such as pg_dump can lock  
all relations they're interested in, preventing schema changes that  
could cause a dump to fail after expending much effort.  
  
Backpatch to 9.5.  
  
Author: Álvaro Herrera <alvherre@alvh.no-ip.org>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Reported-by: Wells Oliver <wells.oliver@gmail.com>  
Discussion: https://postgr.es/m/20201021200659.GA32358@alvherre.pgsql  

commit   : d04c4a8f7066bdac71d012fa868ba9d84538632e    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 27 Oct 2020 12:43:11 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 27 Oct 2020 12:43:11 -0400    

This directory and the ability to build the thread test independently  
were removed in commit 8a2121185b.  
  
Reported-by: e.indrupskaya@postgrespro.ru  
  
Discussion: https://postgr.es/m/160379609706.24746.7506163279454026608@wrigleys.postgresql.org  
  
Backpatch-through: 9.5  

commit   : a645c08838d6d4ae55ac4df57cfd91f0b9e4f812    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 26 Oct 2020 22:38:11 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 26 Oct 2020 22:38:11 -0400    

Reported-by: bob.henkel@gmail.com  
  
Discussion: https://postgr.es/m/160324449781.693.8298142858847611071@wrigleys.postgresql.org  
  
Backpatch-through: 9.5  

commit   : 4747655111b0bae6e45729ee4b06156ea6c40a77    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 26 Oct 2020 19:17:05 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 26 Oct 2020 19:17:05 -0400    

Parallel execution changed the way bloom queries are executed, so update  
the EXPLAIN output, and restructure the docs to be clearer and more  
accurate.  
  
Reported-by: Daniel Westermann  
  
Discussion: https://postgr.es/m/ZR0P278MB0122119FAE78721A694C30C8D2340@ZR0P278MB0122.CHEP278.PROD.OUTLOOK.COM  
  
Author: Daniel Westermann and me  
  
Backpatch-through: 9.6  

commit   : d88d8ad28484a745fffe036a4085f4674b3064bc    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 25 Oct 2020 13:57:46 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 25 Oct 2020 13:57:46 -0400    

If the old row has any "missing" attributes that are supposed to  
be retrieved from an associated tuple descriptor, the wrong things  
happened because the trigger result is shoved directly into an  
executor slot that lacks the missing-attribute data.  Notably,  
CHECK-constraint verification would incorrectly see those columns  
as NULL, and so would RETURNING-list evaluation.  
  
Band-aid around this by forcibly expanding the tuple before passing  
it to the trigger function.  (IMO it was a fundamental misdesign to  
put the missing-attribute data into tuple constraints, which so  
much of the system considers to be optional.  But we're probably  
stuck with that now, and will have to continue to apply band-aids  
as we find other places with similar issues.)  
  
Back-patch to v12.  v11 would also have the issue, except that  
commit 920311ab1 already applied a similar band-aid.  That forced  
expansion in more cases than seem really necessary, though, so  
this isn't a directly equivalent fix.  
  
Amit Langote, with some cosmetic changes by me  
  
Discussion: https://postgr.es/m/16644-5da7ef98a7ac4545@postgresql.org  

commit   : 563973bf066893b9386c1d026433708797361575    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Sun, 25 Oct 2020 22:39:00 +1300    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Sun, 25 Oct 2020 22:39:00 +1300    

Author: Zhijie Hou  
Discussion: https://postgr.es/m/14cd74ea00204cc8a7ea5d738ac82cd1@G08CNEXMBPEKD05.g08.fujitsu.local  
Backpatch-through: 12, where the mistake was introduced  

commit   : fd048e0cb5aa45ef67b5b2b0446f4b1b6bdefbf3    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 24 Oct 2020 13:12:08 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 24 Oct 2020 13:12:08 -0400    

We must not set the "done" flag until after we've executed the  
initialization function.  Otherwise, other threads can fall through  
the initial unlocked test before initialization is really complete.  
  
This has been seen to cause rare failures of ecpg's thread/descriptor  
test, and it could presumably cause other sorts of misbehavior in  
threaded ECPG-using applications, since ecpglib relies on  
pthread_once() in several places.  
  
Diagnosis and patch by me, based on investigation by Alexander Lakhin.  
Back-patch to all supported branches (the bug dates to 2007).  
  
Discussion: https://postgr.es/m/16685-d6cd241872c101d3@postgresql.org  

commit   : e4538708d58400c8c0336ebabca0b7bdb72e0ff6    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 23 Oct 2020 11:32:33 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 23 Oct 2020 11:32:33 -0400    

The ExplainCloseGroup arguments for incremental sort usage data  
didn't match the corresponding ExplainOpenGroup.  This only matters  
for XML-format output, which is probably why we'd not noticed.  
  
Daniel Gustafsson, per bug #16683 from Frits Jalvingh  
  
Discussion: https://postgr.es/m/16683-8005033324ad34e9@postgresql.org  

commit   : 96ed2ae9360d9b89f695f00c2b6417c4e4d9fcba    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 22 Oct 2020 21:23:47 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 22 Oct 2020 21:23:47 -0400    

DST law changes in Palestine, with a whopping 120 hours' notice.  
Also some historical corrections for Palestine.  

commit   : 0e551533b46069ec3b909ce5159eed51b768ca52    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 22 Oct 2020 21:15:22 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 22 Oct 2020 21:15:22 -0400    

There's no functional change at all here, but I'm curious to see  
whether this change successfully shuts up Coverity's warning about  
a useless strcmp(), which appeared with the previous update.  
  
Discussion: http://mm.icann.org/pipermail/tz/2020-October/029370.html  

commit   : 2e4af411075c10c5007eb09bcb67abf7f825572d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 21 Oct 2020 16:18:40 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 21 Oct 2020 16:18:40 -0400    

psql's \connect claims to be able to re-use previous connection  
parameters, but in fact it only re-uses the database name, user name,  
host name (and possibly hostaddr, depending on version), and port.  
This is problematic for assorted use cases.  Notably, pg_dump[all]  
emits "\connect databasename" commands which we would like to have  
re-use all other parameters.  If such a script is loaded in a psql run  
that initially had "-d connstring" with some non-default parameters,  
those other parameters would be lost, potentially causing connection  
failure.  (Thus, this is the same kind of bug addressed in commits  
a45bc8a4f and 8e5793ab6, although the details are much different.)  
  
To fix, redesign do_connect() so that it pulls out all properties  
of the old PGconn using PQconninfo(), and then replaces individual  
properties in that array.  In the case where we don't wish to re-use  
anything, get libpq's default settings using PQconndefaults() and  
replace entries in that, so that we don't need different code paths  
for the two cases.  
  
This does result in an additional behavioral change for cases where  
the original connection parameters allowed multiple hosts, say  
"psql -h host1,host2", and the \connect request allows re-use of the  
host setting.  Because the previous coding relied on PQhost(), it  
would only permit reconnection to the same host originally selected.  
Although one can think of scenarios where that's a good thing, there  
are others where it is not.  Moreover, that behavior doesn't seem to  
meet the principle of least surprise, nor was it documented; nor is  
it even clear it was intended, since that coding long pre-dates the  
addition of multi-host support to libpq.  Hence, this patch is content  
to drop it and re-use the host list as given.  
  
Per Peter Eisentraut's comments on bug #16604.  Back-patch to all  
supported branches.  
  
Discussion: https://postgr.es/m/16604-933f4b8791227b15@postgresql.org  

commit   : ddc728d437a08c68638101ef01d742d6f4476675    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 21 Oct 2020 14:37:26 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 21 Oct 2020 14:37:26 -0300    

Should cause tests to be a bit faster  

commit   : 5f6463a20af183db10d372f16ddeb5690a92aa1b    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 20 Oct 2020 19:22:09 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 20 Oct 2020 19:22:09 -0300    

More precisely, correctly handle the ONLY flag indicating not to  
recurse.  This was implemented in 86f575948c77 by recursing in  
trigger.c, but that's the wrong place; use ATSimpleRecursion instead,  
which behaves properly.  However, because legacy inheritance has never  
recursed in that situation, make sure to do that only for new-style  
partitioning.  
  
I noticed this problem while testing a fix for another bug in the  
vicinity.  
  
This has been wrong all along, so backpatch to 11.  
  
Discussion: https://postgr.es/m/20201016235925.GA29829@alvherre.pgsql  

commit   : 1f53d0b9f45521a85e85b6dcab7c15a7d8b4b973    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 19 Oct 2020 08:52:25 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 19 Oct 2020 08:52:25 +0200    

In shm_mq_receive(), a huge payload could trigger an unjustified  
"invalid memory alloc request size" error due to the way the buffer  
size is increased.  
  
Add error checks (documenting the upper limit) and avoid the error by  
limiting the allocation size to MaxAllocSize.  
  
Author: Markus Wanner <markus.wanner@2ndquadrant.com>  
Discussion: https://www.postgresql.org/message-id/flat/3bb363e7-ac04-0ac4-9fe8-db1148755bfa%402ndquadrant.com  

commit   : 0a1377760bcdfe837ea5f602a800ea97c668bf16    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Tue, 20 Oct 2020 08:31:43 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Tue, 20 Oct 2020 08:31:43 +0530    

In v13, the id for max_parallel_maintenance_workers is defined differently  
as compared to HEAD in docs, so adjust the docs accordingly.  
  
Reported-by: Magnus Hagander and Tom Lane  
Discussion: https://postgr.es/m/CABUevEyAFQZ_jvjY_KtRUWbci4YMyQC1QAMzDQAbLs=XCo3m5Q@mail.gmail.com  

commit   : 1814f915b526d5022b3e2a6ce4ea3bcbe59abe2c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 19 Oct 2020 19:03:46 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 19 Oct 2020 19:03:46 -0400    

When told to process all databases, clusterdb, reindexdb, and vacuumdb  
would reconnect by replacing their --maintenance-db parameter with the  
name of the target database.  If that parameter is a connstring (which  
has been allowed for a long time, though we failed to document that  
before this patch), we'd lose any other options it might specify, for  
example SSL or GSS parameters, possibly resulting in failure to connect.  
Thus, this is the same bug as commit a45bc8a4f fixed in pg_dump and  
pg_restore.  We can fix it in the same way, by using libpq's rules for  
handling multiple "dbname" parameters to add the target database name  
separately.  I chose to apply the same refactoring approach as in that  
patch, with a struct to handle the command line parameters that need to  
be passed through to connectDatabase.  (Maybe someday we can unify the  
very similar functions here and in pg_dump/pg_restore.)  
  
Per Peter Eisentraut's comments on bug #16604.  Back-patch to all  
supported branches.  
  
Discussion: https://postgr.es/m/16604-933f4b8791227b15@postgresql.org  

commit   : 25378db74fd97f2b10ad44d1f0b2e1f8b0a651f2    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 19 Oct 2020 14:33:02 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 19 Oct 2020 14:33:02 -0400    

Since commit 913bbd88d, check_sql_fn_retval() can either insert type  
coercion steps in-line in the Query that produces the SQL function's  
results, or generate a new top-level Query to perform the coercions,  
if modifying the Query's output in-place wouldn't be safe.  However,  
it appears that the latter case has never actually worked, because  
the code tried to inject the new Query back into the query list it was  
passed ... which is not the list that will be used for later processing  
when we execute the SQL function "normally" (without inlining it).  
So we ended up with no coercion happening at run-time, leading to  
wrong results or crashes depending on the datatypes involved.  
  
While the regression tests look like they cover this area well enough,  
through a huge bit of bad luck all the test cases that exercise the  
separate-Query path were checking either inline-able cases (which  
accidentally didn't have the bug) or cases that are no-ops at runtime  
(e.g., varchar to text), so that the failure to perform the coercion  
wasn't obvious.  The fact that the cases that don't work weren't  
allowed at all before v13 probably contributed to not noticing the  
problem sooner, too.  
  
To fix, get rid of the separate "flat" list of Query nodes and instead  
pass the real two-level list that is going to be used later.  I chose  
to make the same change in check_sql_fn_statements(), although that has  
no actual bug, just so that we don't need that data structure at all.  
  
This is an API change, as evidenced by the adjustments needed to  
callers outside functions.c.  That's a bit scary to be doing in a  
released branch, but so far as I can tell from a quick search,  
there are no outside callers of these functions (and they are  
sufficiently specific to our semantics for SQL-language functions that  
it's not apparent why any extension would need to call them).  In any  
case, v13 already changed the API of check_sql_fn_retval() compared to  
prior branches.  
  
Per report from pinker.  Back-patch to v13 where this code came in.  
  
Discussion: https://postgr.es/m/1603050466566-0.post@n3.nabble.com  

commit   : 33acc6bc8795d8e3c2802c78e17e57a75a143904    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 19 Oct 2020 19:28:54 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 19 Oct 2020 19:28:54 +0300    

- Misc grammar and punctuation fixes.  
  
- Stylistic cleanup: use spaces between function arguments and JSON fields  
  in examples. For example "foo(a,b)" -> "foo(a, b)". Add semicolon after  
  last END in a few PL/pgSQL examples that were missing them.  
  
- Make sentence that talked about "..." and ".." operators more clear,  
  by avoiding to end the sentence with "..". That makes it look the same  
  as "..."  
  
- Fix syntax description for HAVING: HAVING conditions cannot be repeated  
  
Patch by Justin Pryzby, per Yaroslav Schekin's report. Backpatch to all  
supported versions, to the extent that the patch applies easily.  
  
Discussion: https://www.postgresql.org/message-id/20201005191922.GE17626%40telsasoft.com  

commit   : 3b5bf7b893fc70d298881cff14f7f0c82d8fee34    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 19 Oct 2020 19:02:25 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 19 Oct 2020 19:02:25 +0300    

ALTER SEQUENCE RESTART was made transactional in commit 3d79013b97.  
Backpatch to v10, where that was introduced.  
  
Patch by Justin Pryzby, per Yaroslav Schekin's report.  
  
Discussion: https://www.postgresql.org/message-id/20201005191922.GE17626%40telsasoft.com  

commit   : f0b3d3bb89ae34281edc49de24f865af85671a37    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 19 Oct 2020 18:50:33 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 19 Oct 2020 18:50:33 +0300    

The output for this query changed in commit 4e2477b7b8. Backport to 9.6  
like that commit.  
  
Patch by Justin Pryzby, per Yaroslav Schekin's report.  
  
Discussion: https://www.postgresql.org/message-id/20201005191922.GE17626%40telsasoft.com  

commit   : d2074daebe1699f0d48fa63f6ba196b6426023ad    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 19 Oct 2020 11:23:51 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 19 Oct 2020 11:23:51 -0400    

The Windows documentation insists that every WSAStartup call should  
have a matching WSACleanup call.  However, if that ever had actual  
relevance, it wasn't in this century.  Every remotely-modern Windows  
kernel is capable of cleaning up when a process exits without doing  
that, and must be so to avoid resource leaks in case of a process  
crash.  Moreover, Postgres backends have done WSAStartup without  
WSACleanup since commit 4cdf51e64 in 2004, and we've never seen any  
indication of a problem with that.  
  
libpq's habit of doing WSAStartup during connection start and  
WSACleanup during shutdown is also rather inefficient, since a  
series of non-overlapping connection requests leads to repeated,  
quite expensive DLL unload/reload cycles.  We document a workaround  
for that (having the application call WSAStartup for itself), but  
that's just a kluge.  It's also worth noting that it's far from  
uncommon for applications to exit without doing PQfinish, and  
we've not heard reports of trouble from that either.  
  
However, the real reason for acting on this is that recent  
experiments by Alexander Lakhin show that calling WSACleanup  
during PQfinish is triggering the symptom we occasionally see  
that a process using libpq fails to emit expected stdio output.  
  
Therefore, let's change libpq so that it calls WSAStartup only  
once per process, during the first connection attempt, and never  
calls WSACleanup at all.  
  
While at it, get rid of the only other WSACleanup call in our code  
tree, in pg_dump/parallel.c; that presumably is equally useless.  
  
Back-patch of HEAD commit 7d00a6b2d.  
  
Discussion: https://postgr.es/m/ac976d8c-03df-d6b8-025c-15a2de8d9af1@postgrespro.ru  

commit   : f2f03f9bb10b0749eddea5ad1dd730926421f090    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 19 Oct 2020 17:58:38 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 19 Oct 2020 17:58:38 +0300    

Commit 028350f619 changed its behavior from "at most" to "exactly", but  
forgot to update the documentation. Backpatch to 9.6.  
  
Patch by Justin Pryzby, per Yaroslav Schekin's report.  
  
Discussion: https://www.postgresql.org/message-id/20201005191922.GE17626%40telsasoft.com  

commit   : d49357c0dc51378aeded51ecb8a290d761ac5b8c    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Mon, 19 Oct 2020 13:47:09 +0200    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Mon, 19 Oct 2020 13:47:09 +0200    

Author: Daniel Gustafsson <daniel@yesql.se>  
Discussion: https://postgr.es/m/A05874AE-8771-4C61-A24E-0B6249B8F3C2@yesql.se  

commit   : 33a332bc1cff27c5138fe117ae56b6a6f476f30c    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Tue, 20 Oct 2020 00:06:40 +1300    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Tue, 20 Oct 2020 00:06:40 +1300    

In the planner, it was possible, given an extreme enough case containing a  
large number of joins for the number of estimated rows to become infinite.  
This could cause problems in initial_cost_mergejoin() where we perform  
some calculations based on those row estimates.  
  
A problem case, presented by Onder Kalaci showed an Assert failure from  
an Assert checking outerstartsel <= outerendsel.  In his test case this  
was effectively NaN <= Inf, which is false.  The NaN outerstartsel came  
from multiplying the infinite outer_path_rows by 0.0.  
  
In master, this problem was fixed by a90c950fc, however, that fix was too  
invasive for the backbranches.  Here we just relax the Asserts to allow  
them to pass.  The worst that appears to happen from this is that we show  
NaN cost values and infinite row estimates in EXPLAIN.  add_path() would  
have had a hard time doing anything useful with such costs, but that does  
not really matter as if the row estimates were even close to accurate,  
such plan would not complete this side of the heat death of the universe.  
  
Reported-by: Onder Kalaci  
Backpatch: 9.5 to 13  
Discussion: https://postgr.es/m/DM6PR21MB1211FF360183BCA901B27F04D80B0@DM6PR21MB1211.namprd21.prod.outlook.com  

commit   : 99ae342fc4ffe5f9a6ec7f540c5a31fb483b06e6    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Mon, 19 Oct 2020 09:34:04 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Mon, 19 Oct 2020 09:34:04 +0530    

The rules to choose the number of parallel workers to perform parallel  
vacuum operation were not clearly specified.  
  
Reported-by: Peter Eisentraut  
Author: Amit Kapila  
Backpatch-through: 13, where it was introduced  
Discussion: https://postgr.es/m/36aa8aea-61b7-eb3c-263b-648e0cb117b7@2ndquadrant.com  

commit   : 1bd9b2b2369608de7763b3947af2f59292152268    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 19 Oct 2020 09:37:50 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 19 Oct 2020 09:37:50 +0900    

When allocating a EVP context, it would have been possible to leak some  
memory allocated directly by OpenSSL, that PostgreSQL lost track of if  
the initialization of the context allocated failed.  The cleanup can be  
done with EVP_MD_CTX_destroy().  
  
Note that EVP APIs exist since OpenSSL 0.9.7 and we have in the tree  
equivalent implementations for older versions since ce9b75d (code  
removed with 9b7cd59a as of 10~).  However, in 9.5 and 9.6, the existing  
code makes use of EVP_MD_CTX_destroy() and EVP_MD_CTX_create() without  
an equivalent implementation when building the tree with OpenSSL 0.9.6  
or older, meaning that this code is in reality broken with such versions  
since it got introduced in e2838c5.  As we have heard no complains about  
that, it does not seem worth bothering with in 9.5 and 9.6, so I have  
left that out for simplicity.  
  
Author: Michael Paquier  
Discussion: https://postgr.es/m/20201015072212.GC2305@paquier.xyz  
Backpatch-through: 9.5  

commit   : d317fd7570ca69553eef9a9ec1825967c2680927    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 17 Oct 2020 16:02:47 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 17 Oct 2020 16:02:47 -0400    

Section 8.5.1.4, which defines these literals, made only a vague  
reference to the fact that they might be evaluated too soon to be  
safe in non-interactive contexts.  Provide a more explicit caution  
against misuse.  Also, generalize the wording in the related tip in  
section 9.9.4: while it clearly described this problem, it implied  
(or really, stated outright) that the problem only applies to table  
DEFAULT clauses.  
  
Per gripe from Tijs van Dam.  Back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/c2LuRv9BiRT3bqIo5mMQiVraEXey_25B4vUn0kDqVqilwOEu_iVF1tbtvLnyQK7yDG3PFaz_GxLLPil2SDkj1MCObNRVaac-7j1dVdFERk8=@thalex.com  

commit   : 3f26dca76343d2e4aca5e2070875c93057925dca    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 16 Oct 2020 21:53:33 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 16 Oct 2020 21:53:33 -0400    

DST law changes in Morocco, Canadian Yukon, Fiji, Macquarie Island,  
Casey Station (Antarctica).  Historical corrections for France,  
Hungary, Monaco.  

commit   : e0cf5e9b226aae3df8ab8df7f5f7c8fe295be24e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 16 Oct 2020 21:40:16 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 16 Oct 2020 21:40:16 -0400    

This changes zic's default output format from "-b fat" to "-b slim".  
We were already using "slim" in v13/HEAD, so those branches drop  
the explicit -b switch in the Makefiles.  Instead, add an explicit  
"-b fat" in v12 and before, so that we don't change the output file  
format in those branches.  (This is perhaps excessively conservative,  
but we decided not to do so in a12079109, and I'll stick with that.)  
  
Other non-cosmetic changes are to drop support for zic's long-obsolete  
"-y" switch, and to ensure that strftime() does not change errno  
unless it fails.  
  
As usual with tzcode changes, back-patch to all supported branches.  

commit   : 3d338a46a4c342fa1a4e276e0c84532141f4264b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 16 Oct 2020 11:59:13 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 16 Oct 2020 11:59:13 -0400    

In theory, the second px_find_digest call in px_crypt_md5 could fail  
even though the first one succeeded, since resource allocation is  
required.  Don't skip testing for a failure.  (If one did happen,  
the likely result would be a crash rather than clean recovery from  
an OOM failure.)  
  
The code's been like this all along, so back-patch to all supported  
branches.  
  
Daniel Gustafsson  
  
Discussion: https://postgr.es/m/AA8D6FE9-4AB2-41B4-98CB-AE64BA668C03@yesql.se  

commit   : 2cde0fd6fcaf70a8cf59972c36e86c00cc97e90c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 16 Oct 2020 11:36:34 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 16 Oct 2020 11:36:34 -0400    

Commit a97e85f2b caused "exceed the available area" warnings in PDF  
builds.  Fine-tune colwidth values to avoid that.  
  
Back-patch to 9.6, like the prior patch.  (This is of dubious value  
before v13, since we were far from free of such warnings in older  
branches.  But we might as well keep the SGML looking the same in all  
branches.)  
  
Per buildfarm.  

commit   : efc9a8e9800cc04ff7460c3c78f9dc2120f3aea6    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Thu, 15 Oct 2020 17:38:00 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Thu, 15 Oct 2020 17:38:00 -0700    

Unfortunately in LLVM 3.9 LLVMGetAttributeCountAtIndex(func, index)  
crashes when called with an index that has 0 attributes. Since there's  
no way to work around this in the C API, add a small C++ wrapper doing  
so.  
  
The only reason this didn't fail before 72559438f92 is that there  
always are function attributes...  
  
Author: Andres Freund <andres@anarazel.de>  
Discussion: https://postgr.es/m/20201016001254.w2nfj7gd74jmb5in@alap3.anarazel.de  
Backpatch: 11-, like 72559438f92  

commit   : 79fe23465d56e7a3e649fd95bdb4e8b0af27a376    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Thu, 15 Oct 2020 20:37:20 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Thu, 15 Oct 2020 20:37:20 -0400    

This commit required support for inline variable definition, which is  
not a requirement.  
  
RELEASE NOTE AUTHOR:  the author of commit 3c0471b5fd  
(pg_upgrade/tablespaces) was Justin Pryzby, not me.  
  
Reported-by: Andres Freund  
  
Discussion: https://postgr.es/m/20201016001959.h24fkywfubkv2pc5@alap3.anarazel.de  
  
Backpatch-through: 9.5  

commit   : 59cfff65b10036b637a3f6e50d8f654e855d3b69    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Thu, 15 Oct 2020 19:33:36 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Thu, 15 Oct 2020 19:33:36 -0400    

Previously, if pg_upgrade failed, and the user recreated the cluster but  
did not remove the new cluster tablespace directory, a later pg_upgrade  
would fail since the new tablespace directory would already exists.  
This adds error reporting for this during check.  
  
Reported-by: Justin Pryzby  
  
Discussion: https://postgr.es/m/20200925005531.GJ23631@telsasoft.com  
  
Backpatch-through: 9.5  

commit   : ae3e75abab222519aef90eb130d93c1ea745ac2e    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Thu, 15 Oct 2020 13:39:41 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Thu, 15 Oct 2020 13:39:41 -0700    

Previously we only copied the function attributes. That caused problems at  
least on s390x: Because we didn't copy the 'zeroext' attribute for  
ExecAggTransReparent()'s *IsNull parameters, expressions invoking it didn't  
ensure that the upper bytes of the registers were zeroed. In the - relatively  
rare - cases where not, ExecAggTransReparent() wrongly ended up in the  
newValueIsNull branch due to the register not being zero. Subsequently causing  
a crash.  
  
It's quite possible that this would cause problems on other platforms, and in  
other places than just ExecAggTransReparent() on s390x.  
  
Thanks to Christoph (and the Debian project) for providing me with access to a  
s390x machine, allowing me to debug this.  
  
Reported-By: Christoph Berg  
Author: Andres Freund  
Discussion: https://postgr.es/m/20201015083246.kie5726xerdt3ael@alap3.anarazel.de  
Backpatch: 11-, where JIT was added  

commit   : 264e517e68190767de7cd50734956db02c6dbef1    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Thu, 15 Oct 2020 15:15:29 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Thu, 15 Oct 2020 15:15:29 -0400    

Previously it wasn't clear exactly what each of the synchronous_commit  
modes accomplished.  This clarifies that, and adds a table describing it.  
Only backpatched through 9.6 since 9.5 doesn't have all the options.  
  
Reported-by: kghost0@gmail.com  
  
Discussion: https://postgr.es/m/159741195522.14321.13812604195366728976@wrigleys.postgresql.org  
  
Backpatch-through: 9.6  

commit   : 9f783aea669f56c2e7c875ee1391949f234a2257    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 15 Oct 2020 09:48:36 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 15 Oct 2020 09:48:36 -0300    

Rather than looking for tablesync workers, it is more reliable to see  
the sync state of the tables.  
  
Per note from Amit Kapila.  
Discussion: https://postgr.es/m/CAA4eK1JSSD7FVwq+_rOme86jUZTQFzjsNU06hQ4-LiRt1xFmSg@mail.gmail.com  

commit   : 47522ee00ddbe77280e4c063605b443ec1de3881    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Thu, 15 Oct 2020 18:23:30 +1300    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Thu, 15 Oct 2020 18:23:30 +1300    

While registering for postmaster exit events, we have to handle a couple  
of edge cases where the postmaster is already gone.  Commit 815c2f09  
missed one: EACCES must surely imply that PostmasterPid no longer  
belongs to our postmaster process (or alternatively an unexpected  
permissions model has been imposed on us).  Like ESRCH, this should be  
treated as a WL_POSTMASTER_DEATH event, rather than being raised with  
ereport().  
  
No known problems reported in the wild.  Per code review from Tom Lane.  
Back-patch to 13.  
  
Reported-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/3624029.1602701929%40sss.pgh.pa.us  

commit   : 53c07dbbf36855a4f5b11654106654b18e00ee15    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Thu, 15 Oct 2020 11:04:07 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Thu, 15 Oct 2020 11:04:07 +0900    

Previously it was documented that toast_tuple_target affected column  
marked as only External or Extended. But this description is not correct  
and toast_tuple_target affects also column marked as Main.  
  
Back-patch to v11 where toast_tuple_target reloption was introduced.  
  
Author: Shinya Okano  
Reviewed-by: Tatsuhito Kasahara, Fujii Masao  
Discussion: https://postgr.es/m/93f46e311a67422e89e770d236059817@oss.nttdata.com  

commit   : 72e43fc313e93c95704c574bcf98805805668063    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 14 Oct 2020 20:12:26 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 14 Oct 2020 20:12:26 -0300    

I removed the duplicate command tags for START_REPLICATION inadvertently  
in commit 07082b08cc5d, but the replication protocol requires them.  The  
fact that the replication protocol was broken was not noticed because  
all our test cases use an optimized code path that exits early, failing  
to verify that the behavior is correct for non-optimized cases.  Put  
them back.  
  
Also document this protocol quirk.  
  
Add a test case that shows the failure.  It might still succeed even  
without the patch when run on a fast enough server, but it suffices to  
show the bug in enough cases that it would be noticed in buildfarm.  
  
Author: Álvaro Herrera <alvherre@alvh.no-ip.org>  
Reported-by: Henry Hinze <henry.hinze@gmail.com>  
Reviewed-by: Petr Jelínek <petr.jelinek@2ndquadrant.com>  
Discussion: https://postgr.es/m/16643-eaadeb2a1a58d28c@postgresql.org  

commit   : e0950135ae5d50140feecc7bc87c018019c6e406    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Thu, 15 Oct 2020 11:31:20 +1300    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Thu, 15 Oct 2020 11:31:20 +1300    

If WaitEventSetWait() reports that the postmaster has gone away, later  
calls to WaitEventSetWait() should continue to report that.  Otherwise  
further waits that occur in the proc_exit() path after we already  
noticed the postmaster's demise could block forever.  
  
Back-patch to 13, where the kqueue support landed.  
  
Reported-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/3624029.1602701929%40sss.pgh.pa.us  

commit   : 855b6f287100f3eab24df0a83998db251ac4fd09    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 13 Oct 2020 17:44:56 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 13 Oct 2020 17:44:56 -0400    

Our infinite_recurse() test to verify sane stack-overrun behavior  
is affected by a bug of the Linux kernel on PPC64: it will get SIGSEGV  
if it receives a signal when the stack depth is (a) over 1MB and  
(b) within a few kB of filling the current physical stack allocation.  
See https://bugzilla.kernel.org/show_bug.cgi?id=205183.  
  
Since this test is a bit time-consuming and we run it in parallel with  
test scripts that do a lot of DDL, it can be expected to get an sinval  
catchup interrupt at some point, leading to failure if the timing is  
wrong.  This has caused more than 100 buildfarm failures over the  
past year or so.  
  
While a fix exists for the kernel bug, it might be years before that  
propagates into all production kernels, particularly in some of the  
older distros we have in the buildfarm.  For now, let's just back off  
and not run this test on Linux PPC64; that loses nothing in test  
coverage so far as our own code is concerned.  
  
To do that, split this test into a new script infinite_recurse.sql  
and skip the test when the platform name is powerpc64...-linux-gnu.  
  
Back-patch to v12.  Branches before that have not been seen to get  
this failure.  No doubt that's because the "errors" test was not  
run in parallel with other tests before commit 798070ec0, greatly  
reducing the odds of an sinval catchup being necessary.  
  
I also back-patched 3c8553547 into v12, just so the new regression  
script would look the same in all branches having it.  
  
Discussion: https://postgr.es/m/3479046.1602607848@sss.pgh.pa.us  
Discussion: https://postgr.es/m/20190723162703.GM22387%40telsasoft.com  

commit   : 962ab473ec3d4c1090ba75fa677167126956c1ee    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 12 Oct 2020 18:01:34 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 12 Oct 2020 18:01:34 -0400    

gistRelocateBuildBuffersOnSplit did not get the memo about which  
attribute count to use.  This could lead to a crash if there were  
included columns and buffering build was chosen.  (Because there  
are random page-split decisions elsewhere in GiST index build,  
the crashes are not entirely deterministic.)  
  
Back-patch to v12 where GiST gained support for included columns.  
  
Pavel Borisov  
  
Discussion: https://postgr.es/m/CALT9ZEECCV5m7wvxg46PC-7x-EybUmnpupBGhSFMoAAay+r6HQ@mail.gmail.com  

commit   : 9343bfefa4514e5623cfc2610c44e3d93d776e64    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 12 Oct 2020 13:31:24 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 12 Oct 2020 13:31:24 -0400    

The prohibitValueChange code paths in set_config_option(), which  
are executed whenever we re-read a PGC_POSTMASTER variable from  
postgresql.conf, neglected to free anything before exiting.  Thus  
we'd leak the proposed new value of a PGC_STRING variable, as noted  
by BoChen in bug #16666.  For all variable types, if the check hook  
creates an "extra" chunk, we'd also leak that.  
  
These are malloc not palloc chunks, so there is no mechanism for  
recovering the leaks before process exit.  Fortunately, the values  
are typically not very large, meaning you'd have to go through an  
awful lot of SIGHUP configuration-reload cycles to make the leakage  
amount to anything.  Still, for a long-lived postmaster process it  
could potentially be a problem.  
  
Oversight in commit 2594cf0e8.  Back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/16666-2c41a4eec61b03e1@postgresql.org  

commit   : 5efa788e1d070dd14cb94a8e087184dda36dc3ea    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sun, 11 Oct 2020 21:31:37 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sun, 11 Oct 2020 21:31:37 -0700    

The implementation uses smaller code when the "expected" operand is a  
small constant, but the implementation needlessly defined the set of  
acceptable constants more narrowly than the ABI does.  Core PostgreSQL  
and PGXN don't use the constant path at all, so this is future-proofing.  
Back-patch to v13, where commit 30ee5d17c20dbb282a9952b3048d6ad52d56c371  
introduced this code.  
  
Reviewed by Tom Lane.  Reported by Christoph Berg.  
  
Discussion: https://postgr.es/m/20201009092825.GD889580@msg.df7cb.de  

commit   : d41cb63ff4d114d856837fbf61ba2872c5076ac2    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sun, 11 Oct 2020 21:31:37 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sun, 11 Oct 2020 21:31:37 -0700    

While xlc defines __64BIT__, gcc does not.  Due to this oversight in  
commit 30ee5d17c20dbb282a9952b3048d6ad52d56c371, gcc builds continued  
implementing 64-bit atomics by way of intrinsics.  Back-patch to v13,  
where that commit first appeared.  
  
Reviewed by Tom Lane.  
  
Discussion: https://postgr.es/m/20201011051043.GA1724101@rfd.leadboat.com  

commit   : dc14aa038e20d0287a569c36498da9469fe9d4e3    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 7 Oct 2020 18:41:39 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 7 Oct 2020 18:41:39 -0400    

It appears that commit cf63c641c, which intended to prevent  
misoptimization of the result-building step in makeOrderedSetArgs,  
didn't go far enough: buildfarm member hornet's version of xlc  
is now optimizing back to the old, broken behavior in which  
list_length(directargs) is fetched only after list_concat() has  
changed that value.  I'm not entirely convinced whether that's  
an undeniable compiler bug or whether it can be justified by a  
sufficiently aggressive interpretation of C sequence points.  
So let's just change the code to make it harder to misinterpret.  
  
Back-patch to all supported versions, just in case.  
  
Discussion: https://postgr.es/m/1830491.1601944935@sss.pgh.pa.us  

commit   : 5ed20a689e3d5d47a70b971f388e9da2a996dea9    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 7 Oct 2020 17:10:26 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 7 Oct 2020 17:10:26 -0400    

The date-vs-timestamp, date-vs-timestamptz, and timestamp-vs-timestamptz  
comparators all worked by promoting the first type to the second and  
then doing a simple same-type comparison.  This works fine, except  
when the conversion result is out of range, in which case we throw an  
entirely avoidable error.  The sources of such failures are  
(a) type date can represent dates much farther in the future than  
the timestamp types can;  
(b) timezone rotation might cause a just-in-range timestamp value to  
become a just-out-of-range timestamptz value.  
  
Up to now we just ignored these corner-case issues, but now we have  
an actual user complaint (bug #16657 from Huss EL-Sheikh), so let's  
do something about it.  
  
It turns out that commit 52ad1e659 already built all the necessary  
infrastructure to support error-free comparisons, but neglected to  
actually use it in the main-line code paths.  Fix that, do a little  
bit of code style review, and remove the now-duplicate logic in  
jsonpath_exec.c.  
  
Back-patch to v13 where 52ad1e659 came in.  We could take this back  
further by back-patching said infrastructure, but given the small  
number of complaints so far, I don't feel a great need to.  
  
Discussion: https://postgr.es/m/16657-cde2f876d8cc7971@postgresql.org  

commit   : 2ea624b4b51caa0e82a4084d2499f5fc72cbe418    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 7 Oct 2020 12:50:54 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 7 Oct 2020 12:50:54 -0400    

Commit 3eb3d3e78 was a few bricks shy of a load: while it correctly  
set the table's "interesting" flag when deciding to dump the data of  
an extension config table, it was not correct to clear that flag  
if we concluded we shouldn't dump the data.  This led to the crash  
reported in bug #16655, because in fact we'll traverse dumpTableSchema  
anyway for all extension tables (to see if they have user-added  
seclabels or RLS policies).  
  
The right thing to do is to force "interesting" true in makeTableDataInfo,  
and otherwise leave the flag alone.  (Doing it there is more future-proof  
in case additional calls are added, and it also avoids setting the flag  
unnecessarily if that function decides the table is non-dumpable.)  
  
This investigation also showed that while only the --inserts code path  
had an obvious failure in the case considered by 3eb3d3e78, the COPY  
code path also has a problem with not having loaded table subsidiary  
data.  That causes fmtCopyColumnList to silently return an empty string  
instead of the correct column list.  That accidentally mostly works,  
which perhaps is why we didn't notice this before.  It would only fail  
if the restore column order is different from the dump column order,  
which only happens in weird inheritance cases, so it's not surprising  
nobody had hit the case with an extension config table.  Nonetheless,  
it's a bug, and it goes a long way back, not just to v12 where the  
--inserts code path started to have a problem with this.  
  
In hopes of catching such cases a bit sooner in future, add some  
Asserts that "interesting" has been set in both dumpTableData and  
dumpTableSchema.  Adjust the test case added by 3eb3d3e78 so that it  
checks the COPY rather than INSERT form of that bug, allowing it to  
detect the longer-standing symptom.  
  
Per bug #16655 from Cameron Daniel.  Back-patch to all supported  
branches.  
  
Discussion: https://postgr.es/m/16655-5c92d6b3a9438137@postgresql.org  
Discussion: https://postgr.es/m/18048b44-3414-b983-8c7c-9165b177900d@2ndQuadrant.com  

commit   : be304cf9f5665e1c19d02f1144d4f0affa0034c7    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 6 Oct 2020 14:31:22 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 6 Oct 2020 14:31:22 -0400    

We only support upgrading from >= 8.4 so no need for this code or tests.  
  
Reported-by: Magnus Hagander  
  
Discussion: https://postgr.es/m/CABUevEx-D0PNVe00tkeQRGennZQwDtBJn=493MJt-x6sppbUxA@mail.gmail.com  
  
Backpatch-through: 9.5  

commit   : 2cb4b8e0ae16e7091a7bd5cf94f21d2719b108e0    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 6 Oct 2020 12:12:09 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 6 Oct 2020 12:12:09 -0400    

This makes checking for older major versions more consistent.  
  
Backpatch-through: 9.5  

commit   : b7f166efade004ba293f52b672961ae064d202cd    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 6 Oct 2020 11:43:53 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 6 Oct 2020 11:43:53 -0400    

This patch prevents crashes or wrong plans when partition-wise joins  
are considered during GEQO planning, as a consequence of the  
EquivalenceClass data structures becoming corrupt after a GEQO  
context reset.  
  
A remaining problem is that successive GEQO cycles will make multiple  
copies of the required EC members, since add_child_join_rel_equivalences  
has no idea that such members might exist already.  For now we'll just  
live with that.  The lack of field complaints of crashes suggests that  
this is a mighty little-used situation.  
  
Back-patch to v12 where this code was introduced.  
  
Discussion: https://postgr.es/m/1683100.1601860653@sss.pgh.pa.us  

commit   : 96423711918f44600c9ef91f4342984624f053bb    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Tue, 6 Oct 2020 15:50:03 +0200    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Tue, 6 Oct 2020 15:50:03 +0200    

Ian submitted an updated patch just as I was pushing the previous one,  
so use this newer wording instead.  
  
Author: Ian Barwick  

commit   : 0639f9b8c251d152695a968c3978edca844c3cad    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Tue, 6 Oct 2020 15:46:36 +0200    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Tue, 6 Oct 2020 15:46:36 +0200    

The behavior is different for different types of objects, so make that  
more clear.  
  
Author: Ian Barwick  

commit   : e9703ce6e7ac263e0e5a6fca9266e09284195dc7    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 5 Oct 2020 16:27:33 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 5 Oct 2020 16:27:33 -0400    

Previously it was unclear exactly how ROWS FROM behaved and how to cast  
the data types of columns returned by FROM functions.  Also document  
that only non-OUT record functions can have their columns cast to data  
types.  
  
Reported-by: guyren@gmail.com  
  
Discussion: https://postgr.es/m/158638264419.662.2482095087061084020@wrigleys.postgresql.org  
  
Backpatch-through: 9.5  

commit   : ef40ab77d5143385d15dcfd08c5a7d66719ef7a3    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 5 Oct 2020 16:07:15 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 5 Oct 2020 16:07:15 -0400    

This is the first paragraph change of master-only commit 253f1025da.  
  
Backpatch-through: PG 12-13 only  

commit   : d1c23d726d50e10179235b6cee6b34543a879b19    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 5 Oct 2020 13:15:39 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 5 Oct 2020 13:15:39 -0400    

get_eclass_for_sort_expr() computes expr_relids and nullable_relids  
early on, even though they won't be needed unless we make a new  
EquivalenceClass, which we often don't.  Aside from the probably-minor  
inefficiency, there's a memory management problem: these bitmapsets will  
be built in the caller's context, leading to dangling pointers if that  
is shorter-lived than root->planner_cxt.  This would be a live bug if  
get_eclass_for_sort_expr() could be called with create_it = true during  
GEQO join planning.  So far as I can find, the core code never does  
that, but it's hard to be sure that no extensions do, especially since  
the comments make it clear that that's supposed to be a supported case.  
Fix by not computing these values until we've switched into planner_cxt  
to build the new EquivalenceClass.  
  
generate_join_implied_equalities() uses inner_rel->relids to look up  
relevant eclasses, but it ought to be using nominal_inner_relids.  
This is presently harmless because a child RelOptInfo will always have  
exactly the same eclass_indexes as its topmost parent; but that might  
not be true forever, and anyway it makes the code confusing.  
  
The first of these is old (introduced by me in f3b3b8d5b), so back-patch  
to all supported branches.  The second only dates to v13, but we might  
as well back-patch it to keep the code looking similar across branches.  
  
Discussion: https://postgr.es/m/1508010.1601832581@sss.pgh.pa.us  

commit   : 019eb962fb869b55ac8db173c4424a5de6cfee61    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 5 Oct 2020 11:42:33 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 5 Oct 2020 11:42:33 -0400    

The descriptions of make_interval() and pg_options_to_table()  
were randomly different from the reality embedded in pg_proc.  
  
(These are not all the discrepancies I found in a quick search,  
but the others perhaps require more discussion, since there's  
at least a case to be made for changing pg_proc not the docs.)  
  
make_interval issue noted by Thomas Kellerer.  
  
Discussion: https://postgr.es/m/7b154ef0-9f22-90b9-7734-4bf23686695b@gmx.net  

commit   : e01e339560ea7d8716924f3b014e902ef646729c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 4 Oct 2020 20:45:06 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 4 Oct 2020 20:45:06 -0400    

I noticed while trying to run the regression tests under a low  
geqo_threshold that one query on information_schema.columns had  
unstable (as in, variable from one run to the next) output order.  
This is pretty unsurprising given the complexity of the underlying  
plan.  Interestingly, of this test's three nigh-identical queries on  
information_schema.columns, the other two already had ORDER BY clauses  
guaranteeing stable output.  Let's make this one look the same.  
  
Back-patch to v10 where this test was added.  We've not heard field  
reports of the test failing, but this experience shows that it can  
happen when testing under even slightly unusual conditions.  

commit   : d2c9ef1c80b6adfbeee49507445c1b2eb3d08783    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Fri, 2 Oct 2020 22:19:31 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Fri, 2 Oct 2020 22:19:31 -0400    

Reported-by: Alexander Lakhin  
  
Discussion: https://postgr.es/m/16486-b9c93d71c02c4907@postgresql.org  
  
Backpatch-through: 9.5  

commit   : 566c6d4fd8bb76a761ae144a33514428ab048880    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Fri, 2 Oct 2020 21:39:33 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Fri, 2 Oct 2020 21:39:33 -0400    

Reported-by: karimelghazouly@gmail.com  
  
Discussion: https://postgr.es/m/159854511172.24991.4373145230066586863@wrigleys.postgresql.org  
  
Backpatch-through: 9.5  

commit   : 6731f1ef19fdf912cfbf2686a4d344a022b7704b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 1 Oct 2020 10:59:20 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 1 Oct 2020 10:59:20 -0400    

Commit 151c0c5f7 neglected the possibility that a TEMP_CONFIG file  
would explicitly set max_wal_senders=0; as indeed buildfarm member  
thorntail does, so that it can test wal_level=minimal in other test  
suites.  Hence, rather than assuming that max_wal_senders=10 will  
prevail if we say nothing, set it explicitly.  
  
Set max_replication_slots=10 explicitly too, just to be safe.  
  
Back-patch to v10, like the previous patch.  
  
Discussion: https://postgr.es/m/723911.1601417626@sss.pgh.pa.us  

commit   : 3c85489ec9cd08ce43976afa75f613f939635cb9    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 1 Oct 2020 11:48:48 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 1 Oct 2020 11:48:48 +0300    

This has been wrong ever since the support for multi-dimensional  
arrays as PL/python function arguments and return values was  
introduced in commit 94aceed317.  
  
Backpatch-through: 10  
Discussion: https://www.postgresql.org/message-id/61647b8e-961c-0362-d5d3-c8a18f4a7ec6%40iki.fi  

commit   : 49433744ff65d8d799572cd616aecaf3074bcda5    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 30 Sep 2020 18:25:22 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 30 Sep 2020 18:25:22 -0300    

The error message about columns in the primary key not including all of  
the partition key was unclear; reword it.  
  
Backpatch all the way to pg11, where it appeared.  
  
Reported-by: Nagaraj Raj <nagaraj.sf@yahoo.com>  
Discussion: https://postgr.es/m/64062533.78364.1601415362244@mail.yahoo.com  

commit   : 99fd38c02299acdc2282ac2dea8057a7a8f5f807    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 30 Sep 2020 15:40:23 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 30 Sep 2020 15:40:23 -0400    

Previously, a conversion such as  
	to_date('-44-02-01','YYYY-MM-DD')  
would result in '0045-02-01 BC', as the code attempted to interpret  
the negative year as BC, but failed to apply the correction needed  
for our internal handling of BC years.  Fix the off-by-one problem.  
  
Also, arrange for the combination of a negative year and an  
explicit "BC" marker to cancel out and produce AD.  This is how  
the negative-century case works, so it seems sane to do likewise.  
  
Continue to read "year 0000" as 1 BC.  Oracle would throw an error,  
but we've accepted that case for a long time so I'm hesitant to  
change it in a back-patch.  
  
Per bug #16419 from Saeed Hubaishan.  Back-patch to all supported  
branches.  
  
Dar Alathar-Yemen and Tom Lane  
  
Discussion: https://postgr.es/m/16419-d8d9db0a7553f01b@postgresql.org  

commit   : db8e60b82d6af88a4c8e1f9572abd5f5d84906b2    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 29 Sep 2020 20:02:58 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 29 Sep 2020 20:02:58 -0400    

PostgresNode.pm set "max_wal_senders = 5" for replication testing,  
but this seems to be slightly too low for our current test suite.  
Slower buildfarm members frequently report "number of requested standby  
connections exceeds max_wal_senders" failures, due to old walsenders  
not exiting instantaneously.  Usually, the test does not fail overall  
because of automatic walreceiver restart, but sometimes the failure  
becomes visible; and in any case such retries slow down the test.  
  
That value came in with commit 89ac7004d, but was soon obsoleted by  
f6d6d2920, which raised the built-in default from zero to 10; so that  
PostgresNode.pm is actually setting it to less than the conservative  
built-in default.  That seems pretty pointless, so let's remove the  
special setting and let the default prevail, in hopes of making  
the TAP tests more robust.  
  
Likewise, the setting "max_replication_slots = 5" is obsolete and  
can be removed.  
  
While here, reverse-engineer a comment about why we're choosing  
less-than-default values for some other settings.  
  
(Note: before v12, max_wal_senders counted against max_connections  
so that the latter setting also needs some fiddling with.)  
  
Back-patch to v10 where the subscription tests were added.  
It's likely that the older branches aren't pushing the boundaries  
of max_wal_senders, but I'm disinclined to spend time trying to  
figure out exactly when it started to be a problem.  
  
Discussion: https://postgr.es/m/723911.1601417626@sss.pgh.pa.us  

commit   : 5610ffaf00a53877ec973881b9b0b7a1acad689a    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Wed, 30 Sep 2020 13:03:01 +1300    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Wed, 30 Sep 2020 13:03:01 +1300    

Explicitly mention that primary key constraints are also included in the  
limitation that the constraint columns must be a superset of the partition key  
columns.  
  
Wording suggestion from Tom Lane.  
  
Discussion: https://postgr.es/m/64062533.78364.1601415362244@mail.yahoo.com  
Backpatch-through: 11, where unique constraints on partitioned tables were added  

commit   : f0e4ec74e452f55922b52f50da4ba4834771a268    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 29 Sep 2020 11:18:30 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 29 Sep 2020 11:18:30 -0400    

When executing a CALL or DO in a non-atomic context (i.e., not inside  
a function or query), plpgsql creates a new plan each time through,  
as a rather hacky solution to some resource management issues.  But  
it failed to free this plan until exit of the current procedure or DO  
block, resulting in serious memory bloat in procedures that called  
other procedures many times.  Fix by remembering to free the plan,  
and by being more honest about restoring the previous state (otherwise,  
recursive procedure calls have a problem).  
  
There was also a smaller leak associated with recalculation of the  
"target" list of output variables.  Fix that by using the statement-  
lifespan context to hold non-permanent values.  
  
Back-patch to v11 where procedures were introduced.  
  
Pavel Stehule and Tom Lane  
  
Discussion: https://postgr.es/m/CAFj8pRDiiU1dqym+_P4_GuTWm76knJu7z9opWayBJTC0nQGUUA@mail.gmail.com  

commit   : 651bdbc811652638e1205440c3181a18feb8f967    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Tue, 29 Sep 2020 11:41:46 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Tue, 29 Sep 2020 11:41:46 +0300    

The SQL standard doesn't require jsonpath .datetime() method to support the  
ISO 8601 format.  But our to_json[b]() functions convert timestamps to text in  
the ISO 8601 format in the sake of compatibility with javascript.  So, we add  
support of the  ISO 8601 to the jsonpath .datetime() in the sake compatibility  
with to_json[b]().  
  
The standard mode of datetime parsing currently supports just template patterns  
and separators in the format string.  In order to implement ISO 8601, we have to  
add support of the format string double quotes to the standard parsing mode.  
  
Discussion: https://postgr.es/m/94321be0-cc96-1a81-b6df-796f437f7c66%40postgrespro.ru  
Author: Nikita Glukhov, revised by me  
Backpatch-through: 13  

commit   : abcc0ab163003d2ab7c82a1e810ba257ebbec15f    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Tue, 29 Sep 2020 11:00:22 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Tue, 29 Sep 2020 11:00:22 +0300    

bffe1bd684 has introduced jsonpath .datetime() method, but default formats  
for time and timestamp contain excess space between time and timezone.  This  
commit removes this excess space making behavior of .datetime() method  
standard-compliant.  
  
Discussion: https://postgr.es/m/94321be0-cc96-1a81-b6df-796f437f7c66%40postgrespro.ru  
Author: Nikita Glukhov  
Backpatch-through: 13  

commit   : 059caf36c3074afd998b6e5f36ea9da460dcaee8    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Tue, 29 Sep 2020 16:21:46 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Tue, 29 Sep 2020 16:21:46 +0900    

Previously the standby server didn't archive timeline history files  
streamed from the primary even when archive_mode is set to "always",  
while it archives the streamed WAL files. This could cause the PITR to  
fail because there was no required timeline history file in the archive.  
The cause of this issue was that walreceiver didn't mark those files as  
ready for archiving.  
  
This commit makes walreceiver mark those streamed timeline history  
files as ready for archiving if archive_mode=always. Then the archiver  
process archives the marked timeline history files.  
  
Back-patch to all supported versions.  
  
Reported-by: Grigory Smolkin  
Author: Grigory Smolkin, Fujii Masao  
Reviewed-by: David Zhang, Anastasia Lubennikova  
Discussion: https://postgr.es/m/54b059d4-2b48-13a4-6f43-95a087c92367@postgrespro.ru  

commit   : 1aedaba78aa8617b24b7a703abd1359f9d78f62a    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 29 Sep 2020 14:16:12 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 29 Sep 2020 14:16:12 +0900    

This addresses a couple of issues with the so-said subject:  
- Report the correct parent relation with the index actually being  
rebuilt or validated.  Previously, the command status remained set to  
the last index created for the progress of the index build and  
validation, which would be incorrect when working on a table that has  
more than one index.  
- Use the correct phase when waiting before the drop of the old  
indexes.  Previously, this was reported with the same status as when  
waiting before the old indexes are marked as dead.  
  
Author: Matthias van de Meent, Michael Paquier  
Discussion: https://postgr.es/m/CAEze2WhqFgcwe1_tv=sFYhLWV2AdpfukumotJ6JNcAOQs3jufg@mail.gmail.com  
Backpatch-through: 12  

commit   : 67b2ceea01576933a1dc881ef6a65403e03483ee    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 28 Sep 2020 20:32:53 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 28 Sep 2020 20:32:53 -0400    

We have a dozen or so places that need to iterate over all but the  
first cell of a List.  Prior to v13 this was typically written as  
	for_each_cell(lc, lnext(list_head(list)))  
Commit 1cff1b95a changed these to  
	for_each_cell(lc, list, list_second_cell(list))  
This patch introduces a new macro for_each_from() which expresses  
the start point as a list index, allowing these to be written as  
	for_each_from(lc, list, 1)  
This is marginally more efficient, since ForEachState.i can be  
initialized directly instead of backing into it from a ListCell  
address.  It also seems clearer and less typo-prone.  
  
Some of the remaining uses of for_each_cell() look like they could  
profitably be changed to for_each_from(), but here I confined myself  
to changing uses of list_second_cell().  
  
Also, fix for_each_cell_setup() and for_both_cell_setup() to  
const-ify their arguments; that's a simple oversight in 1cff1b95a.  
  
Back-patch into v13, on the grounds that (1) the const-ification  
is a minor bug fix, and (2) it's better for back-patching purposes  
if we only have two ways to write these loops rather than three.  
  
In HEAD, also remove list_third_cell() and list_fourth_cell(),  
which were also introduced in 1cff1b95a, and are unused as of  
cc99baa43.  It seems unlikely that any third-party code would  
have started to use them already; anyone who has can be directed  
to list_nth_cell instead.  
  
Discussion: https://postgr.es/m/CAApHDvpo1zj9KhEpU2cCRZfSM3Q6XGdhzuAS2v79PH7WJBkYVA@mail.gmail.com  

commit   : 61a78c71a656593bf4121e624348a990ba5b91da    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 28 Sep 2020 14:12:38 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 28 Sep 2020 14:12:38 -0400    

Failure to do this can result in errors during evaluation of  
the bound expression, as illustrated by the new regression test.  
  
Back-patch to v12 where the ability for partition bounds to be  
expressions was added.  
  
Discussion: https://postgr.es/m/CAJV4CdrZ5mKuaEsRSbLf2URQ3h6iMtKD=hik8MaF5WwdmC9uZw@mail.gmail.com  

commit   : f7873900f353ff210ef2ef2aa587e39196b8bf5a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 26 Sep 2020 16:04:06 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 26 Sep 2020 16:04:06 -0400    

This function leaked some memory while loading qual clauses for  
an RLS policy.  While ordinarily negligible, that could build up  
in some repeated-reload cases, as reported by Konstantin Knizhnik.  
We can improve matters by borrowing the coding long used in  
RelationBuildRuleLock: build stringToNode's result directly in  
the target context, and remember to explicitly pfree the  
input string.  
  
This patch by no means completely guarantees zero leaks within  
this function, since we have no real guarantee that the catalog-  
reading subroutines it calls don't leak anything.  However,  
practical tests suggest that this is enough to resolve the issue.  
In any case, any remaining leaks are similar to those risked by  
RelationBuildRuleLock and other relcache-loading subroutines.  
If we need to fix them, we should adopt a more global approach  
such as that used by the RECOVER_RELATION_BUILD_MEMORY hack.  
  
While here, let's remove the need for an expensive PG_TRY block by  
using MemoryContextSetParent to reparent an initially-short-lived  
context for the RLS data.  
  
Back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/21356c12-8917-8249-b35f-1c447231922b@postgrespro.ru  

commit   : cb8885ac49697eb2568c4764ae3565cea52be92b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 24 Sep 2020 18:19:38 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 24 Sep 2020 18:19:38 -0400    

Parallel pg_dump failed if its -d parameter was a connection string  
containing any essential information other than host, port, or username.  
The same was true for pg_restore with --create.  
  
The reason is that these scenarios failed to preserve the connection  
string from the command line; the code felt free to replace that with  
just the database name when reconnecting from a pg_dump parallel worker  
or after creating the target database.  By chance, parallel pg_restore  
did not suffer this defect, as long as you didn't say --create.  
  
In practice it seems that the error would be obvious only if the  
connstring included essential, non-default SSL or GSS parameters.  
This may explain why it took us so long to notice.  (It also makes  
it very difficult to craft a regression test case illustrating the  
problem, since the test would fail in builds without those options.)  
  
Fix by refactoring so that ConnectDatabase always receives all the  
relevant options directly from the command line, rather than  
reconstructed values.  Inject a different database name, when necessary,  
by relying on libpq's rules for handling multiple "dbname" parameters.  
  
While here, let's get rid of the essentially duplicate _connectDB  
function, as well as some obsolete nearby cruft.  
  
Per bug #16604 from Zsolt Ero.  Back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/16604-933f4b8791227b15@postgresql.org  

commit   : 052014a2066827cb96dbc9ef464ce44293585601    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Thu, 24 Sep 2020 09:26:09 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Thu, 24 Sep 2020 09:26:09 +1200    

Harmonize behavior by moving reponsibility for fsyncing directories down  
into slru.c.  In 10 and later, only the multixact directories were  
missed (see commit 1b02be21), and in older branches all SLRUs were  
missed.  
  
Back-patch to all supported releases.  
  
Reviewed-by: Andres Freund <andres@anarazel.de>  
Reviewed-by: Michael Paquier <michael@paquier.xyz>  
Discussion: https://postgr.es/m/CA%2BhUKGLtsTUOScnNoSMZ-2ZLv%2BwGh01J6kAo_DM8mTRq1sKdSQ%40mail.gmail.com  

commit   : 569f6a89a9153ee05ab429522e835b00b11ad7f9    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 23 Sep 2020 11:36:13 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 23 Sep 2020 11:36:13 -0400    

tsearch_readline() saves the string pointer it returns to the caller  
for possible use in the associated error context callback.  However,  
the caller will usually pfree that string sometime before it next  
calls tsearch_readline(), so that there is a window where an ereport  
will try to print an already-freed string.  
  
The built-in users of tsearch_readline() happen to all do that pfree  
at the bottoms of their loops, so that the window is effectively  
empty for them.  However, this is not documented as a requirement,  
and contrib/dict_xsyn doesn't do it like that, so it seems likely  
that third-party dictionaries might have live bugs here.  
  
The practical consequences of this seem pretty limited in any case,  
since production builds wouldn't clobber the freed string immediately,  
besides which you'd not expect syntax errors in dictionary files  
being used in production.  Still, it's clearly a bug waiting to bite  
somebody.  
  
Fix by pstrdup'ing the string to be saved for the error callback,  
and then pfree'ing it next time through.  It's been like this for  
a long time, so back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/48A4FA71-524E-41B9-953A-FD04EF36E2E7@yesql.se  

commit   : 29be9983a64c011eac0b9ee29895cce71e15ea77    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 21 Sep 2020 16:47:36 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 21 Sep 2020 16:47:36 -0400    

commit   : 4406364e2bf421459be7bd21503da093d910e0c3    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 21 Sep 2020 13:30:18 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 21 Sep 2020 13:30:18 -0400    

The previous text was confusing, per off-list discussion with  
Bruce Momjian.  

commit   : e62c5ea22c12f63d8d5ca3b228a458dfc10ae314    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 21 Sep 2020 12:43:42 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 21 Sep 2020 12:43:42 -0400    

99% of this is docs, but also a couple of comments.  No code changes.  
  
Justin Pryzby  
  
Discussion: https://postgr.es/m/20200919175804.GE30557@telsasoft.com  

commit   : d83268ae10cdeb2aa88e32286e94a8a8f59653a0    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 21 Sep 2020 10:06:30 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 21 Sep 2020 10:06:30 +0200    

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

commit   : f6727f29d52072bd0e87fbc9ed7af0d880db0d5c    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 21 Sep 2020 09:05:13 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 21 Sep 2020 09:05:13 +0200    

commit   : 9ab5ed4194f3863ff744e195027da747d4db4106    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 18 Sep 2020 18:03:44 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 18 Sep 2020 18:03:44 -0400    

These two SQL functions are aliases for the same C function, so this  
change has no semantic effect.  However, because we dropped the  
numeric_fac alias in HEAD (commit 76f412ab3), operator definitions  
based on that one don't port forward, causing problems for cross-version  
upgrade tests based on the regression database.  
  
Patch all active back branches to dodge the problem.  
  
Discussion: https://postgr.es/m/449144.1600439950@sss.pgh.pa.us  

commit   : f083afac9df707778288b9ab448be169a25e3ea6    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Fri, 18 Sep 2020 09:40:04 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Fri, 18 Sep 2020 09:40:04 +0530    

After commits 85f6b49c2c and 3ba59ccc89, we can allow parallel inserts  
which was earlier not possible as parallel group members won't conflict  
for relation extension and page lock.  In those commits, we forgot to  
update comments at few places.  
  
Author: Amit Kapila  
Reviewed-by: Robert Haas and Dilip Kumar  
Backpatch-through: 13  
Discussion: https://postgr.es/m/CAFiTN-tMrQh5FFMPx5aWJ+1gi1H6JxktEhq5mDwCHgnEO5oBkA@mail.gmail.com  

commit   : 0abd9cd2f3a1cad201ca28767aa0a720cc341179    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Thu, 17 Sep 2020 15:16:46 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Thu, 17 Sep 2020 15:16:46 +0530    

For parallel btree scan to work for array of scan keys, it should reach  
BTPARALLEL_DONE state once for every distinct combination of array keys.  
This is required to ensure that the parallel workers don't try to seize  
blocks at the same time for different scan keys. We missed to update this  
state when we discovered that the scan keys can't be satisfied.  
  
Author: James Hunter  
Reviewed-by: Amit Kapila  
Tested-by: Justin Pryzby  
Backpatch-through: 10, where it was introduced  
Discussion: https://postgr.es/m/4248CABC-25E3-4809-B4D0-128E1BAABC3C@amazon.com  

commit   : bfb12cd2b59da2ce51a9c86bf2c468202d8f96ee    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 16 Sep 2020 13:04:38 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 16 Sep 2020 13:04:38 -0300    

Since commit fd5942c18f97 (2012, 9.3-era), walsender has been sending  
completion tags for certain replication commands twice -- and they're  
not even consistent.  Apparently neither libpq nor JDBC have a problem  
with it, but it's not kosher.  Fix by remove the EndCommand() call in  
the common code path for them all, and inserting specific calls to  
EndReplicationCommand() specifically in those places where it's needed.  
  
EndReplicationCommand() is a new simple function to send the completion  
tag for replication commands.  Do this instead of sending a generic  
SELECT completion tag for them all, which was also pretty bogus (if  
innocuous).  While at it, change StartReplication() to use  
EndReplicationCommand() instead of pg_puttextmessage().  
  
In commit 2f9661311b83, I failed to realize that replication commands  
are not close-enough kin of regular SQL commands, so the  
DROP_REPLICATION_SLOT tag I added is undeserved and a type pun.  Take it  
out.  
  
Backpatch to 13, where the latter commit appeared.  The duplicate tag  
has been sent since 9.3, but since nothing is broken, it doesn't seem  
worth fixing.  
  
Per complaints from Tom Lane.  
  
Discussion: https://postgr.es/m/1347966.1600195735@sss.pgh.pa.us  

commit   : c287f585865b81c96602db995dacf2c006c79d58    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Wed, 16 Sep 2020 10:42:28 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Wed, 16 Sep 2020 10:42:28 -0700    

Commit d114cc53 overlooked the fact that pg_upgrade'd B-Tree indexes  
have leaf page high keys whose offset numbers do not match the one from  
the copy of the tuple one level up (the copy stored with a downlink for  
leaf page's right sibling page).  This led to false positive reports of  
corruption from bt_index_parent_check() when it was called to verify a  
pg_upgrade'd index.  
  
To fix, skip comparing the offset number on pg_upgrade'd B-Tree indexes.  
  
Author: Anastasia Lubennikova <a.lubennikova@postgrespro.ru>  
Author: Peter Geoghegan <pg@bowt.ie>  
Reported-By: Andrew Bille <andrewbille@gmail.com>  
Diagnosed-By: Anastasia Lubennikova <a.lubennikova@postgrespro.ru>  
Bug: #16619  
Discussion: https://postgr.es/m/16619-aaba10f83fdc1c3c@postgresql.org  
Backpatch: 13-, where child check was enhanced.  

commit   : 17280b31c2f218f1b1f0c1fbacae7e781010a01b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 16 Sep 2020 13:38:26 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 16 Sep 2020 13:38:26 -0400    

If a partitioned table's column is already marked NOT NULL, there is  
no need to examine its partitions, because we can rely on previous  
DDL to have enforced that the child columns are NOT NULL as well.  
(Unfortunately, the same cannot be said for traditional inheritance,  
so for now we have to restrict the optimization to partitioned tables.)  
Hence, we may skip recursing to child tables in this situation.  
  
The reason this case is worth worrying about is that when pg_dump dumps  
a partitioned table having a primary key, it will include the requisite  
NOT NULL markings in the CREATE TABLE commands, and then add the  
primary key as a separate step.  The primary key addition generates a  
SET NOT NULL as a subcommand, just to be sure.  So the situation where  
a SET NOT NULL is redundant does arise in the real world.  
  
Skipping the recursion does more than just save a few cycles: it means  
that a command such as "ALTER TABLE ONLY partition_parent ADD PRIMARY  
KEY" will take locks only on the partition parent table, not on the  
partitions.  It turns out that parallel pg_restore is effectively  
assuming that that's true, and has little choice but to do so because  
the dependencies listed for such a TOC entry don't include the  
partitions.  pg_restore could thus issue this ALTER while data restores  
on the partitions are still in progress.  Taking unnecessary locks on  
the partitions not only hurts concurrency, but can lead to actual  
deadlock failures, as reported by Domagoj Smoljanovic.  
  
(A contributing factor in the deadlock is that TRUNCATE on a child  
partition wants a non-exclusive lock on the parent.  This seems  
likewise unnecessary, but the fix for it is more invasive so we  
won't consider back-patching it.  Fortunately, getting rid of one  
of these two poor behaviors is enough to remove the deadlock.)  
  
Although support for partitioned primary keys came in with v11,  
this patch is dependent on the SET NOT NULL refactoring done by  
commit f4a3fdfbd, so we can only patch back to v12.  
  
Patch by me; thanks to Alvaro Herrera and Amit Langote for review.  
  
Discussion: https://postgr.es/m/VI1PR03MB31670CA1BD9625C3A8C5DD05EB230@VI1PR03MB3167.eurprd03.prod.outlook.com  

commit   : 3e3f8f20206cbbb8d30be528d2a640d14a95c25c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 16 Sep 2020 12:07:31 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 16 Sep 2020 12:07:31 -0400    

The code recorded cache invalidation events by zeroing the "localreloid"  
field of affected cache entries.  However, it's possible for an inval  
event to occur even while we have the entry open and locked.  So an  
ill-timed inval could result in "cache lookup failed for relation 0"  
errors, if the worker's code tried to use the cleared field.  We can  
fix that by creating a separate bool field to record whether the entry  
needs to be revalidated.  (In the back branches, cram the bool into  
what had been padding space, to avoid an ABI break in the somewhat  
unlikely event that any extension is looking at this struct.)  
  
Also, rearrange the logic in logicalrep_rel_open so that it  
does the right thing in cases where table_open would fail.  
We should retry the lookup by name in that case, but we didn't.  
  
The real-world impact of this is probably small.  In the first place,  
the error conditions are very low probability, and in the second place,  
the worker would just exit and get restarted.  We only noticed because  
in a CLOBBER_CACHE_ALWAYS build, the failure can occur repeatedly,  
preventing the worker from making progress.  Nonetheless, it's clearly  
a bug, and it impedes a useful type of testing; so back-patch to v10  
where this code was introduced.  
  
Discussion: https://postgr.es/m/1032727.1600096803@sss.pgh.pa.us  

commit   : 6e146a663536f86c8421ac6ed08c4eb9a69979fd    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Tue, 15 Sep 2020 21:34:05 -0700    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Tue, 15 Sep 2020 21:34:05 -0700    

Previously, it was based on nBlocksAllocated to account for tapes with  
open write buffers that may not have made it to the BufFile yet.  
  
That was unnecessary, because callers do not need to get the number of  
blocks while a tape has an open write buffer; and it also conflicted  
with the preallocation logic added for HashAgg.  
  
Reviewed-by: Peter Geoghegan  
Discussion: https://postgr.es/m/ce5af05900fdbd0e9185747825a7423c48501964.camel@j-davis.com  
Backpatch-through: 13  

commit   : 42a46f5a76ecb435ac3a29fc3a0d03f1cfff17ab    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Tue, 15 Sep 2020 21:16:31 -0700    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Tue, 15 Sep 2020 21:16:31 -0700    

This was an oversight. The purpose of 7fdd919ae7 was to avoid keeping  
tape buffers around unnecessisarily, but HashAgg didn't rewind early  
enough.  
  
Reviewed-by: Peter Geoghegan  
Discussion: https://postgr.es/m/1fb1151c2cddf8747d14e0532da283c3f97e2685.camel@j-davis.com  
Backpatch-through: 13  

commit   : 873cb8fca9b14bde3e1d5577fcbb7b76d303076d    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 15 Sep 2020 21:03:14 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 15 Sep 2020 21:03:14 -0300    

ALTER TABLE commands in an extension script are added to an event  
trigger command list; but starting with commit b5810de3f4 they do so in  
a memory context that's too short-lived, so when execution ends and time  
comes to use the entries, they've already been freed.  
  
(This would also be a problem with ALTER TABLE commands in a  
multi-command query string, but these serendipitously end in  
PortalContext -- which probably explains why it took so long for this to  
be reported.)  
  
Fix by using the memory context specifically set for that, instead.  
  
Backpatch to 13, where the aforementioned commit appeared.  
  
Reported-by: Philippe Beaudoin  
Author: Jehan-Guillaume de Rorthais <jgdr@dalibo.com>  
Discussion: https://postgr.es/m/20200902193715.6e0269d4@firost  

commit   : d42c6176446440b185fcb95c214b7e40d5758b60    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 15 Sep 2020 14:29:43 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 15 Sep 2020 14:29:43 -0400    

Per gripe from Jonathan Katz.  
  
Discussion: https://postgr.es/m/e0a4d177-d003-8ebb-5296-5a445472b66f@postgresql.org  

commit   : 001d2c5f15bf8d554a7fe28af033d82c24de4e44    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 15 Sep 2020 10:58:37 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 15 Sep 2020 10:58:37 -0400    

Parallel vacuuming isn't restricted to b-tree indexes.  
Noted by Peter Eisentraut.  
  
Discussion: https://postgr.es/m/f1c43223-3987-a23f-2063-18fd0aa4f0d4@2ndquadrant.com  

commit   : efea2b85fa2c3dec1c8039f1c97fcfe53ee5e82c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 14 Sep 2020 16:08:07 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 14 Sep 2020 16:08:07 -0400    

commit   : bab6f77f24407e0924dac292af9e65016fce99bf    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 14 Sep 2020 13:14:53 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 14 Sep 2020 13:14:53 +0200    

Source-Git-URL: https://git.postgresql.org/git/pgtranslation/messages.git  
Source-Git-Hash: 00c0d74fc1f1f2a831077fdf3655c6ae5eeceac3  

commit   : 6fb1c5b528267918a88c4143985a08a3c997e528    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sun, 13 Sep 2020 23:29:51 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sun, 13 Sep 2020 23:29:51 -0700    

A pre-commit review had reported the problem, but the fix reached only  
v10 and earlier.  Back-patch to v11.  
  
Discussion: https://postgr.es/m/20200423.140546.1055476118690602079.horikyota.ntt@gmail.com  

commit   : b1b53f15bbac106e241b14ae1bc13f2708fe74c8    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 14 Sep 2020 06:42:07 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 14 Sep 2020 06:42:07 +0200    

commit   : b380484a850b6bf7d9fc0d85c555a2366e38451f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 13 Sep 2020 12:51:21 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 13 Sep 2020 12:51:21 -0400    

transformCreateStmt() adjusts the transformed statement's RangeVar  
to specify the target schema explicitly, for the express reason  
of making sure that auxiliary statements derived by parse  
transformation operate on the right table.  But the refactoring  
I did in commit 502898192 got this wrong and passed the untransformed  
RangeVar to expandTableLikeClause().  This could lead to assertion  
failures or weird misbehavior if the wrong table was accessed.  
  
Per report from Alexander Lakhin.  Like the previous patch, back-patch  
to all supported branches.  
  
Discussion: https://postgr.es/m/05051f9d-b32b-cb35-6735-0e9f2ab86b5f@gmail.com  

commit   : e6bbe07deec9824eb62fbbf38c4bfe7aaf674d37    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 6 Sep 2020 16:46:13 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 6 Sep 2020 16:46:13 +0200    

The original stylesheets seemed to think this was a good idea, but our  
users find it confusing and unhelpful, so undo that logic.  
  
Reported-by: Fabien COELHO <coelho@cri.ensmp.fr>  
Discussion: https://www.postgresql.org/message-id/flat/alpine.DEB.2.22.394.2006210914370.859381%40pseudo  

commit   : 93106d71a18afdda2b9bf6e6b8e6c7f9cea2d0ef    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Fri, 11 Sep 2020 17:10:02 -0700    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Fri, 11 Sep 2020 17:10:02 -0700    

The preallocation logic is only useful for HashAgg, so disable it when  
sorting.  
  
Also, adjust an out-of-date comment.  
  
Reviewed-by: Peter Geoghegan  
Discussion: https://postgr.es/m/CAH2-Wzn_o7tE2+hRVvwSFghRb75AJ5g-nqGzDUqLYMexjOAe=g@mail.gmail.com  
Backpatch-through: 13  

commit   : aeb781107a7ca0cfe109c188534ecbf9c392f6ba    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 11 Sep 2020 16:15:47 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 11 Sep 2020 16:15:47 -0300    

The stats target can be set since commit d06215d03, but wasn't shown by  
psql.  
  
Author: Justin Pryzby <justin@telsasoft.com>  
Discussion: https://postgr.es/m/20200831050047.GG5450@telsasoft.com  
Reviewed-by: Georgios Kokolatos <gkokolatos@protonmail.com>  
Reviewed-by: Tatsuro Yamada <tatsuro.yamada.tf@nttcom.co.jp>  

commit   : 6dcec8fe13b41b0773e9122168a1b53f3e458206    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 11 Sep 2020 12:53:25 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 11 Sep 2020 12:53:25 -0300    

Thinko in 40b3e2c201af.  
  
Reported-by: "Wang, Shenhao" <wangsh.fnst@cn.fujitsu.com>  
Discussion: https://postgr.es/m/ed98706b82694b57a8c0d339a10732aa@G08CNEXMBPEKD06.g08.fujitsu.local  

commit   : 9892564121d425291c4fd06ff083147dd70b9156    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 10 Sep 2020 18:42:57 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 10 Sep 2020 18:42:57 -0400    

Justin Pryzby  
  
Discussion: https://postgr.es/m/20200910222705.GJ18552@telsasoft.com  

commit   : 3965de54e718600a4703233936e56a3202caf73f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 10 Sep 2020 17:43:16 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 10 Sep 2020 17:43:16 -0400    

Also set the release date ... hopefully we won't have to change that.  

commit   : 3d92252d7d8bf7080ba61f1bda3d27bd8a3617e1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 10 Sep 2020 13:14:09 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 10 Sep 2020 13:14:09 -0400    

Jonathan S. Katz, minor tweaks by me  
  
Discussion: https://postgr.es/m/448a382b-ae07-3126-5a08-aacda9aa28ea@postgresql.org  

commit   : 3f29aa48b6df318e43d0efe5735f61175ef38574    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 10 Sep 2020 12:06:26 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 10 Sep 2020 12:06:26 -0400    

Bring the signal handling for startup-packet collection into line  
with the policy established in commits bedadc732 and 8e19a8264,  
namely don't risk running atexit callbacks when handling SIGQUIT.  
  
Ideally, we'd not do so for SIGTERM or timeout interrupts either,  
but that change seems a bit too risky for the back branches.  
For now, just improve the comments in this area to describe the risk.  
  
Also relocate where BackendInitialize re-disables these interrupts,  
to minimize the code span where they're active.  This doesn't buy  
a whole lot of safety, but it can't hurt.  
  
In passing, rename startup_die() to remove confusion about whether  
it is for the startup process.  
  
Like the previous commits, back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/1850884.1599601164@sss.pgh.pa.us  

commit   : 9f358c5ef31327f7a67af783f5f37468bbac3aed    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 10 Sep 2020 15:31:09 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 10 Sep 2020 15:31:09 +0200    

We have had multiple reports that point to the  
'@colReorder=latn-digit' collation customization being buggy.  We have  
reported this to ICU and are waiting for a fix.  In the meantime,  
remove references to this from the documentation and replace it by  
another reordering example.  Apparently, many users have been picking  
up this example specifically from the documentation.  
  
Author: Jehan-Guillaume de Rorthais <jgdr@dalibo.com>  
Discussion: https://www.postgresql.org/message-id/flat/153201618542.1404.3611626898935613264%40wrigleys.postgresql.org  

commit   : 727f6fb8f71f7ed64e6883164765bbf6cb7684ec    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Thu, 10 Sep 2020 14:15:26 +0200    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Thu, 10 Sep 2020 14:15:26 +0200    

Reported-by: Robert Kahlert  
Author: Daniel Gustafsson  

commit   : d601a930756b96fe05beb75a1b624a8155c98cc8    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Thu, 10 Sep 2020 18:00:01 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Thu, 10 Sep 2020 18:00:01 +0900    

Do some minor cleanup for commit c8434d64c: 1) remove a useless  
assignment (in normal builds) and 2) improve comments a little.  
  
Back-patch to v13 where the aforementioned commit went in.  
  
Author: Etsuro Fujita  
Reviewed-by: Alvaro Herrera  
Discussion: https://postgr.es/m/CAPmGK16yCd2R4=bQ4g8N2dT9TtA5ZU+qNmJ3LPc_nypbNy4_2A@mail.gmail.com  

commit   : 32a433455a0a6918b9c8f300d6c0be73ef06e9f9    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Thu, 10 Sep 2020 16:15:00 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Thu, 10 Sep 2020 16:15:00 +0900    

Standardize Japanese names as given-name-first.  
  
Author: Etsuro Fujita  
Reviewed-by: Peter Eisentraut  
Discussion: https://postgr.es/m/CAPmGK14S5frHWzsKS14R2LeMjKkjr5PeqRGiKZ0os0A+o8BWuQ@mail.gmail.com  

commit   : b3d89b7a889614a5ad549bae49b8a6fdda3a6bdd    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 10 Sep 2020 15:50:42 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 10 Sep 2020 15:50:42 +0900    

Some comments are fixed while on it.  
  
Author: Justin Pryzby  
Discussion: https://postgr.es/m/20200818171702.GK17022@telsasoft.com  
Backpatch-through: 9.6  

commit   : 6f15be5bedfc423b8a8f2f0282e2a0eb20a16663    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Wed, 9 Sep 2020 18:50:24 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Wed, 9 Sep 2020 18:50:24 -0700    

Move applicable code out of RelationBuildDesc(), which nailed relations  
bypass.  Non-assert builds experienced no known problems.  Back-patch to  
v13, where commit c6b92041d38512a4176ed76ad06f713d2e6c01a8 introduced  
rd_firstRelfilenodeSubid.  
  
Kyotaro Horiguchi.  Reported by Justin Pryzby.  
  
Discussion: https://postgr.es/m/20200907023737.GA7158@telsasoft.com  

commit   : 35e59398abbb562f1e831af206f1d1cc8c3cb7db    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 9 Sep 2020 15:32:34 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 9 Sep 2020 15:32:34 -0400    

Commit 8e19a8264 changed the SIGQUIT handlers of almost all server  
processes not to run atexit callbacks.  The archiver process was  
skipped, perhaps because it's not connected to shared memory; but  
it's just as true here that running atexit callbacks in a signal  
handler is unsafe.  So let's make it work like the rest.  
  
In HEAD and v13, we can use the common SignalHandlerForCrashExit  
handler.  Before that, just tweak pgarch_exit to use _exit(2)  
explicitly.  
  
Like the previous commit, back-patch to all supported branches.  
  
Kyotaro Horiguchi, back-patching by me  
  
Discussion: https://postgr.es/m/1850884.1599601164@sss.pgh.pa.us  

commit   : 6b473ab4f23736d67c420909ab65c55228dcd6e6    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 9 Sep 2020 12:00:49 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 9 Sep 2020 12:00:49 -0400    

Commit 15cb2bd27 neglected to make the running text match the  
tables, leaving the reader with the strong impression that  
we cannot count.  Also, don't drop an unrelated para between  
a table and the para describing it.  

commit   : aa33187164e1d8571f1568f0470aaace8f791876    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 9 Sep 2020 11:53:39 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 9 Sep 2020 11:53:39 -0400    

Alexander Lakhin  
  
Discussion: https://postgr.es/m/ce7debdd-c943-d7a7-9b41-687107b27831@gmail.com  

commit   : 1bf0b9c5f58c61c160519a77a8f9dd24cea68b32    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Wed, 9 Sep 2020 12:20:53 +0200    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Wed, 9 Sep 2020 12:20:53 +0200    

Mistake in commit 68b603e1a9.  
  
Reported-by: Ian Barwick  

commit   : d0230a43fcae6f923fcedfe6f27db7fca8760d95    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 8 Sep 2020 19:35:15 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 8 Sep 2020 19:35:15 -0300    

Partitioning tuple route code assumes that the partition chosen while  
descending the partition hierarchy is always the correct one.  This is  
true except when the partition is the default partition and another  
partition has been added concurrently: the partition constraint changes  
and we don't recheck it.  This can lead to tuples mistakenly being added  
to the default partition that should have been rejected.  
  
Fix by rechecking the default partition constraint while descending the  
hierarchy.  
  
An isolation test based on the reproduction steps described by Hao Wu  
(with tweaks for extra coverage) is included.  
  
Backpatch to 12, where this bug came in with 898e5e3290a7.  
  
Reported by: Hao Wu <hawu@vmware.com>  
Author: Amit Langote <amitlangote09@gmail.com>  
Author: Álvaro Herrera <alvherre@alvh.no-ip.org>  
Discussion: https://postgr.es/m/CA+HiwqFqBmcSSap4sFnCBUEL_VfOMmEKaQ3gwUhyfa4c7J_-nA@mail.gmail.com  
Discussion: https://postgr.es/m/DM5PR0501MB3910E97A9EDFB4C775CF3D75A42F0@DM5PR0501MB3910.namprd05.prod.outlook.com  

commit   : b61d048e0d480f4311c62bf3026879c83ba9aaad    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Mon, 7 Sep 2020 13:31:59 -0700    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Mon, 7 Sep 2020 13:31:59 -0700    

Tomas Vondra observed that the IO behavior for HashAgg tends to be  
worse than for Sort. Penalize HashAgg IO costs accordingly.  
  
Also, account for the CPU effort of spilling the tuples and reading  
them back.  
  
Discussion: https://postgr.es/m/20200906212112.nzoy5ytrzjjodpfh@development  
Reviewed-by: Tomas Vondra  
Backpatch-through: 13  

commit   : e02c99bff6fcf7a14292cf99b16e4810ea89a2de    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 7 Sep 2020 14:52:33 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 7 Sep 2020 14:52:33 -0400    

Some of the pre-existing comments were vague about whether they  
referred to all polymorphic types or only the old-style ones.  
  
Also be more consistent about using the "family 1" vs "family 2"  
terminology.  
  
Himanshu Upadhyaya and Tom Lane  
  
Discussion: https://postgr.es/m/CAPF61jBUg9XoMPNuLpoZ+h6UZ2VxKdNt3rQL1xw1GOBwjWzAXQ@mail.gmail.com  

commit   : 1e83138da14d61d572b0b58a9da6a2cf535ea198    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 7 Sep 2020 09:08:58 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 7 Sep 2020 09:08:58 +0200    

current through b7cf9e42ac2d4b153eb781195ebf369d4b8b566e  

commit   : b7cf9e42ac2d4b153eb781195ebf369d4b8b566e    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 7 Sep 2020 14:35:13 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 7 Sep 2020 14:35:13 +0900    

The previous version of the docs mentioned that files are rewritten,  
implying that a second copy of each file gets created, but each file is  
updated in-place.  
  
Author: Michael Banck  
Reviewed-by: Daniel Gustafsson, Michael Paquier  
Discussion: https://postgr.es/m/858086b6a42fb7d17995b6175856f7e7ec44d0a2.camel@credativ.de  
Backpatch-through: 12  

commit   : a82919afe26ad93a135aa5f017a3f31ec5a6547a    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Sun, 6 Sep 2020 19:28:32 +0200    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Sun, 6 Sep 2020 19:28:32 +0200    

It's better to use a relative path into the data directory, than to a  
hardcoded home directory of user 'josh'.  
  
Discussion: https://postgr.es/m/CABUevEyuf67Yu_r9gpDMs5MKifK7+-+pe=ZjKzya4JEn9kUk1w@mail.gmail.com  

commit   : f04203ab7e683bc3e961a40b002cf3c8d1d12100    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 6 Sep 2020 12:55:13 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 6 Sep 2020 12:55:13 -0400    

We reported the wrong types when complaining that an aggregate's  
moving-aggregate implementation is inconsistent with its regular  
implementation.  
  
This was wrong since the feature was introduced, so back-patch  
to all supported branches.  
  
Jeff Janes  
  
Discussion: https://postgr.es/m/CAMkU=1x808LH=LPhZp9mNSP0Xd1xDqEd+XeGcvEe48dfE6xV=A@mail.gmail.com  

commit   : e7f06ea60a3c07128176b294ce3fb0555edd15a5    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 6 Sep 2020 11:50:40 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 6 Sep 2020 11:50:40 -0400    

This is duplicative of an lstat that was just done by the calling  
function (traverse_datadir), besides which we weren't really doing  
anything with the results.  There's not much point in checking to  
see if someone removed the file since the previous lstat, since the  
FILE_ACTION_REMOVE code would have to deal with missing-file cases  
anyway.  Moreover, the "exists = false" assignment was a dead store;  
nothing was done with that value later.  
  
A syscall saved is a syscall earned, so back-patch to 9.5  
where this code was introduced.  
  
Discussion: https://postgr.es/m/1221796.1599329320@sss.pgh.pa.us  

commit   : 8df601bd4067ecdf373ebe43bdf03159a12e2e9d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 4 Sep 2020 21:01:59 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 4 Sep 2020 21:01:59 -0400    

I happened to notice that the new test case I added in b55b4dad9  
falls over if one runs "make check" repeatedly; though not in branches  
after v10.  That's because it was assuming that tmp_check/pgpass  
wouldn't exist already.  However, it's only been since v11 that the  
Makefiles forcibly remove all of tmp_check/ before starting a TAP run.  
This fix to unlink the file is therefore strictly necessary only in  
v10 ... but it seems wisest to do it across the board, rather than  
let the test rely on external logic to get the conditions right.  

commit   : 9b81a30f924cf30e6bf3abb3366706440351e163    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 4 Sep 2020 20:20:05 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 4 Sep 2020 20:20:05 -0400    

Commit 3f60f690f only partially fixed the broken-status-tracking  
issue in LogicalRepApplyLoop: we need ping_sent to have the same  
lifetime as last_recv_timestamp.  The effects are much less serious  
than what that commit fixed, though.  AFAICS this would just lead to  
extra ping requests being sent, once per second until the sender  
responds.  Still, it's a bug, so backpatch to v10 as before.  
  
Discussion: https://postgr.es/m/959627.1599248476@sss.pgh.pa.us  

commit   : 4a4f3bf983b4abd908585a8d752eee0e47627034    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Fri, 4 Sep 2020 12:01:58 -0700    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Fri, 4 Sep 2020 12:01:58 -0700    

Reported-by: Peter Geoghegan  
Discussion: https://postgr.es/m/CAH2-Wz=NZPZc3-fkdmvu=w2itx0PiB-G6QpxHXZOjuvFAzPdZw@mail.gmail.com  
Backpatch-through: 13  

commit   : 72857482c135677703111855f33550c442108eaa    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 4 Sep 2020 13:53:09 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 4 Sep 2020 13:53:09 -0400    

If this data is not collected, pg_dump segfaults if asked for column  
inserts.  
  
Fix by Fabrízio de Royes Mello  
  
Backpatch to release 12 where the bug was introduced.  

commit   : 7574af1e1b94a4de7a6f63f3a7854a508ab7b0e0    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Fri, 4 Sep 2020 13:27:52 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Fri, 4 Sep 2020 13:27:52 -0400    

Reported-by: Kelly Min  
  
Discussion: https://postgr.es/m/CAPSbxatOiQO90LYpSC3+svAU9-sHgDfEP4oFhcEUt_X=DqFA9g@mail.gmail.com  
  
Backpatch-through: 9.5  

commit   : afec6ba0bae0258835b81fcc0eeed3ff9c455427    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 4 Sep 2020 12:40:28 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 4 Sep 2020 12:40:28 -0400    

The "DROP ACCESS METHOD gist2" test will require locking the index  
to be dropped and then its table; while most ordinary operations  
lock a table first then its index.  While no concurrent test scripts  
should be touching fast_emp4000, autovacuum might chance to be  
processing that table when the DROP runs, resulting in a deadlock  
failure.  This is pretty rare but we see it in the buildfarm from  
time to time.  
  
To fix, acquire a lock on fast_emp4000 before issuing the DROP.  
  
Since the point of the exercise is mostly to prevent buildfarm  
failures, back-patch to 9.6 where this test was introduced.  
  
Discussion: https://postgr.es/m/839004.1599185607@sss.pgh.pa.us  

commit   : 17424e79d9794b00bdb6653185fc27ba423d8d81    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 3 Sep 2020 16:52:09 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 3 Sep 2020 16:52:09 -0400    

Because sigsetjmp() will restore the initial state with signals blocked,  
the code path in bgworker.c for reporting an error and exiting would  
execute that way.  Usually this is fairly harmless; but if a parallel  
worker had an error message exceeding the shared-memory communication  
buffer size (16K) it would lock up, because it would wait for a  
resume-sending signal from its parallel leader which it would never  
detect.  
  
To fix, just unblock signals at the appropriate point.  
  
This can be shown to fail back to 9.6.  The lack of parallel query  
infrastructure makes it difficult to provide a simple test case for  
9.5; but I'm pretty sure the issue exists in some form there as well,  
so apply the code change there too.  
  
Vignesh C, reviewed by Bharath Rupireddy, Robert Haas, and myself  
  
Discussion: https://postgr.es/m/CALDaNm1d1hHPZUg3xU4XjtWBOLCrA+-2cJcLpw-cePZ=GgDVfA@mail.gmail.com  

commit   : 214bc9038e39e209924514b77db4ee491f95509a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 3 Sep 2020 11:45:26 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 3 Sep 2020 11:45:26 -0400    

The majority of our audience is probably using a pre-packaged Postgres  
build rather than raw sources.  For them, much of runtime.sgml is not  
too relevant, and they should be reading the packager's docs instead.  
Add some notes pointing that way in appropriate places.  
  
Text by me; thanks to Daniel Gustafsson for review and discussion,  
and to Laurenz Albe for an earlier version.  
  
Discussion: https://postgr.es/m/159430831443.16535.11360317280100947016@wrigleys.postgresql.org  

commit   : 352b8cf59f400e69a80db12f920adf12a1b0607c    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 1 Sep 2020 20:43:23 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 1 Sep 2020 20:43:23 -0400    

Introduced by 8b08f7d4820f; backpatch to 11.  
  
Discussion: https://postgr.es/m/20200812214918.GA30353@alvherre.pgsql  

commit   : 2c7db50ce83ec375ad6ddeba498f07c78bc10e97    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 1 Sep 2020 17:00:10 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 1 Sep 2020 17:00:10 -0400    

Previous wording was "between".  
  
Reported-by: Pavel Luzanov  
  
Discussion: https://postgr.es/m/26906a54-d7cb-2f8e-eed7-e31660024694@postgrespro.ru  
  
Backpatch-through: 9.5  

commit   : 15dad5776578e884ee7857abb278a116c0c3e578    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 1 Sep 2020 13:40:43 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 1 Sep 2020 13:40:43 -0400    

We were already raising an error for DROP INDEX CONCURRENTLY on a  
partitioned table, albeit a different and confusing one:  
  ERROR:  DROP INDEX CONCURRENTLY must be first action in transaction  
  
Change that to throw a more comprehensible error:  
  ERROR:  cannot drop partitioned index \"%s\" concurrently  
  
Michael Paquier authored the test case for indexes on temporary  
partitioned tables.  
  
Backpatch to 11, where indexes on partitioned tables were added.  
  
Reported-by: Jan Mussler <jan.mussler@zalando.de>  
Reviewed-by: Michael Paquier <michael@paquier.xyz>  
Discussion: https://postgr.es/m/16594-d2956ca909585067@postgresql.org  

commit   : 4178b749963cbf28d438b81e38dedcf885ccdda3    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 1 Sep 2020 13:14:44 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 1 Sep 2020 13:14:44 -0400    

Historically there's been a hard-wired assumption here that no line of  
a .pgpass file could be as long as NAMEDATALEN*5 bytes.  That's a bit  
shaky to start off with, because (a) there's no reason to suppose that  
host names fit in NAMEDATALEN, and (b) this figure fails to allow for  
backslash escape characters.  However, it fails completely if someone  
wants to use a very long password, and we're now hearing reports of  
people wanting to use "security tokens" that can run up to several  
hundred bytes.  Another angle is that the file is specified to allow  
comment lines, but there's no reason to assume that long comment lines  
aren't possible.  
  
Rather than guessing at what might be a more suitable limit, let's  
replace the fixed-size buffer with an expansible PQExpBuffer.  That  
adds one malloc/free cycle to the typical use-case, but that's surely  
pretty cheap relative to the I/O this code has to do.  
  
Also, add TAP test cases to exercise this code, because there was no  
test coverage before.  
  
This reverts most of commit 2eb3bc588, as there's no longer a need for  
a warning message about overlength .pgpass lines.  (I kept the explicit  
check for comment lines, though.)  
  
In HEAD and v13, this also fixes an oversight in 74a308cf5: there's not  
much point in explicit_bzero'ing the line buffer if we only do so in two  
of the three exit paths.  
  
Back-patch to all supported branches, except that the test case only  
goes back to v10 where src/test/authentication/ was added.  
  
Discussion: https://postgr.es/m/4187382.1598909041@sss.pgh.pa.us  

commit   : 73018f564af91b135e541b28133369c5e3de975d    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 31 Aug 2020 18:48:38 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 31 Aug 2020 18:48:38 -0400    

Reported-by: Bernd Helmle  
  
Discussion: https://postgr.es/m/31acf8b0f1f701d53245e0cae38abdf5c3a0d559.camel@oopsware.de  
  
Backpatch-through: 13  

commit   : 1d3ff89ecfbbdd8bf56d4773d8f2749156eeb7c1    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 31 Aug 2020 18:33:37 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 31 Aug 2020 18:33:37 -0400    

This follows the American format,  
https://jakubmarian.com/comma-after-i-e-and-e-g/. There is no intention  
of requiring this format for future text, but making existing text  
consistent every few years makes sense.  
  
Discussion: https://postgr.es/m/20200825183619.GA22369@momjian.us  
  
Backpatch-through: 9.5  

commit   : 787ccf5a5fc92698e8cc8ebfb6fe1a0bf28981a4    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 31 Aug 2020 17:51:31 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 31 Aug 2020 17:51:31 -0400    

Reported-by: Antonin Houska  
  
Discussion: https://postgr.es/m/21643.1595353537@antos  
  
Backpatch-through: 9.5  

commit   : cef30b66fdf619a1b7aa0c2605719e64e980c6f2    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 31 Aug 2020 17:36:23 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 31 Aug 2020 17:36:23 -0400    

Also mention files included by postgresql.conf.  
  
Reported-by: Álvaro Herrera  
  
Discussion: https://postgr.es/m/08AD4526-75AB-457B-B2DD-099663F28040@yesql.se  
  
Backpatch-through: 9.5  

commit   : 97dc0d1d58916e2f063ce8a7eec6bd4d3bc29197    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 31 Aug 2020 17:04:40 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 31 Aug 2020 17:04:40 -0400    

Reported-by: Erwin Brandstetter <brsaweda@gmail.com>  
Discussion: https://postgr.es/m/CAGHENJ6Le7S3qJJx2TvWvTwRNS3N=BtoNeb7AF2rZvfNBMeQcg@mail.gmail.com  

commit   : bef7b917a76af659b4d6bce813702764e2c749db    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 31 Aug 2020 17:05:53 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 31 Aug 2020 17:05:53 -0400    

It is an int64.  
  
Reported-by: ajulien@shaktiware.fr  
  
Discussion: https://postgr.es/m/159845038271.24995.15682121015698255155@wrigleys.postgresql.org  
  
Backpatch-through: 9.5  

commit   : 9bb4f98bb7745b7339fb7d102cdc36d66c002f67    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 31 Aug 2020 16:59:59 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 31 Aug 2020 16:59:59 -0400    

There is an file-fdw example that reads the server config file, so cross  
link them.  
  
Reported-by: Oleg Samoilov  
  
Discussion: https://postgr.es/m/159800192078.2886.10431506404995508950@wrigleys.postgresql.org  
  
Backpatch-through: 9.5  

commit   : 8924ca865b18cac0b655170989bcd9507991d06f    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 31 Aug 2020 16:21:03 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 31 Aug 2020 16:21:03 -0400    

Specifically, explain the v3_ca openssl specification.  
  
Discussion: https://postgr.es/m/20200824175653.GA32411@momjian.us  
  
Backpatch-through: 9.5  

commit   : 1bb41c6ad795e018e396eb3e216b2d21fadc865a    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 31 Aug 2020 15:23:19 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 31 Aug 2020 15:23:19 -0400    

For PG, "durable storage" has a clear meaning, while "stable storage"  
does not, so use the former.  
  
Discussion: https://postgr.es/m/20200817165222.GA31806@momjian.us  
  
Backpatch-through: 9.5  

commit   : 8006ac1c5117a56fcd138d663a3fe3709c8f9988    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 31 Aug 2020 13:49:17 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 31 Aug 2020 13:49:17 -0400    

It wasn't clear the non-integers are cast to integers for subscripting,  
rather than throwing an error.  
  
Reported-by: sean@materialize.io  
  
Discussion: https://postgr.es/m/159538675800.624.7728794628229799531@wrigleys.postgresql.org  
  
Backpatch-through: 9.5  

commit   : 64fd65008c62ec011ba2d0673ca09849ae2b07c8    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 31 Aug 2020 13:43:04 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 31 Aug 2020 13:43:04 -0400    

Adds constraints and improves wording.  
  
Reported-by: 2552891@gmail.com  
  
Discussion: https://postgr.es/m/159586122762.680.1361378513036616007@wrigleys.postgresql.org  
  
Backpatch-through: 9.5  

commit   : 785affc1d653bac43b7d4fad93f22e9e51aefcc1    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 31 Aug 2020 13:20:04 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 31 Aug 2020 13:20:04 -0400    

This was not clearly documented when procedures were added in PG 11.  
  
Reported-by: Robin Abbi  
  
Discussion: https://postgr.es/m/CAGmg_NX327KKVuJmbWZD=pGutYFxzZjX1rU+3ji8UuX=8ONn9Q@mail.gmail.com  
  
Backpatch-through: 11  

commit   : 3a1f6a2581e41ee2c724e8422675942d30a52ff7    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Mon, 31 Aug 2020 13:03:54 +0200    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Mon, 31 Aug 2020 13:03:54 +0200    

It has always (since the first commit) worked with relative paths, so  
use the same wording as other parts of the documentation.  
  
Author: Bruce Momjian  
Discussion: https://postgr.es/m/CABUevExx-hm=cit+A9LeKBH39srvk8Y2tEZeEAj5mP8YfzNKUg@mail.gmail.com  

commit   : 845cfe012fd15300cd090b05fb4029a26b848a67    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 30 Aug 2020 14:37:24 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 30 Aug 2020 14:37:24 -0400    

Per discussion, we're planning to remove parser support for postfix  
operators in order to simplify the grammar.  So it behooves us to  
put out a deprecation notice at least one release before that.  
  
There is only one built-in postfix operator, ! for factorial.  
Label it deprecated in the docs and in pg_description, and adjust  
some examples that formerly relied on it.  (The sister prefix  
operator !! is also deprecated.  We don't really have to remove  
that one, but since we're suggesting that people use factorial()  
instead, it seems better to remove both operators.)  
  
Also state in the CREATE OPERATOR ref page that postfix operators  
in general are going away.  
  
Although this changes the initial contents of pg_description,  
I did not force a catversion bump; it doesn't seem essential.  
  
In v13, also back-patch 4c5cf5431, so that there's someplace for  
the <link>s to point to.  
  
Mark Dilger and John Naylor, with some adjustments by me  
  
Discussion: https://postgr.es/m/BE2DF53D-251A-4E26-972F-930E523580E9@enterprisedb.com  

commit   : 1df14a5669428c0060ebdcebed8c1f807b659893    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 27 Aug 2020 17:36:13 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 27 Aug 2020 17:36:13 -0400    

collectMatchBitmap() needs to re-find the index tuple it was previously  
looking at, after transiently dropping lock on the index page it's on.  
The tuple should still exist and be at its prior position or somewhere  
to the right of that, since ginvacuum never removes tuples but  
concurrent insertions could add one.  However, there was a thinko in  
that logic, to the effect of expecting any inserted tuples to have the  
same index "attnum" as what we'd been scanning.  Since there's no  
physical separation of tuples with different attnums, it's not terribly  
hard to devise scenarios where this fails, leading to transient "lost  
saved point in index" errors.  (While I've duplicated this with manual  
testing, it seems impossible to make a reproducible test case with our  
available testing technology.)  
  
Fix by just continuing the scan when the attnum doesn't match.  
  
While here, improve the error message used if we do fail, so that it  
matches the wording used in btree for a similar case.  
  
collectMatchBitmap()'s posting-tree code path was previously not  
exercised at all by our regression tests.  While I can't make  
a regression test that exhibits the bug, I can at least improve  
the code coverage here, so do that.  The test case I made for this  
is an extension of one added by 4b754d6c1, so it only works in  
HEAD and v13; didn't seem worth trying hard to back-patch it.  
  
Per bug #16595 from Jesse Kinkead.  This has been broken since  
multicolumn capability was added to GIN (commit 27cb66fdf),  
so back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/16595-633118be8eef9ce2@postgresql.org  

commit   : 32c42b815ad2377c0bddc4f55b7bf32a5204a87d    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 25 Aug 2020 09:53:12 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 25 Aug 2020 09:53:12 -0400    

They are not "requested" by the server.  
  
Reported-by: Kyotaro Horiguchi  
  
Discussion: https://postgr.es/m/20200825.155320.986648039251743210.horikyota.ntt@gmail.com  
  
Backpatch-through: 9.5  

commit   : 62340f8eca4c9d4e49097eaf0a341aca8450b56b    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 25 Aug 2020 07:29:05 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 25 Aug 2020 07:29:05 +0200    

This fixes some instances that were missed in earlier processings and  
that now look a bit strange because they are inconsistent with nearby  
titles.  

commit   : b4ef5ac0b7bfa734ad908bb5577cf4ee65ce2974    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Mon, 24 Aug 2020 08:22:54 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Mon, 24 Aug 2020 08:22:54 +0530    

We were displaying the wrong phase information for 'info' message in the  
index clean up phase because we were switching to the previous phase a bit  
early. We were also not displaying context information for heap phase  
unless the block number is valid which is fine for error cases but for  
messages at 'info' or lower error level it appears to be inconsistent with  
index phase information.  
  
Reported-by: Sawada Masahiko  
Author: Sawada Masahiko  
Reviewed-by: Amit Kapila  
Backpatch-through: 13, where it was introduced  
Discussion: https://postgr.es/m/CA+fd4k4HcbhPnCs7paRTw1K-AHin8y4xKomB9Ru0ATw0UeTy2w@mail.gmail.com  

commit   : de627adaad3a161b3ae0cafeb76c20519845799b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 22 Aug 2020 14:46:40 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 22 Aug 2020 14:46:40 -0400    

The trouble with doing this is that an apparently-constant subquery  
output column isn't really constant if it is a grouping column that  
appears in only some of the grouping sets.  A qual using such a  
column would be subject to incorrect const-folding after push-down,  
as seen in bug #16585 from Paul Sivash.  
  
To fix, just disable qual pushdown altogether if the sub-query has  
nonempty groupingSets.  While we could imagine far less restrictive  
solutions, there is not much point in working harder right now,  
because subquery_planner() won't move HAVING clauses to WHERE within  
such a subquery.  If the qual stays in HAVING it's not going to be  
a lot more useful than if we'd kept it at the outer level.  
  
Having said that, this restriction could be removed if we used a  
parsetree representation that distinguished such outputs from actual  
constants, which is something I hope to do in future.  Hence, make  
the patch a minimal addition rather than integrating it more tightly  
(e.g. by renumbering the existing items in subquery_is_pushdown_safe's  
comment).  
  
Back-patch to 9.5 where grouping sets were introduced.  
  
Discussion: https://postgr.es/m/16585-9d8c340d23ade8c1@postgresql.org  

commit   : 47de6ac11b53cf24393a2ef048f9e8921163da0a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 22 Aug 2020 12:34:17 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 22 Aug 2020 12:34:17 -0400    

Commit 1281a5c90 rearranged the logic in this area rather drastically,  
and it broke the case of adding a foreign key constraint in the same  
ALTER that adds the pkey or unique constraint it depends on.  While  
self-referential fkeys are surely a pretty niche case, this used to  
work so we shouldn't break it.  
  
To fix, reorganize the scheduling rules in ATParseTransformCmd so  
that a transformed AT_AddConstraint subcommand will be delayed into  
a later pass in all cases, not only when it's been spit out as a  
side-effect of parsing some other command type.  
  
Also tweak the logic so that we won't run ATParseTransformCmd twice  
while doing this.  It seems to work even without that, but it's  
surely wasting cycles to do so.  
  
Per bug #16589 from Jeremy Evans.  Back-patch to v13 where the new  
code was introduced.  
  
Discussion: https://postgr.es/m/16589-31c8d981ca503896@postgresql.org  

commit   : 610394c7b876bc841464aad38f8abed09d63924e    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sat, 22 Aug 2020 22:26:18 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sat, 22 Aug 2020 22:26:18 +0900    

Author: Alexander Lakhin  
Discussion: https://postgr.es/m/a2345841-10a5-4eef-257c-02302347cf39@gmail.com  
Backpatch-through: 13  

commit   : 3669792934593a7b682c5b32dea41c9e3b48e6cc    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Fri, 21 Aug 2020 20:23:09 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Fri, 21 Aug 2020 20:23:09 -0400    

This is a redesign of the intro to the managing databases chapter.  
  
Discussion: https://postgr.es/m/159586122762.680.1361378513036616007@wrigleys.postgresql.org  
  
Author: David G. Johnston  
  
Backpatch-through: 9.5  

commit   : 35f2d22ba909735448606fefc126b73e4fb3c627    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Fri, 21 Aug 2020 18:29:37 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Fri, 21 Aug 2020 18:29:37 -0400    

Reported-by: Jürgen Purtz  
  
Discussion: https://postgr.es/m/15ec5428-d46a-1725-f38d-44986a977abb@purtz.de  
  
Author: Jürgen Purtz  
  
Backpatch-through: 11  

commit   : 894f5dea76e1a59fa2f3e1905c6a44f254d9d08b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 21 Aug 2020 15:00:42 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 21 Aug 2020 15:00:42 -0400    

If a CREATE TABLE command uses both LIKE and traditional inheritance,  
Vars in CHECK constraints and expression indexes that are absorbed  
from a LIKE parent table tended to get mis-numbered, resulting in  
wrong answers and/or bizarre error messages (though probably not any  
actual crashes, thanks to validation occurring in the executor).  
  
In v12 and up, the same could happen to Vars in GENERATED expressions,  
even in cases with no LIKE clause but multiple traditional-inheritance  
parents.  
  
The cause of the problem for LIKE is that parse_utilcmd.c supposed  
it could renumber such Vars correctly during transformCreateStmt(),  
which it cannot since we have not yet accounted for columns added via  
inheritance.  Fix that by postponing processing of LIKE INCLUDING  
CONSTRAINTS, DEFAULTS, GENERATED, INDEXES till after we've performed  
DefineRelation().  
  
The error with GENERATED and multiple inheritance is a simple oversight  
in MergeAttributes(); it knows it has to renumber Vars in inherited  
CHECK constraints, but forgot to apply the same processing to inherited  
GENERATED expressions (a/k/a defaults).  
  
Per bug #16272 from Tom Gottfried.  The non-GENERATED variants of the  
issue are ancient, presumably dating right back to the addition of  
CREATE TABLE LIKE; hence back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/16272-6e32da020e9a9381@postgresql.org  

commit   : bc2ebf3acfd287247cd9ee286c44e969af1c81de    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Sat, 22 Aug 2020 01:22:55 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Sat, 22 Aug 2020 01:22:55 +0900    

Commit 9d701e624f caused the regression test for EXPLAIN to fail on  
the buildfarm member prion. This happened because of instability of  
test output, i.e., in text format, whether "Planning:" line is output  
varies depending on the system state.  
  
This commit updated the regression test so that it ignores that  
"Planning:" line to produce more stable test output and get rid of  
the test failure.  
  
Back-patch to v13.  
  
Author: Fujii Masao  
Discussion: https://postgr.es/m/1803897.1598021621@sss.pgh.pa.us  

commit   : 674899ae02c375b03411c0676e7cfb4bafeebac9    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Fri, 21 Aug 2020 20:48:59 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Fri, 21 Aug 2020 20:48:59 +0900    

Commit ce77abe63c allowed EXPLAIN (BUFFERS) to report the information  
on buffer usage during planning phase. However three issues were  
reported regarding this feature.  
  
(1) Previously, EXPLAIN option BUFFERS required ANALYZE. So the query  
    had to be actually executed by specifying ANALYZE even when we  
    want to see only the planner's buffer usage. This was inconvenient  
    especially when the query was write one like DELETE.  
  
(2) EXPLAIN included the planner's buffer usage in summary  
    information. So SUMMARY option had to be enabled to report that.  
    Also this format was confusing.  
  
(3) The output structure for planning information was not consistent  
    between TEXT format and the others. For example, "Planning" tag  
    was output in JSON format, but not in TEXT format.  
  
For (1), this commit allows us to perform EXPLAIN (BUFFERS) without  
ANALYZE to report the planner's buffer usage.  
  
For (2), this commit changed EXPLAIN output so that the planner's  
buffer usage is reported before summary information.  
  
For (3), this commit made the output structure for planning  
information more consistent between the formats.  
  
Back-patch to v13 where the planner's buffer usage was allowed to  
be reported in EXPLAIN.  
  
Reported-by: Pierre Giraud, David Rowley  
Author: Fujii Masao  
Reviewed-by: David Rowley, Julien Rouhaud, Pierre Giraud  
Discussion: https://postgr.es/m/07b226e6-fa49-687f-b110-b7c37572f69e@dalibo.com  

commit   : 0d7437de73b68b0105d00ff4fed3e7894b02f6d5    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Fri, 21 Aug 2020 09:34:47 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Fri, 21 Aug 2020 09:34:47 +1200    

Reviewed-by: Abhijit Menon-Sen  
Reviewed-by: Andres Freund  
Discussion: https://postgr.es/m/CAApHDvobgmCs6CohqhKTUf7D8vffoZXQTCBTERo9gbOeZmvLTw%40mail.gmail.com  
Backpatch-through: 11, where JIT was added  

commit   : 2a9f042c47053e3ce73f634cce9622fa0151f63c    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 20 Aug 2020 13:49:04 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 20 Aug 2020 13:49:04 -0400    

When the leftover invalid index is "ccold", there's no need to re-run  
the command.  Reword the instructions to make that explicit.  
  
Backpatch to 12, where REINDEX CONCURRENTLY appeared.  
  
Author: Álvaro Herrera <alvherre@alvh.no-ip.org>  
Reviewed-by: Michael Paquier <michael@paquier.xyz>  
Reviewed-by: Julien Rouhaud <rjuju123@gmail.com>  
Discussion: https://postgr.es/m/20200819211312.GA15497@alvherre.pgsql  

commit   : 69ffc2f838990fb2c802087091ce7c2ff1b735eb    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 19 Aug 2020 14:07:49 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 19 Aug 2020 14:07:49 -0400    

Commit a477bfc1d fixed eval_const_expressions() to ensure that it  
didn't generate unnecessary RelabelType nodes, but I failed to notice  
that some other places in the planner had the same issue.  Really  
noplace in the planner should be using plain makeRelabelType(), for  
fear of generating expressions that should be equal() to semantically  
equivalent trees, but aren't.  
  
An example is that because canonicalize_ec_expression() failed  
to be careful about this, we could end up with an equivalence class  
containing both a plain Const, and a Const-with-RelabelType  
representing exactly the same value.  So far as I can tell this led to  
no visible misbehavior, but we did waste a bunch of cycles generating  
and evaluating "Const = Const-with-RelabelType" to prove such entries  
are redundant.  
  
Hence, move the support function added by a477bfc1d to where it can  
be more generally useful, and use it in the places where planner code  
previously used makeRelabelType.  
  
Back-patch to v12, like the previous patch.  While I have no concrete  
evidence of any real misbehavior here, it's certainly possible that  
I overlooked a case where equivalent expressions that aren't equal()  
could cause a user-visible problem.  In any case carrying extra  
RelabelType nodes through planning to execution isn't very desirable.  
  
Discussion: https://postgr.es/m/1311836.1597781384@sss.pgh.pa.us  

commit   : bff41b2b8938f5e3e7d536da6d7a14a1648b4dec    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 18 Aug 2020 13:13:09 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 18 Aug 2020 13:13:09 +0300    

As Tom Lane pointed out, it could defeat the compiler's printf() format  
string verification.  
  
Backpatch to v12, like that patch that introduced it.  
  
Discussion: https://www.postgresql.org/message-id/1069283.1597672779%40sss.pgh.pa.us  

commit   : b83f1bcca0bb460413da4ce856b030502b4f71c5    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 17 Aug 2020 16:20:06 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 17 Aug 2020 16:20:06 -0400    

This should improve stability in the tests.  
  
Per buildfarm member hyrax (CLOBBER_CACHE_ALWAYS) via Tom Lane.  
  
Discussion: https://postgr.es/m/871534.1597503261@sss.pgh.pa.us  

commit   : 8216a1d3ed27364c7b2a9e6db76f15202a6070c1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 17 Aug 2020 15:40:07 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 17 Aug 2020 15:40:07 -0400    

The description of what select_common_type() does was not terribly  
accurate.  Improve it.  
  
David Johnston and Tom Lane  
  
Discussion: https://postgr.es/m/1019930.1597613200@sss.pgh.pa.us  

commit   : 5ca1798f32b7fe730fef7ccd8d69e785a50134b8    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 17 Aug 2020 09:27:29 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 17 Aug 2020 09:27:29 +0300    

A number of client programs have a "--progress" option that when printing  
to a TTY, updates the current line by printing a '\r' and overwriting it.  
After the last line, '\n' needs to be printed to move the cursor to the  
next line. pg_basebackup and pgbench got this right, but pg_rewind and  
pg_checksums were slightly wrong. pg_rewind printed the newline to stdout  
instead of stderr, and pg_checksums printed the newline even when not  
printing to a TTY. Fix them, and also add a 'finished' argument to  
pg_basebackup's progress_report() function, to keep it consistent with  
the other programs.  
  
Backpatch to v12. pg_rewind's newline was broken with the logging changes  
in commit cc8d415117 in v12, and pg_checksums was introduced in v12.  
  
Discussion: https://www.postgresql.org/message-id/82b539e5-ae33-34b0-1aee-22b3379fd3eb@iki.fi  

commit   : 3424c6bef0b897f9c6800f55d34a162a07319795    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 17 Aug 2020 10:24:24 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 17 Aug 2020 10:24:24 +0900    

Since 806a2ae, the work of the bgwriter is split the checkpointer, but a  
portion of the documentation did not get the message.  
  
Author: Masahiko Sawada  
Discussion: https://postgr.es/m/CA+fd4k6jXxjAtjMVC=wG3=QGpauZBtcgN3Jhw+oV7zXGKVLKzQ@mail.gmail.com  
Backpatch-through: 9.5  

commit   : 277e49eca73a719695d0b74360b54124e76c6833    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 15 Aug 2020 15:43:34 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 15 Aug 2020 15:43:34 -0400    

Put the -r option in the right section (it certainly isn't an  
option controlling "the location and format of the output").  
  
Clarify the behavior of the tablespace and waldir options  
(that part per gripe from robert@interactive.co.uk).  
  
Make a large number of small copy-editing fixes in text that  
visibly wasn't written by native speakers, and try to avoid  
grammatical inconsistencies between the descriptions of  
the different options.  
  
Back-patch to v13, since HEAD hasn't meaningfully diverged yet.  
  
Discussion: https://postgr.es/m/159749418850.14322.216503677134569752@wrigleys.postgresql.org  

commit   : 592a589a04bd456410b853d86bd05faa9432cbbb    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sat, 15 Aug 2020 10:15:53 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sat, 15 Aug 2020 10:15:53 -0700    

The SimpleLruTruncate() header comment states the new coding rule.  To  
achieve this, add locktype "frozenid" and two LWLocks.  This closes a  
rare opportunity for data loss, which manifested as "apparent  
wraparound" or "could not access status of transaction" errors.  Data  
loss is more likely in pg_multixact, due to released branches' thin  
margin between multiStopLimit and multiWrapLimit.  If a user's physical  
replication primary logged ":  apparent wraparound" messages, the user  
should rebuild standbys of that primary regardless of symptoms.  At less  
risk is a cluster having emitted "not accepting commands" errors or  
"must be vacuumed" warnings at some point.  One can test a cluster for  
this data loss by running VACUUM FREEZE in every database.  Back-patch  
to 9.5 (all supported versions).  
  
Discussion: https://postgr.es/m/20190218073103.GA1434723@rfd.leadboat.com  

commit   : b538e83f17e36fd0fe0686815da0ff5866ce8a64    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 14 Aug 2020 22:14:03 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 14 Aug 2020 22:14:03 -0400    

nodeSubplan.c expects that the testexpr for a hashable ANY SubPlan  
has the form of one or more OpExprs whose LHS is an expression of the  
outer query's, while the RHS is an expression over Params representing  
output columns of the subquery.  However, the planner only went as far  
as verifying that the clauses were all binary OpExprs.  This works  
99.99% of the time, because the clauses have the right shape when  
emitted by the parser --- but it's possible for function inlining to  
break that, as reported by PegoraroF10.  To fix, teach the planner  
to check that the LHS and RHS contain the right things, or more  
accurately don't contain the wrong things.  Given that this has been  
broken for years without anyone noticing, it seems sufficient to just  
give up hashing when it happens, rather than go to the trouble of  
commuting the clauses back again (which wouldn't necessarily work  
anyway).  
  
While poking at that, I also noticed that nodeSubplan.c had a baked-in  
assumption that the number of hash clauses is identical to the number  
of subquery output columns.  Again, that's fine as far as parser output  
goes, but it's not hard to break it via function inlining.  There seems  
little reason for that assumption though --- AFAICS, the only thing  
it's buying us is not having to store the number of hash clauses  
explicitly.  Adding code to the planner to reject such cases would take  
more code than getting nodeSubplan.c to cope, so I fixed it that way.  
  
This has been broken for as long as we've had hashable SubPlans,  
so back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/1549209182255-0.post@n3.nabble.com  

commit   : b7cc21c57d738b41f6116f46d566b9949a433747    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 14 Aug 2020 17:33:31 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 14 Aug 2020 17:33:31 -0400    

Parallel-restoring a foreign key that references a partitioned table  
with several levels of partitions can fail:  
  
pg_restore: while PROCESSING TOC:  
pg_restore: from TOC entry 6684; 2606 29166 FK CONSTRAINT fk fk_a_fkey postgres  
pg_restore: error: could not execute query: ERROR:  there is no unique constraint matching given keys for referenced table "pk"  
Command was: ALTER TABLE fkpart3.fk  
    ADD CONSTRAINT fk_a_fkey FOREIGN KEY (a) REFERENCES fkpart3.pk(a);  
  
This happens in parallel restore mode because some index partitions  
aren't yet attached to the topmost partitioned index that the FK uses,  
and so the index is still invalid.  The current code marks the FK as  
dependent on the first level of index-attach dump objects; the bug is  
fixed by recursively marking the FK on their children.  
  
Backpatch to 12, where FKs to partitioned tables were introduced.  
  
Reported-by: Tom Lane <tgl@sss.pgh.pa.us>  
Author: Álvaro Herrera <alvherre@alvh.no-ip.org>  
Discussion: https://postgr.es/m/3170626.1594842723@sss.pgh.pa.us  
Backpatch: 12-master  

commit   : 1c6066fbdb70a92b10b8616652d25c4434cd222e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 14 Aug 2020 13:26:57 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 14 Aug 2020 13:26:57 -0400    

Up to now, upon receipt of a SIGTERM ("smart shutdown" command), the  
postmaster has immediately killed all "optional" background processes,  
and subsequently refused to launch new ones while it's waiting for  
foreground client processes to exit.  No doubt this seemed like an OK  
policy at some point; but it's a pretty bad one now, because it makes  
for a seriously degraded environment for the remaining clients:  
  
* Parallel queries are killed, and new ones fail to launch. (And our  
parallel-query infrastructure utterly fails to deal with the case  
in a reasonable way --- it just hangs waiting for workers that are  
not going to arrive.  There is more work needed in that area IMO.)  
  
* Autovacuum ceases to function.  We can tolerate that for awhile,  
but if bulk-update queries continue to run in the surviving client  
sessions, there's eventually going to be a mess.  In the worst case  
the system could reach a forced shutdown to prevent XID wraparound.  
  
* The bgwriter and walwriter are also stopped immediately, likely  
resulting in performance degradation.  
  
Hence, let's rearrange things so that the only immediate change in  
behavior is refusing to let in new normal connections.  Once the last  
normal connection is gone, shut everything down as though we'd received  
a "fast" shutdown.  To implement this, remove the PM_WAIT_BACKUP and  
PM_WAIT_READONLY states, instead staying in PM_RUN or PM_HOT_STANDBY  
while normal connections remain.  A subsidiary state variable tracks  
whether or not we're letting in new connections in those states.  
  
This also allows having just one copy of the logic for killing child  
processes in smart and fast shutdown modes.  I moved that logic into  
PostmasterStateMachine() by inventing a new state PM_STOP_BACKENDS.  
  
Back-patch to 9.6 where parallel query was added.  In principle  
this'd be a good idea in 9.5 as well, but the risk/reward ratio  
is not as good there, since lack of autovacuum is not a problem  
during typical uses of smart shutdown.  
  
Per report from Bharath Rupireddy.  
  
Patch by me, reviewed by Thomas Munro  
  
Discussion: https://postgr.es/m/CALj2ACXAZ5vKxT9P7P89D87i3MDO9bfS+_bjMHgnWJs8uwUOOw@mail.gmail.com  

commit   : cabec1dbdf405211c1a4d30f52a91e8de2cf7226    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 14 Aug 2020 10:40:50 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 14 Aug 2020 10:40:50 +0300    

commit   : 124772e3cac6d3bf6c1f6d32518209c6a3fdd3eb    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 13 Aug 2020 20:00:39 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 13 Aug 2020 20:00:39 -0400    

Make these examples self-contained by providing declarations of the  
user-defined row types they rely on.  There wasn't room to do this  
in the old doc format, but now there is, and I think it makes the  
examples a good bit less confusing.  

commit   : 2f29fd4cb2522dfd64888892f0442a0ead8c6dd0    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 13 Aug 2020 17:33:49 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 13 Aug 2020 17:33:49 -0400    

When a table is scanned by heapam_index_build_range_scan (née  
IndexBuildHeapScan) and the table lock being held allows concurrent data  
changes, it is possible for new HOT chains to sprout in a page that were  
unknown when the scan of a page happened.  This leads to an error such  
as  
  ERROR:  failed to find parent tuple for heap-only tuple at (X,Y) in table "tbl"  
because the root tuple was not present when we first obtained the list  
of the page's root tuples.  This can be fixed by re-obtaining the list  
of root tuples, if we see that a heap-only tuple appears to point to a  
non-existing root.  
  
This was reported by Anastasia as occurring for BRIN summarization  
(which exists since 9.5), but I think it could theoretically also happen  
with CREATE INDEX CONCURRENTLY (much older) or REINDEX CONCURRENTLY  
(very recent).  It seems a happy coincidence that BRIN forces us to  
backpatch this all the way to 9.5.  
  
Reported-by: Anastasia Lubennikova <a.lubennikova@postgrespro.ru>  
Diagnosed-by: Anastasia Lubennikova <a.lubennikova@postgrespro.ru>  
Co-authored-by: Anastasia Lubennikova <a.lubennikova@postgrespro.ru>  
Co-authored-by: Álvaro Herrera <alvherre@alvh.no-ip.org>  
Discussion: https://postgr.es/m/602d8487-f0b2-5486-0088-0f372b2549fa@postgrespro.ru  
Backpatch: 9.5 - master  

commit   : 8782ea2f36a2468e08c227c8d7907a5a1a9f5e32    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 12 Aug 2020 15:33:36 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 12 Aug 2020 15:33:36 -0400    

If a page range is desummarized at just the right time concurrently with  
an index walk, BRIN would raise an error indicating index corruption.  
This is scary and unhelpful; silently returning that the page range is  
not summarized is sufficient reaction.  
  
This bug was introduced by commit 975ad4e602ff as additional protection  
against a bug whose actual fix was elsewhere.  Backpatch equally.  
  
Reported-By: Anastasia Lubennikova <a.lubennikova@postgrespro.ru>  
Diagnosed-By: Alexander Lakhin <exclusion@gmail.com>  
Discussion: https://postgr.es/m/2588667e-d07d-7e10-74e2-7e1e46194491@postgrespro.ru  
Backpatch: 9.5 - master  

commit   : 1754a71986e806330ac3ab9e8125c902286b829d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Aug 2020 17:12:51 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Aug 2020 17:12:51 -0400    

commit   : b601f24c875d79e747eb8b50a4b1555ac22cf8f9    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2020 09:22:54 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2020 09:22:54 -0700    

Back-patch to v10, which introduced logical replication.  
  
Security: CVE-2020-14349  

commit   : 412c5c4010c0bec294f60a10cd56929680d3f95b    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2020 09:22:54 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2020 09:22:54 -0700    

This is like CVE-2018-1058 commit  
582edc369cdbd348d68441fc50fa26a84afd0c1a.  Today, a malicious user of a  
publisher or subscriber database can invoke arbitrary SQL functions  
under an identity running replication, often a superuser.  This fix may  
cause "does not exist" or "no schema has been selected to create in"  
errors in a replication process.  After upgrading, consider watching  
server logs for these errors.  Objects accruing schema qualification in  
the wake of the earlier commit are unlikely to need further correction.  
Back-patch to v10, which introduced logical replication.  
  
Security: CVE-2020-14349  

commit   : 41dae35532d40041297ee728eac1f4584af05570    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2020 09:22:54 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 10 Aug 2020 09:22:54 -0700    

Any libpq client can use the header.  Clients include backend components  
postgres_fdw, dblink, and logical replication apply worker.  Back-patch  
to v10, because another fix needs this.  In released branches, just copy  
the header and keep the original.  

commit   : 98ca64899cec6a4bf3099481aff43b8777319c41    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Aug 2020 10:44:42 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Aug 2020 10:44:42 -0400    

Hostile objects located within the installation-time search_path could  
capture references in an extension's installation or upgrade script.  
If the extension is being installed with superuser privileges, this  
opens the door to privilege escalation.  While such hazards have existed  
all along, their urgency increases with the v13 "trusted extensions"  
feature, because that lets a non-superuser control the installation path  
for a superuser-privileged script.  Therefore, make a number of changes  
to make such situations more secure:  
  
* Tweak the construction of the installation-time search_path to ensure  
that references to objects in pg_catalog can't be subverted; and  
explicitly add pg_temp to the end of the path to prevent attacks using  
temporary objects.  
  
* Disable check_function_bodies within installation/upgrade scripts,  
so that any security gaps in SQL-language or PL-language function bodies  
cannot create a risk of unwanted installation-time code execution.  
  
* Adjust lookup of type input/receive functions and join estimator  
functions to complain if there are multiple candidate functions.  This  
prevents capture of references to functions whose signature is not the  
first one checked; and it's arguably more user-friendly anyway.  
  
* Modify various contrib upgrade scripts to ensure that catalog  
modification queries are executed with secure search paths.  (These  
are in-place modifications with no extension version changes, since  
it is the update process itself that is at issue, not the end result.)  
  
Extensions that depend on other extensions cannot be made fully secure  
by these methods alone; therefore, revert the "trusted" marking that  
commit eb67623c9 applied to earthdistance and hstore_plperl, pending  
some better solution to that set of issues.  
  
Also add documentation around these issues, to help extension authors  
write secure installation scripts.  
  
Patch by me, following an observation by Andres Freund; thanks  
to Noah Misch for review.  
  
Security: CVE-2020-14350  

commit   : 378bd1ed6e4314a8b8b32c555f73524c2283b016    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 10 Aug 2020 15:15:50 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 10 Aug 2020 15:15:50 +0200    

Source-Git-URL: https://git.postgresql.org/git/pgtranslation/messages.git  
Source-Git-Hash: 42620448109473e0d2271f0f0015d3647fbbfff6  

commit   : bc635dd16388015c72e47a4b90c4c3ceecebb0cd    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 9 Aug 2020 16:59:53 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 9 Aug 2020 16:59:53 -0400    

commit   : dd63a71ebe3937e0ec965248513fb71e45ee0ec8    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 9 Aug 2020 12:39:08 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 9 Aug 2020 12:39:08 -0400    

Coverity pointed out, not unreasonably, that we checked fseeko's  
result at every other call site but these.  Failure to seek in the  
temp file (note this is NOT pg_dump's output file) seems quite  
unlikely, and even if it did happen the file length cross-check  
further down would probably detect the problem.  Still, that's a  
poor excuse for not checking the result of a system call.  

commit   : 900429d0c03668ac474770c01ba5911b15025dfb    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Sat, 8 Aug 2020 12:31:55 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Sat, 8 Aug 2020 12:31:55 -0400    

Ashutosh Bapat noticed that when logical walsender needs to wait for  
WAL, and it realizes that it must send a keepalive message to  
walreceiver to update the sent-LSN, which *does not* request a reply  
from walreceiver, it wrongly sets the flag that it's going to wait for  
that reply.  That means that any future would-be sender of feedback  
messages ends up not sending a feedback message, because they all  
believe that a reply is expected.  
  
With built-in logical replication there's not much harm in this, because  
WalReceiverMain will send a ping-back every wal_receiver_timeout/2  
anyway; but with other logical replication systems (e.g. pglogical) it  
can cause significant pain.  
  
This problem was introduced in commit 41d5f8ad734, where the  
request-reply flag was changed from true to false to WalSndKeepalive,  
without at the same time removing the line that sets  
waiting_for_ping_response.  
  
Just removing that line would be a sufficient fix, but it seems better  
to shift the responsibility of setting the flag to WalSndKeepalive  
itself instead of requiring caller to do it; this is clearly less  
error-prone.  
  
Author: Álvaro Herrera <alvherre@alvh.no-ip.org>  
Reported-by: Ashutosh Bapat <ashutosh.bapat@2ndquadrant.com>  
Backpatch: 9.5 and up  
Discussion: https://postgr.es/m/20200806225558.GA22401@alvherre.pgsql  

commit   : f1c3a41bd695c4ba97d50ffa4b2ab2a72068bd3b    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 7 Aug 2020 20:38:55 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 7 Aug 2020 20:38:55 +0200    

This contains all individuals mentioned in the commit messages during  
PostgreSQL 13 development.  
  
current through 79a3ab1e98d6b5952e29ad91e07c0e9fc777cc0b  

commit   : 79a3ab1e98d6b5952e29ad91e07c0e9fc777cc0b    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Fri, 7 Aug 2020 14:45:01 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Fri, 7 Aug 2020 14:45:01 +0900    

Commit 13838740f fixed some issues with step generation in partition  
pruning, but there was yet another one: get_steps_using_prefix() assumes  
that clauses in the passed-in prefix list are sorted in ascending order  
of their partition key numbers, but the caller failed to ensure this for  
range partitioning, which led to an assertion failure in debug builds.  
Adjust the caller function to arrange the clauses in the prefix list in  
the required order for range partitioning.  
  
Back-patch to v11, like the previous commit.  
  
Patch by me, reviewed by Amit Langote.  
  
Discussion: https://postgr.es/m/CAPmGK16jkXiFG0YqMbU66wte-oJTfW6D1HaNvQf%3D%2B5o9%3Dm55wQ%40mail.gmail.com  

commit   : be9bdab983cfc44db1d7f8c06df7d7a7cbcb8128    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Thu, 6 Aug 2020 15:25:47 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Thu, 6 Aug 2020 15:25:47 -0700    

This will be helpful if it ever proves necessary to revoke an opclass's  
support for deduplication.  
  
Backpatch: 13-, where nbtree deduplication was introduced.  

commit   : 05dfb813245bf3b896b5317570a24a3d66e97a41    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Fri, 7 Aug 2020 10:22:08 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Fri, 7 Aug 2020 10:22:08 +1200    

9bdb300de modified the EXPLAIN output for Hash Aggregate to show details  
from parallel workers. However, it neglected to consider that a given  
parallel worker may not have assisted with the given Hash Aggregate. This  
can occur when workers fail to start or during Parallel Append with  
enable_partitionwise_join enabled when only a single worker is working on  
a non-parallel aware sub-plan. It could also happen if a worker simply  
wasn't fast enough to get any work done before other processes went and  
finished all the work.  
  
The bogus output came from the fact that ExplainOpenWorker() skipped  
showing any details for non-initialized workers but show_hashagg_info()  
did show details from the worker.  This meant that the worker properties  
that were shown were not properly attributed to the worker that they  
belong to.  
  
In passing, we also now don't show Hash Aggregate properties for the  
leader process when it did not contribute any work to the Hash Aggregate.  
This can occur either during Parallel Append when only a parallel worker  
worked on a given sub plan or with parallel_leader_participation set to  
off.  This aims to make the behavior of Hash Aggregate's EXPLAIN output  
more similar to Sort's.  
  
Reported-by: Justin Pryzby  
Discussion: https://postgr.es/m/20200805012105.GZ28072%40telsasoft.com  
Backpatch-through: 13, where the original breakage was introduced  

commit   : d0aa57d0e9441b9fab5de5dbed0cb0afd4fa756d    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 5 Aug 2020 17:12:10 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 5 Aug 2020 17:12:10 -0400    

Reported-by: Vyacheslav Shablistyy  
  
Discussion: https://postgr.es/m/159586122762.680.1361378513036616007@wrigleys.postgresql.org  
  
Backpatch-through: 9.5  

commit   : c43a36fa8fff380072d9fc745b1e27baf1a4d3f8    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 5 Aug 2020 15:38:55 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 5 Aug 2020 15:38:55 -0400    

Since we no longer require AccessExclusiveLock to add a partition,  
the executor may see that a partitioned table has more partitions  
than the planner saw.  ExecCreatePartitionPruneState's code for  
matching up the partition lists in such cases was faulty, and would  
misbehave if the planner had successfully pruned any partitions from  
the query.  (Thus, trouble would occur only if a partition addition  
happens concurrently with a query that uses both static and dynamic  
partition pruning.)  This led to an Assert failure in debug builds,  
and probably to crashes or query misbehavior in production builds.  
  
To repair the bug, just explicitly skip zeroes in the plan's  
relid_map[] list.  I also made some cosmetic changes to make the code  
more readable (IMO anyway).  Also, convert the cross-checking Assert  
to a regular test-and-elog, since it's now apparent that this logic  
is more fragile than one would like.  
  
Currently, there's no way to repeatably exercise this code, except  
with manual use of a debugger to stop the backend between planning  
and execution.  Hence, no test case in this patch.  We oughta do  
something about that testability gap, but that's for another day.  
  
Amit Langote and Tom Lane, per report from Justin Pryzby.  Oversight  
in commit 898e5e329; backpatch to v12 where that appeared.  
  
Discussion: https://postgr.es/m/20200802181131.GA27754@telsasoft.com  

commit   : 565f1690264b5773c23b86303645cf11a0893cff    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 4 Aug 2020 15:20:31 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 4 Aug 2020 15:20:31 -0400    

A couple of test cases had connect_timeout=14, a value that seems  
to have been plucked from a hat.  While it's more than sufficient  
for normal cases, slow/overloaded buildfarm machines can get a timeout  
failure here, as per recent report from "sungazer".  Increase to 180  
seconds, which is in line with our typical timeouts elsewhere in  
the regression tests.  
  
Back-patch to 9.6; the code looks different in 9.5, and this doesn't  
seem to be quite worth the effort to adapt to that.  
  
Report: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=sungazer&dt=2020-08-04%2007%3A12%3A22  

commit   : 1a01595cc2ffb20ef9f2bc1a92d39728b65e3797    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 4 Aug 2020 14:36:09 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 4 Aug 2020 14:36:09 +0900    

The test would fail in an environment including a certificate file in  
~/.postgresql/.  bdd6e9b fixed a similar failure, and d6e612f introduced  
the same problem again with a new test.  
  
Author: Kyotaro Horiguchi  
Discussion: https://postgr.es/m/20200804.120033.31225582282178001.horikyota.ntt@gmail.com  
Backpatch-through: 13  

commit   : e7a6cd5dcf24c6d4b04d036a4837c7af154c4b49    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 3 Aug 2020 17:01:42 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 3 Aug 2020 17:01:42 -0400    

Document that hash_mem_multiplier can get query behavior closer to the  
pre-PG 13 behavior of allowing hashing to use more memory.  
  
Reported-by: Peter Geoghegan  
  
Discussion: https://postgr.es/m/CAH2-Wzn3kwQm_pe6g2=ki+P7+ZRqH5GvFGn6SWfv_j7UUgcLdQ@mail.gmail.com  
  
Backpatch-through: 13 only  

commit   : 72ca61101ad4076941f175b50cc86e6372023034    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 3 Aug 2020 14:02:35 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 3 Aug 2020 14:02:35 -0400    

A moment's examination of these queries is sufficient to see that  
they do not produce duplicate rows, unless perhaps there's  
catalog corruption.  Using DISTINCT anyway is inefficient and  
confusing; moreover it sets a poor example for anyone who  
refers to psql -E output to see how to query the catalogs.  

commit   : 6d78f219e8afc57b6ca3765eb2dfa1b8fe095ddc    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 3 Aug 2020 13:11:16 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 3 Aug 2020 13:11:16 -0400    

We've allowed UTC offsets up to +/- 15:59 since commit cd0ff9c0f, but  
that commit forgot to fix the documentation about timetz.  
  
Per bug #16571 from osdba.  
  
Discussion: https://postgr.es/m/16571-eb7501598de78c8a@postgresql.org  

commit   : 44cd434ec4a70d2dfbc460492fc0574d08440250    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 3 Aug 2020 09:46:12 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 3 Aug 2020 09:46:12 -0400    

This ought to work much like C's "#elif defined(name)"; but the code  
implemented it in a way equivalent to endif followed by ifdef, so that  
it didn't matter whether any previous branch of the IF construct had  
succeeded.  Fix that; add some test cases covering elif and nested IFs;  
and improve the documentation, which also seemed a bit confused.  
  
AFAICS the code has been like this since the feature was added in 1999  
(commit b57b0e044).  So while it's surely wrong, there might be code  
out there relying on the current behavior.  Hence, don't back-patch  
into stable branches.  It seems all right to fix it in v13 though.  
  
Per report from Ashutosh Sharma.  Reviewed by Ashutosh Sharma and  
Michael Meskes.  
  
Discussion: https://postgr.es/m/CAE9k0P=dQk9X0cU2tN49S7a9tv733-e1pVdpB1P-pWJ5PdTktg@mail.gmail.com  

commit   : f5293fb09e7346bb663f2f5c63081e8aabe61a8e    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Mon, 3 Aug 2020 12:39:15 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Mon, 3 Aug 2020 12:39:15 +1200    

Instead of writing a query to psql's stdin, use -c.  This avoids a  
failure where psql exits before we write, seen a few times on the build  
farm.  Thanks to Tom Lane for the suggestion.  
  
Back-patch to 11, where the LDAP tests arrived.  
  
Reviewed-by: Noah Misch <noah@leadboat.com>  
Discussion: https://postgr.es/m/CA%2BhUKGLFmW%2BHQYPeKiwSp5sdFFHtFViCpw4Mh6yAgEx74r5-Cw%40mail.gmail.com  

commit   : 719304a3043d9f60247df371f55236058a7f3caa    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 2 Aug 2020 17:00:26 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 2 Aug 2020 17:00:26 -0400    

The type-name pattern in \dAc and \dAf was matched only to the actual  
pg_type.typname string, which is fairly user-unfriendly in cases where  
that is not what's shown to the user by format_type (compare "_int4"  
and "integer[]").  Make this code match what \dT does, i.e. match the  
pattern against either typname or format_type() output.  Also fix its  
broken handling of schema-name restrictions.  (IOW, make these  
processSQLNamePattern calls match \dT's.)  While here, adjust  
whitespace to make the query a little prettier in -E output, too.  
  
Also improve some inaccuracies and shaky grammar in the related  
documentation.  
  
Noted while working on a patch for intarray's opclasses; I wondered  
why I couldn't get a match to "integer*" for the input type name.  

commit   : 22c105595fc736ae94ce3b806da16b0bd8e94fb8    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Sun, 2 Aug 2020 14:23:57 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Sun, 2 Aug 2020 14:23:57 +1200    

Windows 64bit has 4-byte long values which is not suitable for tracking  
disk space usage in the incremental sort code. Let's just make all these  
fields int64s.  
  
Author: James Coleman  
Discussion: https://postgr.es/m/CAApHDvpky%2BUhof8mryPf5i%3D6e6fib2dxHqBrhp0Qhu0NeBhLJw%40mail.gmail.com  
Backpatch-through: 13, where the incremental sort code was added  

commit   : 725b43b9c3b3c25c60ac717c41047ad0dffb1312    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Fri, 31 Jul 2020 15:34:26 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Fri, 31 Jul 2020 15:34:26 -0700    

Commit eba77534 fixed an amcheck false positive bug involving  
inconsistencies in TOAST input state between table and index.  A test  
case was added that verified that such an inconsistency didn't result in  
a spurious corruption related error.  
  
Test coverage from the test was accidentally lost by commit 501e41dd,  
which propagated ALTER TABLE ...  SET STORAGE attstorage state to  
indexes.  This broke the test because the test specifically relied on  
attstorage not being propagated.  This artificially forced there to be  
index tuples whose datums were equivalent to the datums in the heap  
without the datums actually being bitwise equal.  
  
Fix this by updating pg_attribute directly instead.  Commit 501e41dd  
made similar changes to a test_decoding TOAST-related test case which  
made the same assumption, but overlooked the amcheck test case.  
  
Backpatch: 11-, just like commit eba77534 (and commit 501e41dd).  

commit   : 5c439f189bf4bdbb0ff75b2043ca713d76019528    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 31 Jul 2020 17:11:28 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 31 Jul 2020 17:11:28 -0400    

If a base type supports typmods, its array type does too, with the  
same interpretation.  Hence changes in pg_type.typmodin/typmodout  
must be propagated to the array type.  
  
While here, improve AlterTypeRecurse to not recurse to domains if  
there is nothing we'd need to change.  
  
Oversight in fe30e7ebf.  Back-patch to v13 where that came in.  

commit   : 11dce63d6c3f676a9f1829eca96f085b6d935af0    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 31 Jul 2020 11:43:12 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 31 Jul 2020 11:43:12 -0400    

The new hlCover() algorithm that I introduced in commit c9b0c678d  
turns out to potentially take O(N^2) or worse time on long documents,  
if there are many occurrences of individual query words but few or no  
substrings that actually satisfy the query.  (One way to hit this  
behavior is with a "common_word & rare_word" type of query.)  This  
seems unavoidable given the original goal of checking every substring  
of the document, so we have to back off that idea.  Fortunately, it  
seems unlikely that anyone would really want headlines spanning all of  
a long document, so we can avoid the worse-than-linear behavior by  
imposing a maximum length of substring that we'll consider.  
  
For now, just hard-wire that maximum length as a multiple of max_words  
times max_fragments.  Perhaps at some point somebody will argue for  
exposing it as a ts_headline parameter, but I'm hesitant to make such  
a feature addition in a back-patched bug fix.  
  
I also noted that the hlFirstIndex() function I'd added in that  
commit was unnecessarily stupid: it really only needs to check whether  
a HeadlineWordEntry's item pointer is null or not.  This wouldn't make  
all that much difference in typical cases with queries having just  
a few terms, but a cycle shaved is a cycle earned.  
  
In addition, add a CHECK_FOR_INTERRUPTS call in TS_execute_recurse.  
This ensures that hlCover's loop is cancellable if it manages to take  
a long time, and it may protect some other TS_execute callers as well.  
  
Back-patch to 9.6 as the previous commit was.  I also chose to add the  
CHECK_FOR_INTERRUPTS call to 9.5.  The old hlCover() algorithm seems  
to avoid the O(N^2) behavior, at least on the test case I tried, but  
nonetheless it's not very quick on a long document.  
  
Per report from Stephen Frost.  
  
Discussion: https://postgr.es/m/20200724160535.GW12375@tamriel.snowman.net  

commit   : 0d9b64fe8d2d98f8f074334f86aaaedfb2b5a1e1    
  
author   : Tatsuo Ishii <ishii@postgresql.org>    
date     : Fri, 31 Jul 2020 07:46:25 +0900    
  
committer: Tatsuo Ishii <ishii@postgresql.org>    
date     : Fri, 31 Jul 2020 07:46:25 +0900    

In "High Availability, Load Balancing, and Replication" chapter,  
certain descriptions of Pgpool-II were not correct at this point.  It  
does not need conflict resolution. Also "Multiple-Server Parallel  
Query Execution" is not supported anymore.  
  
Discussion: https://postgr.es/m/20200726.230128.53842489850344110.t-ishii%40sraoss.co.jp  
Author: Tatsuo Ishii  
Reviewed-by: Bruce Momjian  
Backpatch-through: 9.5  

commit   : 07cbcdd00c2465a844513f14b7a96232013d3129    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Thu, 30 Jul 2020 08:44:58 -0700    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Thu, 30 Jul 2020 08:44:58 -0700    

Using pg_leftmost_one_post32() yields substantial performance benefits.  
  
Backpatching to version 13 because HLL is used for HashAgg  
improvements in 9878b643, which was also backpatched to 13.  
  
Reviewed-by: Peter Geoghegan  
Discussion: https://postgr.es/m/CAH2-WzkGvDKVDo+0YvfvZ+1CE=iCi88DCOGFF3i1hTGGaxcKPw@mail.gmail.com  
Backpatch-through: 13  

commit   : e710f3b8e7da43de2ad8113ce7c7933928092656    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 30 Jul 2020 15:48:52 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 30 Jul 2020 15:48:52 +0900    

Partitioned indexes are also registered in pg_inherits, but the  
description of this catalog did not reflect that.  
  
Author: Dagfinn Ilmari Mannsåker  
Discussion: https://postgr.es/m/87k0ynj35y.fsf@wibble.ilmari.org  
Backpatch-through: 11  

commit   : 78530c8e7a5abe0b646b0b46527f8799f831e1e1    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Wed, 29 Jul 2020 14:14:57 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Wed, 29 Jul 2020 14:14:57 -0700    

Add a GUC that acts as a multiplier on work_mem.  It gets applied when  
sizing executor node hash tables that were previously size constrained  
using work_mem alone.  
  
The new GUC can be used to preferentially give hash-based nodes more  
memory than the generic work_mem limit.  It is intended to enable admin  
tuning of the executor's memory usage.  Overall system throughput and  
system responsiveness can be improved by giving hash-based executor  
nodes more memory (especially over sort-based alternatives, which are  
often much less sensitive to being memory constrained).  
  
The default value for hash_mem_multiplier is 1.0, which is also the  
minimum valid value.  This means that hash-based nodes continue to apply  
work_mem in the traditional way by default.  
  
hash_mem_multiplier is generally useful.  However, it is being added now  
due to concerns about hash aggregate performance stability for users  
that upgrade to Postgres 13 (which added disk-based hash aggregation in  
commit 1f39bce0).  While the old hash aggregate behavior risked  
out-of-memory errors, it is nevertheless likely that many users actually  
benefited.  Hash agg's previous indifference to work_mem during query  
execution was not just faster; it also accidentally made aggregation  
resilient to grouping estimate problems (at least in cases where this  
didn't create destabilizing memory pressure).  
  
hash_mem_multiplier can provide a certain kind of continuity with the  
behavior of Postgres 12 hash aggregates in cases where the planner  
incorrectly estimates that all groups (plus related allocations) will  
fit in work_mem/hash_mem.  This seems necessary because hash-based  
aggregation is usually much slower when only a small fraction of all  
groups can fit.  Even when it isn't possible to totally avoid hash  
aggregates that spill, giving hash aggregation more memory will reliably  
improve performance (the same cannot be said for external sort  
operations, which appear to be almost unaffected by memory availability  
provided it's at least possible to get a single merge pass).  
  
The PostgreSQL 13 release notes should advise users that increasing  
hash_mem_multiplier can help with performance regressions associated  
with hash aggregation.  That can be taken care of by a later commit.  
  
Author: Peter Geoghegan  
Reviewed-By: Álvaro Herrera, Jeff Davis  
Discussion: https://postgr.es/m/20200625203629.7m6yvut7eqblgmfo@alap3.anarazel.de  
Discussion: https://postgr.es/m/CAH2-WzmD%2Bi1pG6rc1%2BCjc4V6EaFJ_qSuKCCHVnH%3DoruqD-zqow%40mail.gmail.com  
Backpatch: 13-, where disk-based hash aggregation was introduced.