PostgreSQL 15.2 commit log

commit   : 78ec02d612a9b69039ec2610740f738968fe144d    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 6 Feb 2023 16:39:04 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 6 Feb 2023 16:39:04 -0500    

commit   : 6788a55898053ba513753f9bc4ba7d3731676cdb    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 6 Feb 2023 11:43:10 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 6 Feb 2023 11:43:10 -0500    

Security: CVE-2022-41862  

commit   : 1eadfbdd7eb0679ba8d45787aa8b2f06e76de20a    
  
author   : Robert Haas <[email protected]>    
date     : Mon, 6 Feb 2023 11:16:03 -0500    
  
committer: Robert Haas <[email protected]>    
date     : Mon, 6 Feb 2023 11:16:03 -0500    

This reverts commit 98e7234242a652497c99d4d0d6f2bf9a75d4e921. I  
forgot that we're about to wrap a release, and this fix isn't  
critical enough to justify committing it right before we wrap  
a release.  
  
Discussion: http://postgr.es/m/[email protected]  

commit   : 98e7234242a652497c99d4d0d6f2bf9a75d4e921    
  
author   : Robert Haas <[email protected]>    
date     : Mon, 6 Feb 2023 10:51:08 -0500    
  
committer: Robert Haas <[email protected]>    
date     : Mon, 6 Feb 2023 10:51:08 -0500    

In standby mode, we don't actually report progress of recovery,  
but up until now, startup_progress_timeout_handler() nevertheless  
got called every log_startup_progress_interval seconds. That's  
an unnecessary expense, so avoid it.  
  
Report by Thomas Munro. Patch by Bharath Rupireddy, reviewed by  
Simon Riggs, Thomas Munro, and me. Back-patch to v15, where  
the problem was introduced.  
  
Discussion: https://www.postgresql.org/message-id/CA%2BhUKGKCHSffAj8zZJKJvNX7ygnQFxVD6wm1d-2j3fVw%2BMafPQ%40mail.gmail.com  

commit   : ec16eac8dabcd80559dcc6aeec48c0b57fb8b2bd    
  
author   : Peter Eisentraut <[email protected]>    
date     : Mon, 6 Feb 2023 12:15:49 +0100    
  
committer: Peter Eisentraut <[email protected]>    
date     : Mon, 6 Feb 2023 12:15:49 +0100    

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

commit   : 715c345dd9a5594758be9a7aa41e898ead96e2a6    
  
author   : Michael Paquier <[email protected]>    
date     : Mon, 6 Feb 2023 11:20:20 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Mon, 6 Feb 2023 11:20:20 +0900    

pqsecure_open_gss() includes a code path handling error messages with  
v2-style protocol messages coming from the server.  The client-side  
buffer holding the error message does not force a NULL-termination, with  
the data of the server getting copied to the errorMessage of the  
connection.  Hence, it would be possible for a server to send an  
unterminated string and copy arbitrary bytes in the buffer receiving the  
error message in the client, opening the door to a crash or even data  
exposure.  
  
As at this stage of the authentication process the exchange has not been  
completed yet, this could be abused by an attacker without Kerberos  
credentials.  Clients that have a valid kerberos cache are vulnerable as  
libpq opportunistically requests for it except if gssencmode is  
disabled.  
  
Author: Jacob Champion  
Backpatch-through: 12  
Security: CVE-2022-41862  

commit   : 80d43843e70aaa168d17f9a0c2ecc8c88a46b430    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 5 Feb 2023 16:22:32 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 5 Feb 2023 16:22:32 -0500    

commit   : f282b026787da69d88a35404cf62f1cc21cfbb7c    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 3 Feb 2023 14:30:49 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 3 Feb 2023 14:30:49 -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   : 4f74741a5cea38228fdb0fb2967fa2137ea02cbf    
  
author   : Dean Rasheed <[email protected]>    
date     : Fri, 3 Feb 2023 11:11:59 +0000    
  
committer: Dean Rasheed <[email protected]>    
date     : Fri, 3 Feb 2023 11:11:59 +0000    

The prior coding of int64_div_fast_to_numeric() had a number of bugs  
that would cause it to fail under different circumstances, such as  
with log10val2 <= 0, or log10val2 a multiple of 4, or in the "slow"  
numeric path with log10val2 >= 10.  
  
None of those could be triggered by any of our current code, which  
only uses log10val2 = 3 or 6. However, they made it a hazard for any  
future code that might use it. Also, since this is exported by  
numeric.c, users writing their own C code might choose to use it.  
  
Therefore fix, and back-patch to v14, where it was introduced.  
  
Dean Rasheed, reviewed by Tom Lane.  
  
Discussion: https://postgr.es/m/CAEZATCW8gXgW0tgPxPgHDPhVX71%2BSWFRkhnXy%2BTfGDsKLepu2g%40mail.gmail.com  

commit   : e7c2e02a66a2bbdfd937eace2e5838fd44ad1306    
  
author   : Peter Eisentraut <[email protected]>    
date     : Fri, 3 Feb 2023 09:04:35 +0100    
  
committer: Peter Eisentraut <[email protected]>    
date     : Fri, 3 Feb 2023 09:04:35 +0100    

Breaking <phrase> over two lines is not handled by psql's  
create_help.pl.  (It creates faulty \help output.)  
  
Undo the formatting change introduced by  
9bdad1b5153e5d6b77a8f9c6e32286d6bafcd76d to fix this for now.  

commit   : 8488babc7f497949f89f77c1b18e41e0962e5398    
  
author   : Andres Freund <[email protected]>    
date     : Thu, 2 Feb 2023 21:31:48 -0800    
  
committer: Andres Freund <[email protected]>    
date     : Thu, 2 Feb 2023 21:31:48 -0800    

So far we have used containers for testing windows on cirrus-ci. Unfortunately  
they come with substantial overhead: First, the container images are pulled  
onto the host on-demand. Due to the large size of windows containers, that  
ends up taking nearly 4 minutes. Secondly, IO is slow, leading to CI runs  
taking long.  
  
Thus switch to windows VMs, improving windows CI times by well over 2x.  
  
Author: Nazir Bilal Yavuz <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  
Backpatch: 15-, where CI was added  

commit   : 83c7e2f2a2f541b5adc11c9d2826eeaf2a22361a    
  
author   : Thomas Munro <[email protected]>    
date     : Fri, 3 Feb 2023 14:26:54 +1300    
  
committer: Thomas Munro <[email protected]>    
date     : Fri, 3 Feb 2023 14:26:54 +1300    

Back-patch to 15, where in-tree CI began.  
  
Author: Justin Pryzby <[email protected]>  
Discussion: https://postgr.es/m/1441145.1675300332%40sss.pgh.pa.us  

commit   : d54e1fcaa5f23cc654f4174d1d6217d4022996e2    
  
author   : Thomas Munro <[email protected]>    
date     : Thu, 2 Feb 2023 18:13:44 +1300    
  
committer: Thomas Munro <[email protected]>    
date     : Thu, 2 Feb 2023 18:13:44 +1300    

An early release of AF_UNIX in Windows apparently supported Linux-style  
"abstract" Unix sockets, but they do not seem to work in current Windows  
versions and there is no mention of any of this in the Winsock  
documentation.  Remove the mention of Windows from the documentation.  
  
Back-patch to 14, where commit c9f0624b landed.  
  
Discussion: https://postgr.es/m/CA%2BhUKGKrYbSZhrk4NGfoQGT_3LQS5pC5KNE1g0tvE_pPBZ7uew%40mail.gmail.com  

commit   : 65f0d9d27d09ee0880055553dabb10ee44b87285    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 31 Jan 2023 17:36:55 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 31 Jan 2023 17:36:55 -0500    

DST law changes in Greenland and Mexico.  Notably, a new timezone  
America/Ciudad_Juarez has been split off from America/Ojinaga.  
  
Historical corrections for northern Canada, Colombia, and Singapore.  

commit   : e4035a9ca49d8f8bc19b949d6e2600048b198313    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 31 Jan 2023 14:32:24 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 31 Jan 2023 14:32:24 -0500    

This was only mentioned in the description of the text/label, which  
are marked as being in quotes in the synopsis, which can cause  
confusion (as witnessed on IRC).  
  
Also separate the literal and NULL cases in the parameter list, per  
suggestion from Tom Lane.  
  
Also add an example of dropping a security label.  
  
Dagfinn Ilmari Mannsåker, with some tweaks by me  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : c5b2975ec183e8776f82bad33ec957ce58ec709a    
  
author   : Michael Paquier <[email protected]>    
date     : Tue, 31 Jan 2023 12:47:08 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Tue, 31 Jan 2023 12:47:08 +0900    

This test has been added as of 857ee8e that has introduced the SQL  
function txid_status(), with the purpose of checking that a transaction  
ID still in-progress during a crash is correctly marked as aborted after  
recovery finishes.  
  
This test is unstable, and some configuration scenarios may that easier  
to reproduce (wal_level=minimal, wal_compression=on) because the WAL  
holding the information about the in-progress transaction ID may not  
have made it to disk yet, hence a post-crash recovery may cause the same  
XID to be reused, triggering a test failure.  
  
We have discussed a few approaches, like making this function force a  
WAL flush to make it reliable across crashes, but we don't want to pay a  
performance penalty in some scenarios, as well.  The test could have  
been tweaked to enforce a checkpoint but that actually breaks the  
promise of the test to rely on a stable result of txid_status() after  
a crash.  
  
This issue has been reported a few times across the past years, with an  
original report from Kyotaro Horiguchi.  The buildfarm machines tanager,  
hachi and gokiburi enable wal_compression, and fail on this test  
periodically.  
  
Discussion: https://postgr.es/m/[email protected]  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 11  

commit   : 4785af9e6318856d45e51fbc328d52f6c5340e13    
  
author   : Dean Rasheed <[email protected]>    
date     : Mon, 30 Jan 2023 10:07:32 +0000    
  
committer: Dean Rasheed <[email protected]>    
date     : Mon, 30 Jan 2023 10:07:32 +0000    

This fixes a bug that, under some circumstances, would cause MERGE to  
fail to properly recompute expressions for GENERATED STORED columns.  
  
Formerly, ExecInitModifyTable() did not call ExecInitStoredGenerated()  
for a MERGE command, which meant that the generated expressions  
information was not computed until later, when the first merge action  
was executed. However, if the first merge action to execute was an  
UPDATE, then ExecInitStoredGenerated() could decide to skip some some  
generated columns, if the columns on which they depended were not  
updated, which was a problem if the MERGE also contained an INSERT  
action, for which no generated columns should be skipped.  
  
So fix by having ExecInitModifyTable() call ExecInitStoredGenerated()  
for MERGE, and assume that it isn't safe to skip any generated columns  
in a MERGE. Possibly that could be relaxed, by allowing some generated  
columns to be skipped for a MERGE without an INSERT action, but it's  
not clear that it's worth the effort.  
  
Noticed while investigating bug #17759. Back-patch to v15, where MERGE  
was added.  
  
Dean Rasheed, reviewed by Tom Lane.  
  
Discussion:  
  https://postgr.es/m/17759-e76d9bece1b5421c%40postgresql.org  
  https://postgr.es/m/CAEZATCXb_ezoMCcL0tzKwRGA1x0oeE%3DawTaysRfTPq%2B3wNJn8g%40mail.gmail.com  

commit   : d9f5345bf90799a992995d935b712e5040830732    
  
author   : Thomas Munro <[email protected]>    
date     : Thu, 26 Jan 2023 14:50:07 +1300    
  
committer: Thomas Munro <[email protected]>    
date     : Thu, 26 Jan 2023 14:50:07 +1300    

If the final chunk of an oversized tuple being written out to disk was  
exactly 32760 bytes, it would be corrupted due to a fencepost bug.  
  
Bug #17619.  Back-patch to 11 where the code arrived.  
  
While testing that (see test module in archives), I (tmunro) noticed  
that the per-participant page counter was not initialized to zero as it  
should have been; that wasn't a live bug when it was written since DSM  
memory was originally always zeroed, but since 14  
min_dynamic_shared_memory might be configured and it supplies non-zeroed  
memory, so that is also fixed here.  
  
Author: Dmitry Astapov <[email protected]>  
Discussion: https://postgr.es/m/17619-0de62ceda812b8b5%40postgresql.org  

commit   : 88c27b8fe201fe197ef988f0910f282015ea767c    
  
author   : Michael Paquier <[email protected]>    
date     : Wed, 25 Jan 2023 20:00:42 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Wed, 25 Jan 2023 20:00:42 +0900    

network_ops is an opclass family of SpGiST, and the opclass able to  
work on the inet type is named inet_ops.  
  
Oversight in 7a1cd52, that reworked the design of the table listing all  
the operators available.  
  
Reported-by: Laurence Parry  
Reviewed-by: Tom Lane, David G. Johnston  
Discussion: https://postgr.es/m/167458110639.2667300.14741268666497110766@wrigleys.postgresql.org  
Backpatch-through: 14  

commit   : 267135d01d79c63dfba7fe69dd3b40c125c49a6f    
  
author   : Amit Kapila <[email protected]>    
date     : Tue, 24 Jan 2023 09:12:04 +0530    
  
committer: Amit Kapila <[email protected]>    
date     : Tue, 24 Jan 2023 09:12:04 +0530    

The drop database command waits for the logical replication sync worker to  
accept ProcSignalBarrier and the worker's slot creation waits for the drop  
database to finish which leads to a deadlock. This happens because the  
tablesync worker holds interrupts while creating a slot.  
  
We prevent cancel/die interrupts while creating a slot in the table sync  
worker because it is possible that before the server finishes this  
command, a concurrent drop subscription happens which would complete  
without removing this slot and that leads to the slot existing until the  
end of walsender. However, the slot will eventually get dropped at the  
walsender exit time, so there is no danger of the dangling slot.  
  
This patch reallows cancel/die interrupts while creating a slot and  
modifies the test to wait for slots to become zero to prevent finding an  
ephemeral slot.  
  
The reported hang doesn't happen in PG14 as the drop database starts to  
wait for ProcSignalBarrier with PG15 (commits 4eb2176318 and e2f65f4255)  
but it is good to backpatch this till PG14 as it is not a good idea to  
prevent interrupts during a network call that could block indefinitely.  
  
Reported-by: Lakshmi Narayanan Sreethar  
Diagnosed-by: Andres Freund  
Author: Hou Zhijie  
Reviewed-by: Vignesh C, Amit Kapila  
Backpatch-through: 14, where it was introduced in commit 6b67d72b60  
Discussion: https://postgr.es/m/CA+kvmZELXQ4ZD3U=XCXuG3KvFgkuPoN1QrEj8c-rMRodrLOnsg@mail.gmail.com  

commit   : 704a330a9ee882bebbe4abe44c9f174ceaaf2f69    
  
author   : Andres Freund <[email protected]>    
date     : Mon, 23 Jan 2023 18:04:02 -0800    
  
committer: Andres Freund <[email protected]>    
date     : Mon, 23 Jan 2023 18:04:02 -0800    

When libpqrcv_connect (also known as walrcv_connect()) failed, it leaked the  
libpq connection. In most paths that's fairly harmless, as the calling process  
will exit soon after. But e.g. CREATE SUBSCRIPTION could lead to a somewhat  
longer lived leak.  
  
Fix by releasing resources, including the libpq connection, on error.  
  
Add a test exercising the error code path. To make it reliable and safe, the  
test tries to connect to port=-1, which happens to fail during connection  
establishment, rather than during connection string parsing.  
  
Reviewed-by: Noah Misch <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  
Backpatch: 11-  

commit   : 5dc582da6b9a281321e687ae2b52f96b929d8d0e    
  
author   : David Rowley <[email protected]>    
date     : Tue, 24 Jan 2023 13:49:39 +1300    
  
committer: David Rowley <[email protected]>    
date     : Tue, 24 Jan 2023 13:49:39 +1300    

b762fed64 recently changed this test to prevent subquery pullup to allow  
us to test Memoize with lateral_vars.  As pointed out by Tom Lane, OFFSET  
0 is our standard way of preventing subquery pullups, so do it that way  
instead.  
  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 14, same as b762fed64  

commit   : 73f77ab508d1514ca604c47b6f56c5dee4dd9025    
  
author   : David Rowley <[email protected]>    
date     : Tue, 24 Jan 2023 12:29:57 +1300    
  
committer: David Rowley <[email protected]>    
date     : Tue, 24 Jan 2023 12:29:57 +1300    

The test in question was meant to be testing Memoize to ensure it worked  
correctly when the inner side of the join contained lateral vars, however,  
nothing in the lateral subquery stopped it from being pulled up into the  
main query, so the planner did that, and that meant no more lateral vars.  
  
Here we add a simple ORDER BY to stop the planner from being able to  
pullup the lateral subquery.  
  
Author: Richard Guo  
Discussion: https://postgr.es/m/CAMbWs4_LHJaN4L-tXpKMiPFnsCJWU1P8Xh59o0W7AA6UN99=cQ@mail.gmail.com  
Backpatch-through: 14, where Memoize was added.  

commit   : 95f62b16a3344e48ecce1ceb2882e5af24c13a1b    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Mon, 23 Jan 2023 11:56:43 +0200    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Mon, 23 Jan 2023 11:56:43 +0200    

Commit c4649cce39 removed the "shared" and "ntapes" arguments, but the  
comment still talked about "shared". It also talked about "a shared  
file handle", which was technically correct because even before commit  
c4649cce39, the "shared file handle" referred to the "fileset"  
argument, not "shared". But it was very confusing. Improve the  
comment.  
  
Also add a comment on what the "preallocate" argument does.  
  
Backpatch to v15, just to make backpatching other patches easier in  
the future.  
  
Discussion: https://www.postgresql.org/message-id/[email protected]  
Reviewed-by: Peter Eisentraut  

commit   : 9e4288ce6d30024de1586fefa6db077c5f9122c2    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 21 Jan 2023 13:10:29 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 21 Jan 2023 13:10:29 -0500    

The motivation for this change is that when pg_dump dumps a  
partitioned index that's marked REPLICA IDENTITY, it generates a  
command sequence that applies REPLICA IDENTITY before the partitioned  
index has been marked valid, causing restore to fail.  We could  
perhaps change pg_dump to not do it like that, but that would be  
difficult and would not fix existing dump files with the problem.  
There seems to be very little reason for the backend to disallow  
this anyway --- the code ignores indisreplident when the index  
isn't valid --- so instead let's fix it by allowing the case.  
  
Commit 9511fb37a previously expressed a concern that allowing  
indisreplident to be set on invalid indexes might allow us to  
wind up in a situation where a table could have indisreplident  
set on multiple indexes.  I'm not sure I follow that concern  
exactly, but in any case the only way that could happen is because  
relation_mark_replica_identity is too trusting about the existing set  
of markings being valid.  Let's just rip out its early-exit code path  
(which sure looks like premature optimization anyway; what are we  
doing expending code to make redundant ALTER TABLE ... REPLICA  
IDENTITY commands marginally faster and not-redundant ones marginally  
slower?) and fix it to positively guarantee that no more than one  
index is marked indisreplident.  
  
The pg_dump failure can be demonstrated in all supported branches,  
so back-patch all the way.  I chose to back-patch 9511fb37a as well,  
just to keep indisreplident handling the same in all branches.  
  
Per bug #17756 from Sergey Belyashov.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : b152bb7b2724a7c62c2440c510af4926a996bbbc    
  
author   : Noah Misch <[email protected]>    
date     : Sat, 21 Jan 2023 06:08:00 -0800    
  
committer: Noah Misch <[email protected]>    
date     : Sat, 21 Jan 2023 06:08:00 -0800    

When the length was too short, the server read outside the allocation.  
That yielded the same log noise as sending the correct length with  
(backendPID,cancelAuthCode) matching nothing.  Change to a message about  
the unexpected length.  Given the attacker's lack of control over the  
memory layout and the general lack of diversity in memory layouts at the  
code in question, we doubt a would-be attacker could cause a segfault.  
Hence, while the report arrived via [email protected], this is not  
a vulnerability.  Back-patch to v11 (all supported versions).  
  
Andrey Borodin, reviewed by Tom Lane.  Reported by Andrey Borodin.  

commit   : 9a40a031197a302a638d6464c9db081b7839175f    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 20 Jan 2023 11:58:12 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 20 Jan 2023 11:58:12 -0500    

Add "#ifndef FRONTEND" where necessary to make pg_waldump build  
on compilers that don't elide unused static-inline functions.  
  
This back-patches relevant parts of commit 3e9ca5260, fixing build  
breakage from dc7420c2c and back-patching of f10f0ae42.  
  
Per recently-resurrected buildfarm member castoroides.  We aren't  
expecting castoroides to build anything newer than v11, but we  
might as well clean up the intermediate branches while at it.  

commit   : 488e89bf725a3b4a1caf9e3e82ae6e75e914d123    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 19 Jan 2023 19:32:47 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 19 Jan 2023 19:32:47 -0500    

If the public schema has a non-default owner (perhaps due to  
dropping and recreating it) then use of pg_dump's "--if-exists"  
option results in a warning message:  
  
warning: could not find where to insert IF EXISTS in statement "-- *not* dropping schema, since initdb creates it"  
  
This is harmless since the dump output is the same either way,  
but nonetheless it's undesirable.  It's the fault of commit  
a7a7be1f2, which created situations where a TOC entry's "defn"  
or "dropStmt" fields could be just comments.  Although that  
commit fixed up the kluges in pg_backup_archiver.c that munge defn  
strings, it missed doing so for the one that munges dropStmts.  
  
Per bug# 17753 from Justin Zhang.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : abe203304e1567c5938b348a8d9c5ad9b909742d    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 19 Jan 2023 12:23:20 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 19 Jan 2023 12:23:20 -0500    

When ending recovery based on recovery_target_xid matching with  
recovery_target_inclusive = off, we printed an incorrect timestamp  
(always 2000-01-01) in the "recovery stopping before ... transaction"  
log message.  This is a consequence of sloppy refactoring in  
c945af80c: the code to fetch recordXtime out of the commit/abort  
record used to be executed unconditionally, but it was changed  
to get called only in the RECOVERY_TARGET_TIME case.  We need only  
flip the order of operations to restore the intended behavior.  
  
Per report from Torsten Förtsch.  Back-patch to all supported  
branches.  
  
Discussion: https://postgr.es/m/CAKkG4_kUevPqbmyOfLajx7opAQk6Cvwkvx0HRcFjSPfRPTXanA@mail.gmail.com  

commit   : 49e3a5e7149d3f676318f2222aaab30613f8dc59    
  
author   : Michael Paquier <[email protected]>    
date     : Thu, 19 Jan 2023 13:13:27 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Thu, 19 Jan 2023 13:13:27 +0900    

This is wrong since 88e9823, that has switched the WAL sizing  
configuration from checkpoint_segments to min_wal_size and  
max_wal_size.  This missed the recalculation of the internal value of  
the internal "CheckPointSegments", that works as a mapping of the old  
GUC checkpoint_segments, on reload, for example, and it controls the  
timing of checkpoints depending on the volume of WAL generated.  
  
Most users tend to leave checkpoint_completion_target at 0.9 to smooth  
the I/O workload, which is why I guess this has gone unnoticed for so  
long, still it can be useful to tweak and reload the value dynamically  
in some cases to control the timing of checkpoints.  
  
Author: Bharath Rupireddy  
Discussion: https://postgr.es/m/CALj2ACXgPPAm28mruojSBno+F_=9cTOOxHAywu_dfZPeBdybQw@mail.gmail.com  
Backpatch-through: 11  

commit   : 1391916736cf218c7f234471ef3c98f740ed2a5e    
  
author   : Michael Paquier <[email protected]>    
date     : Thu, 19 Jan 2023 10:02:07 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Thu, 19 Jan 2023 10:02:07 +0900    

No buildfarm members have reported that yet, but a recently-refreshed  
Debian host did.  
  
Reviewed-by: Andrew Dunstan  
Discussion: https://postgr.es/m/Y8ey5z4Nav62g4/[email protected]  
Backpatch-through: 11  

commit   : 13764e9bf7f5591eb02a3e90667e55ae734ed164    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 17 Jan 2023 16:00:39 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 17 Jan 2023 16:00:39 -0500    

test_extensions' test_ext_cine extension has the same upgrade hazard  
as test_ext7: the regression test leaves it in an updated state  
from which no downgrade path to default is provided.  This causes  
the update_extensions.sql script helpfully provided by pg_upgrade  
to fail.  So drop it in cross-version-upgrade testing.  
  
Not entirely sure how come I didn't hit this in testing yesterday;  
possibly I'd built the upgrade reference databases with  
testmodules-install-check disabled.  
  
Backpatch to v10 where this module was introduced.  

commit   : 4ad0896bca92d98c7a419af6d30e59543ec9a398    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 16 Jan 2023 20:35:53 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 16 Jan 2023 20:35:53 -0500    

To test pg_upgrade across major PG versions, we have to be able to  
modify or drop any old objects with no-longer-supported properties,  
and we have to be able to deal with cosmetic changes in pg_dump output.  
Up to now, the buildfarm and pg_upgrade's own test infrastructure had  
separate implementations of the former, and we had nothing but very  
ad-hoc rules for the latter (including an arbitrary threshold on how  
many lines of unchecked diff were okay!).  This patch creates a Perl  
module that can be shared by both those use-cases, and adds logic  
that deals with pg_dump output diffs in a much more tightly defined  
fashion.  
  
This largely supersedes previous efforts in commits 0df9641d3,  
9814ff550, and 62be9e4cd, which developed a SQL-script-based solution  
for the task of dropping old objects.  There was nothing fundamentally  
wrong with that work in itself, but it had no basis for solving the  
output-formatting problem.  The most plausible way to deal with  
formatting is to build a Perl module that can perform editing on the  
dump files; and once we commit to that, it makes more sense for the  
same module to also embed the knowledge of what has to be done for  
dropping old objects.  
  
Back-patch versions of the helper module as far as 9.2, to  
support buildfarm animals that still test that far back.  
It's also necessary to back-patch PostgreSQL/Version.pm,  
because the new code depends on that.  I fixed up pg_upgrade's  
002_pg_upgrade.pl in v15, but did not look into back-patching  
it further than that.  
  
Tom Lane and Andrew Dunstan  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : ac01fa647f84e99f092eacbb74fe1744d4bcdd8b    
  
author   : Peter Eisentraut <[email protected]>    
date     : Mon, 16 Jan 2023 09:20:44 +0100    
  
committer: Peter Eisentraut <[email protected]>    
date     : Mon, 16 Jan 2023 09:20:44 +0100    

Remove "%m" from error messages where errno would be bogus.  Add short  
read byte counts where appropriate.  
  
This is equivalent to what was done in  
7897e3bb902c557412645b82120f4d95f7474906, but some code was apparently  
developed concurrently to that and not updated accordingly.  
  
Reviewed-by: Amit Kapila <[email protected]>  
Discussion: https://www.postgresql.org/message-id/flat/[email protected]  

commit   : db9127c58cbaa748d00055ce10c6bf50a7fbcc1e    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 15 Jan 2023 17:32:09 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 15 Jan 2023 17:32:09 -0500    

int2vectorin limited the number of array elements it'd take to  
FUNC_MAX_ARGS, which is probably fine for the traditional use-cases.  
But now that pg_publication_rel.prattrs is an int2vector, it's not  
fine at all: it's easy to construct cases where that can have up to  
about MaxTupleAttributeNumber entries.  Trying to replicate such  
tables leads to logical-replication failures.  
  
As long as we have to touch this code anyway, let's just remove  
the a-priori limit altogether, and let it accept any size that'll  
be allowed by repalloc.  (Note that since int2vector isn't toastable,  
we cannot store arrays longer than about BLCKSZ/2; but there is no  
good excuse for letting int2vectorin depend on that.  Perhaps we  
will lift the no-toast restriction someday.)  
  
While at it, also improve the equivalent logic in oidvectorin.  
I don't know of any practical use-case for long oidvectors right  
now, but doing it right actually makes the code shorter.  
  
Per report from Erik Rijkers.  Back-patch to v15 where  
pg_publication_rel.prattrs was added.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : a8f7687a0b8645697b48cc40fd1a73d455d0c1fc    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 15 Jan 2023 14:06:46 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 15 Jan 2023 14:06:46 -0500    

In commit 8bf6ec3ba I assumed that no code path could reach  
ExecGetExtraUpdatedCols without having gone through  
ExecInitStoredGenerated.  That turns out not to be the case in  
logical replication: if there's an ON UPDATE trigger on the target  
table, trigger.c will call this code before anybody has set up its  
generated columns.  Having seen that, I don't have a lot of faith in  
there not being other such paths.  ExecGetExtraUpdatedCols can call  
ExecInitStoredGenerated for itself, as long as we are willing to  
assume that it is only called in CMD_UPDATE operations, which on  
the whole seems like a safer leap of faith.  
  
Per report from Vitaly Davydov.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 40015cf8ec7a0384a0320c11a31fdeebba4b8e15    
  
author   : Tatsuo Ishii <[email protected]>    
date     : Sat, 14 Jan 2023 18:12:19 +0900    
  
committer: Tatsuo Ishii <[email protected]>    
date     : Sat, 14 Jan 2023 18:12:19 +0900    

<varname>archive_command</varname> was unnecessarily repeated.  
  
Author: Tatsuo Ishii  
Reviewed-by: Amit Kapila  
Backpatch-through: 15  
Discussion: https://postgr.es/m/flat/20230114.110234.666053507266410467.t-ishii%40sranhm.sra.co.jp  

commit   : 93595ffd5964247198699339fd8af19c1e4b6a33    
  
author   : Michael Paquier <[email protected]>    
date     : Fri, 13 Jan 2023 09:30:12 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Fri, 13 Jan 2023 09:30:12 +0900    

As introduced in 2258e76, the docs were hard to parse:  
- The examples used listed a lot of long records, bloating the output.  
These are switched to show less records with the expanded format,  
similarly to pageinspect.  
- The function descriptions listed all the OUT parameters, producing  
long lines.  This is updated so as only the input parameters are  
documented, clarifying the whole.  
- Remove one example on pg_get_wal_stats() when per_record is set to  
true, which is not really necessary once we know the output produced,  
and the behavior of the parameter is documented.  
  
While on it, fix a few grammar mistakes and simplify a couple of  
sentences.  
  
Author: Bharath Rupireddy  
Discussion: https://postgr.es/m/CALj2ACVGcUpziGgQrcT-1G3dHWQQfWjYBu1YQ2ypv9y86dgogg@mail.gmail.com  
Backpatch-through: 15  

commit   : 8a98523a542f0fb6fa19c071922776dac7d45d36    
  
author   : Thomas Munro <[email protected]>    
date     : Fri, 13 Jan 2023 10:40:52 +1300    
  
committer: Thomas Munro <[email protected]>    
date     : Fri, 13 Jan 2023 10:40:52 +1300    

The WAIT_USE_EPOLL and WAIT_USE_KQUEUE implementations of  
WaitEventSetWaitBlock() confused the size of their internal buffer with  
the size of the caller's output buffer, and could ask the kernel for too  
many events.  In fact the set of events retrieved from the kernel needs  
to be able to fit in both buffers, so take the smaller of the two.  
  
The WAIT_USE_POLL and WAIT_USE WIN32 implementations didn't have this  
confusion.  
  
This probably didn't come up before because we always used the same  
number in both places, but commit 7389aad6 calculates a dynamic size at  
construction time, while using MAXLISTEN for its output event buffer on  
the stack.  That seems like a reasonable thing to want to do, so  
consider this to be a pre-existing bug worth fixing.  
  
As discovered by valgrind on skink.  
  
Back-patch to all supported releases for epoll, and to release 13 for  
the kqueue part, which copied the incorrect epoll code.  
  
Reviewed-by: Andres Freund <[email protected]>  
Discussion: https://postgr.es/m/901504.1673504836%40sss.pgh.pa.us  

commit   : 4dc3f94fae3de3f19b5c7dd507beac0216b0cde9    
  
author   : Alexander Korotkov <[email protected]>    
date     : Thu, 12 Jan 2023 18:16:34 +0300    
  
committer: Alexander Korotkov <[email protected]>    
date     : Thu, 12 Jan 2023 18:16:34 +0300    

The current jsonpath code assumes that the referenced variable always exists.  
It could only throw an error at the value valuation time.  At the same time  
existence checking assumes variable is present without valuation, and error  
suppression doesn't work for missing variables.  
  
This commit makes existense checking trigger an error for missing variables.  
This makes the overall behavior consistent.  
  
Backpatch to 12 where jsonpath was introduced.  
  
Reported-by: David G. Johnston  
Discussion: https://postgr.es/m/CAKFQuwbeytffJkVnEqDyLZ%3DrQsznoTh1OgDoOF3VmOMkxcTMjA%40mail.gmail.com  
Author: Alexander Korotkov, David G. Johnston  
Backpatch-through: 12  

commit   : 6f25e48774fe9302ca08dae07420df95998d792a    
  
author   : Michael Paquier <[email protected]>    
date     : Thu, 12 Jan 2023 13:41:22 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Thu, 12 Jan 2023 13:41:22 +0900    

The creation of a logical decoding context in CreateDecodingContext()  
updates some data of its slot for two-phase transactions if enabled by  
the caller, but the code forgot to acquire a spinlock when updating  
these fields like any other code paths.  This could lead to the read of  
inconsistent data.  
  
Oversight in a8fd13c.  
  
Author: Sawada Masahiko  
Discussion: https://postgr.es/m/CAD21AoAD8_fp47191LKuecjDd3DYhoQ4TaucFco1_TEr_jQ-Zw@mail.gmail.com  
Backpatch-through: 15  

commit   : 38255f2d0059a101c3fb791d6523a9e66e55aa66    
  
author   : Dean Rasheed <[email protected]>    
date     : Tue, 10 Jan 2023 14:16:27 +0000    
  
committer: Dean Rasheed <[email protected]>    
date     : Tue, 10 Jan 2023 14:16:27 +0000    

The former code would only detect an unreachable WHEN clause if it had  
an AND condition. Fix, so that unreachable unconditional WHEN clauses  
are also detected.  
  
Back-patch to v15, where MERGE was added.  
  
Discussion: https://postgr.es/m/CAEZATCVQ=7E2z4cSBB49jjeGGsB6WeoYQY32NDeSvcHiLUZ=ow@mail.gmail.com  

commit   : 18b81258ab60cdd172329fe80dd2314d587bd551    
  
author   : Amit Kapila <[email protected]>    
date     : Sat, 7 Jan 2023 12:04:33 +0530    
  
committer: Amit Kapila <[email protected]>    
date     : Sat, 7 Jan 2023 12:04:33 +0530    

After restart, we try to stream the changes for large transactions that  
were not sent before server crash and restart. However, we forget to send  
the abort message for such transactions. This leads to spurious streaming  
files on the subscriber which won't be cleaned till the apply worker or  
the subscriber server restarts.  
  
Reported-by: Dilip Kumar  
Author: Hou Zhijie  
Reviewed-by: Dilip Kumar and Amit Kapila  
Backpatch-through: 14  
Discussion: https://postgr.es/m/OS0PR01MB5716A773F46768A1B75BE24394FB9@OS0PR01MB5716.jpnprd01.prod.outlook.com  

commit   : 2daf4664ce5402e4bd5bda24bf52716137336ad2    
  
author   : Dean Rasheed <[email protected]>    
date     : Fri, 6 Jan 2023 11:16:53 +0000    
  
committer: Dean Rasheed <[email protected]>    
date     : Fri, 6 Jan 2023 11:16:53 +0000    

The ALTER DATABASE|FUNCTION|PROCEDURE|ROLE|ROUTINE|USER ... SET <name>  
case in psql tab completion failed to exclude <name> = "SCHEMA", which  
caused ALTER FUNCTION|PROCEDURE|ROUTINE ... SET SCHEMA to complete  
with "FROM CURRENT" and "TO", which won't work.  
  
Fix that, so that those cases now complete with the list of schemas,  
like other ALTER ... SET SCHEMA commands.  
  
Noticed while testing the recent patch to improve tab completion for  
ALTER FUNCTION/PROCEDURE/ROUTINE, but this is not directly related to  
that patch. Rather, this is a long-standing bug, so back-patch to all  
supported branches.  
  
Discussion: https://postgr.es/m/CALDaNm0s7GQmkLP_mx5Cvk=UzYMnjhPmXBxU8DsHEunFbC5sTg@mail.gmail.com  

commit   : f60acde869985b35146c6f7f941dd571fc88b3c4    
  
author   : Thomas Munro <[email protected]>    
date     : Fri, 6 Jan 2023 16:38:46 +1300    
  
committer: Thomas Munro <[email protected]>    
date     : Fri, 6 Jan 2023 16:38:46 +1300    

Commit 57faaf376 added pg_truncate(const char *path, off_t length), but  
"length" was ignored under WIN32 and the file was unconditionally  
truncated to 0.  
  
There was no live bug, since the only caller passes 0.  
  
Fix, and back-patch to 14 where the function arrived.  
  
Author: Justin Pryzby <[email protected]>  
Discussion: https://postgr.es/m/20230106031652.GR3109%40telsasoft.com  

commit   : 3706cc97aa36bb65fd82dbfc79ca809033bcad1f    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 5 Jan 2023 14:12:17 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 5 Jan 2023 14:12:17 -0500    

We were identifying the updatable generated columns of inheritance  
children by transposing the calculation made for their parent.  
However, there's nothing that says a traditional-inheritance child  
can't have generated columns that aren't there in its parent, or that  
have different dependencies than are in the parent's expression.  
(At present it seems that we don't enforce that for partitioning  
either, which is likely wrong to some degree or other; but the case  
clearly needs to be handled with traditional inheritance.)  
  
Hence, drop the very-klugy-anyway "extraUpdatedCols" RTE field  
in favor of identifying which generated columns depend on updated  
columns during executor startup.  In HEAD we can remove  
extraUpdatedCols altogether; in back branches, it's still there but  
always empty.  Another difference between the HEAD and back-branch  
versions of this patch is that in HEAD we can add the new bitmap field  
to ResultRelInfo, but that would cause an ABI break in back branches.  
Like 4b3e37993, add a List field at the end of struct EState instead.  
  
Back-patch to v13.  The bogus calculation is also being made in v12,  
but it doesn't have the same visible effect because we don't use it  
to decide which generated columns to recalculate; as a consequence of  
which the patch doesn't apply easily.  I think that there might still  
be a demonstrable bug associated with trigger firing conditions, but  
that's such a weird corner-case usage that I'm content to leave it  
unfixed in v12.  
  
Amit Langote and Tom Lane  
  
Discussion: https://postgr.es/m/CA+HiwqFshLKNvQUd1DgwJ-7tsTp=dwv7KZqXC4j2wYBV1aCDUA@mail.gmail.com  
Discussion: https://postgr.es/m/[email protected]  

commit   : aa26980ca0813200c25b06e3ad0f54d449cce8b2    
  
author   : Robert Haas <[email protected]>    
date     : Tue, 3 Jan 2023 14:50:40 -0500    
  
committer: Robert Haas <[email protected]>    
date     : Tue, 3 Jan 2023 14:50:40 -0500    

In user-manag.sgml, document precisely what privileges are conveyed  
by CREATEROLE. Make particular note of the fact that it allows  
changing passwords and granting access to high-privilege roles.  
Also remove the suggestion of using a user with CREATEROLE and  
CREATEDB instead of a superuser, as there is no real security  
advantage to this approach.  
  
Elsewhere in the documentation, adjust text that suggests that  
<literal>CREATEROLE</literal> only allows for role creation, and  
refer to the documentation in user-manag.sgml as appropriate.  
  
Patch by me, reviewed by Álvaro Herrera  
  
Discussion: http://postgr.es/m/CA+TgmoZBsPL8nPhvYecx7iGo5qpDRqa9k_AcaW1SbOjugAY1Ag@mail.gmail.com  

commit   : c772dfe07a9d4e499117f58d47a7c50d56666459    
  
author   : Michael Paquier <[email protected]>    
date     : Tue, 3 Jan 2023 16:26:27 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Tue, 3 Jan 2023 16:26:27 +0900    

While on it, newlines are removed from the end of two elog() strings.  
The others are simple grammar mistakes.  One comment in pg_upgrade  
referred incorrectly to sequences since a7e5457.  
  
Author: Justin Pryzby  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 11  

commit   : c6e75e4c2703d8eb7cb14cbf94a3d3dc36fdabbd    
  
author   : Andres Freund <[email protected]>    
date     : Thu, 29 Dec 2022 12:47:29 -0800    
  
committer: Andres Freund <[email protected]>    
date     : Thu, 29 Dec 2022 12:47:29 -0800    

New versions of perl trigger warnings within perl.h with our compiler  
flags. At least -Wdeclaration-after-statement, -Wshadow=compatible-local are  
known to be problematic.  
  
To avoid these warnings, conditionally use #pragma GCC system_header before  
including plperl.h.  
  
Alternatively, we could add the include paths for problematic headers with  
-isystem, but that is a larger hammer and is harder to search for.  
  
A more granular alternative would be to use #pragma GCC diagnostic  
push/ignored/pop, but gcc warns about unknown warnings being ignored, so every  
to-be-ignored-temporarily compiler warning would require its own pg_config.h  
symbol and #ifdef.  
  
As the warnings are voluminous, it makes sense to backpatch this change. But  
don't do so yet, we first want gather buildfarm coverage - it's e.g. possible  
that some compiler claiming to be gcc compatible has issues with the pragma.  
  
Author: Andres Freund <[email protected]>  
Reviewed-by: Tom Lane <[email protected]>  
Discussion: Discussion: https://postgr.es/m/[email protected]  

commit   : fbed54fb3890894055072381bb13850baf524ba5    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 2 Jan 2023 16:17:00 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 2 Jan 2023 16:17:00 -0500    

When considering an empty grouping set, we fetched  
phasedata->eqfunctions[-1].  Because the eqfunctions array is  
palloc'd, that would always be an aset pointer in released versions,  
and thus the code accidentally failed to malfunction (since it would  
do nothing unless it found a null pointer).  Nonetheless this seems  
like trouble waiting to happen, so add a check for length == 0.  
  
It's depressing that our valgrind testing did not catch this.  
Maybe we should reconsider the choice to not mark that word NOACCESS?  
  
Richard Guo  
  
Discussion: https://postgr.es/m/CAMbWs4-vZuuPOZsKOYnSAaPYGKhmacxhki+vpOKk0O7rymccXQ@mail.gmail.com  

commit   : 1fbcb1360bc19b89369209203ea7cc19b8cde224    
  
author   : Bruce Momjian <[email protected]>    
date     : Mon, 2 Jan 2023 15:00:37 -0500    
  
committer: Bruce Momjian <[email protected]>    
date     : Mon, 2 Jan 2023 15:00:37 -0500    

Backpatch-through: 11  

commit   : dc513bc6544dd7f49a1c2d3bf06c77dbc2b5c9c3    
  
author   : Thomas Munro <[email protected]>    
date     : Sun, 1 Jan 2023 10:43:23 +1300    
  
committer: Thomas Munro <[email protected]>    
date     : Sun, 1 Jan 2023 10:43:23 +1300    

Cirrus is about to shut down its macOS-on-Intel support, so it's time to  
move our CI testing over to ARM instances.  The Homebrew package manager  
changed its default installation prefix for the new architecture, so a  
couple of tests need tweaks to find binaries.  
  
Back-patch to 15, where in-tree CI began.  
  
Author: Justin Pryzby <[email protected]>  
Discussion: https://postgr.es/m/20221122225744.GF11463%40telsasoft.com  

commit   : c4f64cfab9fefd7974c9097be72691c33c7afcea    
  
author   : Tomas Vondra <[email protected]>    
date     : Fri, 30 Dec 2022 19:44:48 +0100    
  
committer: Tomas Vondra <[email protected]>    
date     : Fri, 30 Dec 2022 19:44:48 +0100    

When brin_minmax_multi_union merges summaries, we may end up with just a  
single range after merge_overlapping_ranges. The summaries may contain  
just one range each, and they may overlap (or be exactly the same).  
  
With a single range there's no distance to calculate, but we happen to  
call build_distances anyway - which is fine, we don't calculate the  
distance in this case, except that with asserts this failed due to a  
check there are at least two ranges.  
  
The assert is unnecessarily strict, so relax it a bit and bail out if  
there's just a single range. The relaxed assert would be enough, but  
this way we don't allocate unnecessary memory for distance.  
  
Backpatch to 14, where minmax-multi opclasses were introduced.  
  
Reported-by: Jaime Casanova  
Backpatch-through: 14  
Discussion: https://postgr.es/m/YzVA55qS0hgz8P3r@ahch-to  

commit   : d8209d09170f0029663da4335979b4f49d48b6be    
  
author   : Alvaro Herrera <[email protected]>    
date     : Fri, 23 Dec 2022 17:49:51 +0100    
  
committer: Alvaro Herrera <[email protected]>    
date     : Fri, 23 Dec 2022 17:49:51 +0100    

After some copy-edit I made in commit 3a06a79cd137, we have a <sect2>  
that only contains a warning box.  This doesn't look good.  Rework by  
moving the sect2 title to be the warning's title, and put the 'id' to it  
as well, so that the external reference continues to work.  
  
Backpatch to 15.  
  
In branch master, I also take the opportunity to add titles to a couple  
of other warning boxes elsewhere in the documentation.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 5436cb373c6289eca8fc2b4aabb75f002a0394cf    
  
author   : Alvaro Herrera <[email protected]>    
date     : Fri, 23 Dec 2022 17:27:05 +0100    
  
committer: Alvaro Herrera <[email protected]>    
date     : Fri, 23 Dec 2022 17:27:05 +0100    

The test added in commit e44dae07f931 has a thinko: it wants to read  
info about a few WAL records, but it obtains the LSN of the final record  
to read by asking for the WAL insert position; however,  
pg_get_wal_records_info only accepts to read up to the flush position  
(cf. IsFutureLSN()).  In normal conditions there is no difference, since  
the last record written by the preceding loop is known flushed and it's  
the one the test wants; but it's possible to have some other process  
insert another WAL record that isn't flushed, and that causes the whole  
test to explode.  
  
Fix by having pg_get_wal_records_info() read only up to the flushed  
position.  Backpatch to 15, which is where pg_walinspect appeared.  
  
Author: Karina Litskevich <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  

commit   : 2655ecde2c3313e1f9bc158faee884417252bc38    
  
author   : Alvaro Herrera <[email protected]>    
date     : Fri, 23 Dec 2022 13:21:41 +0100    
  
committer: Alvaro Herrera <[email protected]>    
date     : Fri, 23 Dec 2022 13:21:41 +0100    

Commit 2f9661311b changed command tags from strings to numbers, but  
forgot to adjust the code in the event trigger example, which  
consequently failed to compile.  
  
While fixing that, improve the indentation to adhere to pgindent style.  
  
Backpatch to v13, where the change was introduced.  
  
Author: Laurenz Albe  
Discussion: https://postgr.es/m/[email protected]  

commit   : 9c48a0f00011c45d9a7b8903ffbecd286cf46de0    
  
author   : Michael Paquier <[email protected]>    
date     : Fri, 23 Dec 2022 11:27:11 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Fri, 23 Dec 2022 11:27:11 +0900    

The query used to disable WITH OIDS in all the relations making use of  
it was checking for materialized views, but this is not a supported  
operation.  On the contrary, this needs to be done on foreign tables.  
  
While on it, use quote_ident() in the ALTER TABLE strings built on the  
relation name.  
  
Author: Anton A. Melnikov, Michael Paquier  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 12  

commit   : e3897a3a4c559e20ba2c4f311be6ace8006f9005    
  
author   : Michael Paquier <[email protected]>    
date     : Fri, 23 Dec 2022 10:04:30 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Fri, 23 Dec 2022 10:04:30 +0900    

Three error strings used with cache lookup failures were referring to  
incorrect object types for ACL checks:  
- Schemas  
- Types  
- Foreign Servers  
There errors should never be triggered, but if they do incorrect  
information would be reported.  
  
Author: Justin Pryzby  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 11  

commit   : 1a3daa5bb2e0ec10dd6cee38d120a52bed9213e0    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 22 Dec 2022 10:35:02 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 22 Dec 2022 10:35:02 -0500    

Andrey Lepikhov demonstrated a case where we spend an unreasonable  
amount of time in pull_up_subqueries().  Not only is that recursing  
with no explicit check for stack overrun, but the code seems not  
interruptable by control-C.  Let's stick a CHECK_FOR_INTERRUPTS  
there, along with sprinkling some stack depth checks.  
  
An actual fix for the excessive time consumption seems a bit  
risky to back-patch; but this isn't, so let's do so.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : b87037b373cf5605e6755e50c62348337a0d32c8    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 21 Dec 2022 17:51:50 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 21 Dec 2022 17:51:50 -0500    

seg stores the number of significant digits in an input number  
in a "char" field.  If char is signed, and the input is more than  
127 digits long, the count can read out as negative causing  
seg_out() to print garbage (or, if you're really unlucky,  
even crash).  
  
To fix, clamp the digit count to be not more than FLT_DIG.  
(In theory this loses some information about what the original  
input was, but it doesn't seem like useful information; it would  
not survive dump/restore in any case.)  
  
Also, in case there are stored values of the seg type containing  
bad data, add a clamp in seg_out's restore() subroutine.  
  
Per bug #17725 from Robins Tharakan.  It's been like this  
forever, so back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : ae98debf77d4aba7caa305fa4957577528699470    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 16 Dec 2022 13:07:42 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 16 Dec 2022 13:07:42 -0500    

Such references failed with "cache lookup failed for type 0"  
because we didn't resolve the type of the CYCLE column until after  
analyzing the CTE's query.  We can just move that processing  
to before the recursive parse_sub_analyze call, though.  
  
While here, invent a couple of local variables to make this  
code less egregiously wider-than-80-columns.  
  
Per bug #17723 from Vik Fearing.  Back-patch to v14 where  
the CYCLE feature was added.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 1a9b43c688da9bbb13f0cb07d4b4c03abf1518b5    
  
author   : David Rowley <[email protected]>    
date     : Fri, 16 Dec 2022 11:40:22 +1300    
  
committer: David Rowley <[email protected]>    
date     : Fri, 16 Dec 2022 11:40:22 +1300    

It seems that drop-index-concurrently-1 has started to forget what it was  
originally meant to be testing.  d2d8a229b, which added incremental sorts  
changed the expected plan to be an Index Scan plan instead of a Seq Scan  
plan.  This occurred as the primary key index of the table in question  
provided presorted input and, because that index happened to be the  
cheapest input path due to enable_seqscan being disabled, the incremental  
sort changes just added a Sort on top of that.  It seems based on the name  
of the PREPAREd statement that the intention here is that the query  
produces a seqscan plan.  
  
The reason this test has become broken seems to be due to how the test was  
originally coded.  The test was trying to force a seqscan plan by  
performing some casting to make it so the test_dc index couldn't be used  
to perform the required filtering.  Trying to coax the planner into using  
a plan which has costed in a disable_cost seems like it's always going to  
be flakey as small changes in costs are drowned out by the large  
disable_cost combined with add_path's STD_FUZZ_FACTOR.  Here we get rid of  
the casts that we're using to try to trick the planner into a seqscan and  
instead toggle enable_seqscan as and when required to get the desired  
plan.  
  
Additionally, rename a few things in the test and add some additional  
wording to the comments to try and make it more clear in the future what  
we expect this test to be doing.  
  
Discussion: https://postgr.es/m/CAApHDvrbDhObhLV+=U_K_-t+2Av2av1aL9d+2j_3AO-XndaviA@mail.gmail.com  
Backpatch-through: 13, where d2d8a229b changed the expected test output  

commit   : 18431ee6f511be0c4cf4d7463899ce318c7632eb    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 13 Dec 2022 14:23:59 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 13 Dec 2022 14:23:59 -0500    

Commits f92944137 et al. made IsInTransactionBlock() set the  
XACT_FLAGS_NEEDIMMEDIATECOMMIT flag before returning "false",  
on the grounds that that kept its API promises equivalent to those of  
PreventInTransactionBlock().  This turns out to be a bad idea though,  
because it allows an ANALYZE in a pipelined series of commands to  
cause an immediate commit, which is unexpected.  
  
Furthermore, if we return "false" then we have another issue,  
which is that ANALYZE will decide it's allowed to do internal  
commit-and-start-transaction sequences, thus possibly unexpectedly  
committing the effects of previous commands in the pipeline.  
  
To fix the latter situation, invent another transaction state flag  
XACT_FLAGS_PIPELINING, which explicitly records the fact that we  
have executed some extended-protocol command and not yet seen a  
commit for it.  Then, require that flag to not be set before allowing  
InTransactionBlock() to return "false".  
  
Having done that, we can remove its setting of NEEDIMMEDIATECOMMIT  
without fear of causing problems.  This means that the API guarantees  
of IsInTransactionBlock now diverge from PreventInTransactionBlock,  
which is mildly annoying, but it seems OK given the very limited usage  
of IsInTransactionBlock.  (In any case, a caller preferring the old  
behavior could always set NEEDIMMEDIATECOMMIT for itself.)  
  
For consistency also require XACT_FLAGS_PIPELINING to not be set  
in PreventInTransactionBlock.  This too is meant to prevent commands  
such as CREATE DATABASE from silently committing previous commands  
in a pipeline.  
  
Per report from Peter Eisentraut.  As before, back-patch to all  
supported branches (which sadly no longer includes v10).  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : d79b76b10ed55ceb25377c0623f2a159ad6117b4    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 12 Dec 2022 16:17:49 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 12 Dec 2022 16:17:49 -0500    

jsonb_get_element() was incautious enough to use VARDATA() and  
VARSIZE() directly on an arbitrary text Datum.  That of course  
fails if the Datum is short-header, compressed, or out-of-line.  
The typical result would be failing to match any element of a  
jsonb object, though matching the wrong one seems possible as well.  
  
setPathObject() was slightly brighter, in that it used VARDATA_ANY  
and VARSIZE_ANY_EXHDR, but that only kept it out of trouble for  
short-header Datums.  push_path() had the same issue.  This could  
result in faulty subscripted insertions, though keys long enough to  
cause a problem are likely rare in the wild.  
  
Having seen these, I looked around for unsafe usages in the rest  
of the adt/json* files.  There are a couple of places where it's not  
immediately obvious that the Datum can't be compressed or out-of-line,  
so I added pg_detoast_datum_packed() to cope if it is.  Also, remove  
some other usages of VARDATA/VARSIZE on Datums we just extracted from  
a text array.  Those aren't actively broken, but they will become so  
if we ever start allowing short-header array elements, which does not  
seem like a terribly unreasonable thing to do.  In any case they are  
not great coding examples, and they could also do with comments  
pointing out that we're assuming we don't need pg_detoast_datum_packed.  
  
Per report from [email protected].  Patch by me, but thanks to  
David Johnston for initial investigation.  Back-patch to v14 where  
jsonb subscripting was introduced.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 8b5ba2f3f40a9c82623a19b551bc5790a84275a2    
  
author   : Robert Haas <[email protected]>    
date     : Mon, 12 Dec 2022 10:17:02 -0500    
  
committer: Robert Haas <[email protected]>    
date     : Mon, 12 Dec 2022 10:17:02 -0500    

If sendFileWithContent were used to send a file larger than the  
bbsink buffer size, this would result in corruption. The only  
files that are sent via sendFileWithContent are the backup label  
file, the tablespace map file, and .done files for WAL segments  
included in the backup. Of these, it seems that only the  
tablespace_map file can become large enough to cause a problem,  
and then only if you have a lot of tablespaces. If you do have  
that situation, you might end up with a corrupted  
tablespace_map file, which would be bad.  
  
My commit bef47ff85df18bf4a3a9b13bd2a54820e27f3614 introduced  
this problem.  
  
Report and patch by Antonin Houska.  
  
Discussion: http://postgr.es/m/15764.1670528645@antos  

commit   : 04788ee4c5efcfbf026b968a064fcdd74fcba154    
  
author   : David Rowley <[email protected]>    
date     : Sat, 10 Dec 2022 19:27:53 +1300    
  
committer: David Rowley <[email protected]>    
date     : Sat, 10 Dec 2022 19:27:53 +1300    

9d9c02ccd added code to allow WindowAgg to take some shortcuts when a  
monotonic WindowFunc reached some value that it could never come back  
from due to the function's monotonic nature.  That commit added a  
runCondition field to WindowClause to store the condition which, when it  
becomes false we can start taking shortcuts in nodeWindowAgg.c.  
  
Here we fix an issue where subquery pullups didn't properly update the  
runCondition to update the Vars to properly reference the new query level.  
  
Here we also add a missing call to preprocess_expression() for the  
WindowClause's runCondtion.  The WindowFuncs in the targetlist will have  
had this process done, so we must also do it for the WindowFuncs in the  
runCondition so that they can be correctly found in the targetlist  
during setrefs.c  
  
Bug: #17709  
Reported-by: Alexey Makhmutov  
Author: Richard Guo, David Rowley  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 15, where 9d9c02ccd was introduced  

commit   : ee1c6728d8a9c377287577e34444442fa3ed16eb    
  
author   : Dean Rasheed <[email protected]>    
date     : Fri, 9 Dec 2022 10:03:04 +0000    
  
committer: Dean Rasheed <[email protected]>    
date     : Fri, 9 Dec 2022 10:03:04 +0000    

Commit 7103ebb7aa added support for MERGE, which included support for  
inheritance hierarchies, but didn't document the fact that ONLY could  
be specified before the source and/or target tables to exclude tables  
inheriting from the tables specified.  
  
Update merge.sgml to mention this, and while at it, add some  
regression tests to cover it.  
  
Dean Rasheed, reviewed by Nathan Bossart.  
  
Backpatch to 15, where MERGE was added.  
  
Discussion: https://postgr.es/m/CAEZATCU0XM-bJCvpJuVRU3UYNRqEBS6g4-zH%3Dj9Ye0caX8F6uQ%40mail.gmail.com  

commit   : a0bf7a0eccbf73c7ce4efd7b09c3c9544a57c5a4    
  
author   : Etsuro Fujita <[email protected]>    
date     : Thu, 8 Dec 2022 16:15:01 +0900    
  
committer: Etsuro Fujita <[email protected]>    
date     : Thu, 8 Dec 2022 16:15:01 +0900    

In commit ffbb7e65a, I added a ModifyTableState member to ResultRelInfo  
to save the owning ModifyTableState for use by nodeModifyTable.c when  
performing batch inserts, but as pointed out by Tom Lane, that changed  
the array stride of es_result_relations, and that would break any  
previously-compiled extension code that accesses that array.  Fix by  
removing that member from ResultRelInfo and instead adding a List member  
at the end of EState to save such ModifyTableStates.  
  
Per report from Tom Lane.  Back-patch to v14, like the previous commit;  
I chose to apply the patch to HEAD as well, to make back-patching easy.  
  
Discussion: http://postgr.es/m/4065383.1669395453%40sss.pgh.pa.us  

commit   : 6bcd1d9f30c00fda59cd5210fc368bc086db15f6    
  
author   : Peter Eisentraut <[email protected]>    
date     : Wed, 7 Dec 2022 17:06:50 +0100    
  
committer: Peter Eisentraut <[email protected]>    
date     : Wed, 7 Dec 2022 17:06:50 +0100    

from commit d6f96ed94e7  
  
Author: Paul Jungwirth <[email protected]>  
Reviewed-by: Ian Lawrence Barwick <[email protected]>  
Discussion: https://www.postgresql.org/message-id/flat/6a7c7338-1aa2-4689-d171-0b0b294fdd84%40illuminatedcomputing.com  

commit   : 2a535620cec565e2ef195f99ca186ab71a1cacbb    
  
author   : David Rowley <[email protected]>    
date     : Wed, 7 Dec 2022 00:10:21 +1300    
  
committer: David Rowley <[email protected]>    
date     : Wed, 7 Dec 2022 00:10:21 +1300    

9d9c02ccd added window "run conditions", which allows the evaluation of  
monotonic window functions to be skipped when the run condition is no  
longer true.  Prior to this commit, once the run condition was no longer  
true and we stopped evaluating the window functions, we simply just left  
the ecxt_aggvalues[] and ecxt_aggnulls[] arrays alone to store whatever  
value was stored there the last time the window function was evaluated.  
Leaving a stale value in there isn't really a problem on 64-bit builds as  
all of the window functions which we recognize as monotonic all return  
int8, which is passed by value on 64-bit builds.  However, on 32-bit  
builds, this was a problem as the value stored in the ecxt_values[]  
element would be a by-ref value and it would be pointing to some memory  
which would get reset once the tuple context is destroyed.  Since the  
WindowAgg node will output these values in the resulting tupleslot, this  
could be problematic for the top-level WindowAgg node which must look at  
these values to filter out the rows that don't meet its filter condition.  
  
Here we fix this by just zeroing the ecxt_aggvalues[] and setting the  
ecxt_aggnulls[] array to true when the run condition first becomes false.  
This results in the WindowAgg's output having NULLs for the WindowFunc's  
columns rather than the stale or pointer pointing to possibly freed  
memory.  These tuples with the NULLs can only make it as far as the  
top-level WindowAgg node before they're filtered out.  To ensure that  
these tuples *are* always filtered out, we now insist that OpExprs making  
up the run condition are strict OpExprs.  Currently, all the window  
functions which the planner recognizes as monotonic return INT8 and the  
operator which is used for the run condition must be a member of a btree  
opclass.  In reality, these restrictions exclude nothing that's built-in  
to Postgres and are unlikely to exclude anyone's custom operators due to  
the requirement that the operator is part of a btree opclass.  It would be  
unusual if those were not strict.  
  
Reported-by: Sergey Shinderuk, using valgrind  
Reviewed-by: Richard Guo, Sergey Shinderuk  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 15, where 9d9c02ccd was added  

commit   : c959f84c2b770bc136ade3cfd11f6063a51d2708    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 5 Dec 2022 12:36:41 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 5 Dec 2022 12:36:41 -0500    

A couple of places weren't up to speed for this.  By sheer good  
luck, we didn't fail but just selected a non-memoized join plan,  
at least in the test case we have.  Nonetheless, it's a bug,  
and I'm not quite sure that it couldn't have worse consequences  
in other examples.  So back-patch to v14 where Memoize came in.  
  
Richard Guo  
  
Discussion: https://postgr.es/m/CAMbWs48GkNom272sfp0-WeD6_0HSR19BJ4H1c9ZKSfbVnJsvRg@mail.gmail.com  

commit   : 74a600a1506113cce67aa2d5b869ad69459a8ccd    
  
author   : Michael Paquier <[email protected]>    
date     : Mon, 5 Dec 2022 11:23:27 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Mon, 5 Dec 2022 11:23:27 +0900    

Missing such markups makes it impossible to create links back to these  
GUCs, and all the other parameters have one already.  
  
Author: Ian Lawrence Barwick  
Discussion: https://postgr.es/m/CAB8KJ=jx=6dFB_EN3j0UkuvG3cPu5OmQiM-ZKRAz+fKvS+u8Ng@mail.gmail.com  
Backpatch-through: 11  

commit   : 834d97c32b712c170594378d27385638c5b87c60    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 4 Dec 2022 13:48:12 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 4 Dec 2022 13:48:12 -0500    

It neglected to recurse to the subpath, meaning you'd get back  
a path identical to the input.  This could produce wrong query  
results if the omission meant that the subpath fails to enforce  
some join clause it should be enforcing.  We don't have a test  
case for this at the moment, but the code is obviously broken  
and the fix is equally obvious.  Back-patch to v14 where  
Memoize was introduced.  
  
Richard Guo  
  
Discussion: https://postgr.es/m/CAMbWs4_R=ORpz=Lkn2q3ebPC5EuWyfZF+tmfCPVLBVK5W39mHA@mail.gmail.com  

commit   : bf8fd64ff5e65f8964d1b52c50019f0198ec5f5e    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 4 Dec 2022 13:17:18 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 4 Dec 2022 13:17:18 -0500    

We might fail to generate a partitionwise join, because  
reparameterize_path_by_child() does not support all path types.  
This should not be a hard failure condition: we should just fall back  
to a non-partitioned join.  However, generate_partitionwise_join_paths  
did not consider this possibility and would emit the (misleading)  
error "could not devise a query plan for the given query" if we'd  
failed to make any paths for a child join.  Fix it to give up on  
partitionwise joining if so.  (The accepted technique for giving up  
appears to be to set rel->nparts = 0, which I find pretty bizarre,  
but there you have it.)  
  
I have not added a test case because there'd be little point:  
any omissions of this sort that we identify would soon get fixed  
by extending reparameterize_path_by_child(), so the test would stop  
proving anything.  However, right now there is a known test case based  
on failure to cover MaterialPath, and with that I've found that this  
is broken in all supported versions.  Hence, patch all the way back.  
  
Original report and patch by me; thanks to Richard Guo for  
identifying a test case that works against committed versions.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : c67204db61fa9c4429b30ce031ef833748c8c69a    
  
author   : Dean Rasheed <[email protected]>    
date     : Sat, 3 Dec 2022 12:14:36 +0000    
  
committer: Dean Rasheed <[email protected]>    
date     : Sat, 3 Dec 2022 12:14:36 +0000    

When updating a relation with a rule whose action performed an INSERT  
from a multi-row VALUES list, the rewriter might skip processing the  
VALUES list, and therefore fail to replace any DEFAULTs in it. This  
would lead to an "unrecognized node type" error.  
  
The reason was that RewriteQuery() assumed that a query doing an  
INSERT from a multi-row VALUES list would necessarily only have one  
item in its fromlist, pointing to the VALUES RTE to read from. That  
assumption is correct for the original query, but not for product  
queries produced for rule actions. In such cases, there may be  
multiple items in the fromlist, possibly including multiple VALUES  
RTEs.  
  
What is required instead is for RewriteQuery() to skip any RTEs from  
the product query's originating query, which might include one or more  
already-processed VALUES RTEs. What's left should then include at most  
one VALUES RTE (from the rule action) to be processed.  
  
Patch by me. Thanks to Tom Lane for reviewing.  
  
Back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/CAEZATCV39OOW7LAR_Xq4i%2BLc1Byux%3DeK3Q%3DHD_pF1o9LBt%3DphA%40mail.gmail.com  

commit   : c6a60471a1a5e21bf901ad24cac27874a1886306    
  
author   : Andres Freund <[email protected]>    
date     : Fri, 2 Dec 2022 17:50:26 -0800    
  
committer: Andres Freund <[email protected]>    
date     : Fri, 2 Dec 2022 17:50:26 -0800    

When the relkind of a relache entry changes, because a table is converted into  
a view, pgstats can get confused in 15+, leading to crashes or assertion  
failures.  
  
For HEAD, Tom fixed this in b23cd185fd5, by removing support for converting a  
table to a view, removing the source of the inconsistency. This commit just  
adds an assertion that a relcache entry's relkind does not change, just in  
case we end up with another case of that in the future. As there's no cases of  
changing relkind anymore, we can't add a test that that's handled correctly.  
  
For 15, fix the problem by not maintaining the association with the old pgstat  
entry when the relkind changes during a relcache invalidation processing. In  
that case the pgstat entry needs to be unlinked first, to avoid  
PgStat_TableStatus->relation getting out of sync. Also add a test reproducing  
the issues.  
  
No known problem exists in 11-14, so just add the test there.  
  
Reported-by: vignesh C <[email protected]>  
Author: Andres Freund <[email protected]>  
Reviewed-by: Tom Lane <[email protected]>  
Discussion: https://postgr.es/m/CALDaNm2yXz+zOtv7y5zBd5WKT8O0Ld3YxikuU3dcyCvxF7gypA@mail.gmail.com  
Discussion: https://postgr.es/m/CALDaNm3oZA-8Wbps2Jd1g5_Gjrr-x3YWrJPek-mF5Asrrvz2Dg@mail.gmail.com  
Backpatch: 15-  

commit   : 97299cf99df086af847a641161e8b925fdf840b9    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 2 Dec 2022 14:24:44 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 2 Dec 2022 14:24:44 -0500    

Some options of these commands need to be able to identify the start  
of the function body within the output of pg_get_functiondef().  
It used to be that that always began with "AS", but since the  
introduction of new-style SQL functions, it might also start with  
"BEGIN" or "RETURN".  Fix that on the psql side, and add some  
regression tests.  
  
Noted by me awhile ago, but I didn't do anything about it.  
Thanks to David Johnston for a nag.  
  
Discussion: https://postgr.es/m/AM9PR01MB8268D5CDABDF044EE9F42173FE8C9@AM9PR01MB8268.eurprd01.prod.exchangelabs.com  

commit   : ebf87c019c042a33cf9d2810c1fe360ddc7f8e93    
  
author   : Amit Kapila <[email protected]>    
date     : Fri, 2 Dec 2022 10:34:16 +0530    
  
committer: Amit Kapila <[email protected]>    
date     : Fri, 2 Dec 2022 10:34:16 +0530    

For Updates and Deletes, we were not honoring the columns list for old  
tuple values while sending tuple data via pgoutput. This results in  
pgoutput emitting more columns than expected.  
  
This is not a problem for built-in logical replication as we simply ignore  
additional columns based on the relation information sent previously which  
didn't have those columns. However, some other users of pgoutput plugin  
may expect the columns as per the column list. Also, sending extra columns  
unnecessarily consumes network bandwidth defeating the purpose of the  
column list feature.  
  
Reported-by: Gunnar Morling  
Author: Hou Zhijie  
Reviewed-by: Amit Kapila  
Backpatch-through: 15  
Discussion: https://postgr.es/m/CADGJaX9kiRZ-OH0EpWF5Fkyh1ZZYofoNRCrhapBfdk02tj5EKg@mail.gmail.com  

commit   : 9377b4f30a14e1c79183b3138fa88fc99d4a872a    
  
author   : Jeff Davis <[email protected]>    
date     : Thu, 1 Dec 2022 11:26:32 -0800    
  
committer: Jeff Davis <[email protected]>    
date     : Thu, 1 Dec 2022 11:26:32 -0800    

Backpatch through 12, where nondeterministic collations were  
introduced (5e1963fb76).  
  
Backpatch-through: 12  

commit   : e10799aa252c2232a3d4f73f4875532423f3f7b4    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 1 Dec 2022 12:26:12 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 1 Dec 2022 12:26:12 -0500    

This has always worked, but you'd be unlikely to guess it  
from the documentation.  Add an example showing it.  
  
Lack of docs noted by David Johnston.  Back-patch to v13;  
the documentation layout we used before that was not very  
amenable to squeezing in multiple examples.  
  
Discussion: https://postgr.es/m/CAKFQuwZ4Vy1Xty0G5Ok+ot=NDrU3C6hzF1JwUk-FEkwe3V9_RA@mail.gmail.com  

commit   : afa4a4f764cca2d0232d9f12d0a268c3804afce7    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 1 Dec 2022 12:10:25 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 1 Dec 2022 12:10:25 -0500    

Rearrange the discussion of user-private schemas so that details  
applying only to upgraded-from-pre-v15 databases are in a follow-on  
paragraph, not in the main description of how to set up this pattern.  
This seems a little clearer even today, and it'll get more so as  
pre-v15 systems fade into the sunset.  
  
Wording contributions from Robert Haas, Tom Lane, Noah Misch.  
  
Discussion: https://postgr.es/m/CA+TgmoYUHsfp90inEMAP0yNr7Y_L6EphPH1YOon1JKtBztXHyQ@mail.gmail.com  

commit   : a711b36e5b88e786f541b6c5671f28e997e68415    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 1 Dec 2022 11:38:06 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 1 Dec 2022 11:38:06 -0500    

In commit 40c24bfef, I forgot to use get_rule_expr_paren() for the  
arguments of AT TIME ZONE, resulting in possibly not printing parens  
for expressions that need it.  But get_rule_expr_paren() wouldn't have  
gotten it right anyway, because isSimpleNode() hadn't been taught that  
COERCE_SQL_SYNTAX parent nodes don't guarantee sufficient parentheses.  
Improve all that.  Also use this methodology for F_IS_NORMALIZED, so  
that we don't print useless parens for that.  
  
In passing, remove a comment that was obsoleted later.  
  
Per report from Duncan Sands.  Back-patch to v14 where this code  
came in.  (Before that, we didn't try to print AT TIME ZONE that way,  
so there was no bug just ugliness.)  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : f79cca5bfd2250c56e93f32a21bd3cd39be07724    
  
author   : Bruce Momjian <[email protected]>    
date     : Thu, 1 Dec 2022 10:45:08 -0500    
  
committer: Bruce Momjian <[email protected]>    
date     : Thu, 1 Dec 2022 10:45:08 -0500    

This doc patch (master hash 66bc9d2d3e) was decided to be too  
significant for backpatching, so reverted in all but master.  Also fix  
SGML file header comment in master.  
  
Reported-by:  	Peter Eisentraut  
  
Discussion: https://postgr.es/m/[email protected]  
  
Backpatch-through: 11  

commit   : f2f9e11d35226ff8d4cbb737b7c31d072e212178    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 30 Nov 2022 13:01:41 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 30 Nov 2022 13:01:41 -0500    

Writing "pg_regress --dbname= ..." led to a crash, because  
we weren't expecting there to be no database name supplied.  
It doesn't seem like a great idea to run regression tests  
in whatever is the user's default database; so rather than  
supporting this case let's explicitly reject it.  
  
Per report from Xing Guo.  Back-patch to all supported  
branches.  
  
Discussion: https://postgr.es/m/CACpMh+A8cRvtvtOWVAZsCM1DU81GK4DL26R83y6ugZ1osV=ifA@mail.gmail.com  

commit   : 8592b56faf86be1a8684544ad3a93e2fe8f5aa1b    
  
author   : Bruce Momjian <[email protected]>    
date     : Tue, 29 Nov 2022 20:49:52 -0500    
  
committer: Bruce Momjian <[email protected]>    
date     : Tue, 29 Nov 2022 20:49:52 -0500    

This also adds references to this new chapter at relevant sections of  
our documentation.  Previously much of these internal details were  
exposed to users, but not explained.  This also updates RELEASE  
SAVEPOINT.  
  
Discussion: https://postgr.es/m/CANbhV-E_iy9fmrErxrCh8TZTyenpfo72Hf_XD2HLDppva4dUNA@mail.gmail.com  
  
Author: Simon Riggs, Laurenz Albe  
  
Reviewed-by: Bruce Momjian  
  
Backpatch-through: 11  

commit   : 15571ccd190b242b944422a663a8269f8f688d4f    
  
author   : Michael Paquier <[email protected]>    
date     : Wed, 30 Nov 2022 08:38:27 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Wed, 30 Nov 2022 08:38:27 +0900    

The frontend-side routine in charge of building a SCRAM verifier  
mentioned that the restrictions applying to SASLprep on the password  
with the encoding are described at the top of fe-auth-scram.c, but this  
information is in auth-scram.c.  
  
This is wrong since 8f8b9be, so backpatch all the way down as this is an  
important documentation bit.  
  
Spotted while reviewing a different patch.  
  
Backpatch-through: 11  

commit   : 55fa993d7eacb3f3ef99015649d44606201767e5    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 29 Nov 2022 15:43:17 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 29 Nov 2022 15:43:17 -0500    

Previously, we'd compress only when the active range of array entries  
reached Max(4 * PROCARRAY_MAXPROCS, 2 * pArray->numKnownAssignedXids).  
If max_connections is large, the first term could result in not  
compressing for a long time, resulting in much wastage of cycles in  
hot-standby backends scanning the array to take snapshots.  Get rid  
of that term, and just bound it to 2 * pArray->numKnownAssignedXids.  
  
That however creates the opposite risk, that we might spend too much  
effort compressing.  Hence, consider compressing only once every 128  
commit records.  (This frequency was chosen by benchmarking.  While  
we only tried one benchmark scenario, the results seem stable over  
a fairly wide range of frequencies.)  
  
Also, force compression when processing RecoveryInfo WAL records  
(which should be infrequent); the old code could perform compression  
then, but would do so only after the same array-range check as for  
the transaction-commit path.  
  
Also, opportunistically run compression if the startup process is about  
to wait for WAL, though not oftener than once a second.  This should  
prevent cases where we waste lots of time by leaving the array  
not-compressed for long intervals due to low WAL traffic.  
  
Lastly, add a simple check to keep us from uselessly compressing  
when the array storage is already compact.  
  
Back-patch, as the performance problem is worse in pre-v14 branches  
than in HEAD.  
  
Simon Riggs and Michail Nikolaev, with help from Tom Lane and  
Andres Freund.  
  
Discussion: https://postgr.es/m/CALdSSPgahNUD_=pB_j=1zSnDBaiOtqVfzo8Ejt5J_k7qZiU1Tw@mail.gmail.com  

commit   : 5dfc2b753b0f40ea036bcf621f827b800a422aac    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 29 Nov 2022 11:46:33 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 29 Nov 2022 11:46:33 -0500    

This is an oversight in commit 7c337b6b5: I apparently didn't think  
about the possibility of a SQL function being executed multiple  
times within a query.  In that case, functions.c's primitive caching  
mechanism allows the same utility parse tree to be presented for  
execution more than once.  We have to tell ProcessUtility to make  
a working copy of the parse tree, or bad things happen.  
  
Normally I'd add a regression test, but I think the reported crasher  
is dependent on some rather random implementation choices that are  
nowhere near functions.c, so its usefulness as a long-lived test  
feels questionable.  In any case, this fix is clearly correct given  
the design choices of 7c337b6b5.  
  
Per bug #17702 from Xin Wen.  Thanks to Daniel Gustafsson for  
analysis.  Back-patch to v14 where the faulty commit came in  
(before that, the responsibility for copying scribble-able  
utility parse trees lay elsewhere).  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 556c0b913be150b92ee9fb250d2d5acc6d28f4c2    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 29 Nov 2022 10:52:44 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 29 Nov 2022 10:52:44 -0500    

The JOIN_SEMI case Assert'ed that there are no PlaceHolderVars that  
need to be evaluated at the semijoin's RHS, which is wrong because  
there could be some in the semijoin's qual condition.  However, there  
could not be any references further up than that, and within the qual  
there is not any way that such a PHV could have gone to null yet, so  
we don't really need the PHV and there is no need to avoid making the  
RHS-removal optimization.  The upshot is that there's no actual bug  
in production code, and we ought to just remove this misguided Assert.  
  
While we're here, also drop the JOIN_RIGHT case, which is dead code  
because reduce_outer_joins() already got rid of JOIN_RIGHT.  
  
Per bug #17700 from Xin Wen.  Uselessness of the JOIN_RIGHT case  
pointed out by Richard Guo.  Back-patch to v12 where this code  
was added.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : b5d8fd4182f24ee489aa6bb72308f8712cd8810d    
  
author   : Andrew Dunstan <[email protected]>    
date     : Sun, 27 Nov 2022 09:03:22 -0500    
  
committer: Andrew Dunstan <[email protected]>    
date     : Sun, 27 Nov 2022 09:03:22 -0500    

When loading plperl built against Strawberry perl or the msys2 ucrt perl  
that have been built with gcc, a binary mismatch has been encountered  
which looks like this:  
  
loadable library and perl binaries are mismatched (got handshake key 0000000012800080, needed 0000000012900080)  
  
To cure this we bring the handshake keys into sync by adding  
NO_THREAD_SAFE_LOCALE to the defines used to build plperl.  
  
Discussion: https://postgr.es/m/[email protected]  
Discussion: https://postgr.es/m/[email protected]  
  
Backpatch to all live branches.  

commit   : 3ae0c48a59f747905f26acd38fecdc3e3f505b5b    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 26 Nov 2022 10:30:31 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 26 Nov 2022 10:30:31 -0500    

Another oversight in 9b4eafcaf.  

commit   : fec24b75230e59ebf90ea5acadb577a1e2b2e923    
  
author   : Andrew Dunstan <[email protected]>    
date     : Sat, 26 Nov 2022 07:44:23 -0500    
  
committer: Andrew Dunstan <[email protected]>    
date     : Sat, 26 Nov 2022 07:44:23 -0500    

Commit 9b4eafcaf4 added creattion of a directory to reserve TAP test  
ports at the top of the build tree. In a non-vpath build this means at  
the top of the source tree, so it needs to be added to .gitignore.  
  
As suggested by Michael Paquier  
  
Backpatch to all live branches.  

commit   : fed54fc9a5819d43ab60518306925c38f5e2bc43    
  
author   : Andrew Dunstan <[email protected]>    
date     : Fri, 25 Nov 2022 15:28:38 -0500    
  
committer: Andrew Dunstan <[email protected]>    
date     : Fri, 25 Nov 2022 15:28:38 -0500    

Strawberry uses __builtin_expect which Visual C doesn't have. For this  
case define it as a noop. Solution taken from vim sources.  
  
Backpatch to all live branches  

commit   : 04d61bfe64c9098aa737d0bea428b46a46b358bb    
  
author   : Dean Rasheed <[email protected]>    
date     : Fri, 25 Nov 2022 13:29:51 +0000    
  
committer: Dean Rasheed <[email protected]>    
date     : Fri, 25 Nov 2022 13:29:51 +0000    

Use the relation's rd_rules structure to test whether it has rules,  
rather than the relhasrules flag, which might be out of date.  
  
Reviewed by Tom Lane.  
  
Backpatch to 15, where MERGE was added.  
  
Discussion: https://postgr.es/m/CAEZATCVkBVZABfw71sYvkcPf6tarcOFST5Bc6AOi-LFT9YdccQ%40mail.gmail.com  

commit   : fc02019c09feab1f371fb5881f2f050ce6e30ea9    
  
author   : Etsuro Fujita <[email protected]>    
date     : Fri, 25 Nov 2022 17:45:01 +0900    
  
committer: Etsuro Fujita <[email protected]>    
date     : Fri, 25 Nov 2022 17:45:01 +0900    

Commit b663a4136, which allowed FDWs to INSERT rows in bulk, added to  
nodeModifyTable.c code to flush pending inserts to the foreign-table  
result relation(s) before completing processing of the ModifyTable node,  
but the code failed to take into account the case where the INSERT query  
has modifying CTEs, leading to incorrect results.  
  
Also, that commit failed to flush pending inserts before firing BEFORE  
ROW triggers so that rows are visible to such triggers.  
  
In that commit we scanned through EState's  
es_tuple_routing_result_relations or es_opened_result_relations list to  
find the foreign-table result relations to which pending inserts are  
flushed, but that would be inefficient in some cases.  So to fix, 1) add  
a List member to EState to record the insert-pending result relations,  
and 2) modify nodeModifyTable.c so that it adds the foreign-table result  
relation to the list in ExecInsert() if appropriate, and flushes pending  
inserts properly using the list where needed.  
  
While here, fix a copy-and-pasteo in a comment in ExecBatchInsert(),  
which was added by that commit.  
  
Back-patch to v14 where that commit appeared.  
  
Discussion: https://postgr.es/m/CAPmGK16qutyCmyJJzgQOhfBq%3DNoGDqTB6O0QBZTihrbqre%2BoxA%40mail.gmail.com  

commit   : 898ef41bf6f400264616444fbaea669e0685f98f    
  
author   : Amit Kapila <[email protected]>    
date     : Fri, 25 Nov 2022 09:38:03 +0530    
  
committer: Amit Kapila <[email protected]>    
date     : Fri, 25 Nov 2022 09:38:03 +0530    

In commit 272248a0c, we introduced an InitialRunningXacts array to  
remember transactions and subtransactions that were running when the  
xl_running_xacts record that we decoded was written. This array was  
allocated in the snapshot builder memory context after we restore  
serialized snapshot but we forgot to reset the array while freeing the  
builder memory context. So, the next time when we start decoding in the  
same session where we don't restore any serialized snapshot, we ended up  
using the uninitialized array and that can lead to unpredictable behavior.  
  
This problem doesn't exist in HEAD as instead of using  
InitialRunningXacts, we added the list of transaction IDs and  
sub-transaction IDs, that have modified catalogs and are running during  
snapshot serialization, to the serialized snapshot (see commit 7f13ac8123).  
  
Reported-by: Maxim Orlov  
Author: Masahiko Sawada  
Reviewed-by: Amit Kapila, Maxim Orlov  
Backpatch-through: 11  
Discussion: https://postgr.es/m/CACG=ezZoz_KG+Ryh9MrU_g5e0HiVoHocEvqFF=NRrhrwKmEQJQ@mail.gmail.com  

commit   : f63f29733e2f4fe58f52557699242b80e23e19ee    
  
author   : Alvaro Herrera <[email protected]>    
date     : Thu, 24 Nov 2022 10:45:10 +0100    
  
committer: Alvaro Herrera <[email protected]>    
date     : Thu, 24 Nov 2022 10:45:10 +0100    

There are recent reports involving a very old error message that we have  
no history of hitting -- perhaps a recently introduced bug.  Improve the  
error message in an attempt to improve our chances of investigating the  
bug.  
  
Per reports from Dimos Stamatakis and Bob Krier.  
  
Backpatch to 11.  
  
Discussion: https://postgr.es/m/CO2PR0801MB2310579F65529380A4E5EDC0E20A9@CO2PR0801MB2310.namprd08.prod.outlook.com  
Discussion: https://postgr.es/m/[email protected]  

commit   : 2c0d0ee761551582c9cd3727d444b7408aa82db7    
  
author   : Andrew Dunstan <[email protected]>    
date     : Wed, 23 Nov 2022 07:03:06 -0500    
  
committer: Andrew Dunstan <[email protected]>    
date     : Wed, 23 Nov 2022 07:03:06 -0500    

per gripe from Andres Freund and Tom Lane  
  
Backpatch to all live branches.  

commit   : 2debceed2947029b7368d091be4442eccc798e4f    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 22 Nov 2022 14:40:20 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 22 Nov 2022 14:40:20 -0500    

We've made multiple attempts at preventing get_actual_variable_range  
from taking an unreasonable amount of time (3ca930fc3, fccebe421).  
But there's still an issue for the very first planning attempt after  
deletion of a large number of extremal-valued tuples.  While that  
planning attempt will set "killed" bits on the tuples it visits and  
thereby reduce effort for next time, there's still a lot of work it  
has to do to visit the heap and then set those bits.  It's (usually?)  
not worth it to do that much work at plan time to have a slightly  
better estimate, especially in a context like this where the table  
contents are known to be mutating rapidly.  
  
Therefore, let's bound the amount of work to be done by giving up  
after we've visited 100 heap pages.  Giving up just means we'll  
fall back on the extremal value recorded in pg_statistic, so it  
shouldn't mean that planner estimates suddenly become worthless.  
  
Note that this means we'll still gradually whittle down the problem  
by setting a few more index "killed" bits in each planning attempt;  
so eventually we'll reach a good state (barring further deletions),  
even in the absence of VACUUM.  
  
Simon Riggs, per a complaint from Jakub Wartak (with cosmetic  
adjustments by me).  Back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/CAKZiRmznOwi0oaV=4PHOCM4ygcH4MgSvt8=5cu_vNCfc8FSUug@mail.gmail.com  

commit   : 153e21567750d37b031123d3bbf14f9e2434f4b2    
  
author   : Andrew Dunstan <[email protected]>    
date     : Tue, 22 Nov 2022 10:30:42 -0500    
  
committer: Andrew Dunstan <[email protected]>    
date     : Tue, 22 Nov 2022 10:30:42 -0500    

Currently there is a race condition where if concurrent TAP tests both  
test that they can open a port they will assume that it is free and use  
it, causing one of them to fail. To prevent this we record a reservation  
using an exclusive lock, and any TAP test that discovers a reservation  
checks to see if the reserving process is still alive, and looks for  
another free port if it is.  
  
Ports are reserved in a directory set by the environment setting  
PG_TEST_PORT_DIR, or if that doesn't exist a subdirectory of the top  
build directory as set by Makefile.global, or its own  
tmp_check directory.  
  
The prove_check recipe in Makefile.global.in is extended to export  
top_builddir to the TAP tests. This was already exported by the  
prove_installcheck recipes.  
  
Per complaint from Andres Freund  
  
Backpatched from 9b4eafcaf4 to all live branches  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 1118a8d2c4f5b6dccf1845c73403d036df679648    
  
author   : Alvaro Herrera <[email protected]>    
date     : Tue, 22 Nov 2022 11:26:47 +0100    
  
committer: Alvaro Herrera <[email protected]>    
date     : Tue, 22 Nov 2022 11:26:47 +0100    

This was trying to exercise an ERROR we don't actually have.  
  
Backpatch to 15.  
  
Reported by Teja Mupparti <[email protected]>  
Discussion: https://postgr.es/m/SN6PR2101MB1040BDAF740EA4389484E92BF0079@SN6PR2101MB1040.namprd21.prod.outlook.com  

commit   : 1ad033df16df8d9f9e9f597ca31915266dfbdfb9    
  
author   : Alvaro Herrera <[email protected]>    
date     : Tue, 22 Nov 2022 10:56:07 +0100    
  
committer: Alvaro Herrera <[email protected]>    
date     : Tue, 22 Nov 2022 10:56:07 +0100    

Once a logical slot has acquired a catalog_xmin, it doesn't let go of  
it, even when invalidated by exceeding the max_slot_wal_keep_size, which  
means that dead catalog tuples are not removed by vacuum anymore since  
the point is invalidated, until the slot is dropped.  This could be  
catastrophic if catalog churn is high.  
  
Change the computation of Xmin to ignore invalidated slots,  
to prevent dead rows from accumulating.  
  
Backpatch to 13, where slot invalidation appeared.  
  
Author: Sirisha Chamarthi <[email protected]>  
Reviewed-by: Ashutosh Bapat <[email protected]>  
Discussion: https://postgr.es/m/CAKrAKeUEDeqquN9vwzNeG-CN8wuVsfRYbeOUV9qKO_RHok=j+g@mail.gmail.com  

commit   : 4f997ad06255a2e2cb23c9ba1c30bf42ceb8fbb5    
  
author   : Daniel Gustafsson <[email protected]>    
date     : Mon, 21 Nov 2022 23:25:48 +0100    
  
committer: Daniel Gustafsson <[email protected]>    
date     : Mon, 21 Nov 2022 23:25:48 +0100    

The Hunspell project moved from Sourceforge to Github sometime  
in 2016, so update our links to match the new URL.  Backpatch  
the doc changes to all supported versions.  
  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: v11  

commit   : 0353db996e37c6b923863ee648f4d2f153bf619d    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 21 Nov 2022 17:07:07 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 21 Nov 2022 17:07:07 -0500    

I just spent an annoying amount of time reverse-engineering the  
100%-undocumented API between ts_headline and the text search  
parser's prsheadline function.  Add some commentary about that  
while it's fresh in mind.  Also remove some unused macros in  
wparser_def.c.  
  
While at it, I noticed that when commit 78e73e875 added a  
CHECK_FOR_INTERRUPTS call in TS_execute_recurse, it missed  
doing so in the parallel function TS_phrase_execute, which  
surely needs one just as much.  
  
Back-patch because of the missing CHECK_FOR_INTERRUPTS.  
Might as well back-patch the rest of this too.  

commit   : b8988cf1d0a74f2e394278e0d88c2c133ee252fb    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 21 Nov 2022 15:37:10 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 21 Nov 2022 15:37:10 -0500    

These functions have been marked parallel safe, but the buildfarm's  
response to commit e2933a6e1 exposed the flaw in that thinking:  
if you try to use them on a temporary table, and they run inside  
a parallel worker, they'll fail with "cannot access temporary tables  
during a parallel operation".  
  
Fix that by marking them parallel restricted instead.  Maybe someday  
we'll have a better answer and can reverse this decision.  
  
Back-patch to v15.  To go back further, we'd have to devise variant  
versions of pre-1.10 pageinspect versions.  Given the lack of field  
complaints, it doesn't seem worth the trouble.  We'll just deem  
this case unsupported pre-v15.  (If anyone does complain, it might  
be good enough to update the markings manually in their DBs.)  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : ff9d27ee2b8bbf15ef974732671df9df662f0cf9    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 21 Nov 2022 10:50:50 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 21 Nov 2022 10:50:50 -0500    

pageinspect has occasionally failed on slow buildfarm members,  
with symptoms indicating that the expected effects of VACUUM  
FREEZE didn't happen.  This is presumably because a background  
transaction such as auto-analyze was holding back global xmin.  
  
We can work around that by using a temp table in the test.  
Since commit a7212be8b, that will use an up-to-date cutoff xmin  
regardless of other processes.  And pageinspect itself shouldn't  
really care whether the table is temp.  
  
Back-patch to v14.  There would be no point in older branches  
without back-patching a7212be8b, which seems like more trouble  
than the problem is worth.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : a0d35ebcc570265405a293e509dccbdf0fd5ee45    
  
author   : Andres Freund <[email protected]>    
date     : Wed, 16 Nov 2022 20:00:59 -0800    
  
committer: Andres Freund <[email protected]>    
date     : Wed, 16 Nov 2022 20:00:59 -0800    

ProcSleep() used a PGPROC* variable to point to PROC_QUEUE->links.next,  
because that does "the right thing" with SHMQueueInsertBefore(). While that  
largely works, it's certainly not correct and unnecessary - we can just use  
SHM_QUEUE* to point to the insertion point.  
  
Noticed when testing a 32bit of postgres with undefined behavior  
sanitizer. UBSan noticed that sometimes the supposed PGPROC wasn't  
sufficiently aligned (required since 46d6e5f5679, ensured indirectly, via  
ShmemAllocRaw() guaranteeing cacheline alignment).  
  
For now fix this by using a SHM_QUEUE* for the insertion point. Subsequently  
we should replace all the use of PROC_QUEUE and SHM_QUEUE with ilist.h, but  
that's a larger change that we don't want to backpatch.  
  
Backpatch to all supported versions - it's useful to be able to run postgres  
under UBSan.  
  
Reviewed-by: Tom Lane <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  
Backpatch: 11-  

commit   : ad0867314daa8181031071f316f4c85e87755718    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 19 Nov 2022 13:42:53 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 19 Nov 2022 13:42:53 -0500    

The test output varies when debug_discard_caches is enabled,  
because that causes extra executions of recomputeNamespacePath.  
Maybe putting a hook in that was a bad idea, but as a stopgap,  
just turn off debug_discard_caches in this test.  
  
Per buildfarm (now that we have debug_discard_caches coverage  
again).  Back-patch to v15 where this module was added.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 8e3f104440eeaa407479f0a9287acea483a5108b    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 19 Nov 2022 13:09:14 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 19 Nov 2022 13:09:14 -0500    

basics.source is supposed to be pretty closely in step with  
the examples in chapter 2 of the tutorial, but I forgot to  
update it in commit f05a5e000.  Fix that, and adjust a couple  
of other discrepancies that had crept in over time.  
  
(I notice that advanced.source is nowhere near being in sync  
with chapter 3, but I lack the ambition to do something  
about that right now.)  

commit   : df4e93bea4f9370c14f01d27e6d36cbe7afaac72    
  
author   : Andrew Dunstan <[email protected]>    
date     : Fri, 18 Nov 2022 08:38:26 -0500    
  
committer: Andrew Dunstan <[email protected]>    
date     : Fri, 18 Nov 2022 08:38:26 -0500    

Version strings with unequal numbers of parts were being compared  
incorrectly. We cure this by treating a missing part in the shorter  
version as 0.  
  
per complaint from Jehan-Guillaume de Rorthais, but the fix is mine, not  
his.  
  
Discussion: https://postgr.es/m/20220628225325.53d97b8d@karst  
  
Backpatch to release 14 where this code was introduced.  

commit   : 3d45edcef0e141f2a17a21d0411efa889f843b00    
  
author   : Alvaro Herrera <[email protected]>    
date     : Thu, 17 Nov 2022 18:56:11 +0100    
  
committer: Alvaro Herrera <[email protected]>    
date     : Thu, 17 Nov 2022 18:56:11 +0100    

Reporting tuples for which nothing is done is useless and goes against  
the documented behavior, so don't do it.  
  
Backpatch to 15.  
  
Reported by: Luca Ferrari  
Discussion: https://postgr.es/m/CAKoxK+42MmACUh6s8XzASQKizbzrtOGA6G1UjzCP75NcXHsiNw@mail.gmail.com  

commit   : 41afaa1ed4d40330a7f51f7b398064657b87831b    
  
author   : Noah Misch <[email protected]>    
date     : Thu, 17 Nov 2022 07:35:06 -0800    
  
committer: Noah Misch <[email protected]>    
date     : Thu, 17 Nov 2022 07:35:06 -0800    

This restores compatibility with the not-yet-released successor of  
version 20220807.0.  Back-patch to 9.4, which introduced this code.  
  
Reviewed by Andrew Dunstan.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : cefe182533f38406e032b573dcf506c8da2b0faf    
  
author   : Alvaro Herrera <[email protected]>    
date     : Thu, 17 Nov 2022 12:52:20 +0100    
  
committer: Alvaro Herrera <[email protected]>    
date     : Thu, 17 Nov 2022 12:52:20 +0100    

This commend references a struct that disappeared before MERGE was  
merged ... and ExecDelete is not called by the committed MERGE anyway.  
Revert to the original wording.  
  
Backpatch to 15  

commit   : 1eaa48e998e20766d70ed80cf538f3871d1c562c    
  
author   : Daniel Gustafsson <[email protected]>    
date     : Thu, 17 Nov 2022 10:07:06 +0100    
  
committer: Daniel Gustafsson <[email protected]>    
date     : Thu, 17 Nov 2022 10:07:06 +0100    

UPDATE was listed twice and DELETE was omitted, replace one UPDATE  
with DELETE instead.  
  
Backpatch through v15 where MERGE was added.  
  
Author: Myo Wai Thant <[email protected]>  
Reviewed-by: Richard Guo <[email protected]>  
Discussion: https://postgr.es/m/OSAPR01MB43247E46931E9E9CFC4AA0F29A079@OSAPR01MB4324.jpnprd01.prod.outlook.com  
Backpatch-through: 15  

commit   : e49e191815b6a7fc801e03cf798fb83d3b7f2501    
  
author   : Amit Kapila <[email protected]>    
date     : Mon, 14 Nov 2022 10:32:47 +0530    
  
committer: Amit Kapila <[email protected]>    
date     : Mon, 14 Nov 2022 10:32:47 +0530    

During XLOG_HASH_SPLIT_ALLOCATE_PAGE replay, we were checking for a  
cleanup lock on the new bucket page after acquiring an exclusive lock on  
it and raising a PANIC error on failure. However, it is quite possible  
that checkpointer can acquire the pin on the same page before acquiring a  
lock on it, and then the replay will lead to an error. So instead, directly  
acquire the cleanup lock on the new bucket page during  
XLOG_HASH_SPLIT_ALLOCATE_PAGE replay operation.  
  
Reported-by: Andres Freund  
Author: Robert Haas  
Reviewed-By: Amit Kapila, Andres Freund, Vignesh C  
Backpatch-through: 11  
Discussion: https://postgr.es/m/[email protected]  

commit   : f754e7600a9284b6de8eb78b6b64aa9b46dc80db    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 13 Nov 2022 10:42:03 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 13 Nov 2022 10:42:03 -0500    

This column is new in v16, but it was listed in the v15 docs too  
via a back-patching fumble.  
  
Per report from Peter Gigowski; diagnosis by Julien Rouhaud.  
  
Discussion: https://postgr.es/m/CAM7cJ6XY_PAmx0kGn6U307EKZ+qXDFEBH27WP87-_ygetnBuxQ@mail.gmail.com  

commit   : 0086ee356fd9fd0ced2f21e6b31031cb28b4a64a    
  
author   : Andrew Dunstan <[email protected]>    
date     : Sun, 13 Nov 2022 09:07:53 -0500    
  
committer: Andrew Dunstan <[email protected]>    
date     : Sun, 13 Nov 2022 09:07:53 -0500    

The current code looks for the sample file in the source directory, but  
it seems better to test against the installed sample file.  
  
Backpatch to release 15 where the test was introduced.  
  
Discussion: https://postgr.es/m/[email protected]  
  
Reviewed by Tom Lane, Alvaro Herrera, Michael Paquier.  

commit   : 7a387f513d6c583b1c3fe5e4e0ea2b8cb92c85da    
  
author   : Andrew Dunstan <[email protected]>    
date     : Sun, 13 Nov 2022 08:45:14 -0500    
  
committer: Andrew Dunstan <[email protected]>    
date     : Sun, 13 Nov 2022 08:45:14 -0500    

Currently this only allows for one argument, which must be present, and  
always returns a single string. With this change the following now all  
work:  
  
  $all_config = $node->config_data;  
  %config_map = ($node->config_data);  
  $incdir = $node->config_data('--include-dir');  
  ($incdir, $sharedir) = $node->config_data(  
      qw(--include-dir --share-dir));  
  
Backpatch to release 15 where this was introduced.  
  
Discussion: https://postgr.es/m/[email protected]  
  
Reviewed by Tom Lane, Alvaro Herrera, Michael Paquier.  

commit   : e5f94d42eb38f39af81f934d70c3969913f2862e    
  
author   : Noah Misch <[email protected]>    
date     : Sat, 12 Nov 2022 11:19:50 -0800    
  
committer: Noah Misch <[email protected]>    
date     : Sat, 12 Nov 2022 11:19:50 -0800    

Test files should now ignore has_wal_read_bug() so long as  
wait_for_catchup() is their only known way of reaching the bug.  That's  
at least five files today, a number expected to grow over time.  This  
commit removes skip logic from three.  By doing so, systems having the  
bug regain the ability to catch other kinds of defects via those three  
tests.  The other two, 002_databases.pl and 031_recovery_conflict.pl,  
have been unprotected.  Back-patch to v15, where done_testing() first  
became our standard.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 7bf713dd2d0739fbcd4103971ed69c17ebe677ea    
  
author   : Jeff Davis <[email protected]>    
date     : Thu, 10 Nov 2022 14:46:30 -0800    
  
committer: Jeff Davis <[email protected]>    
date     : Thu, 10 Nov 2022 14:46:30 -0800    

The original report was concerned with a possible inconsistency  
between the heap and the visibility map, which I was unable to  
confirm. The concern has been retracted.  
  
However, there did seem to be a torn page hazard when using  
checksums. By not setting the heap page LSN during redo, the  
protections of minRecoveryPoint were bypassed. Fixed, along with a  
misleading comment.  
  
It may have been impossible to hit this problem in practice, because  
it would require a page tear between the checksum and the flags, so I  
am marking this as a theoretical risk. But, as discussed, it did  
violate expectations about the page LSN, so it may have other  
consequences.  
  
Backpatch to all supported versions.  
  
Reported-by: Konstantin Knizhnik  
Reviewed-by: Konstantin Knizhnik  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 11  

commit   : 9c1a4fc891646110fe9b306fe4103f052504d6d9    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 10 Nov 2022 17:24:26 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 10 Nov 2022 17:24:26 -0500    

The stanza "SET STORAGE may need to add a TOAST table" does not  
test what it's supposed to, and hasn't done so since we added  
the ability to store constant column default values as metadata.  
We need to use a non-constant default to get the expected table  
rewrite to actually happen.  
  
Fix that, and add the missing checks that would have exposed the  
problem to begin with.  
  
Noted while reviewing a patch that made changes in this test case.  
Back-patch to v11 where the problem came in.  

commit   : 576506303c2a1b38383dc905db5f6e11b13ce872    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 10 Nov 2022 10:23:49 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 10 Nov 2022 10:23:49 -0500    

In commit 450ee7012 I supposed that all platforms we now care about have  
snprintf(), since that's required by C99.  Turns out that Microsoft did  
not get around to adding that until VS2015.  We've dropped support for  
VS2013 as of HEAD (cf 6203583b7), but not in the back branches, so add  
a hack for this in the back branches only.  
  
There's no easy shortcut to an exact emulation of standard snprintf  
in VS2013, but fortunately we don't need one: this code was just fine  
with using sprintf before 450ee7012, so we can make it do so again  
on that platform (and any others where the problem might crop up).  
  
Per bug #17681 from Daisuke Higuchi.  Back-patch to v12, like the  
previous patch.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : daadb42e92ed903642bce314e9c7a0325ee6b1b2    
  
author   : Amit Kapila <[email protected]>    
date     : Thu, 10 Nov 2022 17:08:27 +0530    
  
committer: Amit Kapila <[email protected]>    
date     : Thu, 10 Nov 2022 17:08:27 +0530    

The comments atop seem to indicate that we always accumulate invalidation  
messages in a top-level transaction which is neither required nor matches  
with the code.  
  
Author: Amit Kapila  
Reviewd by: Masahiko Sawada  
Backpatch-through: 14, where it was introduced in commit c55040ccd0  
Discussion: https://postgr.es/m/CAA4eK1LxGgnUroPz8STb6OfjVU1yaHoSA+T63URwmGCLdMJ0LA@mail.gmail.com  

commit   : 5962c8cbe5a6f02aa638279822cc59bd364e2081    
  
author   : Michael Paquier <[email protected]>    
date     : Thu, 10 Nov 2022 16:33:52 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Thu, 10 Nov 2022 16:33:52 +0900    

sync_handler was not mentioned in the comment block of the function.  
  
Oversight in dee663f.  
  
Author: Aleksander Alekseev  
Discussion: https://postgr.es/m/CAJ7c6TPUd9BwNY47TtMxaijLHSbyHNdhu=kvbGnvO_bi+oC6_Q@mail.gmail.com  
Backpatch-through: 14  

commit   : 7b6610508d68f0c6191c01e824d90051295a39fc    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 9 Nov 2022 14:15:38 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 9 Nov 2022 14:15:38 -0500    

Replace the stopgap fix I made in 0e758ae89 with a cleaner one.  
  
The real problem with 4ab5dae94 is that it contorted this function's  
logic substantially, by introducing a third code path that required  
different behavior in the function's main loop.  That seems quite  
unnecessary on closer inspection: the new IsBinaryUpgrade case can  
just share the behavior of the other immediate-unlink cases.  Hence,  
revert 4ab5dae94 and most of 0e758ae89 (keeping the latter's  
save/restore errno fix), and add IsBinaryUpgrade to the set of  
conditions tested to choose immediate unlink.  
  
Also fix some additional places with sloppy handling of errno,  
to ensure we have an invariant that we always continue processing  
after any non-ENOENT failure of do_truncate.  I doubt that that's  
fixing any bug of field importance, so I don't feel it necessary to  
back-patch; but we might as well get it right while we're here.  
  
Also improve the comments, which had drifted a bit from what the  
code actually does, and neglected to mention some important  
considerations.  
  
Back-patch to v15, not because this is fixing any bug but because  
it doesn't seem like a good idea for v15's mdunlinkfork logic to be  
significantly different from both v14 and v16.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : e70cd16f2223d76d4f00453eb2cc067d992ed4f3    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 9 Nov 2022 11:08:52 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 9 Nov 2022 11:08:52 -0500    

Add a little to the header comments for these functions to make it  
clearer what guarantees about commit behavior are provided to callers.  
(See commit f92944137 for context.)  
  
Although this is only a comment change, it's really documentation  
aimed at authors of extensions, so it seems appropriate to back-patch.  
  
Yugo Nagata and Tom Lane, per further discussion of bug #17434.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 362ba3e932c0f343a199b74f94ca7b22f4f8448d    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 8 Nov 2022 18:25:03 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 8 Nov 2022 18:25:03 -0500    

Commit fede15417 introduced FILTER by jamming it into the existing  
example introducing HAVING, which seems pedagogically poor to me;  
and it added no information about what the keyword actually does.  
Not to mention that the claimed output didn't match the sample  
data being used in this running example.  
  
Revert that and instead make an independent example using FILTER.  
To help drive home the point that it's a per-aggregate filter,  
we need to use two aggregates not just one; for consistency  
expand all the examples in this segment to do that.  
  
Also adjust the example using WHERE ... LIKE so that it'd produce  
nonempty output with this sample data, and show that output.  
  
Back-patch, as the previous patch was.  (Sadly, v10 is now out  
of scope.)  
  
Discussion: https://postgr.es/m/[email protected]