PostgreSQL 14.0 (upcoming) commit log

commit   : 65ead76961a4be9a10d1c7dbfdcb10765aad8af9    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Tue, 21 Mar 2023 09:18:51 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Tue, 21 Mar 2023 09:18:51 +0530    

We fail to apply updates and deletes when the REPLICA IDENTITY FULL is  
used for the table having dropped columns. We didn't use to ignore dropped  
columns while doing tuple comparison among the tuples from the publisher  
and subscriber during apply of updates and deletes.  
  
Author: Onder Kalaci, Shi yu  
Reviewed-by: Amit Kapila  
Discussion: https://postgr.es/m/CACawEhVQC9WoofunvXg12aXtbqKnEgWxoRx3+v8q32AWYsdpGg@mail.gmail.com  

commit   : 1b9e42e82ae62f2a53e4a3da19b5fff994af5d72    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Tue, 21 Mar 2023 14:29:34 +1300    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Tue, 21 Mar 2023 14:29:34 +1300    

With unlucky timing and parallel_leader_participation=off (not the  
default), PHJ could attempt to access per-batch shared state just as it  
was being freed.  There was code intended to prevent that by checking  
for a cleared pointer, but it was racy.  Fix, by introducing an extra  
barrier phase.  The new phase PHJ_BUILD_RUNNING means that it's safe to  
access the per-batch state to find a batch to help with, and  
PHJ_BUILD_DONE means that it is too late.  The last to detach will free  
the array of per-batch state as before, but now it will also atomically  
advance the phase, so that late attachers can avoid the hazard.  This  
mirrors the way per-batch hash tables are freed (see phases  
PHJ_BATCH_PROBING and PHJ_BATCH_DONE).  
  
An earlier attempt to fix this (commit 3b8981b6, later reverted) missed  
one special case.  When the inner side is empty (the "empty inner  
optimization), the build barrier would only make it to  
PHJ_BUILD_HASHING_INNER phase before workers attempted to detach from  
the hashtable.  In that case, fast-forward the build barrier to  
PHJ_BUILD_RUNNING before proceeding, so that our later assertions hold  
and we can still negotiate who is cleaning up.  
  
Revealed by build farm failures, where BarrierAttach() failed a sanity  
check assertion, because the memory had been clobbered by dsa_free().  
In non-assert builds, the result could be a segmentation fault.  
  
Back-patch to all supported releases.  
  
Author: Thomas Munro <thomas.munro@gmail.com>  
Author: Melanie Plageman <melanieplageman@gmail.com>  
Reported-by: Michael Paquier <michael@paquier.xyz>  
Reported-by: David Geier <geidav.pg@gmail.com>  
Tested-by: David Geier <geidav.pg@gmail.com>  
Discussion: https://postgr.es/m/20200929061142.GA29096%40paquier.xyz  

commit   : 6a78a42fea0c457dfee2a5ac5431df02342eafd2    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Mon, 20 Mar 2023 09:51:50 +0100    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Mon, 20 Mar 2023 09:51:50 +0100    

When calculating distance in brin_minmax_multi_distance_inet(), the  
netmask was applied incorrectly. This results in (seemingly) incorrect  
ordering of values, triggering an assert.  
  
For builds without asserts this is mostly harmless - we may merge other  
ranges, possibly resulting in slightly less efficient index. But it's  
still correct and the greedy algorithm doesn't guarantee optimality  
anyway.  
  
Backpatch to 14, where minmax-multi indexes were introduced.  
  
Reported by Dmitry Dolgov, investigation and fix by me.  
  
Reported-by: Dmitry Dolgov  
Backpatch-through: 14  
Discussion: https://postgr.es/m/17774-c6f3e36dd4471e67@postgresql.org  

commit   : f654f343c6a89f76aa0385bb92a1c6802126974c    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Mon, 20 Mar 2023 13:30:55 +1300    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Mon, 20 Mar 2023 13:30:55 +1300    

When probing the Memoize cache to check if the current cache key values  
exist in the cache, we perform an evaluation of the expressions making up  
the cache key before probing the hash table for those values.  This  
operation could leak memory as it is possible that the cache key is an  
expression which requires allocation of memory, as was the case in bug  
17844.  
  
Here we fix this by correctly switching to the per tuple context before  
evaluating the cache expressions so that the memory is freed next time the  
per tuple context is reset.  
  
Bug: 17844  
Reported-by: Alexey Ermakov  
Discussion: https://postgr.es/m/17844-d2f6f9e75a622bed@postgresql.org  
Backpatch-through: 14, where Memoize was introduced  

commit   : 6fe609496beadfe85124290f220a25075d7f2c04    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 18 Mar 2023 16:11:22 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 18 Mar 2023 16:11:22 -0400    

Per report from rsindlin  
  
Discussion: https://postgr.es/m/167907221210.1803488.5939223864945604536@wrigleys.postgresql.org  

commit   : 5fc1ac151d85a4da8724e1d886fbb6fe3ff519c0    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 17 Mar 2023 13:31:40 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 17 Mar 2023 13:31:40 -0400    

Hash partitioning on an enum is problematic because the hash codes are  
derived from the OIDs assigned to the enum values, which will almost  
certainly be different after a dump-and-reload than they were before.  
This means that some rows probably end up in different partitions than  
before, causing restore to fail because of partition constraint  
violations.  (pg_upgrade dodges this problem by using hacks to force  
the enum values to keep the same OIDs, but that's not possible nor  
desirable for pg_dump.)  
  
Users can work around that by specifying --load-via-partition-root,  
but since that's a dump-time not restore-time decision, one might  
find out the need for it far too late.  Instead, teach pg_dump to  
apply that option automatically when dealing with a partitioned  
table that has hash-on-enum partitioning.  
  
Also deal with a pre-existing issue for --load-via-partition-root  
mode: in a parallel restore, we try to TRUNCATE target tables just  
before loading them, in order to enable some backend optimizations.  
This is bad when using --load-via-partition-root because (a) we're  
likely to suffer deadlocks from restore jobs trying to restore rows  
into other partitions than they came from, and (b) if we miss getting  
a deadlock we might still lose data due to a TRUNCATE removing rows  
from some already-completed restore job.  
  
The fix for this is conceptually simple: just don't TRUNCATE if we're  
dealing with a --load-via-partition-root case.  The tricky bit is for  
pg_restore to identify those cases.  In dumps using COPY commands we  
can inspect each COPY command to see if it targets the nominal target  
table or some ancestor.  However, in dumps using INSERT commands it's  
pretty impractical to examine the INSERTs in advance.  To provide a  
solution for that going forward, modify pg_dump to mark TABLE DATA  
items that are using --load-via-partition-root with a comment.  
(This change also responds to a complaint from Robert Haas that  
the dump output for --load-via-partition-root is pretty confusing.)  
pg_restore checks for the special comment as well as checking the  
COPY command if present.  This will fail to identify the combination  
of --load-via-partition-root and --inserts in pre-existing dump files,  
but that should be a pretty rare case in the field.  If it does  
happen you will probably get a deadlock failure that you can work  
around by not using parallel restore, which is the same as before  
this bug fix.  
  
Having done this, there seems no remaining reason for the alarmism  
in the pg_dump man page about combining --load-via-partition-root  
with parallel restore, so remove that warning.  
  
Patch by me; thanks to Julien Rouhaud for review.  Back-patch to  
v11 where hash partitioning was introduced.  
  
Discussion: https://postgr.es/m/1376149.1675268279@sss.pgh.pa.us  

commit   : a9b716c33d6d1bb02cd604517326dc1938f9abea    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Thu, 16 Mar 2023 23:03:31 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Thu, 16 Mar 2023 23:03:31 -0700    

Unfortunately it turns out that the logfile-only option added in b9f8d1cbad7  
is only available in openldap starting in 2.6.  
  
Luckily the option to control the log level (loglevel/-s) have been around for  
much longer. As it turns out loglevel/-s only control what goes into syslog,  
not what ends up in the file specified with 'logfile' and stderr.  
  
While we currently are specifying 'logfile', nothing ends up in it, as the  
option only controls debug messages, and we didn't set a debug level. The  
debug level can only be configured on the commandline and also prevents  
forking. That'd require larger changes, so this commit doesn't tackle that  
issue.  
  
Specify the syslog level when starting slapd using -s, as that allows to  
prevent all syslog messages if one uses '0' instead of 'none', while loglevel  
doesn't prevent the first message.  
  
Discussion: https://postgr.es/m/20230311233708.3yjdbjkly2q4gq2j@awork3.anarazel.de  
Backpatch: 11-  

commit   : e304e5099258f92a8f7be801ef72c920b299d1d7    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Thu, 16 Mar 2023 17:48:47 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Thu, 16 Mar 2023 17:48:47 -0700    

Until now the tests using slapd spammed syslog for every connection /  
query. Use logfile-only to prevent syslog activity. Unfortunately that only  
takes effect after logging the first message, but that's still much better  
than the prior situation.  
  
Discussion: https://postgr.es/m/20230311233708.3yjdbjkly2q4gq2j@awork3.anarazel.de  
Backpatch: 11-  

commit   : 1c0d4affa22a177b0ac6f08f801ccaacf2217c43    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Fri, 17 Mar 2023 14:44:12 +1300    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Fri, 17 Mar 2023 14:44:12 +1300    

Further to commit 6a9229da, checking for NULL is now redundant.  An "out  
of memory" error would have been thrown already by palloc() and treated  
as FATAL, so we can delete a few more lines.  
  
Back-patch to all releases, like those other commits.  
  
Reported-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/4040668.1679013388%40sss.pgh.pa.us  

commit   : a7a92738ffce35b480d20965ad95317729ae96a2    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Thu, 16 Mar 2023 14:08:44 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Thu, 16 Mar 2023 14:08:44 -0700    

gcc 12+ has complaints like the following:  
  
../../../../../pgsql/src/backend/utils/adt/network.c: In function 'inetnot':  
../../../../../pgsql/src/backend/utils/adt/network.c:1893:34: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=]  
 1893 |                         pdst[nb] = ~pip[nb];  
      |                         ~~~~~~~~~^~~~~~~~~~  
../../../../../pgsql/src/include/utils/inet.h:27:23: note: at offset -1 into destination object 'ipaddr' of size 16  
   27 |         unsigned char ipaddr[16];       /* up to 128 bits of address */  
      |                       ^~~~~~  
../../../../../pgsql/src/include/utils/inet.h:27:23: note: at offset -1 into destination object 'ipaddr' of size 16  
  
This is due to a compiler bug:  
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104986  
  
It has been a year since the bug has been reported without getting fixed. As  
the warnings are verbose and use of gcc 12 is becoming more common, it seems  
worth working around the bug. Particularly because a simple reformulation of  
the loop condition fixes the issue and isn't any less readable.  
  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Author: Andres Freund <andres@anarazel.de>  
Discussion: https://postgr.es/m/144536.1648326206@sss.pgh.pa.us  
Backpatch: 11-  

commit   : 00fc4b3a31010033e8b1a964c90a7a30b8d6a7d7    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Fri, 17 Mar 2023 09:44:42 +1300    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Fri, 17 Mar 2023 09:44:42 +1300    

A comment was left behind claiming that we needed to use malloc() rather  
than palloc() because the corresponding free would run in another  
thread, but that's not true anymore.  Remove that comment.  And, with  
the reason being gone, we might as well actually use palloc().  
  
Back-patch to supported releases, like d41a178b.  
  
Discussion: https://postgr.es/m/CA%2BhUKG%2BpdM9v3Jv4tc2BFx2jh_daY3uzUyAGBhtDkotEQDNPYw%40mail.gmail.com  

commit   : 8f90381a20b259decfbb7174034ca7c457a041d0    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 16 Mar 2023 16:50:56 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 16 Mar 2023 16:50:56 -0400    

Clarify that ATTACH/DETACH PARTITION can be used to perform partition  
maintenance with less locking than straight CREATE TABLE/DROP TABLE.  
This was already stated in some places, but not emphasized.  
  
Back-patch to v14 where DETACH PARTITION CONCURRENTLY was added.  
(We had lower lock levels for ATTACH PARTITION before that, but  
this wording wouldn't apply.)  
  
Justin Pryzby, reviewed by Robert Treat and Jakub Wartak;  
a little further wordsmithing by me  
  
Discussion: https://postgr.es/m/20220718143304.GC18011@telsasoft.com  

commit   : bbf18fe199c5844a39c8cb1aa60e5a13da8103c8    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 15 Mar 2023 12:56:10 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 15 Mar 2023 12:56:10 +0900    

The current implementation of _pgfstat64() is ineffective in detecting a  
terminal handle or an anonymous named pipe.  This commit improves our  
port of fstat() to detect more efficiently such cases by relying on  
GetFileType(), and returning more correct data when the type found is  
either a FILE_TYPE_PIPE (_S_IFIFO) or a FILE_TYPE_CHAR (_S_IFCHR).  
  
This is part of a more global fix to address failures when feeding the  
output generated by pg_dump to pg_restore through a pipe, for example,  
but not all of it.   We are also going to need to do something about  
fseek() and ftello() which are not reliable on WIN32 for the same cases  
where fstat() was incorrect.  Fixing fstat() is independent of the rest,  
though, which is why both fixes are handled separately, and this is the  
first part of it.  
  
Reported-by: Daniel Watzinger  
Author: Daniel Watzinger, Juan José Santamaría Flecha  
Discussion: https://postgr.es/m/b1448cd7-871e-20e3-8398-895e2d1d3bf9@gmail.com  
Backpatch-through: 14  

commit   : 2bef57ee8b38ee7fdbad3fb38b1f8ed31adb381b    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Wed, 15 Mar 2023 13:57:00 +1300    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Wed, 15 Mar 2023 13:57:00 +1300    

Commit 4753ef37 changed vacuum_delay_point() to use the WaitLatch() API,  
to fix the problem that vacuum could keep running for a very long time  
after the postmaster died.  
  
Unfortunately, that broke commit caf626b2's support for fractional  
vacuum_cost_delay, which shipped in PostgreSQL 12.  WaitLatch() works in  
whole milliseconds.  
  
For now, revert the change from commit 4753ef37, but add an explicit  
check for postmaster death.  That's an extra system call on systems  
other than Linux and FreeBSD, but that overhead doesn't matter much  
considering that we willingly went to sleep and woke up again.  (In  
later work, we might add higher resolution timeouts to the latch API so  
that we could do this with our standard programming pattern, but that  
wouldn't be back-patched.)  
  
Back-patch to 14, where commit 4753ef37 arrived.  
  
Reported-by: Melanie Plageman <melanieplageman@gmail.com>  
Discussion: https://postgr.es/m/CAAKRu_b-q0hXCBUCAATh0Z4Zi6UkiC0k2DFgoD3nC-r3SkR3tg%40mail.gmail.com  

commit   : 9b6e0b9c37d644bc99f7c79e01b388f6a3648387    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Wed, 15 Mar 2023 13:17:18 +1300    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Wed, 15 Mar 2023 13:17:18 +1300    

Our waitpid() emulation didn't prevent a PID from being recycled by the  
OS before the call to waitpid().  The postmaster could finish up  
tracking more than one child process with the same PID, and confuse  
them.  
  
Fix, by moving the guts of pgwin32_deadchild_callback() into waitpid(),  
so that resources are released synchronously.  The process and PID  
continue to exist until we close the process handle, which only happens  
once we're ready to adjust our book-keeping of running children.  
  
This seems to explain a couple of failures on CI.  It had never been  
reported before, despite the code being as old as the Windows port.  
Perhaps Windows started recycling PIDs more rapidly, or perhaps timing  
changes due to commit 7389aad6 made it more likely to break.  
  
Thanks to Alexander Lakhin for analysis and Andres Freund for tracking  
down the root cause.  
  
Back-patch to all supported branches.  
  
Reported-by: Andres Freund <andres@anarazel.de>  
Discussion: https://postgr.es/m/20230208012852.bvkn2am4h4iqjogq%40awork3.anarazel.de  

commit   : 7cac191057ea8d6f2358f0504039d29e6c5e2141    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 14 Mar 2023 19:17:31 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 14 Mar 2023 19:17:31 -0400    

The band-aid applied in commit f0bedf3e4 turns out to still need  
some work: it made sure we didn't set Np->last_relevant too small  
(to the left of the decimal point), but it didn't prevent setting  
it too large (off the end of the partially-converted string).  
This could result in fetching data beyond the end of the allocated  
space, which with very bad luck could cause a SIGSEGV, though  
I don't see any hazard of interesting memory disclosure.  
  
Per bug #17839 from Thiago Nunes.  The bug's pretty ancient,  
so back-patch to all supported versions.  
  
Discussion: https://postgr.es/m/17839-aada50db24d7b0da@postgresql.org  

commit   : 7c509f7e5a817ea676479d33bb975d72785ff106    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 14 Mar 2023 11:10:45 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 14 Mar 2023 11:10:45 -0400    

Scanning the expression for compatible Vars isn't really necessary,  
because the subsequent match against StatisticExtInfo entries will  
eliminate expressions containing other Vars just fine.  Moreover,  
this code hadn't stopped to think about what to do with  
PlaceHolderVars or Aggrefs in the clause; and at least for the PHV  
case, that demonstrably leads to failures.  Rather than work out  
whether it's reasonable to ignore those, let's just remove the  
whole stanza.  
  
Per report from Richard Guo.  Back-patch to v14 where this code  
was added.  
  
Discussion: https://postgr.es/m/CAMbWs48Mmvm-acGevXuwpB=g5JMqVSL6i9z5UaJyLGJqa-XPAA@mail.gmail.com  

commit   : 0ee9d685dd80910a269eb44036dc59df511c6d88    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 13 Mar 2023 15:19:00 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 13 Mar 2023 15:19:00 -0400    

The majority of error exit cases in json_lex_string() failed to  
set lex->token_terminator, causing problems for the error context  
reporting code: it would see token_terminator less than token_start  
and do something more or less nuts.  In v14 and up the end result  
could be as bad as a crash in report_json_context().  Older  
versions accidentally avoided that fate; but all versions produce  
error context lines that are far less useful than intended,  
because they'd stop at the end of the prior token instead of  
continuing to where the actually-bad input is.  
  
To fix, invent some macros that make it less notationally painful  
to do the right thing.  Also add documentation about what the  
function is actually required to do; and in >= v14, add an assertion  
in report_json_context about token_terminator being sufficiently  
far advanced.  
  
Per report from Nikolay Shaplov.  Back-patch to all supported  
versions.  
  
Discussion: https://postgr.es/m/7332649.x5DLKWyVIX@thinkpad-pgpro  

commit   : 096e708056ead615f82a851d0825d9d6b40f7c96    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 13 Mar 2023 12:40:28 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 13 Mar 2023 12:40:28 -0400    

check_agg_arguments_walker() supposed that it needn't descend into  
the arguments of a lower-level aggregate function, but this is  
just wrong in the presence of multiple levels of sub-select.  The  
oversight would lead to executor failures on queries that should  
be rejected.  (Prior to v11, they actually were rejected, thanks  
to a "redundant" execution-time check.)  
  
Per bug #17835 from Anban Company.  Back-patch to all supported  
branches.  
  
Discussion: https://postgr.es/m/17835-4f29f3098b2d0ba4@postgresql.org  

commit   : 7e319231c6bba7bad4a71a47ed0aefadf71e1103    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 13 Mar 2023 16:36:31 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 13 Mar 2023 16:36:31 +0900    

The error cases for TLS and GSS encryption were inconsistent.  After TLS  
fails, the connection is marked as dead and follow-up calls of  
PQconnectPoll() would return immediately, but GSS encryption was not  
doing that, so the connection would still have been allowed to enter the  
GSS handling code.  This was handled incorrectly when gssencmode was set  
to "require".  "prefer" was working correctly, and this could not happen  
under "disable" as GSS encryption would not be attempted.  
  
This commit makes the error handling of GSS encryption on par with TLS  
portion, fixing the case of gssencmode=require.  
  
Reported-by: Jacob Champion  
Author: Michael Paquier  
Reviewed-by: Jacob Champion, Stephen Frost  
Discussion: https://postgr.es/m/23787477-5fe1-a161-6d2a-e459f74c4713@timescale.com  
Backpatch-through: 12  

commit   : 4642c2b56a99a2bd86111f8c46f377e2fc362463    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Sun, 12 Mar 2023 09:00:32 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Sun, 12 Mar 2023 09:00:32 -0400    

This was an omission in the original creation of the module.  
  
Also slightly adjust some wording to avoid a double "is".  
  
Backpatch the non-meson piece of this to release 12, where the module  
was introduced.  
  
Discussion: https://postgr.es/m/be869e1c-8e3f-4cde-8609-212c899cccf9@dunslane.net  

commit   : b3a83055c23526787701cd93e76a6df4f5a85920    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Sat, 11 Mar 2023 14:12:51 -0800    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Sat, 11 Mar 2023 14:12:51 -0800    

64bit xids can't represent xids before epoch 0 (see also be504a3e974). When  
FullTransactionIdFromXidAndCtx() was passed such an xid, it'd create a 64bit  
xid far into the future. Noticed while adding assertions in the course of  
investigating be504a3e974, as amcheck's test create such xids.  
  
To fix the issue, just return FirstNormalFullTransactionId in this case. A  
freshly initdb'd cluster already has a newer horizon. The most minimal version  
of this would make the messages for some detected corruptions differently  
inaccurate. To make those cases accurate, switch  
FullTransactionIdFromXidAndCtx() to use the 32bit modulo difference between  
xid and nextxid to compute the 64bit xid, yielding sensible "in the future" /  
"in the past" answers.  
  
Reviewed-by: Mark Dilger <mark.dilger@enterprisedb.com>  
Discussion: https://postgr.es/m/20230108002923.cyoser3ttmt63bfn@awork3.anarazel.de  
Backpatch: 14-, where heapam verification was introduced  

commit   : a42f515d6b45ea19b96fb2868d8acb77251d911d    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Sat, 11 Mar 2023 14:12:51 -0800    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Sat, 11 Mar 2023 14:12:51 -0800    

The initialization order in update_cached_xid_range() was wrong, calling  
FullTransactionIdFromXidAndCtx() before setting  
->next_xid. FullTransactionIdFromXidAndCtx() uses ->next_xid.  
  
In most situations this will not cause visible issues, because the next call  
to update_cached_xid_range() will use a less wrong ->next_xid. It's rare that  
xids advance fast enough for this to be a problem.  
  
Found while adding more asserts to the 64bit xid infrastructure.  
  
Reviewed-by: Mark Dilger <mark.dilger@enterprisedb.com>  
Discussion: https://postgr.es/m/20230108002923.cyoser3ttmt63bfn@awork3.anarazel.de  
Backpatch: 14-, where heapam verification was introduced  

commit   : 786528039911c2270589bb690afab20116ee88f3    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 11 Mar 2023 12:15:41 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 11 Mar 2023 12:15:41 -0500    

If the regex compiler can see that a regex is unsatisfiable  
(for example, '$foo') then it may emit an NFA having no arcs.  
pg_trgm's packGraph function did the wrong thing in this case;  
it would access off the end of a work array, and with bad luck  
could produce a corrupted output data structure causing more  
problems later.  This could end with wrong answers or crashes  
in queries using a pg_trgm GIN or GiST index with such a regex.  
  
Fix by not trying to de-duplicate if there aren't at least 2 arcs.  
  
Per bug #17830 from Alexander Lakhin.  Back-patch to all supported  
branches.  
  
Discussion: https://postgr.es/m/17830-57ff5f89bdb02b09@postgresql.org  

commit   : 53a53ea332131b3d29d8d69e1dc2823f4d6ff21a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 10 Mar 2023 13:52:28 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 10 Mar 2023 13:52:28 -0500    

The COPY documentation is quite clear that "COPY relation TO" copies  
rows from only the named table, not any inheritance children it may  
have.  However, if you enabled row-level security on the table then  
this stopped being true, because the code forgot to apply the ONLY  
modifier in the "SELECT ... FROM relation" query that it constructs  
in order to allow RLS predicates to be attached.  Fix that.  
  
Report and patch by Antonin Houska (comment adjustments and test case  
by me).  Back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/3472.1675251957@antos  

commit   : d811d74be353283a3c8282b46a0a6e75e89de5f9    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Thu, 9 Mar 2023 16:33:24 +1300    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Thu, 9 Mar 2023 16:33:24 +1300    

Commit bdaabb9b started skipping doomed transactions when building the  
list of possible conflicts for SERIALIZABLE READ ONLY.  That makes  
sense, because doomed transactions won't commit, but a couple of subtle  
things broke:  
  
1.  If all uncommitted r/w transactions are doomed, a READ ONLY  
transaction would arbitrarily not benefit from the safe snapshot  
optimization.  It would not be taken immediately, and yet no other  
transaction would set SXACT_FLAG_RO_SAFE later.  
  
2.  In the same circumstances but with DEFERRABLE, GetSafeSnapshot()  
would correctly exit its wait loop without sleeping and then take the  
optimization in non-assert builds, but assert builds would fail a sanity  
check that SXACT_FLAG_RO_SAFE had been set by another transaction.  
  
This is similar to the case for PredXact->WritableSxactCount == 0.  We  
should opt out immediately if our possibleUnsafeConflicts list is empty  
after filtering.  
  
The code to maintain the serializable global xmin is moved down below  
the new opt out site, because otherwise we'd have to reverse its effects  
before returning.  
  
Back-patch to all supported releases.  Bug #17368.  
  
Reported-by: Alexander Lakhin <exclusion@gmail.com>  
Discussion: https://postgr.es/m/17116-d6ca217acc180e30%40postgresql.org  
Discussion: https://postgr.es/m/20110707212159.GF76634%40csail.mit.edu  

commit   : 324281fd5b1b413b70910b8c59d00900efedd256    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Tue, 7 Mar 2023 21:36:49 -0800    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Tue, 7 Mar 2023 21:36:49 -0800    

When vacuum_defer_cleanup_age is bigger than the current xid, including the  
epoch, the subtraction of vacuum_defer_cleanup_age would lead to a wrapped  
around xid. While that normally is not a problem, the subsequent conversion to  
a 64bit xid results in a 64bit-xid very far into the future. As that xid is  
used as a horizon to detect whether rows versions are old enough to be  
removed, that allows removal of rows that are still visible (i.e. corruption).  
  
If vacuum_defer_cleanup_age was never changed from the default, there is no  
chance of this bug occurring.  
  
This bug was introduced in dc7420c2c92.  A lesser version of it exists in  
12-13, introduced by fb5344c969a, affecting only GiST.  
  
The 12-13 version of the issue can, in rare cases, lead to pages in a gist  
index getting recycled too early, potentially causing index entries to be  
found multiple times.  
  
The fix is fairly simple - don't allow vacuum_defer_cleanup_age to retreat  
further than FirstNormalTransactionId.  
  
Patches to make similar bugs easier to find, by adding asserts to the 64bit  
xid infrastructure, have been proposed, but are not suitable for backpatching.  
  
Currently there are no tests for vacuum_defer_cleanup_age. A patch introducing  
infrastructure to make writing a test easier has been posted to the list.  
  
Reported-by: Michail Nikolaev <michail.nikolaev@gmail.com>  
Reviewed-by: Matthias van de Meent <boekewurm+postgres@gmail.com>  
Author: Andres Freund <andres@anarazel.de>  
Discussion: https://postgr.es/m/20230108002923.cyoser3ttmt63bfn@awork3.anarazel.de  
Backpatch: 12-, but impact/fix is smaller for 12-13  

commit   : 9f1e51b5967345afc42efb6c146043b5bcd91679    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 7 Mar 2023 18:21:37 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 7 Mar 2023 18:21:37 -0500    

If a view is defined atop another view, and then CREATE OR REPLACE  
VIEW is used to add columns to the lower view, then when the upper  
view's referencing RTE is expanded by ApplyRetrieveRule we will have  
a subquery RTE with fewer eref->colnames than output columns.  This  
confuses various code that assumes those lists are always in sync,  
as they are in plain parser output.  
  
We have seen such problems before (cf commit d5b760ecb), and now  
I think the time has come to do what was speculated about in that  
commit: let's make ApplyRetrieveRule synthesize some column names to  
preserve the invariant that holds in parser output.  Otherwise we'll  
be chasing this class of bugs indefinitely.  Moreover, it appears from  
testing that this actually gives us better results in the test case  
d5b760ecb added, and likely in other corner cases that we lack  
coverage for.  
  
In HEAD, I replaced d5b760ecb's hack to make expandRTE exit early with  
an elog(ERROR) call, since the case is now presumably unreachable.  
But it seems like changing that in back branches would bring more risk  
than benefit, so there I just updated the comment.  
  
Per bug #17811 from Alexander Lakhin.  Back-patch to all supported  
branches.  
  
Discussion: https://postgr.es/m/17811-d31686b78f0dffc9@postgresql.org  

commit   : 1e05ea51d327635ce56caab56cc47e70716e081f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 6 Mar 2023 18:31:16 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 6 Mar 2023 18:31:16 -0500    

If UPDATE is forced to retry after an EvalPlanQual check, it neglected  
to repeat GENERATED-column computations, even though those might well  
have changed since we're dealing with a different tuple than before.  
Fixing this is mostly a matter of looping back a bit further when  
we retry.  In v15 and HEAD that's most easily done by altering the API  
of ExecUpdateAct so that it includes computing GENERATED expressions.  
  
Also, if an UPDATE in a partitioned table turns into a cross-partition  
INSERT operation, we failed to recompute GENERATED columns.  That's a  
bug since 8bf6ec3ba allowed partitions to have different generation  
expressions; although it seems to have no ill effects before that.  
Fixing this is messier because we can now have situations where the same  
query needs both the UPDATE-aligned set of GENERATED columns and the  
INSERT-aligned set, and it's unclear which set will be generated first  
(else we could hack things by forcing the INSERT-aligned set to be  
generated, which is indeed how fe9e658f4 made it work for MERGE).  
The best fix seems to be to build and store separate sets of expressions  
for the INSERT and UPDATE cases.  That would create ABI issues in the  
back branches, but so far it seems we can leave this alone in the back  
branches.  
  
Per bug #17823 from Hisahiro Kauchi.  The first part of this affects all  
branches back to v12 where GENERATED columns were added.  
  
Discussion: https://postgr.es/m/17823-b64909cf7d63de84@postgresql.org  

commit   : e9051ecd58e9f171c5c92f28c1bbd8f42fa243c1    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Mon, 6 Mar 2023 15:07:15 +1300    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Mon, 6 Mar 2023 15:07:15 +1300    

1.  Make sure that we don't decrement SxactGlobalXminCount twice when  
the SXACT_FLAG_RO_SAFE optimization is reached in a parallel query.  
This could trigger a sanity check failure in assert builds.  Non-assert  
builds recompute the count in SetNewSxactGlobalXmin(), so the problem  
was hidden, explaining the lack of field reports.  Add a new isolation  
test to exercise that case.  
  
2.  Remove an assertion that the DOOMED flag can't be set on a partially  
released SERIALIZABLEXACT.  Instead, ignore the flag (our transaction  
was already determined to be read-only safe, and DOOMED is in fact set  
during partial release, and there was already an assertion that it  
wasn't set sooner).  Improve an existing isolation test so that it  
reaches that case (previously it wasn't quite testing what it was  
supposed to be testing; see discussion).  
  
Back-patch to 12.  Bug #17116.  Defects in commit 47a338cf.  
  
Reported-by: Alexander Lakhin <exclusion@gmail.com>  
Discussion: https://postgr.es/m/17116-d6ca217acc180e30%40postgresql.org  

commit   : 5ad63eee13e70eeff9659bcee024e8249b6bf68c    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 2 Mar 2023 14:03:21 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 2 Mar 2023 14:03:21 +0900    

Attempting to use this function with a raw page not coming from a GiST  
index would cause a crash, as it was missing the same sanity checks as  
gist_page_items_bytea().  This slightly refactors the code so as all the  
basic validation checks for GiST pages are done in a single routine,  
in the same fashion as the pageinspect functions for hash and BRIN.  
  
This fixes an issue similar to 076f4d9.  A test is added to stress for  
this case.  While on it, I have added a similar test for  
brin_page_items() with a combination make of a valid GiST index and a  
raw btree page.  This one was already protected, but it was not tested.  
  
Reported-by: Egor Chindyaskin  
Author: Dmitry Koval  
Discussion: https://postgr.es/m/17815-fc4a2d3b74705703@postgresql.org  
Backpatch-through: 14  

commit   : 1a9356f657e19ae1abeb0ffea0b7edaf69e315cb    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 1 Mar 2023 11:30:17 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 1 Mar 2023 11:30:17 -0500    

This is usually harmless, but if you were very unlucky it could  
provoke a segfault due to the "to" string being right up against  
the end of memory.  Found via valgrind testing (so we might've  
found it earlier, except that our regression tests lacked any  
exercise of translate()'s deletion feature).  
  
Fix by switching the order of the test-for-end-of-string and  
advance-pointer steps.  While here, compute "to_ptr + tolen"  
just once.  (Smarter compilers might figure that out for  
themselves, but let's just make sure.)  
  
Report and fix by Daniil Anisimov, in bug #17816.  
  
Discussion: https://postgr.es/m/17816-70f3d2764e88a108@postgresql.org  

commit   : ba019b4dacf637459148f1327f9345bff031dfe2    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 27 Feb 2023 16:29:51 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 27 Feb 2023 16:29:51 -0500    

postgres_fdw will close its remote session if an sinval cache reset  
occurs, since it's possible that that means some FDW parameters  
changed.  We had two tests that were trying to ensure that the  
session remains alive by setting debug_discard_caches = 0; but  
that's not sufficient.  Even though the tests seem stable enough  
in the buildfarm, they flap a lot under CI.  
  
In the first test, which is checking the ability to recover from  
a lost connection, we can stabilize the results by just not  
caring whether pg_terminate_backend() finds a victim backend.  
If a reset did happen, there won't be a session to terminate  
anymore, but the test can proceed anyway.  (Arguably, we are  
then not testing the unintentional-disconnect case, but as long  
as that scenario is exercised in most runs I think it's fine;  
testing the reset-driven case is of value too.)  
  
In the second test, which is trying to verify the application_name  
displayed in pg_stat_activity by a remote session, we had a race  
condition in that the remote session might go away before we can  
fetch its pg_stat_activity entry.  We can close that race and make  
the test more certainly test what it intends to by arranging things  
so that the remote session itself fetches its pg_stat_activity entry  
(based on PID rather than a somewhat-circular assumption about the  
application name).  
  
Both tests now demonstrably pass under debug_discard_caches = 1,  
so we can remove that hack.  
  
Back-patch into relevant back branches.  
  
Discussion: https://postgr.es/m/20230226194340.u44bkfgyz64c67i6@awork3.anarazel.de  

commit   : 4d68338b26a93f79ad818a462fa96d84ffa2ac51    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Sun, 26 Feb 2023 06:48:41 -0500    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Sun, 26 Feb 2023 06:48:41 -0500    

It's been this way for a very long time, but it appears to have been  
masking an issue that only manifests with different settings. Therefore,  
run the tests in the installation's default encoding/locale.  
  
Backpatch to all live branches.  

commit   : 9eaba06027ae01476a20725e54261e4f64ea023b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 25 Feb 2023 14:44:14 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 25 Feb 2023 14:44:14 -0500    

We already tried to fix this in commits 3f7323cbb et al (and follow-on  
fixes), but now it emerges that there are still unfixed cases;  
moreover, these cases affect all branches not only pre-v14.  I thought  
we had eliminated all cases of making multiple clones of an UPDATE's  
target list when we nuked inheritance_planner.  But it turns out we  
still do that in some partitioned-UPDATE cases, notably including  
INSERT ... ON CONFLICT UPDATE, because ExecInitPartitionInfo thinks  
it's okay to clone and modify the parent's targetlist.  
  
This fix is based on a suggestion from Andres Freund: let's stop  
abusing the ParamExecData.execPlan mechanism, which was only ever  
meant to handle initplans, and instead solve the execution timing  
problem by having the expression compiler move MULTIEXPR_SUBLINK steps  
to the front of their expression step lists.  This is feasible because  
(a) all branches still in support compile the entire targetlist of  
an UPDATE into a single ExprState, and (b) we know that all  
MULTIEXPR_SUBLINKs do need to be evaluated --- none could be buried  
inside a CASE, for example.  There is a minor semantics change  
concerning the order of execution of the MULTIEXPR's subquery versus  
other parts of the parent targetlist, but that seems like something  
we can get away with.  By doing that, we no longer need to worry  
about whether different clones of a MULTIEXPR_SUBLINK share output  
Params; their usage of that data structure won't overlap.  
  
Per bug #17800 from Alexander Lakhin.  Back-patch to all supported  
branches.  In v13 and earlier, we can revert 3f7323cbb and follow-on  
fixes; however, I chose to keep the SubPlan.subLinkId field added  
in ccbb54c72.  We don't need that anymore in the core code, but it's  
cheap enough to fill, and removing a plan node field in a minor  
release seems like it'd be asking for trouble.  
  
Andres Freund and Tom Lane  
  
Discussion: https://postgr.es/m/17800-ff90866b3906c964@postgresql.org  

commit   : 27ff93d18c2ba921cfbb9e2e38f5fb66c130bc9f    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Sat, 25 Feb 2023 14:44:49 +0000    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Sat, 25 Feb 2023 14:44:49 +0000    

If a rule action contains a subquery that refers to columns from OLD  
or NEW, then those are really lateral references, and the planner will  
complain if it sees such things in a subquery that isn't marked as  
lateral. However, at rule-definition time, the user isn't required to  
mark the subquery with LATERAL, and so it can fail when the rule is  
used.  
  
Fix this by marking such subqueries as lateral in the rewriter, at the  
point where they're used.  
  
Dean Rasheed and Tom Lane, per report from Alexander Lakhin.  
Back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/5e09da43-aaba-7ea7-0a51-a2eb981b058b%40gmail.com  

commit   : 0f78df719a90e3f992304f63b146b178e676bed2    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 23 Feb 2023 15:40:28 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 23 Feb 2023 15:40:28 -0500    

Multiple cycles of starting up and shutting down the plugin within a  
single session would eventually lead to "out of relcache_callback_list  
slots", because pgoutput_startup blindly re-registered its cache  
callbacks each time.  Fix it to register them only once, as all other  
users of cache callbacks already take care to do.  
  
This has been broken all along, so back-patch to all supported branches.  
  
Shi Yu  
  
Discussion: https://postgr.es/m/OSZPR01MB631004A78D743D68921FFAD3FDA79@OSZPR01MB6310.jpnprd01.prod.outlook.com  

commit   : f0423bea7f0afe6ccd830e2b729180e4355e04f6    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Thu, 23 Feb 2023 10:55:48 +0000    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Thu, 23 Feb 2023 10:55:48 +0000    

Given an updatable view with a DO ALSO INSERT ... SELECT rule, a  
multi-row INSERT ... VALUES query on the view fails if the VALUES list  
contains any DEFAULTs that are not replaced by view defaults. This  
manifests as an "unrecognized node type" error, or an Assert failure,  
in an assert-enabled build.  
  
The reason is that when RewriteQuery() attempts to replace the  
remaining DEFAULT items with NULLs in any product queries, using  
rewriteValuesRTEToNulls(), it assumes that the VALUES RTE is located  
at the same rangetable index in each product query. However, if the  
product query is an INSERT ... SELECT, then the VALUES RTE is actually  
in the SELECT part of that query (at the same index), rather than the  
top-level product query itself.  
  
Fix, by descending to the SELECT in such cases. Note that we can't  
simply use getInsertSelectQuery() for this, since that expects to be  
given a raw rule action with OLD and NEW placeholder entries, so we  
duplicate its logic instead.  
  
While at it, beef up the checks in getInsertSelectQuery() by checking  
that the jointree->fromlist node is indeed a RangeTblRef, and that the  
RTE it points to has rtekind == RTE_SUBQUERY.  
  
Per bug #17803, from Alexander Lakhin. Back-patch to all supported  
branches.  
  
Dean Rasheed, reviewed by Tom Lane.  
  
Discussion: https://postgr.es/m/17803-53c63ed4ecb4eac6%40postgresql.org  

commit   : 8b9cbd42b61ff55e5519631bada5d310159e3a5f    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Wed, 22 Feb 2023 15:24:09 +0100    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Wed, 22 Feb 2023 15:24:09 +0100    

Whe decoding a transactional logical message, logicalmsg_decode called  
SnapBuildGetOrBuildSnapshot. But we may not have a consistent snapshot  
yet at that point. We don't actually need the snapshot in this case  
(during replay we'll have the snapshot from the transaction), so in  
practice this is harmless. But in assert-enabled build this crashes.  
  
Fixed by requesting the snapshot only in non-transactional case, where  
we are guaranteed to have SNAPBUILD_CONSISTENT.  
  
Backpatch to 11. The issue exists since 9.6.  
  
Backpatch-through: 11  
Reviewed-by: Andres Freund  
Discussion: https://postgr.es/m/84d60912-6eab-9b84-5de3-41765a5449e8@enterprisedb.com  

commit   : 482ab3e4f9e0a2fcef96bdcbe7a719858fae8f79    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Wed, 22 Feb 2023 13:26:20 +0000    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Wed, 22 Feb 2023 13:26:20 +0000    

SPI_result_code_string() was missing support for SPI_OK_TD_REGISTER,  
and in v15 and later, it was missing support for SPI_OK_MERGE, as was  
pltcl_process_SPI_result().  
  
The last of those would trigger an error if a MERGE was executed from  
PL/Tcl. The others seem fairly innocuous, but worth fixing.  
  
Back-patch to all supported branches. Before v15, this is just adding  
SPI_OK_TD_REGISTER to SPI_result_code_string(), which is unlikely to  
be seen by anyone, but seems worth doing for completeness.  
  
Reviewed by Tom Lane.  
  
Discussion:  
  https://postgr.es/m/CAEZATCUg8V%2BK%2BGcafOPqymxk84Y_prXgfe64PDoopjLFH6Z0Aw%40mail.gmail.com  
  https://postgr.es/m/CAEZATCUMe%2B_KedPMM9AxKqm%3DSZogSxjUcrMe%2BsakusZh3BFcQw%40mail.gmail.com  

commit   : dc44180f6e17e10189c2e64a61255985de518a1e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 21 Feb 2023 18:47:47 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 21 Feb 2023 18:47:47 -0500    

If asked to decrease the size of a large (>8K) palloc chunk,  
AllocSetRealloc could improperly change the Valgrind state of memory  
beyond the new end of the chunk: it would mark data UNDEFINED as far  
as the old end of the chunk after having done the realloc(3) call,  
thus tromping on the state of memory that no longer belongs to it.  
One would normally expect that memory to now be marked NOACCESS,  
so that this mislabeling might prevent detection of later errors.  
If realloc() had chosen to move the chunk someplace else (unlikely,  
but well within its rights) we could also mismark perfectly-valid  
DEFINED data as UNDEFINED, causing false-positive valgrind reports  
later.  Also, any malloc bookkeeping data placed within this area  
might now be wrongly marked, causing additional problems.  
  
Fix by replacing relevant uses of "oldsize" with "Min(size, oldsize)".  
It's sufficient to mark as far as "size" when that's smaller, because  
whatever remains in the new chunk size will be marked NOACCESS below,  
and we expect realloc() to have taken care of marking the memory  
beyond the new official end of the chunk.  
  
While we're here, also rename the function's "oldsize" variable  
to "oldchksize" to more clearly explain what it actually holds,  
namely the distance to the end of the chunk (that is, requested size  
plus trailing padding).  This is more consistent with the use of  
"size" and "chksize" to hold the new requested size and chunk size.  
Add a new variable "oldsize" in the one stanza where we're actually  
talking about the old requested size.  
  
Oversight in commit c477f3e44.  Back-patch to all supported branches,  
as that was, just in case anybody wants to do valgrind testing on back  
branches.  
  
Karina Litskevich  
  
Discussion: https://postgr.es/m/CACiT8iaAET-fmzjjZLjaJC4zwSJmrFyL7LAdHwaYyjjQOQ4hcg@mail.gmail.com  

commit   : 663e50e8321192f30559a7dd68a912c43a44dcbb    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 21 Feb 2023 10:56:37 +0100    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 21 Feb 2023 10:56:37 +0100    

Failing to do so results in an error when a pgbench script tries to  
start a serializable transaction inside a pipeline, because by the time  
BEGIN ISOLATION LEVEL SERIALIZABLE is executed, we're already in a  
transaction that has acquired a snapshot, so the server rightfully  
complains.  
  
We can work around that by preparing all commands in the pipeline before  
actually starting the pipeline.  This changes the existing code in two  
aspects: first, we now prepare each command individually at the point  
where that command is about to be executed; previously, we would prepare  
all commands in a script as soon as the first command of that script  
would be executed.  It's hard to see that this would make much of a  
difference (particularly since it only affects the first time to execute  
each script in a client), but I didn't actually try to measure it.  
  
Secondly, we no longer use PQsendPrepare() in pipeline mode, but only  
PQprepare.  There's no specific reason for this change other than no  
longer needing to do differently in pipeline mode.  (Previously we had  
no choice, because in pipeline mode PQprepare could not be used.)  
  
Backpatch to 14, where pgbench got support for pipeline mode.  
  
Reported-by: Yugo NAGATA <nagata@sraoss.co.jp>  
Discussion: https://postgr.es/m/20210716153013.fc53b1c780b06fccc07a7f0d@sraoss.co.jp  

commit   : f3daa3116fad6aa85686aba5b54eaecc07e8f6cf    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Sun, 19 Feb 2023 00:41:18 +0100    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Sun, 19 Feb 2023 00:41:18 +0100    

When evaluating clauses on multiple scan keys of a multi-column BRIN  
index, we can stop processing as soon as we find a scan key eliminating  
the range, and the range should not be added to tbe bitmap.  
  
That's how it worked before 14, but since a681e3c107a the code treated  
the range as matching if it matched at least the last scan key.  
  
Backpatch to 14, where this code was introduced.  
  
Backpatch-through: 14  
Discussion: https://postgr.es/m/ebc18613-125e-60df-7520-fcbe0f9274fc%40enterprisedb.com  

commit   : 14345f3c6a7bc967b168bb1ed40de369a8998941    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 17 Feb 2023 16:40:34 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 17 Feb 2023 16:40:34 -0500    

ruleutils.c blindly printed the user-given alias (or nothing if there  
hadn't been one) for the target table of INSERT/UPDATE/DELETE queries.  
That works a large percentage of the time, but not always: for queries  
appearing in WITH, it's possible that we chose a different alias to  
avoid conflict with outer-scope names.  Since the chosen alias would  
be used in any Var references to the target table, this'd lead to an  
inconsistent printout with consequences such as dump/restore failures.  
  
The correct logic for printing (or not) a relation alias was embedded  
in get_from_clause_item.  Factor it out to a separate function so that  
we don't need a jointree node to use it.  (Only a limited part of that  
function can be reached from these new call sites, but this seems like  
the cleanest non-duplicative factorization.)  
  
In passing, I got rid of a redundant "\d+ rules_src" step in rules.sql.  
  
Initial report from Jonathan Katz; thanks to Vignesh C for analysis.  
This has been broken for a long time, so back-patch to all supported  
branches.  
  
Discussion: https://postgr.es/m/e947fa21-24b2-f922-375a-d4f763ef3e4b@postgresql.org  
Discussion: https://postgr.es/m/CALDaNm1MMntjmT_NJGp-Z=xbF02qHGAyuSHfYHias3TqQbPF2w@mail.gmail.com  

commit   : 864f80feadea85fae70abe3fa9d89408b93547d2    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 15 Feb 2023 10:12:33 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 15 Feb 2023 10:12:33 +0900    

OpenSSL 1.1.1 and newer versions have added support for RSA-PSS  
certificates, which requires the use of a specific routine in OpenSSL to  
determine which hash function to use when compiling it when using  
channel binding in SCRAM-SHA-256.  X509_get_signature_nid(), that is the  
original routine the channel binding code has relied on, is not able to  
determine which hash algorithm to use for such certificates.  However,  
X509_get_signature_info(), new to OpenSSL 1.1.1, is able to do it.  This  
commit switches the channel binding logic to rely on  
X509_get_signature_info() over X509_get_signature_nid(), which would be  
the choice when building with 1.1.1 or newer.  
  
The error could have been triggered on the client or the server, hence  
libpq and the backend need to have their related code paths patched.  
Note that attempting to load an RSA-PSS certificate with OpenSSL 1.1.0  
or older leads to a failure due to an unsupported algorithm.  
  
The discovery of relying on X509_get_signature_info() comes from Jacob,  
the tests have been written by Heikki (with few tweaks from me), while I  
have bundled the whole together while adding the bits needed for MSVC  
and meson.  
  
This issue exists since channel binding exists, so backpatch all the way  
down.  Some tests are added in 15~, triggered if compiling with OpenSSL  
1.1.1 or newer, where the certificate and key files can easily be  
generated for RSA-PSS.  
  
Reported-by: Gunnar "Nick" Bluth  
Author: Jacob Champion, Heikki Linnakangas  
Discussion: https://postgr.es/m/17760-b6c61e752ec07060@postgresql.org  
Backpatch-through: 11  

commit   : 4aa43ba21846ac6cc53c554565898a294ded6ad1    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Mon, 13 Feb 2023 17:09:55 +1300    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Mon, 13 Feb 2023 17:09:55 +1300    

When an aggregate function is used as a WindowFunc and a tuple transitions  
out of the window frame, we ordinarily try to make use of the aggregate  
function's inverse transition function to "unaggregate" the exiting tuple.  
  
This optimization is disabled for various cases, including when the  
aggregate contains a volatile function.  In such a case we'd be unable to  
ensure that the transition value was calculated to the same value during  
transitions and inverse transitions.  Unfortunately, we did this check by  
calling contain_volatile_functions() which does not recursively search  
SubPlans for volatile functions.  If the aggregate function's arguments or  
its FILTER clause contained a subplan with volatile functions then we'd  
fail to notice this.  
  
Here we fix this by just disabling the optimization when the WindowFunc  
contains any subplans.  Volatile functions are not the only reason that a  
subplan may have nonrepeatable results.  
  
Bug: #17777  
Reported-by: Anban Company  
Discussion: https://postgr.es/m/17777-860b739b6efde977%40postgresql.org  
Reviewed-by: Tom Lane  
Backpatch-through: 11  

commit   : 7f8778fcf3428756c1c9ab1ee26ff328e00bf608    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 8 Feb 2023 17:15:23 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 8 Feb 2023 17:15:23 -0500    

It appears no longer possible to build the SGML docs without a local  
installation of the DocBook DTD, because sourceforge.net now only  
permits HTTPS access, and no common version of xsltproc supports that.  
Hence, remove the bits of our documentation suggesting that that's  
possible or useful.  
  
In fact, we might as well add the --nonet option to the build recipes  
automatically, for a bit of extra security.  
  
Also fix our documentation-tool-installation recipes for macOS to  
ensure that xmllint and xsltproc are pulled in from MacPorts or  
Homebrew.  The previous recipes assumed you could use the  
Apple-supplied versions of these tools; which still works, except that  
you'd need to set an environment variable to ensure that they would  
find DTD files provided by those package managers.  Simpler and easier  
to just recommend pulling in the additional packages.  
  
In HEAD, also document how to build docs using Meson, and adjust  
"ninja docs" to just build the HTML docs, for consistency with the  
default behavior of doc/src/sgml/Makefile.  
  
In a fit of neatnik-ism, I also made the ordering of the package  
lists match the order in which the tools are described at the head  
of the appendix.  
  
Aleksander Alekseev, Peter Eisentraut, Tom Lane  
  
Discussion: https://postgr.es/m/CAJ7c6TO8Aro2nxg=EQsVGiSDe-TstP4EsSvDHd7DSRsP40PgGA@mail.gmail.com  

commit   : 0801345758db44ea8d2da7d8e7d8be2cf3d9bc4e    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 8 Feb 2023 13:09:27 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 8 Feb 2023 13:09:27 +0900    

Try to disable ASLR when building in EXEC_BACKEND mode, to avoid random  
memory mapping failures while testing.  For developer use only, no  
effect on regular builds.  
  
This has been originally applied as of f3e7806 for v15~, but  
recently-added buildfarm member gokiburi tests this configuration on  
older branches as well, causing it to fail randomly as ASLR would be  
enabled.  
  
Suggested-by: Andres Freund <andres@anarazel.de>  
Tested-by: Bossart, Nathan <bossartn@amazon.com>  
Discussion: https://postgr.es/m/20210806032944.m4tz7j2w47mant26%40alap3.anarazel.de  
Backpatch-through: 12  

commit   : e4c4e6258c747d440e161f387d2eff84a835ca08    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 6 Feb 2023 16:41:14 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 6 Feb 2023 16:41:14 -0500    

commit   : dfb5ad7cf0d83ac3bb78f0177721f68a6ba60486    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 6 Feb 2023 11:43:10 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 6 Feb 2023 11:43:10 -0500    

Security: CVE-2022-41862  

commit   : 28ac6d0a99d57375dbd9bc2acd16fd1127502ef7    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 6 Feb 2023 12:17:21 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 6 Feb 2023 12:17:21 +0100    

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

commit   : 626f2c1d6b85a6a0780460c7acc306bc2c326266    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 6 Feb 2023 11:20:23 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 6 Feb 2023 11:20:23 +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   : e8c21223e758000be6040785f2cfd0916dc05e97    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 5 Feb 2023 16:22:32 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 5 Feb 2023 16:22:32 -0500    

commit   : 86bfbeab4f439ad527318d9edeb3c71ea46c1ab3    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Fri, 3 Feb 2023 11:09:15 +0000    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Fri, 3 Feb 2023 11:09:15 +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   : 89d28f928c402e9f1890ece4d787825a6c51c2ca    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 3 Feb 2023 09:04:35 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
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   : 36c910f037836ed1b4143f40af43df488c9fbd6c    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Thu, 2 Feb 2023 18:13:44 +1300    
  
committer: Thomas Munro <tmunro@postgresql.org>    
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   : 7e615477996b51487e67e36490be9a4f33114529    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 31 Jan 2023 17:36:55 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
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   : 26da294098882c28467ad07995dbc80742db1d57    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 31 Jan 2023 14:32:24 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
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/87sffqk4zp.fsf@wibble.ilmari.org  

commit   : 96d42bd27fefed662dbf690348186902d4b6954e    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 31 Jan 2023 12:47:12 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 31 Jan 2023 12:47:12 +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/3163112.1674762209@sss.pgh.pa.us  
Discussion: https://postgr.es/m/20210305.115011.558061052471425531.horikyota.ntt@gmail.com  
Backpatch-through: 11  

commit   : 2f65b84683b7e755b4c44dc949f567e6d5d50132    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Thu, 26 Jan 2023 14:50:07 +1300    
  
committer: Thomas Munro <tmunro@postgresql.org>    
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 <dastapov@gmail.com>  
Discussion: https://postgr.es/m/17619-0de62ceda812b8b5%40postgresql.org  

commit   : e9774151c27868ebec08259f3698ebdb321138c4    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 25 Jan 2023 20:00:46 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 25 Jan 2023 20:00:46 +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   : fd270b728b28bd1a2973837498977de67d0a887e    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Tue, 24 Jan 2023 08:55:55 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Tue, 24 Jan 2023 08:55:55 +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   : 0a796b8b3e311ea21cf679bf71f39b42e859a686    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 23 Jan 2023 18:04:02 -0800    
  
committer: Andres Freund <andres@anarazel.de>    
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 <noah@leadboat.com>  
Discussion: https://postgr.es/m/20230121011237.q52apbvlarfv6jm6@awork3.anarazel.de  
Backpatch: 11-  

commit   : 0765b2f8f6fe8b7c1c07f94b764ef8bb74a292b4    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Tue, 24 Jan 2023 13:50:11 +1300    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Tue, 24 Jan 2023 13:50:11 +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/2144818.1674517061@sss.pgh.pa.us  
Backpatch-through: 14, same as b762fed64  

commit   : bcec08907e9357425ec0b3ea9ce03fd41fa6b8de    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Tue, 24 Jan 2023 12:29:24 +1300    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Tue, 24 Jan 2023 12:29:24 +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   : 70ec756b01a4c9e62c189a8d853401393d18cb4b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 21 Jan 2023 13:10:29 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
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/17756-dd50e8e0c8dd4a40@postgresql.org  

commit   : 6900aea67e27990b72bc28b0b69096db9d226cba    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sat, 21 Jan 2023 06:08:00 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
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 security@postgresql.org, this is not  
a vulnerability.  Back-patch to v11 (all supported versions).  
  
Andrey Borodin, reviewed by Tom Lane.  Reported by Andrey Borodin.  

commit   : 21c058648ec2cd257b7b8bb10b98e08564a685a4    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 20 Jan 2023 11:58:12 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
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   : 1034507245571a4a8e614299afe3f2e2ae858c27    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 19 Jan 2023 12:23:20 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
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   : 2e21e2857e5657b6867b337ddce5a22afce320c6    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 19 Jan 2023 13:13:28 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 19 Jan 2023 13:13:28 +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   : efd2474ab5b40778722054659e52254840773f95    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 19 Jan 2023 10:02:10 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 19 Jan 2023 10:02:10 +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/K@paquier.xyz  
Backpatch-through: 11  

commit   : 1b62971bbc3163bbe31346846bc511386f6808cd    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 17 Jan 2023 16:00:39 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
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   : 8e7398dce55b1d2a32a31f11179075086d112b66    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 16 Jan 2023 20:35:53 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
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/891521.1673657296@sss.pgh.pa.us  

commit   : f463335e1f29b8f5b47d8b606d10cdf76817970f    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 16 Jan 2023 09:20:44 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
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 <amit.kapila16@gmail.com>  
Discussion: https://www.postgresql.org/message-id/flat/f3501945-c591-8cc3-5ef0-b72a2e0eaa9c@enterprisedb.com  

commit   : a8b88c26f7061689ef1aea1b8fd234fed8e1fc9e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 15 Jan 2023 14:06:46 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
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/d259d69652b8c2ff50e14cda3c236c7f@postgrespro.ru  

commit   : 547e60b8317e3c351900c650988327b73cf7ae33    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Fri, 13 Jan 2023 10:40:52 +1300    
  
committer: Thomas Munro <tmunro@postgresql.org>    
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 <andres@anarazel.de>  
Discussion: https://postgr.es/m/901504.1673504836%40sss.pgh.pa.us  

commit   : 0d9221f1d251b956a33660bff1420140f8abebcb    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Thu, 12 Jan 2023 18:16:34 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
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   : b2cc5b81001ad5e856d7316bab11f08ce1386d4b    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Sat, 7 Jan 2023 11:52:41 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Sat, 7 Jan 2023 11:52:41 +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   : 48599a18d07999c7503b9f47ec43c0f19b603001    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Fri, 6 Jan 2023 11:15:22 +0000    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Fri, 6 Jan 2023 11:15:22 +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   : af209b7893f45af04f1b6f6304e9882069111da7    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Fri, 6 Jan 2023 16:38:46 +1300    
  
committer: Thomas Munro <tmunro@postgresql.org>    
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 <pryzby@telsasoft.com>  
Discussion: https://postgr.es/m/20230106031652.GR3109%40telsasoft.com  

commit   : 8cd190e13a22dab12e86f7f1b59de6b9b128c784    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 5 Jan 2023 14:12:17 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
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/2793383.1672944799@sss.pgh.pa.us  

commit   : 5136c3fb575bb46f5f33c0485c972aa5dea0757a    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Tue, 3 Jan 2023 14:50:40 -0500    
  
committer: Robert Haas <rhaas@postgresql.org>    
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   : e373e5578bc39af4f20a4b70c5db1895d0e2d3d1    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 3 Jan 2023 16:26:30 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 3 Jan 2023 16:26:30 +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/20221230231257.GI1153@telsasoft.com  
Backpatch-through: 11  

commit   : 7b5dec760f7d7cb8df0fe10051a6aca806581957    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Thu, 29 Dec 2022 12:47:29 -0800    
  
committer: Andres Freund <andres@anarazel.de>    
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 <andres@anarazel.de>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: Discussion: https://postgr.es/m/20221228182455.hfdwd22zztvkojy2@awork3.anarazel.de  

commit   : a02740e53fb7d1668e2d0ea1362743d23211d43d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 2 Jan 2023 16:17:00 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
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   : fdaba0a2d749bff497313b584f86855a1440d43e    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 2 Jan 2023 15:00:37 -0500    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 2 Jan 2023 15:00:37 -0500    

Backpatch-through: 11  

commit   : 883dc0214a64c0923455bf30bfcc5f953e70af39    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Fri, 30 Dec 2022 19:44:48 +0100    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
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   : 169d301f3305b47eff0cddd48aa0a563a3c38d4b    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 23 Dec 2022 13:21:41 +0100    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
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/81e36ac17dc80489e74dc5b6914afa6ccdb1a99d.camel@cybertec.at  

commit   : fd36b82c5d74ed355660beae79925a9faa36a084    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 23 Dec 2022 11:27:14 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 23 Dec 2022 11:27:14 +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/49f389ba-95ce-8a9b-09ae-f60650c0e7c7@inbox.ru  
Backpatch-through: 12  

commit   : 7ad458e06b1bf1408d9d089a843070943d6c7c6a    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 23 Dec 2022 10:04:33 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 23 Dec 2022 10:04:33 +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/20221222153041.GN1153@telsasoft.com  
Backpatch-through: 11  

commit   : 97431d673992326f4f85e4f185941444f33e20db    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 22 Dec 2022 10:35:02 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
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/703c09a2-08f3-d2ec-b33d-dbecd62428b8@postgrespro.ru  

commit   : f489b480f4aa8b4db4858a7bef1b42c984992c8a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 21 Dec 2022 17:51:50 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
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/17725-0a09313b67fbe86e@postgresql.org  

commit   : ea5ae4cae6a230e048f0ff4587b54d441712c6fd    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 16 Dec 2022 13:07:42 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
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/17723-2c4985ff111e7bba@postgresql.org  

commit   : 171d7746a21dfb0e19c008b7a398e1ee1ad7f74e    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Fri, 16 Dec 2022 11:40:55 +1300    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Fri, 16 Dec 2022 11:40:55 +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   : ae47f8a9664a65b233ee3c716f3098a5ba71f615    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 13 Dec 2022 14:23:59 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
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/65a899dd-aebc-f667-1d0a-abb89ff3abf8@enterprisedb.com  

commit   : a18328bb3395188befc2785dbbe47f0d84baf6d1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 12 Dec 2022 16:17:49 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
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 exe-dealer@yandex.ru.  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/205321670615953@mail.yandex.ru  

commit   : d43a97ef493a7edc9e03b5dd15870e04a0c38f75    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Thu, 8 Dec 2022 16:15:03 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Thu, 8 Dec 2022 16:15:03 +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   : dc3648f65bea3d3373b4e0026ae83bd8f436ee40    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 5 Dec 2022 12:36:41 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
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   : 1bd84ef6778017f89c2ca80377c3ae02ed3f4861    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 5 Dec 2022 11:23:30 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 5 Dec 2022 11:23:30 +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   : ce093aa18062f64d5eb16175e361cc34a222c1db    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 4 Dec 2022 13:48:12 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
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   : ec3daeec316ff999d3e8f12a3587cdb4d0af81b0    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 4 Dec 2022 13:17:18 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
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/1854233.1669949723@sss.pgh.pa.us  

commit   : 2c7ed9f752924c038abffb46999a0f543139d797    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Sat, 3 Dec 2022 12:16:07 +0000    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Sat, 3 Dec 2022 12:16:07 +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   : 6344bc0974dcdf1854d7e5312d5233d2c097a328    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Fri, 2 Dec 2022 17:50:26 -0800    
  
committer: Andres Freund <andres@anarazel.de>    
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 <vignesh21@gmail.com>  
Author: Andres Freund <andres@anarazel.de>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
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   : 303b26c1bb14abf20a35a9cddebee65e10f5ebd4    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 2 Dec 2022 14:24:44 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
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   : 47e1224d590ccbc0d745e812dffe2fa913201776    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Thu, 1 Dec 2022 11:26:32 -0800    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Thu, 1 Dec 2022 11:26:32 -0800    

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

commit   : 7ec2bfe9e0315a296a70e0f716e6dbe3ecfcd530    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 1 Dec 2022 12:26:12 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
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   : de0ff6088e324f5f879c070e3369bc7ad8136b1b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 1 Dec 2022 11:38:06 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
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/f41566aa-a057-6628-4b7c-b48770ecb84a@deepbluecap.com  

commit   : cf9bcb0f0421af15d7b9bebe00c8cf649bee399d    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Thu, 1 Dec 2022 10:45:08 -0500    
  
committer: Bruce Momjian <bruce@momjian.us>    
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/c6304b19-6ff7-f3af-0148-cf7aa7e2fbfd@enterprisedb.com  
  
Backpatch-through: 11  

commit   : a949b7320fdfad445453375a1630f81f6bd3b49d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 30 Nov 2022 13:01:41 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
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   : 5d208b90b75b00ff96095e4402a7cfa55f65f2ac    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 29 Nov 2022 20:49:52 -0500    
  
committer: Bruce Momjian <bruce@momjian.us>    
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   : cdea14a245b17df6d86f6c1193bc3726d4686605    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 30 Nov 2022 08:38:30 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 30 Nov 2022 08:38:30 +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   : 06998eab16b2165b5f27014a0843b75e377cc63e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 29 Nov 2022 15:43:17 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
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   : 7715a3c244507a52e64fbfe36547ec09eafd4af0    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 29 Nov 2022 11:46:33 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
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/17702-ad24fdcdd1e9047a@postgresql.org  

commit   : 0224646beec657fb3a7791d237293ad4caea3255    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 29 Nov 2022 10:52:44 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
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/17700-2b5c10d917c30687@postgresql.org  

commit   : f3f70b8de66c0bae86f4761e152c10dd39f6f179    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Sun, 27 Nov 2022 09:03:22 -0500    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
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/20211005004334.tgjmro4kuachwiuc@alap3.anarazel.de  
Discussion: https://postgr.es/m/c2da86a0-2906-744c-923d-16da6047875e@dunslane.net  
  
Backpatch to all live branches.  

commit   : 4e9e1b2a625eccfdfd09b8fca9693dd1fe96f256    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 26 Nov 2022 10:30:31 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 26 Nov 2022 10:30:31 -0500    

Another oversight in 9b4eafcaf.  

commit   : ec7b29cb954fca911fddb9a76a19170256338c8f    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Sat, 26 Nov 2022 07:44:23 -0500    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
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   : f76191fd994aa1e49110b496f6c7119052118dee    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 25 Nov 2022 15:28:38 -0500    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
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   : e52245228ecf3a58b031c820332bc56478bb1ba2    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Fri, 25 Nov 2022 17:45:03 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Fri, 25 Nov 2022 17:45:03 +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   : 9f2cc1a73ccf84c24dc4c386721b3bb73757dc24    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Fri, 25 Nov 2022 09:25:50 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Fri, 25 Nov 2022 09:25:50 +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   : 8e7c86785a11cd3e56f895b8e2a489546c36a350    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 24 Nov 2022 10:45:10 +0100    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
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/17518-04e368df5ad7f2ee@postgresql.org  

commit   : c93254424f288557eeef13343be8f72536cb9ffe    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Wed, 23 Nov 2022 07:17:26 -0500    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Wed, 23 Nov 2022 07:17:26 -0500    

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

commit   : bd06fe4dee6321a3eabc1832f1faa736350d5d2c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 22 Nov 2022 14:40:20 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
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   : 870d6218e6d73dca8ec37b4d7f5076b74eeaeffe    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Tue, 22 Nov 2022 10:35:04 -0500    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Tue, 22 Nov 2022 10:35:04 -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/20221002164931.d57hlutrcz4d2zi7@awork3.anarazel.de  

commit   : 1b3ed757145dd6fa29feb6a31084527a6d6a46e3    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 22 Nov 2022 10:56:07 +0100    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
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 <sirichamarthi22@gmail.com>  
Reviewed-by: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>  
Discussion: https://postgr.es/m/CAKrAKeUEDeqquN9vwzNeG-CN8wuVsfRYbeOUV9qKO_RHok=j+g@mail.gmail.com  

commit   : 385b317715179fd60b6a2899a3d10b13ca52ad4d    
  
author   : Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Mon, 21 Nov 2022 23:25:48 +0100    
  
committer: Daniel Gustafsson <dgustafsson@postgresql.org>    
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/DC9A662A-360D-4125-A453-5A6CB9C6C4B4@yesql.se  
Backpatch-through: v11  

commit   : 1b9c04b1389b0e8ee7f493477c22c25f65a2f89a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 21 Nov 2022 17:07:07 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
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   : 47a22dc2cb89aca2e54c9cf9fe2da4a5e8ba4cb4    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 21 Nov 2022 15:37:48 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 21 Nov 2022 15:37:48 -0500    

This reverts commit 5cda142bb9d2bd7e7ed1c22ae89afe58abfa8d7b  
(in v14 only).  
  
It turns out that that fails under force_parallel_mode = regress,  
because pageinspect's disk-access functions are marked parallel  
safe, which they are not if you try to use them on a temp table.  
The cost of fixing that pre-v15 seems to exceed the value of  
making this test case fully stable, so we will just leave things  
as-is in v14.  

commit   : 5cda142bb9d2bd7e7ed1c22ae89afe58abfa8d7b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 21 Nov 2022 10:50:50 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
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/2892135.1668976646@sss.pgh.pa.us  

commit   : fc4154286e0e47d748d19183fd05be794a019be8    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Wed, 16 Nov 2022 20:00:59 -0800    
  
committer: Andres Freund <andres@anarazel.de>    
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 <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/20221117014230.op5kmgypdv2dtqsf@awork3.anarazel.de  
Backpatch: 11-  

commit   : bb3f42aae382106b91d60b861333a08ff6007e9c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 19 Nov 2022 13:09:14 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
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   : 03ac48549438f26b796c1f536c2b545c6c50f259    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 19 Nov 2022 12:00:27 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 19 Nov 2022 12:00:27 -0500    

getPolicies() had the same disease I fixed in other places in  
commit e3fcbbd62, i.e., it was calling pg_get_expr() for  
expressions on tables that we don't necessarily have lock on.  
To fix, restrict the query to only collect interesting rows,  
rather than doing the filtering on the client side.  
  
Back-patch of commit 3e6e86abc.  That's been in v15/HEAD long enough  
to have some confidence about it, so now let's fix the problem in  
older branches.  
  
Discussion: https://postgr.es/m/2273648.1634764485@sss.pgh.pa.us  
Discussion: https://postgr.es/m/7d7eb6128f40401d81b3b7a898b6b4de@W2012-02.nidsa.loc  
Discussion: https://postgr.es/m/45c93d57-9973-248e-d2df-e02ca9af48d4@darold.net  

commit   : 55f30e6c7640c80fbb7be90fad668ee4bffa0e97    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 19 Nov 2022 11:40:30 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 19 Nov 2022 11:40:30 -0500    

Avoid calling pg_get_partkeydef(), pg_get_expr(relpartbound),  
and regtypeout until we have lock on the relevant tables.  
The existing coding is at serious risk of failure if there  
are any concurrent DROP TABLE commands going on --- including  
drops of other sessions' temp tables.  
  
Back-patch of commit e3fcbbd62.  That's been in v15/HEAD long enough  
to have some confidence about it, so now let's fix the problem in  
older branches.  
  
Original patch by me; thanks to Gilles Darold for back-patching  
legwork.  
  
Discussion: https://postgr.es/m/2273648.1634764485@sss.pgh.pa.us  
Discussion: https://postgr.es/m/7d7eb6128f40401d81b3b7a898b6b4de@W2012-02.nidsa.loc  
Discussion: https://postgr.es/m/45c93d57-9973-248e-d2df-e02ca9af48d4@darold.net  

commit   : 038512f71ea807d6c2b8e519f2416a9a5283d9bf    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 18 Nov 2022 08:38:26 -0500    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
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   : 32d5a4974c81aeaca7ffc025f0a5fda88b71cba6    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 17 Nov 2022 16:54:30 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 17 Nov 2022 16:54:30 -0500    

This is a back-patch of the v15-era commit f10f0ae42 into older  
supported branches.  The idea is to design out bugs in which an  
ill-timed relcache flush clears rel->rd_smgr partway through  
some code sequence that wasn't expecting that.  We had another  
report today of a corner case that reliably crashes v14 under  
debug_discard_caches (nee CLOBBER_CACHE_ALWAYS), and therefore  
would crash once in a blue moon in the field.  We're unlikely  
to get rid of all such code paths unless we adopt the more  
rigorous coding rules instituted by f10f0ae42.  Therefore,  
even though this is a bit invasive, it's time to back-patch.  
Some comfort can be taken in the fact that f10f0ae42 has been  
in v15 for 16 months without problems.  
  
I left the RelationOpenSmgr macro present in the back branches,  
even though no core code should use it anymore, in order to not break  
third-party extensions in minor releases.  Such extensions might opt  
to start using RelationGetSmgr instead, to reduce their code  
differential between v15 and earlier branches.  This carries a hazard  
of failing to compile against headers from existing minor releases.  
However, once compiled the extension should work fine even with such  
releases, because RelationGetSmgr is a "static inline" function so  
it creates no link-time dependency.  So depending on distribution  
practices, that might be an OK tradeoff.  
  
Per report from Spyridon Dimitrios Agathos.  Original patch  
by Amul Sul.  
  
Discussion: https://postgr.es/m/CAFM5RaqdgyusQvmWkyPYaWMwoK5gigdtW-7HcgHgOeAw7mqJ_Q@mail.gmail.com  
Discussion: https://postgr.es/m/CANiYTQsU7yMFpQYnv=BrcRVqK_3U3mtAzAsJCaqtzsDHfsUbdQ@mail.gmail.com  

commit   : aaf28c90654425c2e94dc2c8b2d0d8d971483c7e    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Thu, 17 Nov 2022 07:35:06 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
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/20221117061805.GA4020280@rfd.leadboat.com  

commit   : 9693f190076ec04fd06d63ab00ba4d0383515b7c    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Mon, 14 Nov 2022 10:22:28 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Mon, 14 Nov 2022 10:22:28 +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/20220810022617.fvjkjiauaykwrbse@awork3.anarazel.de  

commit   : f893af496100737b7fa1ef861ac8bd2705b4d5f1    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Thu, 10 Nov 2022 14:46:30 -0800    
  
committer: Jeff Davis <jdavis@postgresql.org>    
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/fed17dac-8cb8-4f5b-d462-1bb4908c029e@garret.ru  
Backpatch-through: 11