PostgreSQL 16.0 (upcoming) commit log

commit   : 0ffbe6e59197e5e2b3bf026f594fabb8ada9bec3    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 23 May 2023 15:19:33 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 23 May 2023 15:19:33 +0200    

Similar to client_min_messages etc.  

commit   : dfe0169988f32e7cb9c48fad9ab3de71c6c39a55    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 23 May 2023 15:19:12 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 23 May 2023 15:19:12 +0200    

commit   : f40177c904f17721c3d33a6c202b74f3f2d4874d    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 23 May 2023 15:18:06 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 23 May 2023 15:18:06 +0200    

commit   : 5cb54fc310fb84287cbdc74533f3420490a2f63a    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 23 May 2023 00:27:01 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 23 May 2023 00:27:01 -0400    

Reported-by: John Naylor  
  
Discussion: https://postgr.es/m/CAFBsxsEuAx4_nq=200u=70S5r83C2hzO-a9+c6YXTCbOFeDAfw@mail.gmail.com  

commit   : e0b82fc8e8317881ecdd1e28bece55ea0db952da    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 22 May 2023 17:08:08 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 22 May 2023 17:08:08 -0400    

commit   : 60751aa50313b3498de199a3cd62e5f30e6b6091    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 22 May 2023 13:58:24 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 22 May 2023 13:58:24 -0400    

Reported-by: Jonathan Katz  
  
Discussion: https://postgr.es/m/2fd2cc0e-df39-3e77-8fcf-35aad5796b0a@postgresql.org  

commit   : 1f9f6aa491986ed4e65851e827d021e9c784fd42    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 22 May 2023 11:50:20 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 22 May 2023 11:50:20 -0400    

That's how other boolean options are handled, so do likewise.  
The previous coding with "enable" and "disable" was seemingly  
modeled on gssencmode, but that's a three-way flag.  
  
While at it, add PGGSSDELEGATION to the set of environment  
variables cleared by pg_regress and Utils.pm.  
  
Abhijit Menon-Sen, per gripe from Alvaro Herrera  
  
Discussion: https://postgr.es/m/20230522091609.nlyuu4nolhycqs2p@alvherre.pgsql  

commit   : 4123455a9e5463495a6e9be8423e671c874ec19f    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 22 May 2023 10:20:53 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 22 May 2023 10:20:53 -0400    

commit   : 473e02f6f9ba1863c59a9e40736a633ed52c139f    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 22 May 2023 12:44:31 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 22 May 2023 12:44:31 +0200    

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

commit   : 4042b2e18781532d5dd6ee3cef38c4fbb0249202    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 22 May 2023 12:26:40 +0200    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 22 May 2023 12:26:40 +0200    

Apparently an oversight in 2820adf7755d.  

commit   : ac298d3cb56b015acd40d2e015e07a87d8aff124    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Sun, 21 May 2023 23:39:27 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Sun, 21 May 2023 23:39:27 -0400    

Improve description of "Allow logical decoding on standbys".  

commit   : 2dcd1578c40153250836df62f625863056c28a81    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Sun, 21 May 2023 20:03:56 -0700    
  
committer: Nathan Bossart <nathan@postgresql.org>    
date     : Sun, 21 May 2023 20:03:56 -0700    

This change renames --admin to --with-admin, --role to --member-of,  
and --member to --with-member.  Many people found the previous  
names to be confusing.  The --admin and --member options are new in  
v16, but --role has been there for a while, so that one has been  
kept (but left undocumented) for backward compatibility.  
  
Suggested-by: Peter Eisentraut  
Reviewed-by: Tom Lane, Michael Paquier  
Discussion: https://postgr.es/m/ZFvVZvQDliIWmOwg%40momjian.us  

commit   : de7c3fd34e0fc0a3f77537e1d12efcd01d255534    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Sun, 21 May 2023 22:52:42 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Sun, 21 May 2023 22:52:42 -0400    

Reported-by: Andres Freund, jian he  
  
Discussion: https://postgr.es/m/20230521171341.jjxykfsefsek4kzj@awork3.anarazel.de, 20230521171341.jjxykfsefsek4kzj@awork3.anarazel.de  

commit   : c822358a256ca1f3b8b08557b9c9f0efa8d41675    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Sun, 21 May 2023 15:57:37 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Sun, 21 May 2023 15:57:37 -0400    

Reported-by: Tom Lane  
  
Discussion: https://postgr.es/m/277016.1684689065@sss.pgh.pa.us  

commit   : b9c755a2f625b7dca6323804b140b016d95a0b1d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 21 May 2023 15:25:43 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 21 May 2023 15:25:43 -0400    

Use the clause's required_relids not clause_relids for testing  
whether it is computable at the current join level, if it is a  
clone clause generated by deconstruct_distribute_oj_quals().  
  
Arguably, this is more correct and we should do it for all clauses;  
that would at least remove the handwavy claim that we are doing  
it to save cycles compared to inspecting Vars individually.  
However, attempting to do that exposes that we are not being careful  
to compute an accurate value for required_relids in all cases.  
I'm unsure whether it's a good idea to attempt to do that for v16,  
or leave it as future clean-up.  In the meantime, this quick hack  
demonstrably fixes some cases, so let's squeeze it in for beta1.  
  
Patch by me, but great thanks to Richard Guo for investigation  
and testing.  The new test cases are all modeled on his examples.  
  
Discussion: https://postgr.es/m/CAMbWs4-_vwkBij4XOQ5ukxUvLgwTm0kS5_DO9CicUeKbEfKjUw@mail.gmail.com  

commit   : eabb22525efc40ce0d83580584094a0248ac0682    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Sun, 21 May 2023 09:48:37 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Sun, 21 May 2023 09:48:37 -0700    

The assertion checked that the size of the relation is not "too large" - but  
the code is explicitly dealing with the possibility of another backend  
extending the relation concurrently. In that case the new relation size could  
be bigger than what the current backend needs, wrongly triggering an assertion  
failure.  
  
Unfortunately it is hard to write a reliable and affordable regression tests  
for this, as a lot of concurrency is needed to encounter the bug.  
  
Introduced in 31966b151e6a.  
  
Reported-by: Melanie Plageman <melanieplageman@gmail.com>  

commit   : bc971f4025c378ce500d86597c34b0ef996d4d8c    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Sun, 21 May 2023 09:44:55 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Sun, 21 May 2023 09:44:55 -0700    

WalSndWakeup() currently loops through all the walsenders slots, with a  
spinlock acquisition and release for every iteration, to wake up waiting  
walsenders.  
  
This commonly was not a problem before e101dfac3a53c. But, to allow logical  
decoding on standbys, we need to wake up logical walsenders after every WAL  
record is applied on the standby, rather just when flushing WAL or switching  
timelines.  This causes a performance regression for workloads replaying a lot  
of WAL records.  
  
To solve this, we use condition variable (CV) to efficiently wake up  
walsenders in WalSndWakeup().  
  
Every walsender prepares to sleep on a shared memory CV. Note that it just  
prepares to sleep on the CV (i.e., adds itself to the CV's waitlist), but does  
not actually wait on the CV (IOW, it never calls ConditionVariableSleep()). It  
still uses WaitEventSetWait() for waiting, because CV infrastructure doesn't  
handle FeBe socket events currently. The processes (startup process,  
walreceiver etc.)  wanting to wake up walsenders use  
ConditionVariableBroadcast(), which in turn calls SetLatch(), helping  
walsenders come out of WaitEventSetWait().  
  
We use separate shared memory CVs for physical and logical walsenders for  
selective wake ups, see WalSndWakeup() for more details.  
  
This approach is simple and reasonably efficient. But not very elegant. But  
for 16 it seems to be a better path than a larger redesign of the CV  
mechanism.  A desirable future improvement would be to add support for CVs  
into WaitEventSetWait().  
  
This still leaves us with a small regression in very extreme workloads (due to  
the spinlock acquisition in ConditionVariableBroadcast() when there are no  
waiters) - but that seems acceptable.  
  
Reported-by: Andres Freund <andres@anarazel.de>  
Suggested-by: Andres Freund <andres@anarazel.de>  
Author: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>  
Reviewed-by: "Drouvot, Bertrand" <bertranddrouvot.pg@gmail.com>  
Reviewed-by: Zhijie Hou <houzj.fnst@fujitsu.com>  
Discussion: https://www.postgresql.org/message-id/20230509190247.3rrplhdgem6su6cg%40awork3.anarazel.de  

commit   : 30579d23b22655e340e9806fb3425e73eed60876    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Sun, 21 May 2023 11:55:50 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Sun, 21 May 2023 11:55:50 -0400    

Reported-by: Ian Lawrence Barwick  
  
Discussion: https://postgr.es/m/CAB8KJ=hLvQDb53WdigV7OBEBh5tzQ7eA=pG0ZpccoRVBUNCXYA@mail.gmail.com  

commit   : b62381d9a23b4b96259cf560e411137656201704    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 21 May 2023 11:21:19 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 21 May 2023 11:21:19 -0400    

Tweak column widths in a couple of tables to avoid "contents  
... exceed the available area" warnings.  Remove usage of  
some non-Latin-1 characters.  
  
Discussion: https://postgr.es/m/614600.1684537037@sss.pgh.pa.us  

commit   : a2eb99a01e015a76682911ae3980762f6ee6ac8c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 21 May 2023 10:55:18 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 21 May 2023 10:55:18 -0400    

Complete the task begun in 9c0a0e2ed: we don't want to use the  
abbreviation "deleg" for GSS delegation in any user-visible places.  
(For consistency, this also changes most internal uses too.)  
  
Abhijit Menon-Sen and Tom Lane  
  
Discussion: https://postgr.es/m/949048.1684639317@sss.pgh.pa.us  

commit   : f4001a553770b3114dd11846c6789ad6c34ef111    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Sat, 20 May 2023 20:18:51 -0700    
  
committer: Nathan Bossart <nathan@postgresql.org>    
date     : Sat, 20 May 2023 20:18:51 -0700    

These were missed in 9c0a0e2ed9.  
  
Discussion: https://postgr.es/m/20230521031757.GA3835667%40nathanxps13  

commit   : 9c0a0e2ed92a1a94ec30d36f8ea1ab12c928292b    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Sat, 20 May 2023 21:32:54 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Sat, 20 May 2023 21:32:54 -0400    

This is more consistent with existing GUC spelling.  
  
Discussion: https://postgr.es/m/ZGdnEsGtNj7+fZoa@momjian.us  

commit   : cf109ffc205063f82258e0643588491a153c3a45    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Sat, 20 May 2023 21:03:13 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Sat, 20 May 2023 21:03:13 -0400    

*  document to_reg* accepting OIDs  
*  document pg_log_standby_snapshot()  
*  document pg_input_is_valid() and pg_input_error_info()  
*  handle rename of function to pg_split_walfile_name()  
*  fix character encoding problem for Przemyslaw Sztoch  
*  remove partition section  
  
Reported-by: jian he, Tom Lane, Bertrand Drouvot  

commit   : 1c006c067124403d63b6ad3eac687b4217f05691    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 19 May 2023 17:28:04 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 19 May 2023 17:28:04 -0400    

commit   : 0245f8db36f375326c2bae0c3420d3c77714e72d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 19 May 2023 17:24:48 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 19 May 2023 17:24:48 -0400    

Run pgindent, pgperltidy, and reformat-dat-files.  
  
This set of diffs is a bit larger than typical.  We've updated to  
pg_bsd_indent 2.1.2, which properly indents variable declarations that  
have multi-line initialization expressions (the continuation lines are  
now indented one tab stop).  We've also updated to perltidy version  
20230309 and changed some of its settings, which reduces its desire to  
add whitespace to lines to make assignments etc. line up.  Going  
forward, that should make for fewer random-seeming changes to existing  
code.  
  
Discussion: https://postgr.es/m/20230428092545.qfb3y5wcu4cm75ur@alvherre.pgsql  

commit   : df6b19fbbc20d830de91d9bea68715a39635b568    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 19 May 2023 16:43:57 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 19 May 2023 16:43:57 -0400    

Our standard version of perltidy is now 20230309.  
Add a --valign-exclusion-list setting to reduce crosstalk  
between nearby lines of Perl code.  
  
Also, update instructions for running pgindent  
(missed in b16259b3c).  
  
Discussion: https://postgr.es/m/20230428092545.qfb3y5wcu4cm75ur@alvherre.pgsql  

commit   : 722541ead194635d77163bda057cc0064ff81149    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 19 May 2023 16:36:38 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 19 May 2023 16:36:38 -0400    

Run renumber_oids.pl to move high-numbered OIDs down, as per pre-beta  
tasks specified by RELEASE_CHANGES.  For reference, the command was  
  
./renumber_oids.pl --first-mapped-oid 8000 --target-oid 6200  

commit   : d0f952691ff532aa0c54e9d146fac8d590596646    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 19 May 2023 15:24:07 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 19 May 2023 15:24:07 -0400    

In commit 9df8f903e I (tgl) switched join_is_removable() from  
using the min relid sets of the join under consideration to  
using its full syntactic relid sets.  This was a mistake,  
as it allowed join removal in cases where a reference to the  
join output would survive in some syntactically-lower join  
condition.  Revert to the former coding.  
  
Richard Guo  
  
Discussion: https://postgr.es/m/CAMbWs4-EU9uBGSP7G-iTwLBhRQ=rnZKvFDhD+n+xhajokyPCKg@mail.gmail.com  

commit   : 70b42f2790292cc30aa07563f343f7ba6749af01    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 19 May 2023 14:26:34 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 19 May 2023 14:26:34 -0400    

The idea of EvalPlanQual is that we replace the query's scan of the  
result relation with a single injected tuple, and see if we get a  
tuple out, thereby implying that the injected tuple still passes the  
query quals.  (In join cases, other relations in the query are still  
scanned normally.)  This logic was not updated when commit 86dc90056  
made it possible for a single DML query plan to have multiple result  
relations, when the query target relation has inheritance or partition  
children.  We replaced the output for the current result relation  
successfully, but other result relations were still scanned normally;  
thus, if any other result relation contained a tuple satisfying the  
quals, we'd think the EPQ check passed, even if it did not pass for  
the injected tuple itself.  This would lead to update or delete  
actions getting performed when they should have been skipped due to  
a conflicting concurrent update in READ COMMITTED isolation mode.  
  
Fix by blocking all sibling result relations from emitting tuples  
during an EvalPlanQual recheck.  In the back branches, the fix is  
complicated a bit by the need to not change the size of struct  
EPQState (else we'd have ABI-breaking changes in offsets in  
struct ModifyTableState).  Like the back-patches of 3f7836ff6  
and 4b3e37993, add a separately palloc'd struct to avoid that.  
The logic is the same as in HEAD otherwise.  
  
This is only a live bug back to v14 where 86dc90056 came in.  
However, I chose to back-patch the test cases further, on the  
grounds that this whole area is none too well tested.  I skipped  
doing so in v11 though because none of the test applied cleanly,  
and it didn't quite seem worth extra work for a branch with only  
six months to live.  
  
Per report from Ante Krešić (via Aleksander Alekseev)  
  
Discussion: https://postgr.es/m/CAJ7c6TMBTN3rcz4=AjYhLPD_w3FFT0Wq_C15jxCDn8U4tZnH1g@mail.gmail.com  

commit   : ed7e686a031e5b9469e0813af2f513dfdd77560b    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 19 May 2023 20:19:28 +0200    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 19 May 2023 20:19:28 +0200    

Don't throw away the previous value when an invalid value is proposed.  
  
Discussion: https://postgr.es/m/20230519110205.updpbjiuqgbox6gp@alvherre.pgsql  

commit   : 8e7912e73da008862180112cc6ba4d0aa5fa955d    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 19 May 2023 18:45:29 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 19 May 2023 18:45:29 +0200    

commit   : e5f85744eaa5ca83ff4d27509ed094ca33ed485e    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Fri, 19 May 2023 12:29:50 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Fri, 19 May 2023 12:29:50 -0400    

Reported-by: Nathan Bossart, Sehrope Sarkuni  

commit   : 8c4040edf456d9241816176eacb79e4d9a0034fc    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Fri, 19 May 2023 16:31:11 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Fri, 19 May 2023 16:31:11 +0200    

Should a hash join exceed memory limit, the hashtable is split up into  
multiple batches. The number of batches is doubled each time a given  
batch is determined not to fit in memory. Each batch file is allocated  
with a block-sized buffer for buffering tuples and parallel hash join  
has additional sharedtuplestore accessor buffers.  
  
In some pathological cases requiring a lot of batches, often with skewed  
data, bad stats, or very large datasets, users can run out-of-memory  
solely from the memory overhead of all the batch files' buffers.  
  
Batch files were allocated in the ExecutorState memory context, making  
it very hard to identify when this batch explosion was the source of an  
OOM. This commit allocates the batch files in a dedicated memory  
context, making it easier to identify the cause of an OOM and work to  
avoid it.  
  
Based on initial draft by Tomas Vondra, with significant reworks and  
improvements by Jehan-Guillaume de Rorthais.  
  
Author: Jehan-Guillaume de Rorthais <jgdr@dalibo.com>  
Author: Tomas Vondra <tomas.vondra@enterprisedb.com>  
Reviewed-by:  Melanie Plageman <melanieplageman@gmail.com>  
Discussion: https://postgr.es/m/20190421114618.z3mpgmimc3rmubi4@development  
Discussion: https://postgr.es/m/20230504193006.1b5b9622%40karst#273020ff4061fc7a2fbb1ba96b281f17  

commit   : 507615fc533b1b65bcecc6218e36436687fe8420    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Fri, 19 May 2023 16:19:54 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Fri, 19 May 2023 16:19:54 +0200    

Add a high level description of our implementation of the hybrid hash  
join algorithm to the block comment in nodeHashjoin.c.  
  
Author: Melanie Plageman <melanieplageman@gmail.com>  
Reviewed-by: Tomas Vondra <tomas.vondra@enterprisedb.com>  
Reviewed-by: Jehan-Guillaume de Rorthais <jgdr@dalibo.com>  
Discussion: https://postgr.es/m/20230516160051.4267a800%40karst  

commit   : b973f93b6c540f65c960bfb19af55f3d4afe4b72    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 19 May 2023 10:57:46 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 19 May 2023 10:57:46 -0400    

Commits 681d9e462 et al added a test case in namespace.sql that  
implicitly relied on there not being a table "public.abc".  
However, the concurrently-run transactions.sql test creates precisely  
such a table, so with the right timing you'd get a failure.  
Creating a table named as generically as "abc" in a common schema  
seems like bad practice, so fix this by changing the name of  
transactions.sql's table.  (Compare 2cf8c7aa4.)  
  
Marina Polyakova  
  
Discussion: https://postgr.es/m/80d0201636665d82185942e7112257b4@postgrespro.ru  

commit   : 803b4a26ca3fdddbb6e3ce87a23bfbcc8a8669f3    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 19 May 2023 15:57:38 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 19 May 2023 15:57:38 +0200    

commit   : 6ff33cdbabdf770ca9d6b417c0687c04b2cd4d36    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Fri, 19 May 2023 09:30:00 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Fri, 19 May 2023 09:30:00 -0400    

Reported-by: Vibhor Kumar  

commit   : 1a620cbae5c48dc89f7cb08602c331f5751df71a    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Fri, 19 May 2023 08:31:11 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Fri, 19 May 2023 08:31:11 -0400    

Reported-by: Hans Buschmann  

commit   : 4c9deebd37ecbeb1bbf6baaf43bafc2f84b9011b    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 19 May 2023 13:42:06 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 19 May 2023 13:42:06 +0200    

The previous order in the file didn't make sense and matched neither  
the header file nor the smgr API.  
  
Discussion: https://www.postgresql.org/message-id/flat/22fed8ba-01c3-2008-a256-4ea912d68fab%40enterprisedb.com  

commit   : 0b8ace8d773257fffeaceda196ed94877c2b74df    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 19 May 2023 10:52:04 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 19 May 2023 10:52:04 +0200    

Most (older) comments in md.c and smgr.c are indented with a leading  
tab on all lines, which isn't the current style and makes updating the  
comments a bit annoying.  This reindents all these lines with a single  
space, as is the normal style.  This issue exists in various shapes  
throughout the code but it's pretty consistent here, and since there  
is a patch pending to refresh some of the comments in these files, it  
seems sensible to clean this up here separately.  
  
Discussion: https://www.postgresql.org/message-id/flat/22fed8ba-01c3-2008-a256-4ea912d68fab%40enterprisedb.com  

commit   : e7bff46e50b85c6b37723426188498dab973806c    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 19 May 2023 12:37:58 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 19 May 2023 12:37:58 +0900    

Non-leaf pages of GiST indexes contain key attributes, leaf pages  
contain both key and non-key attributes, and gist_page_items() ignored  
the handling of non-key attributes.  This caused a few problems when  
using gist_page_items() on a GiST index with INCLUDE:  
- On a non-leaf page, the function would crash.  
- On a leaf page, the function would work, but miss to display all the  
values for included attributes.  
  
This commit fixes gist_page_items() to handle such cases in a more  
appropriate way, and now displays the values of key and non-key  
attributes for each item separately in a style consistent with what  
ruleutils.c would generate for the attribute list, depending on the page  
type dealt with.  In a way similar to how a record is displayed, values  
would be double-quoted for key or non-key attributes if required.  
  
ruleutils.c did not provide a routine able to control if non-key  
attributes should be displayed, so an extended() routine for index  
definitions is added to work around the leaf and non-leaf page  
differences.  
  
While on it, this commit fixes a third problem related to the amount of  
data reported for key attributes.  The code originally relied on  
BuildIndexValueDescription() (used for error reports on constraints)  
that would not print all the data stored in the index but the index  
opclass's input type, so this limited the amount of information  
available.  This switch makes gist_page_items() much cheaper as there is  
no need to run ACL checks for each item printed, which is not an issue  
anyway as superuser rights are required to execute the functions of  
pageinspect.  Opclasses whose data cannot be displayed can rely on  
gist_page_items_bytea().  
  
The documentation of this function was slightly incorrect for the  
output results generated on HEAD and v15, so adjust it on these  
branches.  
  
Author: Alexander Lakhin, Michael Paquier  
Discussion: https://postgr.es/m/17884-cb8c326522977acb@postgresql.org  
Backpatch-through: 14  

commit   : 613a7eca9ca9f13d1f9fd8a7806bbded1836e58f    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Thu, 18 May 2023 23:17:03 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Thu, 18 May 2023 23:17:03 -0400    

Reported-by: Peter Geoghegan  

commit   : ce3673daded3fe3a101b0c008235dcf8bfe9ffec    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Thu, 18 May 2023 22:22:17 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Thu, 18 May 2023 22:22:17 -0400    

Discussion: https://postgr.es/m/ZFvVZvQDliIWmOwg@momjian.us  

commit   : f79ee34702d485fb30427816b95e6c944660fc23    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Thu, 18 May 2023 21:44:22 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Thu, 18 May 2023 21:44:22 -0400    

Reported-by: Peter Geoghegan  

commit   : 428c0cae929b7d2b26a830fbba55619c57ceba55    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Fri, 19 May 2023 01:53:30 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Fri, 19 May 2023 01:53:30 +0200    

Commit 3581cbdcd6 added a flag to identify empty BRIN ranges. This adds  
the new flag to brin_page_items() output.  
  
This is kept as a separate commit as it should not be backpatched.  
  
Reviewed-by: Justin Pryzby, Matthias van de Meent, Alvaro Herrera  
Discussion: https://postgr.es/m/402430e4-7d9d-6cf1-09ef-464d80afff3b@enterprisedb.com  

commit   : 3581cbdcd64f5aceb445f60df23141d08ed50617    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Fri, 19 May 2023 00:00:22 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Fri, 19 May 2023 00:00:22 +0200    

BRIN indexes did not properly distinguish between summaries for empty  
(no rows) and all-NULL ranges, treating them as essentially the same  
thing. Summaries were initialized with allnulls=true, and opclasses  
simply reset allnulls to false when processing the first non-NULL value.  
This however produces incorrect results if the range starts with a NULL  
value (or a sequence of NULL values), in which case we forget the range  
contains NULL values when adding the first non-NULL value.  
  
This happens because the allnulls flag is used for two separate  
purposes - to mark empty ranges (not representing any rows yet) and  
ranges containing only NULL values.  
  
Opclasses don't know which of these cases it is, and so don't know  
whether to set hasnulls=true. Setting the flag in both cases would make  
it correct, but it would also make BRIN indexes useless for queries with  
IS NULL clauses. All ranges start empty (and thus allnulls=true), so all  
ranges would end up with either allnulls=true or hasnulls=true.  
  
The severity of the issue is somewhat reduced by the fact that it only  
happens when adding values to an existing summary with allnulls=true.  
This can happen e.g. for small tables (because a summary for the first  
range exists for all BRIN indexes), or for tables with large fraction of  
NULL values in the indexed columns.  
  
Bulk summarization (e.g. during CREATE INDEX or automatic summarization)  
that processes all values at once is not affected by this issue. In this  
case the flags were updated in a slightly different way, not forgetting  
the NULL values.  
  
To identify empty ranges we use a new flag, stored in an unused bit in  
the BRIN tuple header so the on-disk format remains the same. A matching  
flag is added to BrinMemTuple, into a 3B gap after bt_placeholder.  
That means there's no risk of ABI breakage, although we don't actually  
pass the BrinMemTuple to any public API.  
  
We could also skip storing index tuples for empty summaries, but then  
we'd have to always process such ranges - even if there are no rows in  
large parts of the table (e.g. after a bulk DELETE), it would still  
require reading the pages etc. So we store them, but ignore them when  
building the bitmap.  
  
Backpatch to 11. The issue exists since BRIN indexes were introduced in  
9.5, but older releases are already EOL.  
  
Backpatch-through: 11  
Reviewed-by: Justin Pryzby, Matthias van de Meent, Alvaro Herrera  
Discussion: https://postgr.es/m/402430e4-7d9d-6cf1-09ef-464d80afff3b@enterprisedb.com  

commit   : 1158c8c4e350b92ad6fecae894c8c1c777495954    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Thu, 18 May 2023 18:53:28 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Thu, 18 May 2023 18:53:28 -0400    

Reported-by: Peter Geoghegan  

commit   : 07ef30a0282064f688a1923ba5e7c850f2ff5776    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Thu, 18 May 2023 18:25:21 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Thu, 18 May 2023 18:25:21 -0400    

Reported-by: Jonathan Katz  

commit   : d8a81108a87bd5e8e9ca136d3195e146a58b9e4d    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Thu, 18 May 2023 17:42:47 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Thu, 18 May 2023 17:42:47 -0400    

commit   : 3ec8a3bfb5472ecf93aba416e9f384ea16d340d1    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Thu, 18 May 2023 13:00:31 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Thu, 18 May 2023 13:00:31 +0200    

When merging BRIN summaries, union_tuples() did not correctly update the  
target hasnulls/allnulls flags. When merging all-NULL summary into a  
summary without any NULL values, the result had both flags set to false  
(instead of having hasnulls=true).  
  
This happened because the code only considered the hasnulls flags,  
ignoring the possibility the source summary has allnulls=true.  
  
Discovered while investigating issues with handling empty BRIN ranges  
and handling of NULL values, but it's a separate problem (has nothing to  
do with empty ranges).  
  
Fixed by considering both flags on the source summary, and updating the  
hasnulls flag on the target summary.  
  
Backpatch to 11. The bug exists since 9.5 (where BRIN indexes were  
introduced), but those releases are EOL already.  
  
Discussion: https://postgr.es/m/9d993d0d-e431-2196-9ccc-0554d0e60154%40enterprisedb.com  

commit   : 0791930aaaed2678daf694fa8b06cf81cd72cd69    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Thu, 18 May 2023 16:33:05 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Thu, 18 May 2023 16:33:05 -0400    

commit   : 206a67e27fa15d75bd7b9ddf41d7e18d19bbb9db    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Thu, 18 May 2023 16:00:04 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Thu, 18 May 2023 16:00:04 -0400    

commit   : c9dc480a21f2746f5a96a8f68a22e633ba69c405    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Thu, 18 May 2023 11:04:30 -0700    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Thu, 18 May 2023 11:04:30 -0700    

commit   : 1e16af8ab5d7f307b66e496eff6ec573d9fd8eb0    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Thu, 18 May 2023 10:37:55 -0700    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Thu, 18 May 2023 10:37:55 -0700    

Separate the documentation for language tags themselves from the  
available collation settings which can be included in a language tag.  
  
Include tables of the available options, more details about the  
effects of each option, and additional examples.  
  
Also include an explanation of the "levels" of textual features and  
how they relate to collation.  
  
Discussion: https://postgr.es/m/25787ec7-4c04-9a8a-d241-4dc9be0b1ba3@postgresql.org  
Reviewed-by: Jonathan S. Katz  

commit   : 8a2523ff354077180084b43a04be01f10aafdb8c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 18 May 2023 10:39:16 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 18 May 2023 10:39:16 -0400    

Pass it the RestrictInfo under consideration, not just the  
clause_relids.  This should save some trivial amount of  
code at the call sites, and it gives us more flexibility  
about what clause_is_computable_at() does.  There's no  
actual functional change here, though.  
  
Discussion: https://postgr.es/m/3564467.1684352557@sss.pgh.pa.us  

commit   : 1c634f6647c28354258d114041252475325aea32    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Wed, 17 May 2023 13:43:41 -0700    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Wed, 17 May 2023 13:43:41 -0700    

Fixes memory error in cases where the length of the language name  
returned by uloc_getLanguage() is exactly ULOC_LANG_CAPACITY, in which  
case the status is set to U_STRING_NOT_TERMINATED_WARNING.  
  
Also check in call sites for other ICU functions that are expected to  
return a C string to be safe (no bug is known at these other call  
sites).  
  
Reported-by: Alexander Lakhin  
Discussion: https://postgr.es/m/2098874d-c111-41e4-9063-30bcf135226b@gmail.com  

commit   : 6de31ce446e59a1f947c7ebe4e4bbe7ca2b842bc    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Wed, 17 May 2023 13:18:40 -0700    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Wed, 17 May 2023 13:18:40 -0700    

Discussion: https://postgr.es/m/daa9f060aa2349ebc84444515efece49e7b32c5d.camel@j-davis.com  

commit   : 009bd237bf6db64ea1131df71f19a529b119fbef    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 17 May 2023 21:33:13 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 17 May 2023 21:33:13 +0200    

The original patch for percentrepl.c c96de2ce17 adopted the error  
messages from basebackup_to_shell, but that uses terminology that  
doesn't really fit with the new API naming.  

commit   : 093e5c57d506783a95dd8feddd9a3f2651e1aeba    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Wed, 17 May 2023 11:18:35 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Wed, 17 May 2023 11:18:35 -0700    

28e626bde00 added the concept of IOOps but neglected to include writeback  
operations. ac8d53dae5 added time spent doing these I/O operations. Without  
counting writeback, checkpointer write time in the log often differed  
substantially from that in pg_stat_io. To fix this, add IOOp IOOP_WRITEBACK  
and track writeback in pg_stat_io.  
  
Bumps catversion.  
  
Author: Melanie Plageman <melanieplageman@gmail.com>  
Reviewed-by: Kyotaro Horiguchi <horikyota.ntt@gmail.com>  
Reported-by: Andres Freund <andres@anarazel.de>  
Discussion: https://postgr.es/m/20230419172326.dhgyo4wrrhulovt6%40awork3.anarazel.de  

commit   : 52676dc2e016df5cd842a4f6073b25ee8e681b9f    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Wed, 17 May 2023 11:17:12 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Wed, 17 May 2023 11:17:12 -0700    

For clarity of review, renaming the function parameter "context" in  
ScheduleBufferTagForWriteback() and IssuePendingWritebacks() to  
"wb_context" is a separate commit. The next commit adds an "io_context"  
parameter and "wb_context" makes it more clear which is which.  
  
Author: Melanie Plageman <melanieplageman@gmail.com>  
Discussion: https://postgr.es/m/CAAKRu_acc6iL4M3hvOTeztf_ZPpsB3Pqio5aVHgZ5q=Pi3BZKg@mail.gmail.com  

commit   : 322875597c0c15cd85d03c8621038f4945c8caa3    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Wed, 17 May 2023 11:17:02 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Wed, 17 May 2023 11:17:02 -0700    

Using the minimum BUFFER_USAGE_LIMIT value, we can make one of the pg_stat_io  
test tables smaller while still causing reuses.  
  
Author: Melanie Plageman <melanieplageman@gmail.com>  
Discussion: https://postgr.es/m/CAAKRu_acc6iL4M3hvOTeztf_ZPpsB3Pqio5aVHgZ5q=Pi3BZKg@mail.gmail.com  

commit   : b9a7a822723aebb16cbe7e5fb874e5124745b07e    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Wed, 17 May 2023 20:06:50 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Wed, 17 May 2023 20:06:50 +0300    

This reverts commit 096dd80f3ccc and its fixups beecbe8e5001, afdd9f7f0e00,  
529da086ba, db93e739ac61.  
  
Catversion is bumped.  
  
Discussion: https://postgr.es/m/d46f9265-ff3c-6743-2278-6772598233c2%40pgmasters.net  

commit   : 58dc80acc5ebf12223be90db1a97dc0b31ca4e1f    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 17 May 2023 19:13:08 +0200    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 17 May 2023 19:13:08 +0200    

Remove spurious semicolon from one error message, and print the  
offending value of a parameter reported as invalid in another.  

commit   : 98bd4c72fd6c4f9d6a2b3b449cb89f335116ab5a    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 17 May 2023 18:55:51 +0200    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 17 May 2023 18:55:51 +0200    

Other callers of that function do things this way, but this one didn't  
get the memo.  

commit   : 69c430626b5eb44825a12e8bc90a59a90c4f5a03    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 17 May 2023 11:46:15 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 17 May 2023 11:46:15 -0400    

Oversight in commit 867be9c07 (which should get reverted  
along with that, if we ever do revert it).  Per buildfarm.  

commit   : 9df8f903eb6758be5a19e66cdf77e922e9329c31    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 17 May 2023 11:13:52 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 17 May 2023 11:13:52 -0400    

After applying outer-join identity 3 in the forward direction,  
it was possible for the planner to mistakenly apply a qual clause  
from above the two outer joins at the now-lower join level.  
This can give the wrong answer, since a value that would get nulled  
by the now-upper join might not yet be null.  
  
To fix, when we perform such a transformation, consider that the  
now-lower join hasn't really completed the outer join it's nominally  
responsible for and thus its relid set should not include that OJ's  
relid (nor should its output Vars have that nullingrel bit set).  
Instead we add those bits when the now-upper join is performed.  
The existing rules for qual placement then suffice to prevent  
higher qual clauses from dropping below the now-upper join.  
There are a few complications from needing to consider transitive  
closures in case multiple pushdowns have happened, but all in all  
it's not a very complex patch.  
  
This is all new logic (from 2489d76c4) so no need to back-patch.  
The added test cases all have the same results as in v15.  
  
Tom Lane and Richard Guo  
  
Discussion: https://postgr.es/m/0b819232-4b50-f245-1c7d-c8c61bf41827@postgrespro.ru  

commit   : 867be9c0738bef591544d39985f886b7d8e99bf0    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 17 May 2023 10:50:35 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 17 May 2023 10:50:35 -0400    

It seems like the code that these checks are backstopping may have  
a few bugs left in it.  Use a test-and-elog so that the tests are  
performed even in non-assert builds, and so that we get something  
more informative than "server closed the connection" on failure.  
  
Committed separately with the idea that eventually we'll revert  
this.  It might be awhile though.  
  
Discussion: https://postgr.es/m/3014965.1684293045@sss.pgh.pa.us  

commit   : 1a05c1d252993b0a59c58a6daf91a2df9333044f    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Wed, 17 May 2023 16:49:31 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Wed, 17 May 2023 16:49:31 +0200    

LZ4File_write() did not advance the input pointer on subsequent invocations of  
LZ4F_compressUpdate(). As a result the generated compressed output would be a  
compressed version of the same input chunk.  
  
Tests failed to catch this error because the data would comfortably fit  
within the default buffer size, as a single chunk. Tests have been added  
to provide adequate coverage of multi-chunk compression.  
  
WriteDataToArchiveLZ4() which is also using LZ4F_compressUpdate() did  
not suffer from this omission.  
  
Author: Georgios Kokolatos <gkokolatos@pm.me>  
Reported-by: Michael Paquier <michael@paquier.xyz>  
Discussion: https://postgr.es/m/ZFhCyn4Gm2eu60rB%40paquier.xyz  

commit   : 3c18d90f8907e53c3021fca13ad046133c480e4d    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Wed, 17 May 2023 16:35:17 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Wed, 17 May 2023 16:35:17 +0200    

LZ4Stream_gets did not null-terminate its output buffer. The callers expected  
the buffer to be null-terminated and passed it around to functions such as  
sscanf with unintended consequences.  
  
Author: Georgios Kokolatos <gkokolatos@pm.me>  
Reported-by: Alexander Lakhin <exclusion@gmail.com>  
Discussion: https://postgr.es/m/94ae9bca-5ebb-1e68-bb7b-4f32e89fefbe@gmail.com  

commit   : d8c3106bb60e4f87be595f241e173ba3c2b7aa2c    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 17 May 2023 10:19:17 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 17 May 2023 10:19:17 +0900    

This is equivalent to a revert of f193883 and fb32748, with the addition  
that the declaration of the SQLValueFunction node needs to gain a couple  
of node_attr for query jumbling.  The performance impact of removing the  
function call inlining is proving to be too huge for some workloads  
where these are used.  A worst-case test case of involving only simple  
SELECT queries with a SQL keyword is proving to lead to a reduction of  
10% in TPS via pgbench and prepared queries on a high-end machine.  
  
None of the tests I ran back for this set of changes saw such a huge  
gap, but Alexander Lakhin and Andres Freund have found that this can be  
noticeable.  Keeping the older performance would mean to do more  
inlining in the executor when using COERCE_SQL_SYNTAX for a function  
expression, similarly to what SQLValueFunction does.  This requires more  
redesign work and there is little time until 16beta1 is released, so for  
now reverting the change is the best way forward, bringing back the  
previous performance.  
  
Bump catalog version.  
  
Reported-by: Alexander Lakhin  
Discussion: https://postgr.es/m/b32bed1b-0746-9b20-1472-4bdc9ca66d52@gmail.com  

commit   : 1d369c9e90f311ec98b07a259cac48c404c773d5    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 16 May 2023 10:53:42 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 16 May 2023 10:53:42 -0400    

fuzzystrmatch's difference() function assumes that _soundex()  
always initializes its output buffer fully.  This was not so for  
the case of a string containing no alphabetic characters, resulting  
in unstable output and Valgrind complaints.  
  
Fix by using memset() to fill the whole buffer in the early-exit  
case.  Also make some cosmetic improvements (I didn't care for the  
random switches between "instr[0]" and "*instr" notation).  
  
Report and diagnosis by Alexander Lakhin (bug #17935).  
Back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/17935-b99316aa79c18513@postgresql.org  

commit   : 27debd05dcbdfe3db487ba82568f7f9ae25ddde2    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 16 May 2023 11:50:08 +0200    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 16 May 2023 11:50:08 +0200    

Move a variable name out of the translatable message, to make it  
identical to others.  

commit   : c44b59fad453fd4be9656d58dd5f51a11149c961    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 16 May 2023 11:47:25 +0200    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 16 May 2023 11:47:25 +0200    

The problem that these messages protect against can only occur because  
a corrupted hash spill file was written, i.e., a Postgres bug.  There's  
no reason to have them as translatable.  
  
Backpatch to 15, where these messages were changed by commit c4649cce39a4.  
  
Reviewed-by: Daniel Gustafsson <daniel@yesql.se>  
Discussion: https://postgr.es/m/20230510175407.dwa5v477pw62ikyx@alvherre.pgsql  

commit   : 8cb94344c3c7130a0cd5e21e83705739f552187e    
  
author   : Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Tue, 16 May 2023 10:49:48 +0200    
  
committer: Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Tue, 16 May 2023 10:49:48 +0200    

Commit 558fff0adf got the order of the parameters to test_status_failed  
mixed up which resulted in the runtime being reported as 0 ms.  Fix by  
changing the order to the correct one.  No backpatching is needed since  
this has not been shipped in a release yet.  
  
Discussion: https://postgr.es/m/0134C9EC-5F6B-4EAC-B2D5-BB4249BEBD4D@yesql.se  

commit   : 44e977d7ecb915d1181007e700f2da31acb6ea4c    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 16 May 2023 16:51:44 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 16 May 2023 16:51:44 +0900    

Issue spotted while reviewing a different patch touching this area.  
  
Discussion: https://postgr.es/m/ZGM1U5D5EuBUbasi@paquier.xyz  

commit   : c91f3560835f76bd8c9f614bebaa8c634b98b451    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 16 May 2023 08:59:34 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 16 May 2023 08:59:34 +0200    

commit   : 489b5409e4a0fa36c951561bae8ae4394e7d623f    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 16 May 2023 06:13:59 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 16 May 2023 06:13:59 +0200    

for consistency with surrounding headings  

commit   : 08c45ae235660844167de8730da908d351f4352d    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 15 May 2023 16:02:07 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 15 May 2023 16:02:07 +0900    

References to SDK 8.1a should have been cleaned up in 495ed0e, as only  
version 10 and above are supported with Windows 10 and newer versions.  
  
Reported-by: Thomas Munro  
Discussion: https://postgr.es/m/CA+hUKG++qE9uVjQaTTD7oaC8a2T3h8K50=Eqyx9uUZvOHa__ww@mail.gmail.com  

commit   : 92155e15d3cfe97758552484acb1583aaf71cda6    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 15 May 2023 07:07:09 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 15 May 2023 07:07:09 +0200    

Using a test function before a possible skip_all is incorrect.  If the  
skip_all is called, the test output will become incorrect and the test  
file will fail.  
  
a4f23f9b3c introduced a new test before skip_all.  After discussion,  
this doesn't really need to be a test.  Instead, we just bail out if  
the condition is not satisfied.  
  
Discussion: https://www.postgresql.org/message-id/af5567a1-aea6-fbdb-7e4b-d1e23a43c43b@enterprisedb.com  

commit   : 1d70fb400c2c8312dac3ff19a1bb1cb5351047ce    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 15 May 2023 06:27:40 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 15 May 2023 06:27:40 +0200    

commit   : 63932a6d38e5dfa6df2a51a04b7314ec1e4d3de7    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Mon, 15 May 2023 10:45:19 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Mon, 15 May 2023 10:45:19 +1200    

Commit a73952b7956 (new in 16) required default values in guc_table.c  
and C variable initializers to match.  This one only matched when  
XLOG_BLCKSZ == 8kB.  Fix by using the same expression in both places  
with a new DEFAULT_XXX macro, as done for other GUCs.  
  
Reviewed-by: Andres Freund <andres@anarazel.de>  
Discussion: https://postgr.es/m/CA+hUKGLNmLV=VrT==5MqnbARgx2ifRSFtdd8ofdfrdSLL3yv5A@mail.gmail.com  

commit   : 319bae9a8da66678d80d862440e54cebc7b1cc24    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Mon, 15 May 2023 10:31:14 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Mon, 15 May 2023 10:31:14 +1200    

Give the new GUC introduced by d4e71df6 a name that is clearly not  
intended for mainstream use quite yet.  
  
Future proposals would drop the prefix only after adding infrastructure  
to make it efficient.  Having the switch in the tree sooner is good  
because it might lead to new discoveries about the hazards awaiting us  
on a wide range of systems, but that name was too enticing and could  
lead to cross-version confusion in future, per complaints from Noah and  
Justin.  
  
Suggested-by: Noah Misch <noah@leadboat.com>  
Reviewed-by: Noah Misch <noah@leadboat.com>  
Reviewed-by: Justin Pryzby <pryzby@telsasoft.com> (the idea, not the patch)  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> (ditto)  
Discussion: https://postgr.es/m/20230430041106.GA2268796%40rfd.leadboat.com  

commit   : 4d5105a684ba20bf6a98e6ae48224fe93382c040    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Fri, 12 May 2023 13:50:46 -0700    
  
committer: Nathan Bossart <nathan@postgresql.org>    
date     : Fri, 12 May 2023 13:50:46 -0700    

c3afe8cf5a updated this error message, but it didn't use the new  
style established in de4d456b40.  
  
Reviewed-by: Tom Lane  
Discussion: https://postgr.es/m/20230512203721.GA2644063%40nathanxps13.home  

commit   : 51b2c08798867cb9788090704b37c4698b456240    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 12 May 2023 16:11:14 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 12 May 2023 16:11:14 -0400    

Don't use PSQL_WATCH_PAGER when stdin/stdout are not a terminal.  
This corresponds to the restrictions on when other commands will  
use [PSQL_]PAGER.  There isn't a lot of sense in trying to use a  
pager in non-interactive cases, and doing so allows an environment  
setting to break our tests.  
  
Also, ignore PSQL_WATCH_PAGER if it is set but empty or all-blank,  
for the same reasons we ignore such settings of [PSQL_]PAGER (see  
commit 18f8f784c).  
  
No documentation change is really needed, since there is nothing  
suggesting that these constraints on [PSQL_]PAGER didn't already  
apply to PSQL_WATCH_PAGER too.  But I rearranged the text  
a little to make it read more naturally (IMHO anyway).  
  
Per report from Pavel Stehule.  Back-patch to v15 where  
PSQL_WATCH_PAGER was introduced.  
  
Discussion: https://postgr.es/m/CAFj8pRDTwFzmEWdA-gdAcUh0ZnxUioSfTMre71WyB_wNJy-8gw@mail.gmail.com  

commit   : e32701b8d285cd402f75fc9059d083e89ee8166b    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 12 May 2023 09:45:50 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 12 May 2023 09:45:50 +0200    

Since the behavior of the UNICODE collation can change with new  
ICU/Unicode versions, we need to apply the versioning mechanism to it.  
We do this with an UPDATE command in initdb; this is similar to how we  
put the collation version into pg_database already.  
  
Reported-by: Daniel Verite <daniel@manitou-mail.org>  
Discussion: https://www.postgresql.org/message-id/49417853-7bdd-4b23-a4e9-04c7aff33821@manitou-mail.org  

commit   : c8b881d21fd8e0214bc43280d6231cc2c6ef55ef    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 11 May 2023 13:44:25 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 11 May 2023 13:44:25 -0400    

I've had a bee in my bonnet for some time about getting rid of  
RestrictInfo.is_pushed_down, because it's squishily defined and  
requires not-inexpensive extra tests to use (cf RINFO_IS_PUSHED_DOWN).  
In commit 2489d76c4, I tried to make remove_rel_from_query() not  
depend on that macro; but the replacement test is buggy,  
as exposed by a report from Rushabh Lathia and Robert Haas.  
That change was pretty incidental to the main goal of 2489d76c4,  
so let's just revert it for now.  (Getting rid of is_pushed_down  
is still far away, anyway.)  
  
Discussion: https://postgr.es/m/CA+TgmoYco=hmg+iX1CW9Y1_CzNoSL81J03wUG-d2_3=rue+L2A@mail.gmail.com  

commit   : 375407f4940ba0922513666f00852c54943eb1a0    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Wed, 10 May 2023 10:49:50 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Wed, 10 May 2023 10:49:50 -0700    

Fix a link from the "Heap-Only Tuples" documentation section.  
Previously, its "fillfactor" link pointed to the "CREATE TABLE"  
command's documentation.  Now the link directly points to the fillfactor  
storage parameter documentation (which is about half way into the  
"CREATE TABLE" sect1).  
  
Oversight in commit 115464bb.  
  
Backpatch: 12-, the first version with a usable reloption link.  

commit   : c39f2f68e95a54e430c6a7b7d1e9f98cedff5aff    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 10 May 2023 18:26:10 +0200    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 10 May 2023 18:26:10 +0200    

There was some odd wording in corner-case gram.y error messages "some  
error ... at or near", which appears to have been modeled after "syntax  
error" messages.  However, they don't work that way, and they're just  
wrong.  They're also uncovered by tests.  Remove the trailing words,  
and also add tests.  
  
They were introduced with 5a2832465fd8; backpatch to 15.  
  
Author: Álvaro Herrera <alvherre@alvh.no-ip.org>  

commit   : d8bcce1b5e99d8f6f12cb7a94190fdc5622355af    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 10 May 2023 13:51:51 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 10 May 2023 13:51:51 +0200    

due to the changes in commit dac048f71e  

commit   : 605994651b6a4209b418cb09d3c223ca269f7cfc    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 10 May 2023 11:24:30 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 10 May 2023 11:24:30 +0900    

An update of the GUC stats_fetch_consistency in a transaction would be  
able to trigger an assertion when doing cache->snapshot.  In this case,  
when retrieving a pgstat entry after the switch, a new snapshot would be  
rebuilt, confusing pgstat_build_snapshot() because a snapshot is already  
cached with an unexpected mode ("cache").  
  
In order to fix this problem, this commit adds a flag to force a  
snapshot clear each time this GUC is changed.  Some tests are added to  
check, while on it.  
  
Some optimizations in avoiding the snapshot clear should be possible  
depending on what is cached and the current GUC value, I guess, but this  
solution is simple, and ensures that the state of the cache is updated  
each time a new pgstat entry is fetched, hence being consistent with the  
level wanted by the client that has set the GUC.  
  
Note that cache->none and snapshot->none would not cause issues, as  
fetching a pgstat entry would be retrieved from shared memory on the  
second attempt, however a snapshot would still be cached.  Similarly,  
none->snapshot and none->cache would build a new snapshot on the second  
fetch attempt.  Finally, snapshot->cache would cache a new snapshot on  
the second attempt.  
  
Reported-by: Alexander Lakhin  
Author: Kyotaro Horiguchi  
Discussion: https://postgr.es/m/17804-2a118cd046f2d0e5@postgresql.org  
backpatch-through: 15  

commit   : 4d47eff99cc08255f0ae3cc27dc24cc9b30a32e7    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 10 May 2023 10:19:57 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 10 May 2023 10:19:57 +0900    

Issue noted while looking at a patch related to that.  
  
Discussion: https://postgr.es/m/ZE9LiFc7JdNHokz/@paquier.xyz  

commit   : c5b7f67fcc8c4a01c82660eb0996a3c697fac283    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Tue, 9 May 2023 14:25:33 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Tue, 9 May 2023 14:25:33 +0530    

The commit a6e04b1d20 added a test to ensure that the invalidated logical  
slots don't retain WAL. The test was ensuring that the checkpoint removes  
the WAL files corresponding to invalidated logical slots on the standby  
node but missed the point that the standby node also had a physical slot  
which led to the prevention of WAL file removal. Move the creation of  
physical slot on the standby and initialization of cascading standby closer  
to the test case that actually required it so that other tests don't get  
affected by the presence of the physical slot on standby.  
  
Author: Bertrand Drouvot  
Reviewed-by: Amit Kapila  
Discussion: https://postgr.es/m/2fefa454-5a70-2174-ddbf-4a0e41537139@gmail.com  

commit   : 3d144c6c86025272e1711539f5fafb6fb85c4feb    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Tue, 9 May 2023 09:28:06 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Tue, 9 May 2023 09:28:06 +0530    

The callback function pa_shutdown() accesses MyLogicalRepWorker which may  
not be initialized if there is an error during the initialization of the  
parallel apply worker. The other problem is that by the time it is invoked  
even after the initialization of the worker, the MyLogicalRepWorker will  
be reset by another callback logicalrep_worker_onexit. So, it won't have  
the required information.  
  
To fix this, register the shutdown callback after we are attached to the  
worker slot.  
  
After this fix, we observed another issue which is that sometimes the  
leader apply worker tries to receive the message from the error queue that  
might already be detached by the parallel apply worker leading to an  
error. To prevent such an error, we ensure that the leader apply worker  
detaches from the parallel apply worker's error queue before stopping it.  
  
Reported-by: Sawada Masahiko  
Author: Hou Zhijie  
Reviewed-by: Sawada Masahiko, Amit Kapila  
Discussion: https://postgr.es/m/CAD21AoDo+yUwNq6nTrvE2h9bB2vZfcag=jxWc7QxuWCmkDAqcA@mail.gmail.com  

commit   : 455f948b0d03a556533a7e4a1a8abf45f0eb202e    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Mon, 8 May 2023 20:50:51 -0700    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Mon, 8 May 2023 20:50:51 -0700    

This reverts commit f7faa9976cc0504c027a20ed66ceca9018041dd4.  
  
Discussion: https://postgr.es/m/483826.1683582475@sss.pgh.pa.us  

commit   : 5698f07947396e1a7cd6564390306aafa26fc189    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 8 May 2023 13:17:31 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 8 May 2023 13:17:31 -0700    

Commit 1de58df4, which added page-level freezing, taught VACUUM to reuse  
each page's "set-visibility-map" snapshotConflictHorizon for freezing  
(at least in the vast majority of cases where freezing went ahead).  
This made VACUUM FREEZE much less prone to generating recovery conflicts  
on standbys; VACUUM FREEZE became only slightly more likely to cause  
recovery conflicts than an equivalent VACUUM.  
  
Update old documentation that specifically warned of the likelihood of  
recovery conflicts from VACUUM FREEZE.  Explain the same general issue  
(the issue of VACUUM generating recovery conflicts even in the absence  
of dead row cleanup) using the example of conflicts caused by VISIBLE  
WAL records.  

commit   : f7faa9976cc0504c027a20ed66ceca9018041dd4    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Mon, 8 May 2023 10:34:51 -0700    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Mon, 8 May 2023 10:34:51 -0700    

The conversion was intended to be for convenience, but it's more  
likely to be confusing than useful.  
  
The user can still directly specify 'en-US-u-va-posix' if desired.  
  
Discussion: https://postgr.es/m/f83f089ee1e9acd5dbbbf3353294d24e1f196e95.camel@j-davis.com  
Discussion: https://postgr.es/m/37520ec1ae9591f83132f82dbd625f3fc2d69c16.camel@j-davis.com  

commit   : 8d525d7b9545884a3e0d79adcd61543f9ae2ae28    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 8 May 2023 11:24:47 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 8 May 2023 11:24:47 -0400    

Security: CVE-2023-2454  

commit   : ca73753b090c33bc69ce299b4d7fff891a77b8ad    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 8 May 2023 10:12:44 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 8 May 2023 10:12:44 -0400    

If an SRF in the FROM clause references a table having row-level  
security policies, and we inline that SRF into the calling query,  
we neglected to mark the plan as potentially dependent on which  
role is executing it.  This could lead to later executions in the  
same session returning or hiding rows that should have been hidden  
or returned instead.  
  
Our thanks to Wolfgang Walther for reporting this problem.  
  
Stephen Frost and Tom Lane  
  
Security: CVE-2023-2455  

commit   : 681d9e4621aac0a9c71364b6f54f00f6d8c4337f    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Mon, 8 May 2023 06:14:07 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 8 May 2023 06:14:07 -0700    

The two methods don't cooperate, so set_config_option("search_path",  
...) has been ineffective under non-empty overrideStack.  This defect  
enabled an attacker having database-level CREATE privilege to execute  
arbitrary code as the bootstrap superuser.  While that particular attack  
requires v13+ for the trusted extension attribute, other attacks are  
feasible in all supported versions.  
  
Standardize on the combination of NewGUCNestLevel() and  
set_config_option("search_path", ...).  It is newer than  
PushOverrideSearchPath(), more-prevalent, and has no known  
disadvantages.  The "override" mechanism remains for now, for  
compatibility with out-of-tree code.  Users should update such code,  
which likely suffers from the same sort of vulnerability closed here.  
Back-patch to v11 (all supported versions).  
  
Alexander Lakhin.  Reported by Alexander Lakhin.  
  
Security: CVE-2023-2454  

commit   : b8c3f6df85e78e09c9709fc895aced719aebd7f9    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 8 May 2023 08:24:42 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 8 May 2023 08:24:42 +0200    

commit   : 9f9abfeb10026bc2c2ac7076c6adff201608eab5    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 8 May 2023 07:43:54 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 8 May 2023 07:43:54 +0200    

The refactoring in 03d02f54a6 lost a translation marker.  

commit   : 0890f7d528c45bcfef7d3edd5618e121f0357250    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 8 May 2023 13:47:36 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 8 May 2023 13:47:36 +0900    

Author: Peter Smith  
Reviewed-by: David Zhang  
Discussion: https://postgr.es/m/CAHut+Pst11ac2hcmePt1=oTmBwTT=DAssRR1nsdoy4BT+68=Mg@mail.gmail.com  

commit   : 90f0d2881445a266038d349073e571f06def656b    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 8 May 2023 06:15:26 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 8 May 2023 06:15:26 +0200    

The refactoring in ebfb814f7c lost some translation markers.  

commit   : 41e2c52fd6ebed6eff4184f68048813cc8886ec1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 7 May 2023 11:01:15 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 7 May 2023 11:01:15 -0400    

This was overlooked when MERGE was added, but it's essential  
support for MERGE in new-style SQL functions.  
  
Alvaro Herrera  
  
Discussion: https://postgr.es/m/3579737.1683293801@sss.pgh.pa.us  

commit   : 58f5edf849900bc248b7c909ca17da7287306c41    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 5 May 2023 21:25:44 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 5 May 2023 21:25:44 +0900    

This wait event was documented as "CommitTsBuffer" since its  
introduction, but the code named it "CommitTSBuffer".  This commit fixes  
the code to follow the term documented, which is also more consistent  
with the naming of the other wait events used for commit timestamps.  
  
Introduced by 5da1493.  
  
Author: Alexander Lakhin  
Discussion: https://postgr.es/m/e8c38840-596a-83d6-bd8d-cebc51111572@gmail.com  
Backpatch-through: 13  

commit   : 95f5a7a42c048ec01ba2650496296fe88aacd50f    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 5 May 2023 11:10:25 +0200    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 5 May 2023 11:10:25 +0200    

Commit f75cec4fff87 changed the order in which the relations are  
permission-checked in RI_Initial_Check, which the sepgsql test is  
sensitive to.  Adapt.  
  
Discussion: https://postgr.es/m/3468125.1683238309@sss.pgh.pa.us  

commit   : b1c4ed2f02b0c4cf1942e6eb2995bdbf8db5cccf    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 5 May 2023 07:50:08 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 5 May 2023 07:50:08 +0200    

from 2fe3bdbd69  

commit   : 5d42a97519581a31bdc1d3d4cf10c07ae18b8296    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 5 May 2023 06:29:49 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 5 May 2023 06:29:49 +0200    

Commit 153e215677 added the portlock directory.  This is created in  
$ENV{top_builddir} if it is set.  Under PGXS, top_builddir points into  
the installation directory, which is not necessarily writable and in  
any case inappropriate to use by a test suite.  The cause of the  
problem is that the prove_installcheck target in Makefile.global  
exports top_builddir, which isn't useful (since no other Perl code  
actually reads it) and breaks this use case.  The reason this code is  
there is probably that is has been dragged around with various other  
changes, in particular a0fc813266, but without a real purpose of its  
own.  By just removing the exporting of top_builddir in  
prove_installcheck, the portlock directory then ends up under  
tmp_check in the build directory, which is more suitable.  
  
Reviewed-by: Andrew Dunstan <andrew@dunslane.net>  
Discussion: https://www.postgresql.org/message-id/78d1cfa6-0065-865d-584b-cde6d8c18aff@enterprisedb.com  

commit   : 57d0051706b897048063acc14c2c3454200c488f    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Wed, 3 May 2023 11:32:43 -0700    
  
committer: Nathan Bossart <nathan@postgresql.org>    
date     : Wed, 3 May 2023 11:32:43 -0700    

If we exit a PG_TRY block early via "continue", "break", "goto", or  
"return", we'll skip unwinding its exception stack.  This change  
moves a couple of such "return" statements in PL/Python out of  
PG_TRY blocks.  This was introduced in d0aa965c0a and affects all  
supported versions.  
  
We might also be able to add compile-time checks to prevent  
recurrence, but that is left as a future exercise.  
  
Reported-by: Mikhail Gribkov, Xing Guo  
Author: Xing Guo  
Reviewed-by: Michael Paquier, Andres Freund, Tom Lane  
Discussion: https://postgr.es/m/CAMEv5_v5Y%2B-D%3DCO1%2Bqoe16sAmgC4sbbQjz%2BUtcHmB6zcgS%2B5Ew%40mail.gmail.com  
Discussion: https://postgr.es/m/CACpMh%2BCMsGMRKFzFMm3bYTzQmMU5nfEEoEDU2apJcc4hid36AQ%40mail.gmail.com  
Backpatch-through: 11 (all supported versions)  

commit   : f75cec4fff877ef24e4932a628fc974f3116ed16    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 4 May 2023 19:55:56 +0200    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 4 May 2023 19:55:56 +0200    

RI_Initial_Check was setting up a list of RTEPermissionInfo for  
ExecCheckPermissions() wrong, and the problem is subtle enough that it  
doesn't have any immediate effect in core code.  However, if an  
extension is using the ExecutorCheckPerms_hook, then it would get the  
wrong parameters and perhaps arrive at a wrong conclusion, or outright  
malfunction.  Fix by constructing that list and the RTE list more  
honestly.  
  
We also add an assertion check to verify that these lists match.  This  
new assertion would have caught this bug.  
  
Co-authored-by: Олег Целебровский (Oleg Tselebrovskii) <o.tselebrovskiy@postgrespro.ru>  
Co-authored-by: Álvaro Herrera <alvherre@alvh.no-ip.org>  
Reviewed-by: Amit Langote <amitlangote09@gmail.com>  
Discussion: https://postgr.es/m/3722b7a2cbe27a1796ee40824bd86dd1@postgrespro.ru  

commit   : 4c40995f61227c579bd7269a829c00013ac66492    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 4 May 2023 11:48:23 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 4 May 2023 11:48:23 -0400    

These functions incautiously fetched the array's first lower bound  
even when the array is zero-dimensional, thus fetching the word  
after the allocated array space.  While almost always harmless,  
with very bad luck this could result in SIGSEGV.  Fix by adding  
an early exit for empty input.  
  
Per bug #17920 from Alexander Lakhin.  
  
Discussion: https://postgr.es/m/17920-f7c228c627b6d02e%40postgresql.org  

commit   : 0553528e7c2bb9eb4148ff9e3c51b9094ab67f70    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 4 May 2023 11:00:33 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 4 May 2023 11:00:33 -0400    

Like plperl before f47004add, plpython wasn't being sufficiently  
careful about checking that list-of-list structures represent  
rectangular arrays, so that it would accept some cases in which  
different parts of the "array" are nested to different depths.  
This was exacerbated by Python's weak distinction between  
sequences and lists, so that in some cases strings could get  
treated as though they are lists (and burst into individual  
characters) even though a different ordering of the upper-level  
list would give a different result.  
  
Some of this behavior was unreachable (without risking a crash)  
before 81eaaf65e.  It seems like a good idea to clean it all up  
in the same releases, rather than shipping a non-crashing but  
nonetheless visibly buggy behavior in the name of minimal change.  
Hence, back-patch.  
  
Per bug #17912 and further testing by Alexander Lakhin.  
  
Discussion: https://postgr.es/m/17912-82ceed78731d9cdc@postgresql.org  

commit   : 5472743d9e8583638a897b47558066167cc14583    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 4 May 2023 12:09:59 +0200    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 4 May 2023 12:09:59 +0200    

This reverts commit ec386948948c and its fixup 589bb816499e.  
  
This change was intended to support query planning avoiding acquisition  
of locks on partitions that were going to be pruned; however, the  
overall project took a different direction at [1] and this bit is no  
longer needed.  Put things back the way they were as agreed in [2], to  
avoid unnecessary complexity.  
  
Discussion: [1] https://postgr.es/m/4191508.1674157166@sss.pgh.pa.us  
Discussion: [2] https://postgr.es/m/20230502175409.kcoirxczpdha26wt@alvherre.pgsql  

commit   : 919c486a275bcdd83d2add77da87b6edbd91418c    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 4 May 2023 06:44:38 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 4 May 2023 06:44:38 +0200    

Add:  
  
- "Restartpoint"  
- "Log sequence number"  
  
"LSN" was already listed in the Acronyms appendix, but it is more  
suitable as a glossary entry, so move it there and have the acronyms  
entry link into the glossary.  
  
Also turn on DocBook parameter glossentry.show.acronym to show  
acronyms for glossary entries, which is being used here.  
  
Reviewed-by: Daniel Gustafsson <daniel@yesql.se>  
Reviewed-by: Alvaro Herrera <alvherre@alvh.no-ip.org>  
Discussion: https://www.postgresql.org/message-id/flat/60915312-62cd-9c94-0d94-556023ece45f%40enterprisedb.com  

commit   : a6e04b1d20c2e9cece9b64bb5b36ebfdc3a9031b    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Thu, 4 May 2023 08:33:56 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Thu, 4 May 2023 08:33:56 +0530    

Author: Bertrand Drouvot  
Reviewed-by: Shi yu, Amit Kapila, Vignesh C  
Discussion: https://postgr.es/m/2fefa454-5a70-2174-ddbf-4a0e41537139@gmail.com  

commit   : 1ab763fc22adc88e5d779817e7b42b25a9dd7c9e    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 3 May 2023 11:08:24 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 3 May 2023 11:08:24 +0200    

commit   : de63f8dadee4afa152ce177fd3c562d47373a728    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Wed, 3 May 2023 10:13:13 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Wed, 3 May 2023 10:13:13 +0530    

During exit, the logical replication apply worker tries to release session  
level locks, if any. However, if the apply worker exits due to an error  
before its connection is initialized, trying to release locks can lead to  
assertion failure. The locks will be acquired once the worker is  
initialized, so we don't need to release them till the worker  
initialization is complete.  
  
Reported-by: Alexander Lakhin  
Author: Hou Zhijie based on inputs from Sawada Masahiko and Amit Kapila  
Reviewed-by: Amit Kapila  
Discussion: https://postgr.es/m/2185d65f-5aae-3efa-c48f-fb42b173ef5c@gmail.com  

commit   : 6489875ce6b16662142bc70e003437b9753c199f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 2 May 2023 17:55:01 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 2 May 2023 17:55:01 -0400    

plperl, plpython, and pltcl all provide query-execution functions  
that are thin wrappers around SPI_execute() or its variants.  
The SPI functions document their row-count limit arguments clearly,  
as "maximum number of rows to return, or 0 for no limit".  However  
the PLs' documentation failed to explain this special behavior of  
zero, so that a reader might well assume it means "fetch zero  
rows".  Improve that.  
  
Daniel Gustafsson and Tom Lane, per report from Kieran McCusker  
  
Discussion: https://postgr.es/m/CAGgUQ6H6qYScctOhktQ9HLFDDoafBKHyUgJbZ6q_dOApnzNTXg@mail.gmail.com  

commit   : 08237056f84e3a9ed75e8a698428c669f4d35db4    
  
author   : Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Tue, 2 May 2023 13:15:29 +0200    
  
committer: Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Tue, 2 May 2023 13:15:29 +0200    

The <source>_traverse_files functions take a callback for processing  
files, but both the local and libpq source implementations called the  
function directly without using the callback argument. While there is  
no bug right now as the function called is the same as the callback,  
fix by calling the callback to reduce the risk of subtle bugs in the  
future.  
  
Author: Junwang Zhao <zhjwpku@gmail.com>  
Reviewed-by: Richard Guo <guofenglinux@gmail.com>  
Discussion: https://postgr.es/m/CAEG8a3Jdwgh+PZr2zh1=t8apA4Yz8tKq+uubPqoCt14nvWKHEw@mail.gmail.com  

commit   : e0bb5d0c5bcada63dc9b8a1a72a344a07bf930ce    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 2 May 2023 10:59:21 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 2 May 2023 10:59:21 +0200    

Some updates for SQL:2023 and some new features in PostgreSQL 16.  

commit   : 7039c7cff6736780c3bbb41a90a6dfea0f581ad2    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 2 May 2023 09:41:03 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 2 May 2023 09:41:03 +0200    

Commit a4c17c8617 added in the install rule but not the uninstall  
rule.  

commit   : 8961cb9a0315fa23458587b3df547ca8d8e00f85    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 2 May 2023 12:23:08 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 2 May 2023 12:23:08 +0900    

The changes done in this commit impact comments with no direct  
user-visible changes, with fixes for incorrect function, variable or  
structure names.  
  
Author: Alexander Lakhin  
Discussion: https://postgr.es/m/e8c38840-596a-83d6-bd8d-cebc51111572@gmail.com  

commit   : 6fd8ae6888847da842ee4810fcd83b013cbed27f    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 2 May 2023 11:40:46 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 2 May 2023 11:40:46 +0900    

Author: Alexander Lakhin  
Discussion: https://postgr.es/m/e8c38840-596a-83d6-bd8d-cebc51111572@gmail.com  
Backpatch-through: 14  

commit   : f47004add16041a9cbd19aef29775ca4d9d6001e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 29 Apr 2023 13:06:44 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 29 Apr 2023 13:06:44 -0400    

plperl_array_to_datum() wasn't sufficiently careful about checking  
that nested lists represent a rectangular array structure; it would  
accept inputs such as "[1, []]".  This is a bit related to the  
PL/Python bug fixed in commit 81eaaf65e, but it doesn't seem to  
provide any direct route to a memory stomp.  Instead the likely  
failure mode is for makeMdArrayResult to be passed fewer Datums than  
the claimed array dimensionality requires, possibly leading to a wild  
pointer dereference and SIGSEGV.  
  
Per report from Alexander Lakhin.  It's been broken for a long  
time, so back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/5ebae5e4-d401-fadf-8585-ac3eaf53219c@gmail.com  

commit   : 81eaaf65e393d03f49a781009fba876f81fe9d0b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 28 Apr 2023 12:24:29 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 28 Apr 2023 12:24:29 -0400    

If PLySequence_ToArray came across a zero-length sublist, it'd compute  
the overall array size as zero, possibly leading to a memory clobber.  
(This would likely qualify as a security bug, were it not that plpython  
is an untrusted language already.)  
  
I think there are other corner-case issues in this code as well, notably  
that the error messages don't match the core code and for some ranges  
of array sizes you'd get "invalid memory alloc request size" rather than  
the intended message about array size.  
  
Really this code has no business doing its own array size calculation  
at all, so remove the faulty code in favor of using ArrayGetNItems().  
  
Per bug #17912 from Alexander Lakhin.  Bug seems to have come in with  
commit 94aceed31, so back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/17912-82ceed78731d9cdc@postgresql.org  

commit   : 4dadd660f0719206ce3914d4ad9b6aad69d6db6e    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 28 Apr 2023 19:29:12 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 28 Apr 2023 19:29:12 +0900    

CREATE SCHEMA AUTHORIZATION with appended schema elements can lead to  
crashes when comparing the schema name of the query with the schemas  
used in the qualification of some clauses in the elements' queries.  
  
The origin of the problem is that the transformation routine for the  
elements listed in a CREATE SCHEMA query uses as new, expected, schema  
name the one listed in CreateSchemaStmt itself.  However, depending on  
the query, CreateSchemaStmt.schemaname may be NULL, being computed  
instead from the role specification of the query given by the  
AUTHORIZATION clause, that could be either:  
- A user name string, with the new schema name being set to the same  
value as the role given.  
- Guessed from CURRENT_ROLE, SESSION_ROLE or CURRENT_ROLE, with a new  
schema name computed from the security context where CREATE SCHEMA is  
running.  
  
Regression tests are added for CREATE SCHEMA with some appended elements  
(some of them with schema qualifications), covering also some role  
specification patterns.  
  
While on it, this simplifies the context structure used during the  
transformation of the elements listed in a CREATE SCHEMA query by  
removing the fields for the role specification and the role type.  They  
were not used, and for the role specification this could be confusing as  
the schema name may by extracted from that at the beginning of  
CreateSchemaCommand().  
  
This issue exists for a long time, so backpatch down to all the versions  
supported.  
  
Reported-by: Song Hongyu  
Author: Michael Paquier  
Reviewed-by: Richard Guo  
Discussion: https://postgr.es/m/17909-f65c12dfc5f0451d@postgresql.org  
Backpatch-through: 11  

commit   : 4a6603cd4650a335ee38d894d7bbb452b1bf822f    
  
author   : Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Fri, 28 Apr 2023 10:30:05 +0200    
  
committer: Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Fri, 28 Apr 2023 10:30:05 +0200    

Commit 7d71d3dd08 changed resetting the VacuumFailsafeActive flag to an  
assertion since the flag is reset before starting vacuuming a relation.  
This however failed to take recursive calls of vacuum_rel() and vacuum  
of TOAST tables into consideration. Fix by reverting back to resettting  
the flag.  
  
Author: Masahiko Sawada <sawada.mshk@gmail.com>  
Reviewed-by: Melanie Plageman <melanieplageman@gmail.com>  
Reported-by: John Naylor <john.naylor@enterprisedb.com>  
Discussion: https://postgr.es/m/CAFBsxsFz=GqaG5Ens5aNgVYoV2Y+pfMUijX0ku+CCkWfALwiqg@mail.gmail.com  

commit   : b72f564d87d10b5e5a91aedec605e48f80cb74ee    
  
author   : Masahiko Sawada <msawada@postgresql.org>    
date     : Fri, 28 Apr 2023 15:40:12 +0900    
  
committer: Masahiko Sawada <msawada@postgresql.org>    
date     : Fri, 28 Apr 2023 15:40:12 +0900    

Also adjust the indentation of the comment to the surrounding parameters.  
  
Author: Masahiko Sawada  
Reviewed-by: David Rowley, Daniel Gustafsson, Melanie Plageman  
Discussion: https://postgr.es/m/CAD21AoCBSqmqOKVH4Q256DeCC_UE50gu1sgixcjLFZGLEbABVA@mail.gmail.com  

commit   : 4d26d93ff7fbf7bde5710595255ca9c8033a1402    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Fri, 28 Apr 2023 08:45:19 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Fri, 28 Apr 2023 08:45:19 +0530    

The test to ensure that decoding changes via logical slot from another  
database will fail was incorrectly done on the primary node instead of on  
the standby node.  
  
In the passing, make the test to wait for replay catchup by using  
wait_for_replay_catchup(). This will make it consistent with the way we  
wait at other places in the test.  
  
Author: Shi yu  
Reviewed-by: Bertrand Drouvot, Amit Kapila  
Discussion: https://postgr.es/m/OSZPR01MB6310B0A507A0F2A2D379F38CFD6A9@OSZPR01MB6310.jpnprd01.prod.outlook.com  

commit   : b72623671d9c0ead4ac219c69762246073fe2185    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Thu, 27 Apr 2023 13:43:48 -0700    
  
committer: Nathan Bossart <nathan@postgresql.org>    
date     : Thu, 27 Apr 2023 13:43:48 -0700    

The call to XLogGetReplicationSlotMinimumLSN() might return a  
greater LSN than the one given to the function.  Subsequent segment  
number calculations might then underflow, which could result in  
unexpected behavior when removing or recyling WAL files.  This was  
introduced with max_slot_wal_keep_size in c655077639.  To fix, skip  
the block of code for replication slots if the LSN is greater.  
  
Reported-by: Xu Xingwang  
Author: Kyotaro Horiguchi  
Reviewed-by: Junwang Zhao  
Discussion: https://postgr.es/m/17903-4288d439dee856c6%40postgresql.org  
Backpatch-through: 13  

commit   : db93e739ac61332126207b16f14da93f8ecac594    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Thu, 27 Apr 2023 22:06:14 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Thu, 27 Apr 2023 22:06:14 +0300    

The current code unintentionally uses the wrong datum to construct an array.  
The bug was introduced by 096dd80f3c, so no backpatching is needed.  
  
Reported-by: David Steele  
Discussion: https://postgr.es/m/d46f9265-ff3c-6743-2278-6772598233c2%40pgmasters.net  
Author: Nathan Bossart  
Reviewed-by: David Steele, Tom Lane  

commit   : df38157d94662a64e2f83aa8a0110fd1ee7c4776    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 27 Apr 2023 11:55:06 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 27 Apr 2023 11:55:06 -0400    

Python 3 changed the behavior of PyMapping_Check(), breaking the  
test in plpython_to_hstore() that verifies whether a function result  
to be transformed is acceptable.  A backwards-compatible fix is to  
first verify that the object doesn't pass PySequence_Check().  
  
Perhaps accidentally, our other uses of PyMapping_Check() already  
follow uses of PySequence_Check(), so that no other bugs were  
created by this change.  
  
Per bug #17908 from Alexander Lakhin.  Back-patch to all supported  
branches.  
  
Dmitry Dolgov and Tom Lane  
  
Discussion: https://postgr.es/m/17908-3f19a125d56a11d6@postgresql.org  

commit   : 376dc820531bafcbf105fff74c5b14c23d9950af    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Thu, 27 Apr 2023 14:22:53 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Thu, 27 Apr 2023 14:22:53 +0530    

Author: Bertrand Drouvot  
Reviewed-by: Vignesh C, Alvaro Herrera, Amit Kapila  
Discussion: https://postgr.es/m/2fefa454-5a70-2174-ddbf-4a0e41537139@gmail.com  

commit   : bedc1f0564d12c4a89fc9de3044201166542dc3d    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 27 Apr 2023 13:34:05 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 27 Apr 2023 13:34:05 +0900    

As written, pg_dump would call twice parse_compress_specification() for  
the custom and directory formats to build a compression specification if  
no compression option is defined, as these formats should be compressed  
by default when compiled with zlib, or use no compression without zlib.  
This made the code logic quite confusing, and the first compression  
specification built would be incorrect before being overwritten by the  
second one.  
  
Rather than creating two compression specifications, this commit changes  
a bit the order of the checks for the compression options so as  
compression_algorithm_str is now set to a correct value for the custom  
and format directory when no compression option is defined.  This makes  
the code easier to understand, as parse_compress_specification() is now  
called once for all the format, with or without user-specified  
compression methods.  One comment was also confusing for the non-zlib  
case, so remove it while on it.  
  
This code has been introduced in 5e73a60 when adding support for  
compression specifications in pg_dump.  
  
Per discussion with Justin Pryzby and Georgios Kokolatos.  
  
Discussion: https://postgr.es/m/20230225050214.GH1653@telsasoft.com  

commit   : 7b7fa85130330128b404eddebd4f33c6739454b0    
  
author   : Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Wed, 26 Apr 2023 14:24:13 +0200    
  
committer: Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Wed, 26 Apr 2023 14:24:13 +0200    

Commit ce6b672e44 changed dumping GRANT commands to ensure that  
grantors already have an ADMIN OPTION on the role for which it  
is granting permissions. Looping over the grants per role has a  
stop condition on dumping the grant statements, but accidentally  
missed updating the variable for the conditional check.  
  
Author: Andreas Scherbaum <ads@pgug.de>  
Co-authored-by: Artur Zakirov <zaartur@gmail.com>  
Discussion: https://postgr.es/m/de44299d-cd31-b41f-2c2a-161fa5e586a5@pgug.de  

commit   : 4def50eba99e0a7e9b4c09fa3e33209d6d6fb834    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Wed, 26 Apr 2023 20:15:00 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Wed, 26 Apr 2023 20:15:00 +0900    

commit   : a4c17c86176cfa712f541b81b2a026ae054b275e    
  
author   : Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Wed, 26 Apr 2023 11:40:01 +0200    
  
committer: Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Wed, 26 Apr 2023 11:40:01 +0200    

Commit 664d75753 added the BackgroundPsql module with helper functions  
for tests running interactive or background psql tasks. The new module  
was however not added to the install rules of the build systems.  
  
Reported-by: Peter Eisentraut <peter.eisentraut@enterprisedb.com>  
Discussion: https://postgr.es/m/c0ba3008-dbc8-e53f-29f2-2e9abe72b2a2@enterprisedb.com  

commit   : 828e93a6f2dbf4bc7a24bc3ce166c34879eeb8b1    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Wed, 26 Apr 2023 10:39:46 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Wed, 26 Apr 2023 10:39:46 +1200    

The recently added inclusion of guc.h in smgr.h is not necessary and  
introduces more server-related stuff. Removing the directive helps  
avoid potential issues with including sgmr.h in frontends.  
  
Author: Kyotaro Horiguchi <horikyota.ntt@gmail.com>  
Discussion: https://postgr.es/m/20230425.115748.2130383825066921512.horikyota.ntt%40gmail.com  

commit   : 84cc1426745b4bc91242caec9173a2ca19a4af79    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 26 Apr 2023 07:10:06 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 26 Apr 2023 07:10:06 +0900    

SLRUFlushSync has been accidently removed during dee663f, that has moved  
the flush of the SLRU files to the checkpointer, so add it back.  The  
issue has been noticed by Thomas when checking for orphaned wait  
events.  
  
Author: Thomas Munro  
Reviewed-by: Bharath Rupireddy  
Discussion: https://postgr.es/m/CA+hUKGK6tqm59KuF1z+h5Y8fsWcu5v8+84kduSHwRzwjB2aa_A@mail.gmail.com  

commit   : bfac8f8bc4a44c67c9f35b5266676278e4ba1217    
  
author   : Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Tue, 25 Apr 2023 13:54:10 +0200    
  
committer: Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Tue, 25 Apr 2023 13:54:10 +0200    

Commit 1021bd6a89 excluded autovacuum workers from cost-limit balance  
calculations when per-relation options were set.  The code checks for  
limit and cost_delay being greater than zero, but since cost_delay can  
be set to -1 the test needs to check for greater than or zero.  
  
Backpatch to all supported branches since 1021bd6a89 was backpatched  
all the way at the time.  
  
Author: Masahiko Sawada <sawada.mshk@gmail.com>  
Reviewed-by: Melanie Plageman <melanieplageman@gmail.com>  
Reviewed-by: Daniel Gustafsson <daniel@yesql.se>  
Discussion: https://postgr.es/m/CAD21AoBS7o6Ljt_vfqPQPf67AhzKu3fR0iqk8B=vVYczMugKMQ@mail.gmail.com  
Backpatch-through: v11 (all supported branches)  

commit   : 3034dc56ef4b9bc1490e2b1e09fcdf3eeae53e8f    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Tue, 25 Apr 2023 08:33:09 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Tue, 25 Apr 2023 08:33:09 +0530    

Reduce the log level in 035_standby_logical_decoding.pl as the test  
doesn't require the higher log level. This helps to shrink the output size  
and speed up the test a bit.  
  
Author: Bertrand Drouvot  
Discussion: https://postgr.es/m/2fefa454-5a70-2174-ddbf-4a0e41537139@gmail.com  
Discussion: https://postgr.es/m/523315.1681245505@sss.pgh.pa.us  

commit   : 806fad7573e2b44de57888e3c04eab8eec4a69a8    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 25 Apr 2023 09:42:19 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 25 Apr 2023 09:42:19 +0900    

The leak would show up when using batch inserts with foreign tables  
included in a partition tree, as the slots used in the batch were not  
reset once processed.  In order to fix this problem, some  
ExecClearTuple() are added to clean up the slots used once a batch is  
filled and processed, mapping with the number of slots currently in use  
as tracked by the counter ri_NumSlots.  
  
This buffer refcount leak has been introduced in b676ac4 with the  
addition of the executor facility to improve bulk inserts for FDWs, so  
backpatch down to 14.  
  
Alexander has provided the patch (slightly modified by me).  The test  
for postgres_fdw comes from me, based on the test case that the author  
has sent in the report.  
  
Author: Alexander Pyhalov  
Discussion: https://postgr.es/m/b035780a740efd38dc30790c76927255@postgrespro.ru  
Backpatch-through: 14  

commit   : 1118cd37eb61e6a2428f457a8b2026a7bb3f801a    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 24 Apr 2023 12:20:52 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Mon, 24 Apr 2023 12:20:52 -0700    

vacuum_defer_cleanup_age was introduced before hot_standby_feedback and  
replication slots existed. It is hard to use reasonably - commonly it will  
either be set too low (not preventing recovery conflicts, while still causing  
some bloat), or too high (causing a lot of bloat). The alternatives do not  
have that issue.  
  
That on its own might not be sufficient reason to remove  
vacuum_defer_cleanup_age, but it also complicates computation of xid  
horizons. See e.g. the bug fixed in be504a3e974. It also is untested.  
  
This commit removes TransactionIdRetreatSafely(), as there are no users  
anymore. There might be potential future users, hence noting that here.  
  
Reviewed-by: Daniel Gustafsson <daniel@yesql.se>  
Reviewed-by: Justin Pryzby <pryzby@telsasoft.com>  
Reviewed-by: Alvaro Herrera <alvherre@alvh.no-ip.org>  
Discussion: https://postgr.es/m/20230317230930.nhsgk3qfk7f4axls@awork3.anarazel.de  

commit   : 441ee1677e6b580794c81943a937cd84363672f3    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 24 Apr 2023 14:19:46 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 24 Apr 2023 14:19:46 -0400    

Commit 04fe805a1 modified plpgsql so that datatype casts make use of  
expressions cached by plancache.c, in place of older code where these  
expression trees were managed by plpgsql itself.  However, I (tgl)  
forgot that we use a separate, shorter-lived cast info hashtable in  
DO blocks.  The new mechanism thus resulted in session-lifespan  
leakage of the plancache data once a DO block containing one or more  
casts terminated.  To fix, split the cast hash table into two parts,  
one that tracks only the plancache's CachedExpressions and one that  
tracks the expression state trees generated from them.  DO blocks need  
their own expression state trees and hence their own version of the  
second hash table, but there's no reason they can't share the  
CachedExpressions with regular plpgsql functions.  
  
Per report from Ajit Awekar.  Back-patch to v12 where the issue  
was introduced.  
  
Ajit Awekar and Tom Lane  
  
Discussion: https://postgr.es/m/CAHv6PyrNaqdvyWUspzd3txYQguFTBSnhx+m6tS06TnM+KWc_LQ@mail.gmail.com  

commit   : fce3b26e97ca98de054734e2af7d9125661a9b3f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 24 Apr 2023 13:01:33 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 24 Apr 2023 13:01:33 -0400    

The name of this function suggests that it ought to reparent R/W  
expanded objects to be children of the persistent aggcontext, instead  
of copying them.  In fact it does no such thing, and if you try to  
make it do so you will see multiple regression failures.  Rename it  
to the less-misleading ExecAggCopyTransValue, and add commentary  
about why that attractive-sounding optimization won't work.  Also  
adjust comments at call sites, some of which were describing logic  
that has since been moved into ExecAggCopyTransValue.  
  
Discussion: https://postgr.es/m/3004282.1681930251@sss.pgh.pa.us  

commit   : 5a8366ad75eb70cffa791119b404c897983260c6    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 24 Apr 2023 15:39:54 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 24 Apr 2023 15:39:54 +0200    

Some feature names have been adjusted over time upstream.  This pulls  
in those changes.  

commit   : c5e4ec293ea527394fc1d0006ab88047b3ce580f    
  
author   : Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Mon, 24 Apr 2023 11:40:23 +0200    
  
committer: Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Mon, 24 Apr 2023 11:40:23 +0200    

Commit 0b5d1fb36 fixed the SSL test to properly handle the error message  
from OpenSSL when the system CA pool is missing of invalid, so with that  
we can remove the workaround in Cirrus for when Homebrew clears the cert  
from OPENSSLDIR.  
  
Author: Jacob Champion <jchampion@timescale.com>  
Discussion: https://postgr.es/m/CAAWbhmj3JtKuRcHcMuf1eCJmoZxMXdzLaYpEGmzu9+kgRGpu3A@mail.gmail.com  

commit   : 69537f5d17eab2919c9d88880cb242de1e7a647d    
  
author   : Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Mon, 24 Apr 2023 11:16:17 +0200    
  
committer: Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Mon, 24 Apr 2023 11:16:17 +0200    

Commit 6df7a9698bb accidentally included two identical prototypes for  
default_multirange_selectivi() and commit 086cf1458c6 added a break;  
statement where one was already present, thus duplicating it.  While  
there is no bug caused by this, fix by removing the duplicated lines  
as they provide no value.  
  
Backpatch the fix for duplicate prototypes to v14 and the duplicate  
break statement fix to all supported branches to avoid backpatching  
hazards due to the removal.  
  
Reported-by: Anton Voloshin <a.voloshin@postgrespro.ru>  
Discussion: https://postgr.es/m/0e69cb60-0176-f6d0-7e15-6478b7d85724@postgrespro.ru  

commit   : 781ac42d43ab2b5af07fd720a01c68348a4d1d20    
  
author   : Masahiko Sawada <msawada@postgresql.org>    
date     : Mon, 24 Apr 2023 15:37:14 +0900    
  
committer: Masahiko Sawada <msawada@postgresql.org>    
date     : Mon, 24 Apr 2023 15:37:14 +0900    

An oversight in commit 216a784829c.  
  
Author: Masahiko Sawada  
Reviewed-by: Kyotaro Horiguchi, Amit Kapila  
Discussion: https://postgr.es/m/CAD21AoDDbM8_HJt-nMCvcjTK8K9hPzXWqJj7pyaUvR4mm_NrSg@mail.gmail.com  

commit   : 19e65dff38bdccdf2cac7f2083342101df6bea57    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Mon, 24 Apr 2023 08:37:58 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Mon, 24 Apr 2023 08:37:58 +0530    

The commit c3afe8cf5a added a new subscription option 'password_required'  
which should be shown with \dRs+ command.  
  
Author: Vignesh C  
Reviewed-by: Amit Kapila, Robert Haas  
Discussion: https://postgr.es/m/CAA4eK1LRz5sCZxwCW6OtpjLtWPvRwBihQOM4jzQm6ppfpexqGA@mail.gmail.com  
Discussion: https://postgr.es/m/9DFC88D3-1300-4DE8-ACBC-4CEF84399A53@enterprisedb.com  

commit   : 244ab8c00c427d35901a6f1eb97e4e22b2916e7e    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sun, 23 Apr 2023 18:58:19 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sun, 23 Apr 2023 18:58:19 -0700    

Just intagg is obsolete, and having a one-entry list gives undue weight.  
  
Discussion: https://postgr.es/m/20230409185050.GA949159@rfd.leadboat.com  

commit   : 8bbd0cce92be98de9f4f727b8bf66fe26e5831ea    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Sun, 23 Apr 2023 13:58:25 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Sun, 23 Apr 2023 13:58:25 +0300    

Unaligned siglen could lead to an unaligned access to subsequent key fields.  
  
Backpatch to 13, where opclass options were introduced.  
  
Reported-by: Alexander Lakhin  
Bug: 17847  
Discussion: https://postgr.es/m/17847-171232970bea406b%40postgresql.org  
Reviewed-by: Tom Lane, Pavel Borisov, Alexander Lakhin  
Backpatch-through: 13  

commit   : cd115c3530bd59bb0305d62ccef1c9504207ff4c    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Sun, 23 Apr 2023 13:55:49 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Sun, 23 Apr 2023 13:55:49 +0300    

We need to call them only when validate == true.  
  
Backpatch to 13, where opclass options were introduced.  
  
Reported-by: Tom Lane  
Discussion: https://postgr.es/m/2656633.1681831542%40sss.pgh.pa.us  
Reviewed-by: Tom Lane, Pavel Borisov  
Backpatch-through: 13  

commit   : 0ec0e2095579ca16fb4f3aee086e57fd1a7533eb    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 22 Apr 2023 11:52:46 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 22 Apr 2023 11:52:46 -0400    

In commit 2e6ba1315, I missed that there was a redundant  
second reference to pg_bsd_indent's old repo.  

commit   : 5cd1a5af4d17496a58678c8eb7ab792119c2d723    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Fri, 21 Apr 2023 13:11:18 -0700    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Fri, 21 Apr 2023 13:11:18 -0700    

Discussion: https://postgr.es/m/878relf7cb.fsf@news-spur.riddles.org.uk  
Reported-by: Andrew Gierth  

commit   : c04c6c5d6f5f213f217f1e356bf1c2d8b4e255a2    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Fri, 21 Apr 2023 08:19:41 -0700    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Fri, 21 Apr 2023 08:19:41 -0700    

For regex escape sequences, just test directly for the relevant ASCII  
characters rather than using locale-sensitive character  
classification.  
  
This fixes an assertion failure when a locale considers a non-ASCII  
character, such as "൧", to be a digit.  
  
Reported-by: Richard Guo  
Discussion: https://postgr.es/m/CAMbWs49Q6UoKGeT8pBkMtJGJd+16CBFZaaWUk9Du+2ERE5g_YA@mail.gmail.com  
Backpatch-through: 11  

commit   : a23ab2eebfb19bacb9e8d91edb822a0fec37334c    
  
author   : Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Fri, 21 Apr 2023 12:29:38 +0200    
  
committer: Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Fri, 21 Apr 2023 12:29:38 +0200    

Commit 7f5b198 introduced TAP tests that use string literals to mark  
the presence of a query in server logs.  Reorder the markers to make  
sure they are used in alphabetical order for easier debugging.  
  
Author: Gurjeet Singh <gurjeet@singh.im>  
Reviewed-by: Jelte Fennema <postgres@jeltef.nl>  
Discussion: https://postgr.es/m/CABwTF4WcYAENqyUQS2crAYfDuJ497v82ty2-MirjaC+zz9e8nQ@mail.gmail.com  

commit   : 60ce452729239f10ebbd0803a0ecc460f7f9238a    
  
author   : Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Fri, 21 Apr 2023 10:23:38 +0200    
  
committer: Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Fri, 21 Apr 2023 10:23:38 +0200    

The errormessage for an incorrect require_auth method wasn't using the  
common "invalid %s value" errormessage which lessens the burden on our  
translators.  Fix by changing to that format to make use of existing  
translations and to make error messages consistent in wording.  
  
Reported and fixed by Gurjeet Singh with some tweaking by myself.  
  
Author: Gurjeet Singh <gurjeet@singh.im>  
Discussion: https://postgr.es/m/CABwTF4Xu3g9zohJ9obu8m7MKbf8g63NgpRDjwqPHQgAtB+Gb8Q@mail.gmail.com  

commit   : 0a16512d40a58c5046c2ab4ca7eabb8393f31c18    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Fri, 21 Apr 2023 16:46:41 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Fri, 21 Apr 2023 16:46:41 +0900    

Commit 7f5b19817e introduced the PGLOADBALANCEHOSTS environment  
variable for connection load balancing in libpq. However, documentation  
for this variable was missing.  
  
Author: Fujii Masao  
Reviewed-by: Jelte Fennema  
Discussion: https://postgr.es/m/e2b44cf7-aa16-e726-1d4a-a69508ebf6b9@oss.nttdata.com  

commit   : 84e05beb111335c0755ef37a7f4d64822170b76d    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Fri, 21 Apr 2023 11:41:58 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Fri, 21 Apr 2023 11:41:58 +1200    

Author: Alexander Lakhin  
Discussion: https://postgr.es/m/d5f68d19-c0fc-91a9-118d-7c6a5a3f5fad@gmail.com  

commit   : d91d1635292a290191339b868bcc71ef42ca50ce    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Fri, 21 Apr 2023 10:46:08 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Fri, 21 Apr 2023 10:46:08 +1200    

This function was renamed in 0c9d84427 but this comment wasn't updated.  
  
Author: Alexander Lakhin  
Discussion: https://postgr.es/m/699beab4-a6ca-92c9-f152-f559caf6dc25@gmail.com  

commit   : 0ecb87e1fa07a733494e35636e55807b0f3fc1ed    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 21 Apr 2023 07:21:50 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 21 Apr 2023 07:21:50 +0900    

a9c70b46 added the statistics view pg_stat_io which contained columns  
"io_context" and "io_object".  Given that the columns are in the  
pg_stat_io view, the "io" prefix is somewhat redundant, so remove it.  
  
The code variables referring to these fields are kept unchanged so as  
they can keep their context about I/O.  
  
Bump catalog version.  
  
Author: Melanie Plageman  
Reviewed-by: Kyotaro Horiguchi, Fabrízio de Royes Mello  
Discussion: https://postgr.es/m/CAAKRu_aAQoJWrvT2BYYQvJChFKra_O-5ra3jhzKJZqWsTR1CPQ@mail.gmail.com  

commit   : eab2d3147e3c13aca4a9aca52c0a9a581a8d224a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 20 Apr 2023 18:12:32 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 20 Apr 2023 18:12:32 -0400    

We've long used "--strip-unneeded" for shared libraries but plain  
"-x" for static libraries when stripping symbols with GNU strip.  
There doesn't seem to be any really good reason for that though,  
since --strip-unneeded produces smaller output (as "-x" alone  
does not remove debug symbols).  Moreover it seems that  
llvm-strip, although it identifies as GNU strip, misbehaves when  
given "-x" for this purpose.  It's unclear whether that's  
intentional or a bug in llvm-strip, but in any case it seems like  
changing to use --strip-unneeded in all cases should be a win.  
  
Note that this doesn't change our behavior when dealing with  
non-GNU strip.  
  
Per gripes from Ed Maste and Palle Girgensohn.  Back-patch,  
in case anyone wants to use llvm-strip with stable branches.  
  
Discussion: https://postgr.es/m/17898-5308d09543463266@postgresql.org  
Discussion: https://postgr.es/m/20230420153338.bbj2g5jiyy3afhjz@awork3.anarazel.de  

commit   : a9781ae11ba2fdb44a3a72c9a7ebb727140b25c5    
  
author   : Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Thu, 20 Apr 2023 15:45:44 +0200    
  
committer: Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Thu, 20 Apr 2023 15:45:44 +0200    

Commit 7d71d3dd0 introduced finer grained updates of autovacuum option  
changes by increasing the frequency of reading the configuration file.  
The debug logging of cost parameter was however changed such that some  
initial values weren't logged.  Fix by changing logging to use the old  
frequency of logging regardless of them changing.  
  
Also avoid taking a log for rendering the log message unless the set  
loglevel is such that the log entry will be emitted.  
  
Author: Masahiko Sawada <sawada.mshk@gmail.com>  
Discussion: https://postgr.es/m/CAD21AoBS7o6Ljt_vfqPQPf67AhzKu3fR0iqk8B=vVYczMugKMQ@mail.gmail.com  

commit   : 0d0aeb04c1277edb0733cbf5bf4243c47a439015    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Thu, 20 Apr 2023 23:51:38 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Thu, 20 Apr 2023 23:51:38 +1200    

indexes-unique.html mentioned nothing about the availability of NULLS NOT  
DISTINCT to modify the NULLs-are-not-equal behavior of unique indexes.  
Add this to the synopsis and clarify what it does regarding NULLs.  
  
Author: David Gilman, David Rowley  
Reviewed-by: Corey Huinker  
Discussion: https://postgr.es/m/CALBH9DDr3NLqzWop1z5uZE-M5G_GYUuAeHFHQeyzFbNd8W0d=Q@mail.gmail.com  
Backpatch-through: 15, where NULLS NOT DISTINCT was added  

commit   : c1cc4e688b60090f194017c6e15e330a725fba3e    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Thu, 20 Apr 2023 08:56:18 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Thu, 20 Apr 2023 08:56:18 +0530    

The apply worker is restarted if any subscription option that affects the  
remote connection was changed. In commit c3afe8cf5a, we added the option  
'password_required' which can affect the remote connection, so we should  
restart the worker if it was changed.  
  
Author: Amit Kapila  
Reviewed-by: Robert Haas  
Discussion: https://postgr.es/m/CAA4eK1+z9UDFEynXLsWeMMuUZc1iQkRwj2HNDtxUHTPo-u1F4A@mail.gmail.com  
Discussion: https://postgr.es/m/9DFC88D3-1300-4DE8-ACBC-4CEF84399A53@enterprisedb.com  

commit   : 7d3d72b55edd1b7552a9a358991555994efab0e9    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Thu, 20 Apr 2023 13:15:23 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Thu, 20 Apr 2023 13:15:23 +1200    

Old versions of Solaris and illumos had buffer overrun bugs in their  
strxfrm() implementations.  The bugs were fixed more than a decade ago  
and the relevant releases are long out of vendor support.  It's time to  
remove the defense added by commit be8b06c3.  
  
Reviewed-by: Nathan Bossart <nathandbossart@gmail.com>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/CA+hUKGJ-ZPJwKHVLbqye92-ZXeLoCHu5wJL6L6HhNP7FkJ=meA@mail.gmail.com  

commit   : e35ded29566f679e52888a8d34468bb51bc78bed    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Thu, 20 Apr 2023 10:34:46 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Thu, 20 Apr 2023 10:34:46 +1200    

list_copy_head() given an empty List would crash from trying to  
dereference the List to obtain its length.  Since NIL is how we represent  
an empty List, we should just be returning another empty List in this  
case.  
  
list_copy_head() is new to v16, so let's fix it now before too many people  
start coding around the buggy NIL behavior.  
  
Reported-by: Miroslav Bendik  
Discussion: https://postgr.es/m/CAPoEpV02WhawuWnmnKet6BqU63bEu7oec0pJc=nKMtPsHMzTXQ@mail.gmail.com