PostgreSQL 16.0 commit log

commit   : c372fbbd8e911f2412b80a8c39d7079366565d67    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 11 Sep 2023 16:25:06 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 11 Sep 2023 16:25:06 -0400    

commit   : 2439153f4477892b5af0f05e1c95eb0a048608bd    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 11 Sep 2023 16:10:09 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 11 Sep 2023 16:10:09 -0400    

commit   : e472a8c51c935ee074ab83197a1358325cc91b1b    
  
author   : Alvaro Herrera <[email protected]>    
date     : Mon, 11 Sep 2023 14:22:52 +0200    
  
committer: Alvaro Herrera <[email protected]>    
date     : Mon, 11 Sep 2023 14:22:52 +0200    

This file was missed in the previous update.  
  
Source-Git-URL: ssh://[email protected]/pgtranslation/messages.git  
Source-Git-Hash: de944161c6153124a7bf720cb99823ff31b64bab  

commit   : 6bdeed9844d77d051905771c5673364d4e385052    
  
author   : Alvaro Herrera <[email protected]>    
date     : Mon, 11 Sep 2023 14:08:53 +0200    
  
committer: Alvaro Herrera <[email protected]>    
date     : Mon, 11 Sep 2023 14:08:53 +0200    

Source-Git-URL: ssh://[email protected]/pgtranslation/messages.git  
Source-Git-Hash: 06696f05da005029a2326e1cbb234917a9286914  

commit   : efaa50c783d73d99b4e999012f9f0a9ffdad3e50    
  
author   : Bruce Momjian <[email protected]>    
date     : Fri, 8 Sep 2023 17:25:15 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Fri, 8 Sep 2023 17:25:15 -0400    

Reported-by: Laurenz Albe  
  
Discussion: https://postgr.es/m/[email protected]  
  
Author: Laurenz Albe  
  
Backpatch-through: 11  

commit   : 1b95c8d85fa66c0ef63591b8064b023872a8f43c    
  
author   : Masahiko Sawada <[email protected]>    
date     : Fri, 8 Sep 2023 22:50:56 +0900    
  
committer: Masahiko Sawada <[email protected]>    
date     : Fri, 8 Sep 2023 22:50:56 +0900    

The new test added by commit 68a59f9e9 disables the subscription and  
manually drops the associated replication slot. However, since  
disabling the subsubscription doesn't wait for a walsender to release  
the replication slot and exit, pg_drop_replication_slot() could  
fail. Avoid failure by adding a wait for the replication slot to  
become inactive.  
  
Reported-by: Hou Zhijie, as per buildfarm  
Reviewed-by: Hou Zhijie  
Discussion: https://postgr.es/m/OS0PR01MB571682316378379AA34854F694E9A%40OS0PR01MB5716.jpnprd01.prod.outlook.com  
Backpatch-through: 15  

commit   : bae47d78673e42bc203bc5a8172e058f1c5bb548    
  
author   : Daniel Gustafsson <[email protected]>    
date     : Fri, 8 Sep 2023 11:34:43 +0200    
  
committer: Daniel Gustafsson <[email protected]>    
date     : Fri, 8 Sep 2023 11:34:43 +0200    

Extend the PG_TEST_EXTRA documentation to mention resource intensive  
tests as well. The previous wording only mentioned special software  
and security in the main paragraph, with resource usage listed on one  
of the tests in the list.  
  
Backpatch to v15 where f47ed79cc8 added wal_consistenct_checking as  
a PG_TEST_EXTRA target.  
  
Author: Nazir Bilal Yavuz <[email protected]>  
Discussion: https://postgr.es/m/CAN55FZ0OthTuBdiNkaX2BvxuHdK4Y1MVEb8_uEuD1yHMPmT9Og@mail.gmail.com  
Backpatch-through: 15  

commit   : 1057958436c5b9f0468fc3bf08dd49b1e0f43acb    
  
author   : Michael Paquier <[email protected]>    
date     : Thu, 7 Sep 2023 14:12:25 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Thu, 7 Sep 2023 14:12:25 +0900    

pgbouncer can cause PQbackendPID() to return negative values due to it  
filling be_pid with random bytes (even these days pid_max can only be  
set up to 2^22 on 64b machines on Linux, for example, so this cannot  
happen with normal PID numbers).  When this happens, pg_basebackup may  
generate a temporary slot name that may not be accepted by the parser,  
leading to spurious failures, like:  
pg_basebackup: error: could not send replication command  
ERROR:  replication slot name "pg_basebackup_-1201966863" contains  
invalid character  
  
This commit fixes that problem by formatting the result from  
PQbackendPID() as an unsigned integer when creating the temporary  
replication slot name, so as the invalid character is gone and the  
command can be parsed.  
  
Author: Jelte Fennema  
Reviewed-by: Daniel Gustafsson, Nishant Sharma  
Discussion: https://postgr.es/m/CAGECzQQOGvYfp8ziF4fWQ_o8s2K7ppaoWBQnTmdakn3s-4Z=5g@mail.gmail.com  
Backpatch-through: 11  

commit   : 8d1cf9674a253f88d52c365804b9b4d3a7eeab9d    
  
author   : Thomas Munro <[email protected]>    
date     : Thu, 7 Sep 2023 11:47:42 +1200    
  
committer: Thomas Munro <[email protected]>    
date     : Thu, 7 Sep 2023 11:47:42 +1200    

This test fails due to known bugs in the test and the server.  Those  
will be fixed in master shortly and possibly back-patched a bit later,  
but in the meantime it is unhelpful for package maintainers if the tests  
randomly fail, and it's not a good time to make complex changes in 16.  
  
This had already been done for older branches prior to 15's release.  
Now we're about to release 16, and Debian's test builds are regularly  
failing on one architecture, so let's do the same for 15 and 16.  
  
Reported-by: Christoph Berg <[email protected]>  
Reported-by: Bharath Rupireddy <[email protected]>  
Discussion: https://postgr.es/m/CALj2ACVr8au2J_9D88UfRCi0JdWhyQDDxAcSVav0B0irx9nXEg%40mail.gmail.com  

commit   : 253bc4eb284b3d3e5fe554f74fcc50ca10e8fd61    
  
author   : Bruce Momjian <[email protected]>    
date     : Wed, 6 Sep 2023 16:52:24 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Wed, 6 Sep 2023 16:52:24 -0400    

Reported-by: [email protected]  
  
Diagnosed-by: Laurenz Albe  
  
Discussion: https://postgr.es/m/[email protected]  
  
Author: Laurenz Albe  
  
Backpatch-through: 11  

commit   : 3ddc889e334f21c6dc98753dcd8b485b275b5e33    
  
author   : Bruce Momjian <[email protected]>    
date     : Wed, 6 Sep 2023 15:36:07 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Wed, 6 Sep 2023 15:36:07 -0400    

Reported-by: Magnus Hagander  
  
Discussion: https://postgr.es/m/CABUevEwBXi5oqqMj429Lxjro1uu-fdKgSkJtgJS5aTOmujEGQQ@mail.gmail.com  
  
Backpatch-through: 16 only  

commit   : b323fcc58cb15200572a8515bc9b5bb1882c4d42    
  
author   : Peter Eisentraut <[email protected]>    
date     : Wed, 6 Sep 2023 09:04:30 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Wed, 6 Sep 2023 09:04:30 +0200    

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

commit   : ae7e3ae8c6ee1a877ef5940cafdb4a051d80feca    
  
author   : Peter Eisentraut <[email protected]>    
date     : Wed, 6 Sep 2023 08:11:22 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Wed, 6 Sep 2023 08:11:22 +0200    

current through 57a011b666  

commit   : 57a011b6664f284bedd172595dbeb910a53e9121    
  
author   : Bruce Momjian <[email protected]>    
date     : Tue, 5 Sep 2023 13:05:28 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Tue, 5 Sep 2023 13:05:28 -0400    

Reported-by: Ryo Matsumura  
  
Discussion: https://postgr.es/m/TYCPR01MB11316B3FB56EE54D70BF0CEF6E8E4A@TYCPR01MB11316.jpnprd01.prod.outlook.com  
  
Backpatch-through: 11  

commit   : 9ddecd40664f7523b18f760aea0e04936e8a2302    
  
author   : Peter Eisentraut <[email protected]>    
date     : Tue, 5 Sep 2023 11:36:55 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Tue, 5 Sep 2023 11:36:55 +0200    

Fixup for commit 37188cea0c.  

commit   : fac3fa0d5b21ce59258a691b88e4176a06722bfc    
  
author   : Michael Paquier <[email protected]>    
date     : Mon, 4 Sep 2023 14:55:49 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Mon, 4 Sep 2023 14:55:49 +0900    

This could lead to an imprecise choice when splitting an index page of a  
GiST index on a tsvector, deciding which entries should remain on the  
old page and which entries should move to a new page.  
  
This is wrong since tsearch2 has been moved into core with commit  
140d4ebcb46e, so backpatch all the way down.  This error has been  
spotted by valgrind.  
  
Author: Alexander Lakhin  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 11  

commit   : c397c98ae63d57c35766dbefe4ea34a5162abf53    
  
author   : Michael Paquier <[email protected]>    
date     : Mon, 4 Sep 2023 08:04:40 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Mon, 4 Sep 2023 08:04:40 +0900    

Dropping a database while a connection is attempted on it was able to  
lead to the presence of valid database entries in shared statistics.  
The issue is that MyDatabaseId was getting set too early than it should,  
as, if the connection attempted on the dropped database fails when  
renamed or dropped, the shutdown callback of the shared statistics would  
finish by re-inserting a correct entry related to the database already  
dropped.  
  
As analyzed by the bug reporters, this issue could lead to phantom  
entries in the database list maintained by the autovacuum launcher  
(in rebuild_database_list()) if the database dropped was part of the  
database list when it was still valid.  After the database was dropped,  
it would remain the highest on the list of databases to considered by  
the autovacuum worker as things to process.  This would prevent  
autovacuum jobs to happen on all the other databases still present.  
  
The commit fixes this issue by delaying setting MyDatabaseId until the  
database existence has been re-checked with the second scan on  
pg_database after getting a shared lock on it, and by switching  
pgstat_update_dbstats() so as nothing happens if MyDatabaseId is not  
valid.  
  
Issue introduced by 5891c7a8ed8f, so backpatch down to 15.  
  
Reported-by: Will Mortensen, Jacob Speidel  
Analyzed-by: Will Mortensen, Jacob Speidel  
Author: Andres Freund  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 15  

commit   : 22297cd65fa5efeffebcfaebfdda174dcdbd821a    
  
author   : Bruce Momjian <[email protected]>    
date     : Thu, 31 Aug 2023 15:14:18 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Thu, 31 Aug 2023 15:14:18 -0400    

Backpatch-through: 16 only  

commit   : d5feb6011e629cc1096bbaa10af5ffcc6c17f908    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Thu, 31 Aug 2023 13:02:15 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Thu, 31 Aug 2023 13:02:15 +0300    

The comment in heapgettup_advance_block() says that it reports the  
scan position before checking for end of scan, but that didn't match  
the code. The code was refactored in commit 7ae0ab0ad9, which  
inadvertently changed the order of the check and reporting. Change it  
back.  
  
This caused a few regression test failures with a small shared_buffers  
setting like 10 MB. The 'portals' and 'cluster' tests perform seqscans  
that are large enough that sync seqscans kick in. When the sync scan  
position is not updated at end of scan, the next seq scan doesn't  
start at the beginning of the table, and the test queries are  
sensitive to that.  
  
Reviewed-by: Melanie Plageman, David Rowley  
Discussion: https://www.postgresql.org/message-id/[email protected]  
Backpatch-through: 16  

commit   : 133654a05b4367e3e70f7cfe496a4b9386674fcf    
  
author   : Nathan Bossart <[email protected]>    
date     : Wed, 30 Aug 2023 14:47:20 -0700    
  
committer: Nathan Bossart <[email protected]>    
date     : Wed, 30 Aug 2023 14:47:20 -0700    

Unlike the other pg_stat_get_backend* functions,  
pg_stat_get_backend_subxact() looks up the backend entry by using  
its integer argument as a 1-based index in an internal array.  The  
other functions look for the entry with the matching session  
backend ID.  These numbers often match, but that isn't reliably  
true.  
  
This commit resolves this discrepancy by introducing  
pgstat_get_local_beentry_by_backend_id() and using it in  
pg_stat_get_backend_subxact().  We cannot use  
pgstat_get_beentry_by_backend_id() because it returns a  
PgBackendStatus, which lacks the locally computed additions  
available in LocalPgBackendStatus that are required by  
pg_stat_get_backend_subxact().  
  
Author: Ian Barwick  
Reviewed-by: Sami Imseih, Michael Paquier, Robert Haas  
Discussion: https://postgr.es/m/CAB8KJ%3Dj-ACb3H4L9a_b3ZG3iCYDW5aEu3WsPAzkm2S7JzS1Few%40mail.gmail.com  
Backpatch-through: 16  

commit   : 8dfa37b797843a83a5756ea3309055e8953e1a86    
  
author   : Nathan Bossart <[email protected]>    
date     : Wed, 30 Aug 2023 14:47:14 -0700    
  
committer: Nathan Bossart <[email protected]>    
date     : Wed, 30 Aug 2023 14:47:14 -0700    

Presently, pgstat_fetch_stat_beentry() accepts a session's backend  
ID as its argument, and pgstat_fetch_stat_local_beentry() accepts a  
1-based index in an internal array as its argument.  The former is  
typically used wherever a user must provide a backend ID, and the  
latter is usually used internally when looping over all entries in  
the array.  This difference was first introduced by d7e39d72ca.  
Before that commit, both functions accepted a 1-based index to the  
internal array.  
  
This commit renames these two functions to make it clear whether  
they use the backend ID or the 1-based index to look up the entry.  
This is preparatory work for a follow-up change that will introduce  
a function for looking up a LocalPgBackendStatus using a backend  
ID.  
  
Reviewed-by: Ian Barwick, Sami Imseih, Michael Paquier, Robert Haas  
Discussion: https://postgr.es/m/CAB8KJ%3Dj-ACb3H4L9a_b3ZG3iCYDW5aEu3WsPAzkm2S7JzS1Few%40mail.gmail.com  
Backpatch-through: 16  

commit   : 5220b568c5ad8d9ac97c0401453267491a378ef3    
  
author   : Etsuro Fujita <[email protected]>    
date     : Wed, 30 Aug 2023 17:15:01 +0900    
  
committer: Etsuro Fujita <[email protected]>    
date     : Wed, 30 Aug 2023 17:15:01 +0900    

Commit e4106b252 should have updated this test, but did not; back-patch  
to all supported branches.  
  
Reviewed by Richard Guo.  
  
Discussion: http://postgr.es/m/CAPmGK15nR0NXLSCKQAcqbZbTzrzd5MozowWnTnGfPkayndF43Q%40mail.gmail.com  

commit   : 1d2939b6dc638f9b9f9e747bec478cb1a7a459b6    
  
author   : Michael Paquier <[email protected]>    
date     : Wed, 30 Aug 2023 08:03:48 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Wed, 30 Aug 2023 08:03:48 +0900    

nFreeBlocks, defined as a long, stores the number of free blocks in a  
logical tape.  ltsGetFreeBlock() has been using an int to store the  
value of nFreeBlocks, which could lead to overflows on platforms where  
long and int are not the same size (in short everything except Windows  
where long is 4 bytes).  
  
The problematic intermediate variable is switched to be a long instead  
of an int.  
  
Issue introduced by c02fdc9223015, so backpatch down to 13.  
  
Author: Ranier vilela  
Reviewed-by: Peter Geoghegan, David Rowley  
Discussion: https://postgr.es/m/CAEudQApLDWCBR_xmwNjGBrDo+f+S4E87x3s7-+hoaKqYdtC4JQ@mail.gmail.com  
Backpatch-through: 13  

commit   : 39d4207e876fa55971cd20a7677b78f067971fd3    
  
author   : Peter Eisentraut <[email protected]>    
date     : Tue, 29 Aug 2023 15:15:54 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Tue, 29 Aug 2023 15:15:54 +0200    

The logical_replication_mode GUC is intended for testing and debugging  
purposes, but its current name may be misleading and encourage users to make  
unnecessary changes.  
  
To avoid confusion, renaming the GUC to a less misleading name  
debug_logical_replication_streaming that casual users are less likely to mistakenly  
assume needs to be modified in a regular logical replication setup.  
  
Author: Hou Zhijie <[email protected]>  
Reviewed-by: Peter Smith <[email protected]>  
Discussion: https://www.postgresql.org/message-id/flat/d672d774-c44b-6fec-f993-793e744f169a%40eisentraut.org  

commit   : cd59fcff256d68e028bf8a181d4e166e81b6474b    
  
author   : Daniel Gustafsson <[email protected]>    
date     : Tue, 29 Aug 2023 14:27:40 +0200    
  
committer: Daniel Gustafsson <[email protected]>    
date     : Tue, 29 Aug 2023 14:27:40 +0200    

While there are numerous instances of using "power of 2" in the code,  
translated user-facing messages use "power of two". Fix two instances  
which used "power of 2" instead.  
  
This is a backpatch of 95fff2abee in master.  
  
Author: Kyotaro Horiguchi <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: v16  

commit   : 5f38ff3d0f65b7d092362aaf7375cce050a13bba    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Tue, 29 Aug 2023 09:09:40 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Tue, 29 Aug 2023 09:09:40 +0300    

After commit b0bea38705, syslogger prints 63 warnings about failing to  
close a listen socket at postmaster startup. That's because the  
syslogger process forks before the ListenSockets array is initialized,  
so ClosePostmasterPorts() calls "close(0)" 64 times. The first call  
succeeds, because fd 0 is stdin.  
  
This has been like this since commit 9a86f03b4e in version 13, which  
moved the SysLogger_Start() call to before initializing ListenSockets.  
We just didn't notice until commit b0bea38705 added the LOG message.  
  
Reported by Michael Paquier and Jeff Janes.  
  
Author: Michael Paquier  
Discussion: https://www.postgresql.org/message-id/ZOvvuQe0rdj2slA9%40paquier.xyz  
Discussion: https://www.postgresql.org/message-id/[email protected]#482670177eb4eaf4c9f03c1eed963e5f  
Backpatch-through: 13  

commit   : d94dadcc5020f6746203896dba5a9627872ba2ee    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 28 Aug 2023 16:26:56 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 28 Aug 2023 16:26:56 -0400    

commit   : 66ed5a2e92d206ae95fa460d9e5648b636b8270a    
  
author   : Peter Eisentraut <[email protected]>    
date     : Mon, 28 Aug 2023 09:23:57 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Mon, 28 Aug 2023 09:23:57 +0200    

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

commit   : ef0e7dbcbed403ba53a1d77faf96600785e57d7a    
  
author   : Peter Eisentraut <[email protected]>    
date     : Sun, 27 Aug 2023 20:30:53 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Sun, 27 Aug 2023 20:30:53 +0200    

current through a842ba407c  

commit   : 60d7d50f426b17b544fd8c24024d87ab8331984f    
  
author   : Peter Eisentraut <[email protected]>    
date     : Sun, 27 Aug 2023 20:29:05 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Sun, 27 Aug 2023 20:29:05 +0200    

This name was incorrect in the underlying commit message.  (The  
correct name is already listed.)  
  
Reported-by: Denis Laxalde <[email protected]>  

commit   : 8d70eb731c43c4ccb5fa5642518a277ef3f6b860    
  
author   : Peter Eisentraut <[email protected]>    
date     : Sun, 27 Aug 2023 20:27:32 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Sun, 27 Aug 2023 20:27:32 +0200    

Reported-by: Vik Fearing <[email protected]>  

commit   : a842ba407c375b4088ee0fa569780b5328cdebe8    
  
author   : Bruce Momjian <[email protected]>    
date     : Thu, 24 Aug 2023 21:44:31 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Thu, 24 Aug 2023 21:44:31 -0400    

Reported-by: Jeff Davis  
  
Discussion:  https://postgr.es/m/[email protected]  
  
Backpatch-through: 16 only  

commit   : 2e7d15ab69d91abc874f6b5d89df4d7c5a4f2c17    
  
author   : Nathan Bossart <[email protected]>    
date     : Thu, 24 Aug 2023 10:13:31 -0700    
  
committer: Nathan Bossart <[email protected]>    
date     : Thu, 24 Aug 2023 10:13:31 -0700    

Commit 7b378237aa added a status message to pg_upgrade that is 60  
characters wide.  Since the MESSAGE_WIDTH macro is currently set to  
60, there is no space between this new status message and the "ok"  
or "failed" indicator appended when the step completes.  To fix  
this problem, this commit increases the value of MESSAGE_WIDTH to  
62.  
  
Suggested-by: Bharath Rupireddy  
Reviewed-by: Peter Eisentraut  
Discussion: https://postgr.es/m/CALj2ACVVvk1cYLtWVxHv%3DZ1Ubq%3DUES9fhKbUU4c9k4W%2BfEDnbw%40mail.gmail.com  
Backpatch-through: 16  

commit   : ba0d737caa44d322c709c4d64e95de86b126f3e4    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 24 Aug 2023 12:02:40 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 24 Aug 2023 12:02:40 -0400    

Revalidation of a plancache entry (after a cache invalidation event)  
requires acquiring a snapshot.  Normally that is harmless, but not  
if the cached statement is one that needs to run without acquiring a  
snapshot.  We were already aware of that for TransactionStmts,  
but for some reason hadn't extrapolated to the other statements that  
PlannedStmtRequiresSnapshot() knows mustn't set a snapshot.  This can  
lead to unexpected failures of commands such as SET TRANSACTION  
ISOLATION LEVEL.  We can fix it in the same way, by excluding those  
command types from revalidation.  
  
However, we can do even better than that: there is no need to  
revalidate for any statement type for which parse analysis, rewrite,  
and plan steps do nothing interesting, which is nearly all utility  
commands.  To mechanize this, invent a parser function  
stmt_requires_parse_analysis() that tells whether parse analysis does  
anything beyond wrapping a CMD_UTILITY Query around the raw parse  
tree.  If that's what it does, then rewrite and plan will just  
skip the Query, so that it is not possible for the same raw parse  
tree to produce a different plan tree after cache invalidation.  
  
stmt_requires_parse_analysis() is basically equivalent to the  
existing function analyze_requires_snapshot(), except that for  
obscure reasons that function omits ReturnStmt and CallStmt.  
It is unclear whether those were oversights or intentional.  
I have not been able to demonstrate a bug from not acquiring a  
snapshot while analyzing these commands, but at best it seems mighty  
fragile.  It seems safer to acquire a snapshot for parse analysis of  
these commands too, which allows making stmt_requires_parse_analysis  
and analyze_requires_snapshot equivalent.  
  
In passing this fixes a second bug, which is that ResetPlanCache  
would exclude ReturnStmts and CallStmts from revalidation.  
That's surely *not* safe, since they contain parsable expressions.  
  
Per bug #18059 from Pavel Kulakov.  Back-patch to all supported  
branches.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : ce18252d0b48d206d42cfbe1028e48d776e01831    
  
author   : Peter Eisentraut <[email protected]>    
date     : Thu, 24 Aug 2023 14:22:02 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Thu, 24 Aug 2023 14:22:02 +0200    

commit   : 4cdcff4d93b202fd30e6b3927874af9002247779    
  
author   : Peter Eisentraut <[email protected]>    
date     : Thu, 24 Aug 2023 13:59:40 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Thu, 24 Aug 2023 13:59:40 +0200    

Update source code comment changes belonging to the changes in  
6a6389a08b.  
  
Discussion: https://www.postgresql.org/message-id/flat/[email protected]  

commit   : 155c81463c26d908a1579b6d90e7b39b6f61df8b    
  
author   : Peter Eisentraut <[email protected]>    
date     : Tue, 22 Aug 2023 14:12:45 +0200    
  
committer: Thomas Munro <[email protected]>    
date     : Tue, 22 Aug 2023 14:12:45 +0200    

Commit 319bae9a renamed the GUC.  Rename the check and assign functions  
to match, and alphabetize.  
  
Back-patch to 16.  
  
Author: Peter Eisentraut <[email protected]>  
Discussion: https://postgr.es/m/2769341e-fa28-c2ee-3e4b-53fdcaaf2271%40eisentraut.org  

commit   : 13e2665df3d01de5b0e039eb41b5e358e2b29ae5    
  
author   : Amit Kapila <[email protected]>    
date     : Thu, 24 Aug 2023 14:51:57 +0530    
  
committer: Amit Kapila <[email protected]>    
date     : Thu, 24 Aug 2023 14:51:57 +0530    

The SnapBuildRestoreContents() used a const value in the error message to  
indicate the size in bytes it was expecting to read from the serialized  
snapshot file. Fix it by reporting the size that was actually passed.  
  
Author: Hou Zhijie  
Reviewed-by: Amit Kapila  
Backpatch-through: 16  
Discussion: http://postgr.es/m/OS0PR01MB5716D408364F7DF32221C08D941FA@OS0PR01MB5716.jpnprd01.prod.outlook.com  

commit   : 8179d1bdf7763bab8a55022268bcfada011e8a4f    
  
author   : Peter Eisentraut <[email protected]>    
date     : Thu, 24 Aug 2023 10:24:38 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Thu, 24 Aug 2023 10:24:38 +0200    

Conditionals cannot be inside gettext trigger functions, they must be  
applied outside.  

commit   : 8fa09a11c994b85a4f4e6c09c5465f561b17c22b    
  
author   : Peter Eisentraut <[email protected]>    
date     : Thu, 24 Aug 2023 08:23:43 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Thu, 24 Aug 2023 08:23:43 +0200    

The parenthesized plural is unnecessary here and inconsistent with  
nearby similar messages.  

commit   : 7d8e7036177a9fce94a6b99a5a12d65568556fde    
  
author   : Bruce Momjian <[email protected]>    
date     : Wed, 23 Aug 2023 21:33:03 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Wed, 23 Aug 2023 21:33:03 -0400    

Backpatch-through: 16 only  

commit   : 5a16984ff1f3556f4bd29723e11d3594f41db90b    
  
author   : David Rowley <[email protected]>    
date     : Thu, 24 Aug 2023 10:33:48 +1200    
  
committer: David Rowley <[email protected]>    
date     : Thu, 24 Aug 2023 10:33:48 +1200    

The meson build scripts attempt to find files left over from configure  
and fail, mentioning that "make maintainer-clean" should be run to remove  
these.  This seems to have been done for files generated from configure.  
pg_config_paths.h is generated during the actual make build, so seems to  
have been missed.  This would result in compilation using the wrong  
pg_config_paths.h file.  
  
Here we just add this file to generated_sources_ac so that meson errors  
out if pg_config_paths.h exists.  
  
Likely this wasn't noticed before because make maintainer-clean will  
remove pg_config_paths.h, however, people using the MSVC build scripts  
are more likely to run into issues and they have to manually remove  
these files and pg_config_paths.h wasn't listed as a conflicting file to  
remove in the meson log.  
  
Backpatch-through: 16, where meson support was added  
Discussion: https://postgr.es/m/CAApHDvqjYOxZfmLKAOWKFEE7LOr9_E6UA6YNmx9r8nxStcS3gg@mail.gmail.com  

commit   : e8a8cd05d4b9533cf5bff0f4a4ee83a40df62875    
  
author   : Andres Freund <[email protected]>    
date     : Wed, 23 Aug 2023 15:15:28 -0700    
  
committer: Andres Freund <[email protected]>    
date     : Wed, 23 Aug 2023 15:15:28 -0700    

See prior commit for an explanation for the goal of the change and why it had  
to be split into two commits.  
  
Reviewed-by: Daniel Gustafsson <[email protected]>  
Reviewed-by: Nazir Bilal Yavuz <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  
Backpatch: 15-, where CI support was added  

commit   : 9ed46c78a3625001a863bbcbfd5f1c696c1def46    
  
author   : Andres Freund <[email protected]>    
date     : Wed, 23 Aug 2023 15:15:28 -0700    
  
committer: Andres Freund <[email protected]>    
date     : Wed, 23 Aug 2023 15:15:28 -0700    

cirrus-ci will soon restrict the amount of free resources every user gets (as  
have many other CI providers). For most users of CI that should not be an  
issue. But e.g. for cfbot it will be an issue.  
  
To allow configuring different resources on a per-repository basis, introduce  
infrastructure for overriding the task execution environment. Unfortunately  
this is not entirely trivial, as yaml anchors have to be defined before their  
use, and cirrus-ci only allows injecting additional contents at the end of  
.cirrus.yml.  
  
To deal with that, move the definition of the CI tasks to  
.cirrus.tasks.yml. The main .cirrus.yml is loaded first, then, if defined, the  
file referenced by the REPO_CI_CONFIG_GIT_URL variable, will be added,  
followed by the contents of .cirrus.tasks.yml. That allows  
REPO_CI_CONFIG_GIT_URL to override the yaml anchors defined in .cirrus.yml.  
  
Unfortunately git's default merge / rebase strategy does not handle copied  
files, just renamed ones. To avoid painful rebasing over this change, this  
commit just renames .cirrus.yml to .cirrus.tasks.yml, without adding a new  
.cirrus.yml. That's done in the followup commit, which moves the relevant  
portion of .cirrus.tasks.yml to .cirrus.yml.  Until that is done,  
REPO_CI_CONFIG_GIT_URL does not fully work.  
  
The subsequent commit adds documentation for how to configure custom compute  
resources to src/tools/ci/README  
  
Reviewed-by: Daniel Gustafsson <[email protected]>  
Reviewed-by: Nazir Bilal Yavuz <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  
Backpatch: 15-, where CI support was added  

commit   : f518c909ead1be7c88ee1f53db13bdef7c50d1ca    
  
author   : Andres Freund <[email protected]>    
date     : Wed, 23 Aug 2023 12:29:50 -0700    
  
committer: Andres Freund <[email protected]>    
date     : Wed, 23 Aug 2023 12:29:50 -0700    

The main reason for this change is to reduce different ways of executing  
tasks, making it easier to use custom compute resources for cfbot. A secondary  
benefit is that the tasks seem slightly faster this way, apparently the  
increased startup overhead is outweighed by reduced runtime overhead.  
  
Reviewed-by: Daniel Gustafsson <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  
Backpatch: 15-, where CI support was added  

commit   : cad461b044b521c5f80d180194d6e27dce82c424    
  
author   : Andres Freund <[email protected]>    
date     : Wed, 23 Aug 2023 12:27:40 -0700    
  
committer: Andres Freund <[email protected]>    
date     : Wed, 23 Aug 2023 12:27:40 -0700    

This is done in preparation for making the compute resources for CI  
configurable. It also looks cleaner.  
  
Reviewed-by: Daniel Gustafsson <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  
Backpatch: 15-, where CI support was added  

commit   : 5581a9a3953020dd9df18ffd00b788f296bd60e0    
  
author   : Andres Freund <[email protected]>    
date     : Wed, 23 Aug 2023 12:27:29 -0700    
  
committer: Andres Freund <[email protected]>    
date     : Wed, 23 Aug 2023 12:27:29 -0700    

The number of CPUs is the cost-determining factor. Most instance types that  
run tests have more memory/core than what we specified, there's no real  
benefit in wasting that.  
  
Reviewed-by: Daniel Gustafsson <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  
Backpatch: 15-, where CI support was added  

commit   : c3b874c431bc5d1399c011e9e5ce1e30b756f930    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Wed, 23 Aug 2023 18:08:40 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Wed, 23 Aug 2023 18:08:40 +0300    

_bt_allequalimage() does complicated things, so it's not OK to call it  
in a critical section. Per buildfarm failure on 'prion', which uses  
-DRELCACHE_FORCE_RELEASE -DCATCACHE_FORCE_RELEASE options.  
  
Discussion: https://www.postgresql.org/message-id/[email protected]  
Backpatch-through: 16, like commit ccadf73163 that introduced this  

commit   : 6bc1fd4e60e9556ba5e04710049fdf42e3134f47    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Wed, 23 Aug 2023 17:21:31 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Wed, 23 Aug 2023 17:21:31 +0300    

Some of the ambuildempty functions used smgrwrite() directly, followed  
by smgrimmedsync(). A few small problems with that:  
  
Firstly, one is supposed to use smgrextend() when extending a  
relation, not smgrwrite(). It doesn't make much difference in  
production builds. smgrextend() updates the relation size cache, so  
you miss that, but that's harmless because we never use the cached  
relation size of an init fork. But if you compile with  
CHECK_WRITE_VS_EXTEND, you get an assertion failure.  
  
Secondly, the smgrwrite() calls were performed before WAL-logging, so  
the page image written to disk had 0/0 as the LSN, not the LSN of the  
WAL record. That's also harmless in practice, but seems sloppy.  
  
Thirdly, it's better to use the buffer cache, because then you don't  
need to smgrimmedsync() the relation to disk, which adds latency.  
Bypassing the cache makes sense for bulk operations like index  
creation, but not when you're just initializing an empty index.  
Creation of unlogged tables is hardly performance bottleneck in any  
real world applications, but nevertheless.  
  
Backpatch to v16, but no further. These issues should be harmless in  
practice, so better to not rock the boat in older branches.  
  
Reviewed-by: Robert Haas  
Discussion: https://www.postgresql.org/message-id/[email protected]  

commit   : 5fd424c87a86dd19d6cb15a18d1662ffc7368de1    
  
author   : Daniel Gustafsson <[email protected]>    
date     : Wed, 23 Aug 2023 14:13:07 +0200    
  
committer: Daniel Gustafsson <[email protected]>    
date     : Wed, 23 Aug 2023 14:13:07 +0200    

The list of external language drivers and procedural languages was  
never complete or exhaustive, and rather than attempting to manage  
it the content has migrated to the wiki.  This replaces the tables  
altogether with links to the wiki as we regularly get requests for  
adding various projects,  which we reject without any clear policy  
for why or how the content should be managed.  
  
The threads linked to below are the most recent discussions about  
this, the archives contain many more.  
  
Backpatch to all supported branches since the list on the wiki  
applies to all branches.  
  
Author: Jonathan Katz <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: v11  

commit   : 103df207a71e74d64173edcb7bacec872933755b    
  
author   : Peter Eisentraut <[email protected]>    
date     : Wed, 23 Aug 2023 11:23:42 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Wed, 23 Aug 2023 11:23:42 +0200    

In particular, add an example EBCDIC collation.  
  
Author: Daniel Verite <[email protected]>  
Discussion: https://www.postgresql.org/message-id/flat/[email protected]  

commit   : 0b9127de12daf4b6eb33766a592c38fda3853bff    
  
author   : Peter Eisentraut <[email protected]>    
date     : Wed, 23 Aug 2023 08:25:56 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Wed, 23 Aug 2023 08:25:56 +0200    

It previously pointed to the collation API documentation, which our  
users don't need, but the containing chapter seems useful.  

commit   : 6f168e077e4671ecc0796e9aeb7ad61fc3e5b6dd    
  
author   : Peter Eisentraut <[email protected]>    
date     : Wed, 23 Aug 2023 08:12:50 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Wed, 23 Aug 2023 08:12:50 +0200    

commit   : f58af9f416f95b1b396aab55c5978f277fe13ac7    
  
author   : Thomas Munro <[email protected]>    
date     : Wed, 23 Aug 2023 12:10:18 +1200    
  
committer: Thomas Munro <[email protected]>    
date     : Wed, 23 Aug 2023 12:10:18 +1200    

Commit 31966b15 invented a way for functions dealing with relation  
extension to accept a Relation in online code and an SMgrRelation in  
recovery code.  It seems highly likely that future bufmgr.c interfaces  
will face the same problem, and need to do something similar.  
Generalize the names so that each interface doesn't have to re-invent  
the wheel.  
  
Back-patch to 16.  Since extension AM authors might start using the  
constructor macros once 16 ships, we agreed to do the rename in 16  
rather than waiting for 17.  
  
Reviewed-by: Peter Geoghegan <[email protected]>  
Reviewed-by: Andres Freund <[email protected]>  
Discussion: https://postgr.es/m/CA%2BhUKG%2B6tLD2BhpRWycEoti6LVLyQq457UL4ticP5xd8LqHySA%40mail.gmail.com  

commit   : d8cd49e992eb0d0f3d447d6b41866ce1b573b01d    
  
author   : Bruce Momjian <[email protected]>    
date     : Tue, 22 Aug 2023 19:37:26 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Tue, 22 Aug 2023 19:37:26 -0400    

Backpatch-through: 16 only  

commit   : 501704e826fc75d7d1c8976a8d177f8ce3ea0b4c    
  
author   : Jeff Davis <[email protected]>    
date     : Tue, 22 Aug 2023 11:21:36 -0700    
  
committer: Jeff Davis <[email protected]>    
date     : Tue, 22 Aug 2023 11:21:36 -0700    

Commit 396d348b04 did not account for the default collation.  
  
Also, use pg_log_warning() instead of Assert().  
  
Discussion: https://postgr.es/m/ce071503fee88334aa70f360e6e4ea14d48305ee.camel%40j-davis.com  
Reviewed-by: Michael Paquier  
Backpatch-through: 15  

commit   : f938acd68b08704a086b5f41eaf1989026d6f013    
  
author   : Andrew Dunstan <[email protected]>    
date     : Tue, 22 Aug 2023 11:57:08 -0400    
  
committer: Andrew Dunstan <[email protected]>    
date     : Tue, 22 Aug 2023 11:57:08 -0400    

Attribute missing values might be needed past the lifetime of the tuple  
descriptors from which they are extracted. To avoid possibly using  
pointers for by-reference values which might thus be left dangling, we  
cache a datumCopy'd version of the datum in the TopMemoryContext. Since  
we first search for the value this only needs to be done once per  
session for any such value.  
  
Original complaint from Tom Lane, idea for mitigation by Andrew Dunstan,  
tweaked by Tom Lane.  
  
Backpatch to version 11 where missing values were introduced.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : e9f535463a12af2d4e7973dbf1db53c7097df31b    
  
author   : Bruce Momjian <[email protected]>    
date     : Tue, 22 Aug 2023 15:15:24 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Tue, 22 Aug 2023 15:15:24 -0400    

Reported-by: Pavel Luzanov  
  
Discussion: https://postgr.es/m/[email protected]  
  
Backpatch-through: 16 only  

commit   : 8c76a556658ddb56e33be5507131874776c00907    
  
author   : Peter Eisentraut <[email protected]>    
date     : Tue, 22 Aug 2023 10:54:16 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Tue, 22 Aug 2023 10:54:16 +0200    

This contains all individuals mentioned in the commit messages during  
PostgreSQL 16 development.  
  
current through REL_16_BETA3  

commit   : 7fb906d80aa07cd83ada2a60588679e68f635939    
  
author   : Bruce Momjian <[email protected]>    
date     : Mon, 21 Aug 2023 18:55:41 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Mon, 21 Aug 2023 18:55:41 -0400    

Reported-by: Erwin Brandstetter  
  
Discussion: https://postgr.es/m/CAGHENJ5Cj3wBH07YM5Lw2h5q8s65cNg_NEdkkWvmRo+vOormWw@mail.gmail.com  
  
Backpatch-through: 16 only  

commit   : 00be0bc3d57f1b01249429bc0a154ecb41e02e7f    
  
author   : Bruce Momjian <[email protected]>    
date     : Mon, 21 Aug 2023 17:54:29 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Mon, 21 Aug 2023 17:54:29 -0400    

Also split out new role ADMIN syntax entry.  
  
Reported-by: Pavel Luzanov  
  
Discussion: https://postgr.es/m/[email protected]  
  
Backpatch-through: 16 only  

commit   : d6af45052dc8a9d97a18e1a3b9febabd891ba270    
  
author   : Michael Paquier <[email protected]>    
date     : Mon, 21 Aug 2023 13:33:04 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Mon, 21 Aug 2023 13:33:04 +0900    

This commit fixes the function of $subject for shared relations.  This  
feature has been added by e042678.  Unfortunately, this new behavior got  
removed by 5891c7a when moving statistics to shared memory.  
  
Reported-by: Mitsuru Hinata  
Author: Masahiro Ikeda  
Reviewed-by: Kyotaro Horiguchi, Masahiko Sawada  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 15  

commit   : dd2a731d9caffa8c9f6d82f2b72dd460b67decd7    
  
author   : Andres Freund <[email protected]>    
date     : Sat, 19 Aug 2023 12:40:45 -0700    
  
committer: Andres Freund <[email protected]>    
date     : Sat, 19 Aug 2023 12:40:45 -0700    

A significant chunk of the time on the macos CI task is spent installing  
packages using homebrew. The downloads of the packages are cached, but the  
installation needs to happen every time. We can't cache the whole homebrew  
installation, because it is too large due to pre-installed packages.  
  
Speed this up by installing packages using macports and caching the  
installation as .dmg. That's a lot faster than unpacking a tarball.  
  
In addition, don't install llvm - it wasn't enabled when building, so it's  
just a waste of time/space.  
  
This substantially speeds up the mac CI time, both in the cold cache and in  
the warm cache case (the latter from ~1m20s to ~5s).  
  
It doesn't seem great to have diverging sources of packages for CI between  
branches, so backpatch to 15 (where CI was added).  
  
Discussion: https://postgr.es/m/[email protected]  
Backpatch: 15-, where CI was added  

commit   : dcfc49c1b652dfe41273579aeaf6b454c51f037b    
  
author   : Peter Eisentraut <[email protected]>    
date     : Fri, 18 Aug 2023 07:41:14 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Fri, 18 Aug 2023 07:41:14 +0200    

There was a warning that FORMAT JSON has no effect on json/jsonb  
types, which is true, but it's not clear why we should issue a warning  
about it.  The SQL standard does not say anything about this, which  
should generally govern the behavior here.  So remove it.  
  
Discussion: https://www.postgresql.org/message-id/flat/dfec2cae-d17e-c508-6d16-c2dba82db486%40eisentraut.org  

commit   : 6337e994e89797d60b68ac6786c6a322ac00a382    
  
author   : Thomas Munro <[email protected]>    
date     : Thu, 17 Aug 2023 15:45:13 +1200    
  
committer: Thomas Munro <[email protected]>    
date     : Thu, 17 Aug 2023 15:45:13 +1200    

In rare circumstances involving relfilenode reuse, it might have been  
possible for smgr_targblock to finish up pointing past the end.  
  
Oversight in b74e94dc.  Back-patch to 15.  
  
Reviewed-by: Heikki Linnakangas <[email protected]>  
Discussion: https://postgr.es/m/CA%2BhUKGJ8NTvqLHz6dqbQnt2c8XCki4r2QvXjBQcXpVwxTY_pvA%40mail.gmail.com  

commit   : 11f4935490eb8597fcc0e3e71c2caf90e6154943    
  
author   : Bruce Momjian <[email protected]>    
date     : Wed, 16 Aug 2023 22:22:12 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Wed, 16 Aug 2023 22:22:12 -0400    

Backpatch-through: 16 only  

commit   : 6b86a3e0b421a0e0c9cfa02ddc0525e431379ee4    
  
author   : Bruce Momjian <[email protected]>    
date     : Wed, 16 Aug 2023 14:34:49 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Wed, 16 Aug 2023 14:34:49 -0400    

Still need to add links to doc sections.  
  
Backpatch-through: 16 only  

commit   : c672262779833a6b58cf5a4e85a9b76efd660cb7    
  
author   : Peter Eisentraut <[email protected]>    
date     : Wed, 16 Aug 2023 16:17:00 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Wed, 16 Aug 2023 16:17:00 +0200    

We had essentially the same error in several different wordings.  
Unify that.  

commit   : 842b65905046be8a979a67484c9fd4110e4e2dfe    
  
author   : Peter Eisentraut <[email protected]>    
date     : Wed, 16 Aug 2023 15:09:50 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Wed, 16 Aug 2023 15:09:50 +0200    

Discussion: https://www.postgresql.org/message-id/CAHut+PtfzQ7JRkb0-Y_UejAxaLQ17-bGMvV4MJJHcPoP3ML2bg@mail.gmail.com  

commit   : c5c8bd29b9a22a05f81857c6921c0bc615140cc5    
  
author   : Bruce Momjian <[email protected]>    
date     : Tue, 15 Aug 2023 09:15:21 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Tue, 15 Aug 2023 09:15:21 -0400    

Backpatch-through: 16 only  

commit   : acc5c4fd8f83e5991cab11d7299d112e89cb3fe7    
  
author   : Thomas Munro <[email protected]>    
date     : Tue, 15 Aug 2023 10:20:11 +1200    
  
committer: Thomas Munro <[email protected]>    
date     : Tue, 15 Aug 2023 10:20:11 +1200    

Commit b91dd9de was concerned with a theoretical problem with our  
non-atomic condition variable operations.  If you stop sleeping, and  
then cancel the sleep in a separate step, you might be signaled in  
between, and that could be lost.  That doesn't matter for callers of  
ConditionVariableBroadcast(), but callers of ConditionVariableSignal()  
might be upset if a signal went missing like this.  
  
Commit bc971f4025c interacted badly with that logic, because it doesn't  
use ConditionVariableSleep(), which would normally put us back in the  
wait list.  ConditionVariableCancelSleep() would be confused and think  
we'd received an extra signal, and try to forward it to another backend,  
resulting in wakeup storms.  
  
New idea: ConditionVariableCancelSleep() can just return true if we've  
been signaled.  Hypothetical users of ConditionVariableSignal() would  
then still have a way to deal with rare lost signals if they are  
concerned about that problem.  
  
Back-patch to 16, where bc971f4025c arrived.  
  
Reported-by: Tomas Vondra <[email protected]>  
Reviewed-by: Andres Freund <[email protected]>  
Discussion: https://postgr.es/m/2840876b-4cfe-240f-0a7e-29ffd66711e7%40enterprisedb.com  

commit   : 03fb43f6ed63fd2d52bf8ec305893a31ef0a38e5    
  
author   : Bruce Momjian <[email protected]>    
date     : Mon, 14 Aug 2023 17:28:39 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Mon, 14 Aug 2023 17:28:39 -0400    

Backpatch-through: 16 only  

commit   : d37ab378b6e773c278c14b9554a1ea23b355aab9    
  
author   : Andres Freund <[email protected]>    
date     : Mon, 14 Aug 2023 09:54:03 -0700    
  
committer: Andres Freund <[email protected]>    
date     : Mon, 14 Aug 2023 09:54:03 -0700    

The new relation extension logic, introduced in 00d1e02be24, could lead to  
slowdowns in some scenarios. E.g., when loading narrow rows into a table using  
COPY, the caller of RelationGetBufferForTuple() will only request a small  
number of pages. Without concurrency, we just extended using pwritev() in that  
case. However, if there is *some* concurrency, we switched between extending  
by a small number of pages and a larger number of pages, depending on the  
number of waiters for the relation extension logic.  However, some  
filesystems, XFS in particular, do not perform well when switching between  
extending files using fallocate() and pwritev().  
  
To avoid that issue, remember the number of prior relation extensions in  
BulkInsertState and extend more aggressively if there were prior relation  
extensions. That not just avoids the aforementioned slowdown, but also leads  
to noticeable performance gains in other situations, primarily due to  
extending more aggressively when there is no concurrency. I should have done  
it this way from the get go.  
  
Reported-by: Masahiko Sawada <[email protected]>  
Author: Andres Freund <[email protected]>  
Discussion: https://postgr.es/m/CAD21AoDvDmUQeJtZrau1ovnT_smN940=Kp6mszNGK3bq9yRN6g@mail.gmail.com  
Backpatch: 16-, where the new relation extension code was added  

commit   : 2243ef8dd6fbe1f4ae3ffc7db1ee9af9427ecadb    
  
author   : Andres Freund <[email protected]>    
date     : Sat, 12 Aug 2023 13:09:45 -0700    
  
committer: Andres Freund <[email protected]>    
date     : Sat, 12 Aug 2023 13:09:45 -0700    

The option causes a measurable slowdown. Macos is, by far, the most expensive  
platform for CI, therefore it doesn't make sense to run such a test there.  
  
d3b111e3205 used a small segment size for two tasks, one with autoconf, one  
with meson. In hindsight that is a bit overkill, it's unlikely that the option  
would silently break. Thus don't move the -Dsegsize_blocks=6, just remove  
it. I did however change the autoconf test to use 6 instead of 8 blocks, as  
long as we allow it, a non-power-of-two test seems like a good idea.  
  
While at it, add a comment explaining why we use a small segment size for CI.  
  
Author: Andres Freund <[email protected]>  
Reviewed-by: Heikki Linnakangas <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  
Backpatch: 16-, where d3b111e3205 introduced the use of -Dsegsize_blocks=6  

commit   : 4bec616f26f5f39a6819804f2b7992495a1a7a6f    
  
author   : Andres Freund <[email protected]>    
date     : Sat, 12 Aug 2023 13:06:04 -0700    
  
committer: Andres Freund <[email protected]>    
date     : Sat, 12 Aug 2023 13:06:04 -0700    

RANDOMIZE_ALLOCATED_MEMORY causes a measurable slowdown. Macos is, by far, the  
most expensive platform for CI, therefore it doesn't make sense to run such a  
test there.  
  
Ubsan and asan on linux should detect most of the the cases of uninitialized  
memory, so it doesn't really seem worth using -DRANDOMIZE_ALLOCATED_MEMORY in  
another instance type.  
  
Author: Andres Freund <[email protected]>  
Reviewed-by: Heikki Linnakangas <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  
Backpatch: 16-, where 89d16b635 added the use of -DRANDOMIZE_ALLOCATED_MEMORY  

commit   : 7823a298ba5c54a67f98c928f73500bc4089449f    
  
author   : Noah Misch <[email protected]>    
date     : Sat, 12 Aug 2023 14:37:05 -0700    
  
committer: Noah Misch <[email protected]>    
date     : Sat, 12 Aug 2023 14:37:05 -0700    

pg_logical_emit_message(false, '_', repeat('x', 1069547465)) failed with  
self-contradictory message "WAL record would be 1069547520 bytes (of  
maximum 1069547520 bytes)".  There's no particular benefit from allowing  
or denying one byte in either direction; XLogRecordMaxSize could rise a  
few megabytes without trouble.  Hence, this is just for cleanliness.  
Back-patch to v16, where this check first appeared.  

commit   : 7bed93a469bfa6954ce937b72ef1dc76fda7159e    
  
author   : Jeff Davis <[email protected]>    
date     : Thu, 10 Aug 2023 10:16:59 -0700    
  
committer: Jeff Davis <[email protected]>    
date     : Thu, 10 Aug 2023 10:16:59 -0700    

The fix itself is fine, but the test revealed other problems related  
to parallel query that are not easily fixable. Remove the test for  
now to fix the buildfarm.  
  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 11  

commit   : 1b594a326a88bf1604360daa5a274096c0762fec    
  
author   : Alvaro Herrera <[email protected]>    
date     : Thu, 10 Aug 2023 12:04:07 +0200    
  
committer: Alvaro Herrera <[email protected]>    
date     : Thu, 10 Aug 2023 12:04:07 +0200    

Commit 19d8e2308bc5 changed the list of set-of-columns that can be  
returned by RelationGetIndexAttrBitmap, but didn't update its  
"documentation".  That was pretty hard to read already, so rewrite to  
make it more comprehensible, adding the missing values while at it.  
  
Backpatch to 16, like that commit.  
  
Discussion: https://postgr.es/m/[email protected]  
Reviewed-by: Tomas Vondra <[email protected]>  

commit   : c8c033f721de1e25c90acf146fabee77c9dbf92e    
  
author   : Bruce Momjian <[email protected]>    
date     : Wed, 9 Aug 2023 22:09:17 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Wed, 9 Aug 2023 22:09:17 -0400    

Backpatch-through: 16 only  

commit   : fc3e21282fae2b5b44c59e56e1fc4958915bd817    
  
author   : Bruce Momjian <[email protected]>    
date     : Wed, 9 Aug 2023 20:48:31 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Wed, 9 Aug 2023 20:48:31 -0400    

Reported-by: Noah Misch  
  
Discussion: https://postgr.es/m/[email protected]  
  
Backpatch-through: 16 only  

commit   : 0752461d3a1114d560225fae7522dde0ab544b63    
  
author   : Bruce Momjian <[email protected]>    
date     : Wed, 9 Aug 2023 20:37:41 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Wed, 9 Aug 2023 20:37:41 -0400    

Backpatch-through: 16 only  

commit   : 6e1d1c58488e685370de0becc5a81d6502a8e099    
  
author   : Bruce Momjian <[email protected]>    
date     : Wed, 9 Aug 2023 18:01:50 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Wed, 9 Aug 2023 18:01:50 -0400    

Reported-by: Noah Misch  
  
Discussion: https://postgr.es/m/[email protected]  
  
Backpatch-through: 16 only  

commit   : 89cadf30c605d509f12b0b7f80119cbba38efc6e    
  
author   : Bruce Momjian <[email protected]>    
date     : Wed, 9 Aug 2023 17:47:03 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Wed, 9 Aug 2023 17:47:03 -0400    

Reported-by: Michael Paquier  
  
Discussion: https://postgr.es/m/ZL0M28/[email protected]  
  
Backpatch-through: 16 only  

commit   : 0d56c32c8e724f96f4aa5b15645d427f6e2ddf21    
  
author   : Jeff Davis <[email protected]>    
date     : Mon, 7 Aug 2023 15:13:06 -0700    
  
committer: Jeff Davis <[email protected]>    
date     : Mon, 7 Aug 2023 15:13:06 -0700    

Renaming a role can affect the meaning of the special string $user, so  
must cause search_path to be recalculated.  
  
Discussion: https://postgr.es/m/[email protected]  
Reviewed-by: Nathan Bossart, Michael Paquier  
Backpatch-through: 11  

commit   : e90308ae6b4a468d089733cc6f650bda144c01cc    
  
author   : Bruce Momjian <[email protected]>    
date     : Wed, 9 Aug 2023 13:56:26 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Wed, 9 Aug 2023 13:56:26 -0400    

Reported-by: Erik Rijkers  
  
Discussion: https://postgr.es/m/[email protected]  
  
Backpatch-through: 16 only  

commit   : 98cb73f5c98de86e85a90c06babdd7b1a37540db    
  
author   : Bruce Momjian <[email protected]>    
date     : Wed, 9 Aug 2023 13:23:39 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Wed, 9 Aug 2023 13:23:39 -0400    

Reported-by: Laurenz Albe  
  
Discussion: https://postgr.es/m/[email protected]  
  
Backpatch-through: 16 only  

commit   : 86415153f47a4ad8e332262592e0a32f14f226c6    
  
author   : Bruce Momjian <[email protected]>    
date     : Wed, 9 Aug 2023 11:16:26 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Wed, 9 Aug 2023 11:16:26 -0400    

Feature was removed by commit 957445996f.  
  
Discussion: 957445996f  
  
Backpatch-through: 16  

commit   : 0dd5545378d79bc0080dd34824f428458cf7448d    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 7 Aug 2023 16:05:20 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 7 Aug 2023 16:05:20 -0400    

commit   : f53511010b72d7d314e22be7c63ef94792fee345    
  
author   : Noah Misch <[email protected]>    
date     : Mon, 7 Aug 2023 06:05:56 -0700    
  
committer: Noah Misch <[email protected]>    
date     : Mon, 7 Aug 2023 06:05:56 -0700    

Substituting such values in extension scripts facilitated SQL injection  
when @extowner@, @extschema@, or @extschema:...@ appeared inside a  
quoting construct (dollar quoting, '', or "").  No bundled extension was  
vulnerable.  Vulnerable uses do appear in a documentation example and in  
non-bundled extensions.  Hence, the attack prerequisite was an  
administrator having installed files of a vulnerable, trusted,  
non-bundled extension.  Subject to that prerequisite, this enabled an  
attacker having database-level CREATE privilege to execute arbitrary  
code as the bootstrap superuser.  By blocking this attack in the core  
server, there's no need to modify individual extensions.  Back-patch to  
v11 (all supported versions).  
  
Reported by Micah Gate, Valerie Woolard, Tim Carey-Smith, and Christoph  
Berg.  
  
Security: CVE-2023-39417  

commit   : e8386b2cef7741aa4e49870691d67f792d5f6789    
  
author   : Peter Eisentraut <[email protected]>    
date     : Mon, 7 Aug 2023 12:06:49 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Mon, 7 Aug 2023 12:06:49 +0200    

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

commit   : ae89129aa3555c263b8c3ccc4c0f1ef7e46201aa    
  
author   : David Rowley <[email protected]>    
date     : Mon, 7 Aug 2023 22:14:54 +1200    
  
committer: David Rowley <[email protected]>    
date     : Mon, 7 Aug 2023 22:14:54 +1200    

The use of Memoize was already disabled in normal joins when the join  
conditions had volatile functions per the code in  
match_opclause_to_indexcol().  Ordinarily, the parameterization for the  
inner side of a nested loop will be an Index Scan or at least eventually  
lead to an index scan (perhaps nested several joins deep). However, for  
lateral joins, that's not the case and seq scans can be parameterized  
too, so we can't rely on match_opclause_to_indexcol().  
  
Here we explicitly check the parameterization for volatile functions and  
don't consider the generation of a Memoize path when such functions  
are present.  
  
Author: Richard Guo  
Discussion: https://postgr.es/m/CAMbWs49nHFnHbpepLsv_yF3qkpCS4BdB-v8HoJVv8_=Oat0u_w@mail.gmail.com  
Backpatch-through: 14, where Memoize was introduced  

commit   : 67a007dc0cdb8578726c2000a7abc513109cb4a2    
  
author   : Dean Rasheed <[email protected]>    
date     : Mon, 7 Aug 2023 09:27:09 +0100    
  
committer: Dean Rasheed <[email protected]>    
date     : Mon, 7 Aug 2023 09:27:09 +0100    

If MERGE executes an UPDATE action on a table with row-level security,  
the code incorrectly applied the WITH CHECK clauses from the target  
table's INSERT policies to new rows, instead of the clauses from the  
table's UPDATE policies. In addition, it failed to check new rows  
against the target table's SELECT policies, if SELECT permissions were  
required (likely to always be the case).  
  
In addition, if MERGE executes a DO NOTHING action for matched rows,  
the code incorrectly applied the USING clauses from the target table's  
DELETE policies to existing target tuples. These policies were applied  
as checks that would throw an error, if they did not pass.  
  
Fix this, so that a MERGE UPDATE action applies the same RLS policies  
as a plain UPDATE query with a WHERE clause, and a DO NOTHING action  
does not apply any RLS checks (other than adding clauses from SELECT  
policies to the join).  
  
Back-patch to v15, where MERGE was introduced.  
  
Dean Rasheed, reviewed by Stephen Frost.  
  
Security: CVE-2023-39418  

commit   : f0a3805d7c44ed1c01668061bc2f6458e7b1369a    
  
author   : Etsuro Fujita <[email protected]>    
date     : Thu, 3 Aug 2023 17:45:01 +0900    
  
committer: Etsuro Fujita <[email protected]>    
date     : Thu, 3 Aug 2023 17:45:01 +0900    

Commit f49842d1e added a new callback for custom scan paths, but missed  
updating the documentation.  
  
Back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/CAPmGK15ODkN%2B%3DhkBCufj1HBW0x5OTb65Xuy7ryXchMdiCMpx_g%40mail.gmail.com  

commit   : c575e00230ed1262edb7845e2e9a22ec164bf9f0    
  
author   : Etsuro Fujita <[email protected]>    
date     : Thu, 3 Aug 2023 17:15:01 +0900    
  
committer: Etsuro Fujita <[email protected]>    
date     : Thu, 3 Aug 2023 17:15:01 +0900    

Commit e7cb7ee14 allowed custom scan providers to create CustomPath  
paths for join relations as well, but missed updating the comments.  
  
Back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/CAPmGK15ODkN%2B%3DhkBCufj1HBW0x5OTb65Xuy7ryXchMdiCMpx_g%40mail.gmail.com  

commit   : 5c0fcef76a44bb834d4d13685b877e62409e6984    
  
author   : Masahiko Sawada <[email protected]>    
date     : Wed, 2 Aug 2023 15:01:10 +0900    
  
committer: Masahiko Sawada <[email protected]>    
date     : Wed, 2 Aug 2023 15:01:10 +0900    

Commit 7259736a6 updated the comment but it was not correct since  
ReorderBufferLargestStreamableTopTXN() returns only top-level  
transactions.  
  
Reviewed-by: Amit Kapila  
Discussion: https://postgr.es/m/CAD21AoA9XB7OR86BqvrCe2dMYX%2BZv3-BvVmjF%3DGY2z6jN-kqjg%40mail.gmail.com  
Backpatch-through: 14  

commit   : 803660ea4c5d9d2b3c7e1b0a9fc4b99359ba0a85    
  
author   : Andres Freund <[email protected]>    
date     : Tue, 1 Aug 2023 11:22:03 -0700    
  
committer: Andres Freund <[email protected]>    
date     : Tue, 1 Aug 2023 11:22:03 -0700    

The stats regression test attempts to ensure that Buffer Access Strategy  
"reuses" are being counted in pg_stat_io by vacuuming a table which is larger  
than the size of the strategy ring. However, when shared buffers are in  
sufficiently high demand, another backend could evict one of the blocks in the  
strategy ring before the first backend has a chance to reuse the buffer. The  
backend using the strategy would then evict another shared buffer and add that  
buffer to the strategy ring. This counts as an eviction and not a reuse in  
pg_stat_io. Count both evictions and reuses in the test to ensure it does not  
fail incorrectly.  
  
Reported-by: Jeff Davis <[email protected]>,  
Author: Melanie Plageman <[email protected]>  
Reviewed-by: Alexander Lakhin <[email protected]>  
Reviewed-by: Masahiko Sawada <[email protected]>  
Discussion: https://postgr.es/m/CAAKRu_bNG27AxG9TdPtwsL6wg8AWbVckjmTL2t1HF=miDQuNtw@mail.gmail.com  

commit   : 4e2e75cd29eb7bc591afe30fd7425629fe2c5a5d    
  
author   : David Rowley <[email protected]>    
date     : Wed, 2 Aug 2023 12:06:08 +1200    
  
committer: David Rowley <[email protected]>    
date     : Wed, 2 Aug 2023 12:06:08 +1200    

Between 6fcda9aba and 1b6f632a3, the pg_strtoint functions became quite  
a bit slower in v16, despite efforts in 6b423ec67 to speed these up.  
  
Since the majority of cases for these functions will only contain  
base-10 digits, perhaps prefixed by a '-', it makes sense to have a  
special case for this and just fall back on the more complex version  
which processes hex, octal, binary and underscores if the fast path  
version fails to parse the string.  
  
While we're here, update the header comments for these functions to  
mention that hex, octal and binary formats along with underscore  
separators are now supported.  
  
Author: Andres Freund, David Rowley  
Reported-by: Masahiko Sawada  
Reviewed-by: Dean Rasheed, John Naylor  
Discussion: https://postgr.es/m/CAD21AoDvDmUQeJtZrau1ovnT_smN940%3DKp6mszNGK3bq9yRN6g%40mail.gmail.com  
Backpatch-through: 16, where 6fcda9aba and 1b6f632a3 were added  

commit   : b25acc302524cf61bee46e1aad5bebb276449270    
  
author   : David Rowley <[email protected]>    
date     : Wed, 2 Aug 2023 01:40:27 +1200    
  
committer: David Rowley <[email protected]>    
date     : Wed, 2 Aug 2023 01:40:27 +1200    

This was failing for queries which try to get the .type() of a  
jpiLikeRegex.  For example:  
  
select jsonb_path_query('["string", "string"]',  
                        '($[0] like_regex ".{7}").type()');  
  
Reported-by: Alexander Kozhemyakin  
Bug: #18035  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 12, where SQL/JSON path was added.  

commit   : 695f5deb7902865901eb2d50a70523af655c3a00    
  
author   : Etsuro Fujita <[email protected]>    
date     : Fri, 28 Jul 2023 15:45:01 +0900    
  
committer: Etsuro Fujita <[email protected]>    
date     : Fri, 28 Jul 2023 15:45:01 +0900    

Commit e7cb7ee14, which introduced the infrastructure for FDWs and  
custom scan providers to replace joins with scans, failed to add support  
handling of pseudoconstant quals assigned to replaced joins in  
createplan.c, leading to an incorrect plan without a gating Result node  
when postgres_fdw replaced a join with such a qual.  
  
To fix, we could add the support by 1) modifying the ForeignPath and  
CustomPath structs to store the list of RestrictInfo nodes to apply to  
the join, as in JoinPaths, if they represent foreign and custom scans  
replacing a join with a scan, and by 2) modifying create_scan_plan() in  
createplan.c to use that list in that case, instead of the  
baserestrictinfo list, to get pseudoconstant quals assigned to the join;  
but #1 would cause an ABI break.  So fix by modifying the infrastructure  
to just disallow replacing joins with such quals.  
  
Back-patch to all supported branches.  
  
Reported by Nishant Sharma.  Patch by me, reviewed by Nishant Sharma and  
Richard Guo.  
  
Discussion: https://postgr.es/m/CADrsxdbcN1vejBaf8a%2BQhrZY5PXL-04mCd4GDu6qm6FigDZd6Q%40mail.gmail.com  

commit   : de3f0e3fe0e7d44620111c5723504a3a6e8c046e    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 27 Jul 2023 11:56:35 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 27 Jul 2023 11:56:35 -0400    

Historically, hba.c limited tokens in the authentication configuration  
files (pg_hba.conf and pg_ident.conf) to less than 256 bytes.  We have  
seen a few reports of this limit causing problems; notably, for  
moderately-complex LDAP configurations.  Let's get rid of the fixed  
limit by using a StringInfo instead of a fixed-size buffer.  
This actually takes less code than before, since we can get rid of  
a nontrivial error recovery stanza.  It's doubtless a hair slower,  
but parsing the content of the HBA files should in no way be  
performance-critical.  
  
Although this is a pretty straightforward patch, it doesn't seem  
worth the risk to back-patch given the small number of complaints  
to date.  In released branches, we'll just raise MAX_TOKEN to  
ameliorate the problem.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : c1308ce2d9224f0ec08128ab35e161837f9a5105    
  
author   : David Rowley <[email protected]>    
date     : Thu, 27 Jul 2023 14:48:44 +1200    
  
committer: David Rowley <[email protected]>    
date     : Thu, 27 Jul 2023 14:48:44 +1200    

9f8377f7a added code to allow COPY FROM insert a column's default value  
when the input matches the DEFAULT string specified in the COPY command.  
  
Here we fix some inefficient code which needlessly palloc0'd an array to  
store if we should use the default value or input value for the given  
column.  This array was being palloc0'd and pfree'd once per row.  It's  
much more efficient to allocate this once and just reset the values once  
per row.  
  
Reported-by: Masahiko Sawada  
Author: Masahiko Sawada  
Discussion: https://postgr.es/m/CAD21AoDvDmUQeJtZrau1ovnT_smN940%3DKp6mszNGK3bq9yRN6g%40mail.gmail.com  
Backpatch-through: 16, where 9f8377f7a was introduced.  

commit   : b4f14d2e433bf9f2499f07bcaca07b9ff13d641b    
  
author   : Masahiko Sawada <[email protected]>    
date     : Wed, 26 Jul 2023 14:41:23 +0900    
  
committer: Masahiko Sawada <[email protected]>    
date     : Wed, 26 Jul 2023 14:41:23 +0900    

Commit 5764f611e used dclist_delete_from() to remove the proc from the  
wait queue. However, since it doesn't clear dist_node's next/prev to  
NULL, it could call RemoveFromWaitQueue() twice: when the process  
detects a deadlock and then when cleaning up locks on aborting the  
transaction. The waiting lock information is cleared in the first  
call, so it led to a crash in the second call.  
  
Backpatch to v16, where the change was introduced.  
  
Bug: #18031  
Reported-by: Justin Pryzby, Alexander Lakhin  
Reviewed-by: Andres Freund  
Discussion: https://postgr.es/m/ZKy4AdrLEfbqrxGJ%40telsasoft.com  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 16  

commit   : 35c85c3c9b90eb70937c8f409d2e7615b2bdb538    
  
author   : Masahiko Sawada <[email protected]>    
date     : Tue, 25 Jul 2023 15:09:31 +0900    
  
committer: Masahiko Sawada <[email protected]>    
date     : Tue, 25 Jul 2023 15:09:31 +0900    

Previously, when selecting an usable index for update/delete for the  
REPLICA IDENTITY FULL table, in IsIndexOnlyExpression(), we used to  
check if all index fields are not expressions. However, it was not  
necessary, because it is enough to check if only the leftmost index  
field is not an expression (and references the remote table column)  
and this check has already been done by  
RemoteRelContainsLeftMostColumnOnIdx().  
  
This commit removes IsIndexOnlyExpression() and  
RemoteRelContainsLeftMostColumnOnIdx() and all checks for usable  
indexes for REPLICA IDENTITY FULL tables are now performed by  
IsIndexUsableForReplicaIdentityFull().  
  
Backpatch this to remain the code consistent.  
  
Reported-by: Peter Smith  
Reviewed-by: Amit Kapila, Önder Kalacı  
Discussion: https://postgr.es/m/CAHut%2BPsGRE5WSsY0jcLHJEoA17MrbP9yy8FxdjC_ZOAACxbt%2BQ%40mail.gmail.com  
Backpatch-through: 16  

commit   : ad486b0eaef4b2fcb7c672fcbf5c2f31eb99ac83    
  
author   : Amit Kapila <[email protected]>    
date     : Tue, 25 Jul 2023 09:01:29 +0530    
  
committer: Amit Kapila <[email protected]>    
date     : Tue, 25 Jul 2023 09:01:29 +0530    

We include the message type while displaying an error context in the  
apply worker. Now, while retrieving the message type string if the  
message type is unknown we throw an error that will hide the original  
error. So, instead, we need to simply return the string indicating an  
unknown message type.  
  
Reported-by: Ashutosh Bapat  
Author: Euler Taveira, Amit Kapila  
Reviewed-by: Ashutosh Bapat  
Backpatch-through: 15  
Discussion: https://postgr.es/m/CAExHW5suAEDW-mBZt_qu4RVxWZ1vL54-L+ci2zreYWebpzxYsA@mail.gmail.com  

commit   : bd2f46c6559ddcafe7bae5015ac45b69bc014067    
  
author   : Andres Freund <[email protected]>    
date     : Mon, 24 Jul 2023 19:07:52 -0700    
  
committer: Andres Freund <[email protected]>    
date     : Mon, 24 Jul 2023 19:07:52 -0700    

Due to the bug LimitAdditionalPins() could return 0, violating  
LimitAdditionalPins()'s API ("One additional pin is always allowed"). This  
could be hit when setting shared_buffers very low and using a fair amount of  
concurrency.  
  
This bug was introduced in 31966b151e6a.  
  
Author: "Anton A. Melnikov" <[email protected]>  
Reported-by: "Anton A. Melnikov" <[email protected]>  
Reported-by: Victoria Shepard  
Discussion: https://postgr.es/m/[email protected]  
Backpatch: 16-  

commit   : b1dc946eee3d8d4fd9776ccbc21bcb4ab747b998    
  
author   : Alvaro Herrera <[email protected]>    
date     : Mon, 24 Jul 2023 17:48:06 +0200    
  
committer: Alvaro Herrera <[email protected]>    
date     : Mon, 24 Jul 2023 17:48:06 +0200    

Some of the test_decoding test output was extremely wide, because it  
deals with massive toasted values, and the aligned mode causes psql to  
produce 200kB of whitespace and dashes. Change to unaligned mode  
temporarily to avoid that behavior.  
  
Backpatch to 14, where it applies cleanly.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 28ce9d51f9082318e84f2a84385871394dcf2130    
  
author   : Alvaro Herrera <[email protected]>    
date     : Mon, 24 Jul 2023 17:14:22 +0200    
  
committer: Alvaro Herrera <[email protected]>    
date     : Mon, 24 Jul 2023 17:14:22 +0200    

Because PostgreSQL::Version is very nuanced about development version  
numbers, the comparison to 16beta2 makes it think that that release is  
older than 16, therefore applying a database tweak that doesn't work  
there (the comparison is only supposed to match when run on version 15).  
As suggested by Andrew Dunstan, fix by having AdjustUpgrade.pm public  
methods create a separate PostgreSQL::Version object to use for these  
comparisons, that only carries the major version number.  
  
While at it, have the same methods ensure that the objects given are of  
the expected type.  
  
Backpatch to 16.  This module goes all the way back to 9.2, but there's  
probably no need for this fix except where betas still live.  
  
Co-authored-by: Andrew Dunstan <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  

commit   : 11237e5a46ca2221aca5c74bf43bb58eff8dcc3b    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 22 Jul 2023 10:32:52 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 22 Jul 2023 10:32:52 -0400    

After 3c90dcd03, try_partitionwise_join's child_joinrelids  
variable is read only in an Assert, provoking a compiler  
warning in non-assert builds.  Rearrange code to avoid the  
warning and eliminate unnecessary work in the non-assert case.  
  
Per CI testing (via Jeff Davis and Bharath Rupireddy)  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : f75595cd80d134d5a63929a90a0347ff9729b79a    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 21 Jul 2023 12:00:14 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 21 Jul 2023 12:00:14 -0400    

Applying add_outer_joins_to_relids() to a child join doesn't actually  
work, even if we've built a SpecialJoinInfo specialized to the child,  
because that function will also compare the join's relids to elements  
of the main join_info_list, which only deal in regular relids not  
child relids.  This mistake escaped detection by the existing  
partitionwise join tests because they didn't test any cases where  
add_outer_joins_to_relids() needs to add additional OJ relids (that  
is, any cases where join reordering per identity 3 is possible).  
  
Instead, let's apply adjust_child_relids() to the relids of the parent  
join.  This requires minor code reordering to collect the relevant  
AppendRelInfo structures first, but that's work we'd do shortly anyway.  
  
Report and fix by Richard Guo; cosmetic changes by me  
  
Discussion: https://postgr.es/m/CAMbWs49NCNbyubZWgci3o=_OTY=snCfAPtMnM-32f3mm-K-Ckw@mail.gmail.com  

commit   : 66a9003e2e3ec05e9b62d6bfb6797fa35fb01d15    
  
author   : Amit Langote <[email protected]>    
date     : Fri, 21 Jul 2023 19:28:31 +0900    
  
committer: Amit Langote <[email protected]>    
date     : Fri, 21 Jul 2023 19:28:31 +0900    

A CaseTestExpr is currently being put into  
JsonValueExpr.formatted_expr as placeholder for the result of  
evaluating JsonValueExpr.raw_expr, which in turn is evaluated  
separately.  Though, there's no need for this indirection if  
raw_expr itself can be embedded into formatted_expr and evaluated  
as part of evaluating the latter, especially as there is no  
special reason to evaluate it separately.  So this commit makes it  
so.  As a result, JsonValueExpr.raw_expr no longer needs to be  
evaluated in ExecInterpExpr(), eval_const_exprs_mutator() etc. and  
is now only used for displaying the original "unformatted"  
expression in ruleutils.c.  Comments about and the code manipulating  
formatted_expr is updated to mention that it is now always set and  
is the expression that gives a JsonValueExpr its runtime value.  
  
While at it, this also removes the function makeCaseTestExpr(),  
because the code in makeJsonConstructorExpr() looks more readable  
without it IMO and isn't used by anyone else either.  
  
Finally, a note is added in the comment above CaseTestExpr's  
definition that JsonConstructorExpr is also using it.  
  
Backpatched to 16 from the development branch to keep the code in  
sync across branches.  
  
Reviewed-by: Álvaro Herrera <[email protected]>  
Discussion: https://postgr.es/m/CA+HiwqE4XTdfb1nW=Ojoy_tQSRhYt-q_kb6i5d4xcKyrLC1Nbg@mail.gmail.com  

commit   : c0f53139611cf6b24175bea27bfbddb0ea5b7378    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 20 Jul 2023 14:23:46 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 20 Jul 2023 14:23:46 -0400    

If both the passed-in plan pointer and plansource->gplan are  
NULL, CachedPlanIsSimplyValid would think that the plan pointer  
is possibly-valid and try to dereference it.  For the one extant  
call site in plpgsql, this situation doesn't normally happen  
which is why we've not noticed. However, it appears to be possible  
if the previous use of the cached plan failed, as per report from  
Justin Pryzby.  Add an extra check to prevent crashing.  
Back-patch to v13 where this code was added.  
  
Discussion: https://postgr.es/m/ZLlV+STFz1l/[email protected]  

commit   : 7825a1b01e400434835253b4ff38dd96d823d454    
  
author   : Amit Langote <[email protected]>    
date     : Thu, 20 Jul 2023 16:23:49 +0900    
  
committer: Amit Langote <[email protected]>    
date     : Thu, 20 Jul 2023 16:23:49 +0900    

This allows it to pass to coerce_to_specific_type() the actual name  
corresponding to the specific JSON_* function expression being  
transformed, instead of the currently hardcoded string.  
  
Backpatched to 16 from the development branch to keep the code in  
sync across branches.  
  
Reviewed-by: Álvaro Herrera <[email protected]>  
Discussion: https://postgr.es/m/CA+HiwqHu58pO3cJ7rB6ZLwUztVdG1J66xSjDdjfan5uT5NhESw@mail.gmail.com  

commit   : 0a1d2a7df852f16c452eef8a83003943125162c7    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 19 Jul 2023 12:46:30 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 19 Jul 2023 12:46:30 -0400    

With the addition of INHERIT and SET options for role grants,  
the historical display of role memberships in \du/\dg is woefully  
inadequate.  Besides those options, there are pre-existing  
shortcomings that you can't see the ADMIN option nor the grantor.  
  
To fix this, remove the "Member of" column from \du/\dg altogether  
(making that output usefully narrower), and invent a new meta-command  
"\drg" that is specifically for displaying role memberships.  It  
shows one row for each role granted to the selected role(s), with  
the grant options and grantor.  
  
We would not normally back-patch such a feature addition post  
feature freeze, but in this case the change is mainly driven by  
v16 changes in the server, so it seems appropriate to include it  
in v16.  
  
Pavel Luzanov, with bikeshedding and review from a lot of people,  
but particularly David Johnston  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 245d0e6d0d1cc563c986fa34736b111bdf260af0    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 19 Jul 2023 11:00:34 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 19 Jul 2023 11:00:34 -0400    

IN and NOT IN work fine on records and arrays, so just say that  
they accept "expressions" not "scalar expressions".  I think that  
that phrasing was meant to say that they don't work on set-returning  
expressions, but that's not the common meaning of "scalar".  
  
Revise the description of row-constructor comparisons to make it  
perhaps a bit less confusing.  (This partially reverts some  
dubious wording changes made by commit f56651519.)  
  
Per gripe from Ilya Nenashev.  Back-patch to supported branches.  
In HEAD and v16, also drop a NOTE about pre-8.2 behavior, which  
is hopefully no longer of interest to anybody.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : e6e451c1d7e5bc70f0f3a63cbf06eb298f56a76e    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 18 Jul 2023 11:59:39 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 18 Jul 2023 11:59:39 -0400    

The "count" argument of SPI_exec() only limits execution when  
the query is actually returning rows.  This was not the case  
before PG 9.0, so this example was correct when written; but  
we missed updating it in commit 2ddc600f8.  Extend the example  
to show the behavior both with and without RETURNING.  
  
While here, improve the commentary and markup for the rest  
of the example.  
  
David G. Johnston and Tom Lane, per report from Curt Kolovson.  
Back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/CANhYJV6HWtgz_qjx_APfK0PAgLUzY-2vjLuj7i_o=TZF1LAQew@mail.gmail.com  

commit   : 926aa6d11bde9f0b6b0e45ca5a26646aacac8be3    
  
author   : Michael Paquier <[email protected]>    
date     : Tue, 18 Jul 2023 14:04:46 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Tue, 18 Jul 2023 14:04:46 +0900    

This has been missed in cb0cca1, noticed before buildfarm member koel  
has been able to complain while poking at a different patch.  Like the  
other commit, backpatch all the way down to limit the odds of merge  
conflicts.  
  
Backpatch-through: 11  

commit   : f88bc9f3883970327598271d26afdb525112874b    
  
author   : Michael Paquier <[email protected]>    
date     : Tue, 18 Jul 2023 13:44:27 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Tue, 18 Jul 2023 13:44:27 +0900    

A crash in the middle of a checkpoint with some two-phase state data  
already flushed to disk by this checkpoint could cause a follow-up crash  
recovery to recover twice the same transaction, once from what has been  
found in pg_twophase/ at the beginning of recovery and a second time  
when replaying its corresponding record.  
  
This would lead to FATAL failures in the startup process during  
recovery, where the same transaction would have a state recovered twice  
instead of once:  
LOG:  recovering prepared transaction 731 from shared memory  
LOG:  recovering prepared transaction 731 from shared memory  
FATAL:  lock ExclusiveLock on object 731/0/0 is already held  
  
This issue is fixed by skipping the addition of any 2PC state coming  
from a record whose equivalent 2PC state file has already been loaded in  
TwoPhaseState at the beginning of recovery by restoreTwoPhaseData(),  
which is OK as long as the system has not reached a consistent state.  
  
The timing to get a messed up recovery processing is very racy, and  
would very unlikely happen.  The thread that has reported the issue has  
demonstrated the bug using injection points to force a PANIC in the  
middle of a checkpoint.  
  
Issue introduced in 728bd99, so backpatch all the way down.  
  
Reported-by: "suyu.cmj" <[email protected]>  
Author: "suyu.cmj" <[email protected]>  
Author: Michael Paquier  
Discussion: https://postgr.es/m/109e6994-b971-48cb-84f6-829646f18b4c.mengjuan.cmj@alibaba-inc.com  
Backpatch-through: 11  

commit   : efe8d8226929137f8c96f45e0904868b53ba56bc    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 17 Jul 2023 16:54:54 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 17 Jul 2023 16:54:54 -0400    

fe-auth.c references CHAR_BIT since commit 3a465cc67, but it  
did not #include <limits.h>, which per POSIX is where that  
symbol is defined.  This escaped notice so far because  
(a) on most platforms, <sys/param.h> pulls in <limits.h>,  
(b) even if yours doesn't, OpenSSL pulls it in, so compiling  
with --with-openssl masks the omission.  
  
Per bug #18026 from Marcel Hofstetter.  Back-patch to v16.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 4a7301c7ad1c504c5a3f485a1d28cfd62b3ecbb0    
  
author   : Amit Langote <[email protected]>    
date     : Fri, 14 Jul 2023 14:28:38 +0900    
  
committer: Amit Langote <[email protected]>    
date     : Fri, 14 Jul 2023 14:28:38 +0900    

In a61b1f74823, we failed to update transformFromClauseItem() and  
buildNSItemFromLists() to set ParseNamespaceItem.p_perminfo causing  
it to point to garbage.  
  
Pointed out by Tom Lane.  
  
Reported-by: Farias de Oliveira <[email protected]>  
Discussion: https://postgr.es/m/3173476.1689286373%40sss.pgh.pa.us  
Backpatch-through: 16  

commit   : 27da47122075971aeacd4e2284d7907dde8a7204    
  
author   : Michael Paquier <[email protected]>    
date     : Fri, 14 Jul 2023 11:16:03 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Fri, 14 Jul 2023 11:16:03 +0900    

RelationReloadIndexInfo() is a fast-path used for index reloads in the  
relation cache, and it has always forgotten about updating  
indisreplident, which is something that would happen after an index is  
selected for a replica identity.  This can lead to incorrect cache  
information provided when executing a command in a transaction context  
that updates indisreplident.  
  
None of the code paths currently on HEAD that need to check upon  
pg_index.indisreplident fetch its value from the relation cache, always  
relying on a fresh copy on the syscache.  Unfortunately, this may not be  
the case of out-of-core code, that could see out-of-date value.  
  
Author: Shruthi Gowda  
Reviewed-by: Robert Haas, Dilip Kumar, Michael Paquier  
Discussion: https://postgr.es/m/CAASxf_PBcxax0wW-3gErUyftZ0XrCs3Lrpuhq4-Z3Fak1DoW7Q@mail.gmail.com  
Backpatch-through: 11  

commit   : 31f9d41d625dc6ca8c1469edd6919316b18174fe    
  
author   : Michael Paquier <[email protected]>    
date     : Fri, 14 Jul 2023 10:13:14 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Fri, 14 Jul 2023 10:13:14 +0900    

indisvalid is switched to true for partitioned indexes when all its  
partitions have valid indexes when attaching a new partition, up to the  
top-most parent if all its leaves are themselves valid when dealing with  
multiple layers of partitions.  
  
The copy of the tuple from pg_index used to switch indisvalid to true  
came from the relation cache, which is incorrect.  Particularly, in the  
case reported by Shruthi Gowda, executing a series of commands in a  
single transaction would cause the validation of partitioned indexes to  
use an incorrect version of a pg_index tuple, as indexes are reloaded  
after an invalidation request with RelationReloadIndexInfo(), a much  
faster version than a full index cache rebuild.  In this case, the  
limited information updated in the cache leads to an incorrect version  
of the tuple used.  One of the symptoms reported was the following  
error, with a replica identity update, for instance:  
"ERROR: attempted to update invisible tuple"  
  
This is incorrect since 8b08f7d, so backpatch all the way down.  
  
Reported-by: Shruthi Gowda  
Author: Michael Paquier  
Reviewed-by: Shruthi Gowda, Dilip Kumar  
Discussion: https://postgr.es/m/CAASxf_PBcxax0wW-3gErUyftZ0XrCs3Lrpuhq4-Z3Fak1DoW7Q@mail.gmail.com  
Backpatch-through: 11  

commit   : a4b4cc1d60f7e8ccfcc8ff8cb80c28ee411ad9a9    
  
author   : Andres Freund <[email protected]>    
date     : Thu, 13 Jul 2023 13:03:30 -0700    
  
committer: Andres Freund <[email protected]>    
date     : Thu, 13 Jul 2023 13:03:30 -0700    

Until now, when DROP DATABASE got interrupted in the wrong moment, the removal  
of the pg_database row would also roll back, even though some irreversible  
steps have already been taken. E.g. DropDatabaseBuffers() might have thrown  
out dirty buffers, or files could have been unlinked. But we continued to  
allow connections to such a corrupted database.  
  
To fix this, mark databases invalid with an in-place update, just before  
starting to perform irreversible steps. As we can't add a new column in the  
back branches, we use pg_database.datconnlimit = -2 for this purpose.  
  
An invalid database cannot be connected to anymore, but can still be  
dropped.  
  
Unfortunately we can't easily add output to psql's \l to indicate that some  
database is invalid, it doesn't fit in any of the existing columns.  
  
Add tests verifying that a interrupted DROP DATABASE is handled correctly in  
the backend and in various tools.  
  
Reported-by: Evgeny Morozov <[email protected]>  
Author: Andres Freund <[email protected]>  
Reviewed-by: Daniel Gustafsson <[email protected]>  
Reviewed-by: Thomas Munro <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  
Discussion: https://postgr.es/m/[email protected]  
Backpatch: 11-, bug present in all supported versions  

commit   : 03ccc9569cd87fcbe01e4ba052c22ad0d9a3b71d    
  
author   : Andres Freund <[email protected]>    
date     : Thu, 13 Jul 2023 13:03:30 -0700    
  
committer: Andres Freund <[email protected]>    
date     : Thu, 13 Jul 2023 13:03:30 -0700    

When vac_truncate_clog() encounters bogus datfrozenxid / datminmxid values, it  
returns early. Unfortunately, until now, it did not release  
WrapLimitsVacuumLock. If the backend later tries to acquire  
WrapLimitsVacuumLock, the session / autovacuum worker hangs in an  
uncancellable way. Similarly, other sessions will hang waiting for the  
lock. However, if the backend holding the lock exited or errored out for some  
reason, the lock was released.  
  
The bug was introduced as a side effect of 566372b3d643.  
  
It is interesting that there are no production reports of this problem. That  
is likely due to a mix of bugs leading to bogus values having gotten less  
common, process exit releasing locks and instances of hangs being hard to  
debug for "normal" users.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : e27f3f52c289a2f6e67f9319602df190a92446c0    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 13 Jul 2023 13:07:51 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 13 Jul 2023 13:07:51 -0400    

GiST compress functions (like all GiST opclass functions) are  
supposed to be called in short-lived memory contexts, so that  
minor memory leaks in them are not of concern, and indeed  
explicit pfree's are likely slightly counterproductive.  
But this one in g_intbig_compress() is more than  
slightly counterproductive, because it's guarded by  
"if (in != DatumGetArrayTypeP(entry->key))" which means  
that if this test succeeds, we've detoasted the datum twice.  
(And to add insult to injury, the extra detoast result is  
leaked.)  Let's just drop the whole stanza, relying on the  
GiST temporary context mechanism to clean up in good time.  
  
The analogous bit in g_int_compress() is  
       if (r != (ArrayType *) DatumGetPointer(entry->key))  
           pfree(r);  
which doesn't have the gratuitous-detoast problem so  
I left it alone.  Perhaps there is a case for removing  
unnecessary pfree's more widely, but I'm not sure if it's  
worth the code churn.  
  
The potential extra decompress seems expensive enough to  
justify calling this a (minor) performance bug and  
back-patching.  
  
Konstantin Knizhnik, Matthias van de Meent, Tom Lane  
  
Discussion: https://postgr.es/m/CAEze2Wi86=DxErfvf+SCB2UKmU2amKOF60BKuJOX=w-RojRn0A@mail.gmail.com  

commit   : b4018ecb88a49612730398d15d3d96d68abe1137    
  
author   : Peter Eisentraut <[email protected]>    
date     : Thu, 13 Jul 2023 12:56:35 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Thu, 13 Jul 2023 12:56:35 +0200    

We can't inject the name of the logical replication worker into a log  
message like that.  But for these messages we don't really need the  
precision of knowing what kind of worker it was, so just write  
"logical replication worker" and keep the message in one piece.  
  
Discussion: https://www.postgresql.org/message-id/flat/CAHut%2BPt1xwATviPGjjtJy5L631SGf3qjV9XUCmxLu16cHamfgg%40mail.gmail.com  

commit   : 4946910a875ce84823236f2a06e576b16080465f    
  
author   : Masahiko Sawada <[email protected]>    
date     : Thu, 13 Jul 2023 15:03:24 +0900    
  
committer: Masahiko Sawada <[email protected]>    
date     : Thu, 13 Jul 2023 15:03:24 +0900    

Commit 89e46da5e allowed REPLICA IDENTITY FULL tables to use an index  
on the subscriber during apply of update/delete. This commit clarifies  
in the documentation that the leftmost field of candidate indexes must  
be a column (not an expression) that references the published relation  
column.  
  
The source code comments are also updated accordingly.  
  
Reviewed-by: Peter Smith, Amit Kapila  
Discussion: https://postgr.es/m/CAD21AoDJjffEvUFKXT27Q5U8-UU9JHv4rrJ9Ke8Zkc5UPWHLvA@mail.gmail.com  
Backpatch-through: 16  

commit   : 7fc064d9b70f58998d3e8de78ece52b4e1376428    
  
author   : Andres Freund <[email protected]>    
date     : Wed, 12 Jul 2023 16:26:03 -0700    
  
committer: Andres Freund <[email protected]>    
date     : Wed, 12 Jul 2023 16:26:03 -0700    

In the event the llvm option is defined to be 'auto', it is possible  
that the host machine might not have a C++ compiler. If that is the  
case, then we shouldn't continue reaching for the llvm dependency.  
  
To make it easier to understand the case where LLVM support is disabled due to  
lacking a C++ compiler, add a message noting that fact.  
  
Author: Tristan Partin <[email protected]>  
Reviewed-by: Andres Freund <[email protected]>  
Discussion: https://postgr.es/m/CSPIJVUDZFKX.3KHMOAVGF94RV@c3po  
Backpatch: 16-, where meson support was added  

commit   : 5a7280d9880f94c632425703ac68a17a218474fb    
  
author   : Andres Freund <[email protected]>    
date     : Wed, 12 Jul 2023 16:26:03 -0700    
  
committer: Andres Freund <[email protected]>    
date     : Wed, 12 Jul 2023 16:26:03 -0700    

That was already done in a lot of places, but not all.  
  
Backpatch this to keep the the meson files aligned as long as reasonably  
possible.  
  
Author: Tristan Partin <[email protected]>  
Reviewed-by: Andres Freund <[email protected]>  
Discussion: https://postgr.es/m/CSPIJVUDZFKX.3KHMOAVGF94RV@c3po  
Backpatch: 16-, where meson support was added  

commit   : eeb28a2d94220a8540a57ca8204eaff8cadaf1fa    
  
author   : Andres Freund <[email protected]>    
date     : Wed, 12 Jul 2023 16:26:03 -0700    
  
committer: Andres Freund <[email protected]>    
date     : Wed, 12 Jul 2023 16:26:03 -0700    

That way CI knows to pick up the file if the test fails.  
  
Discussion: https://postgr.es/m/[email protected]  
Backpatch: 16-, where the test was added  

commit   : 93dcdfa88f5f9befb781558920e02d3ee86dc629    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 10 Jul 2023 12:14:34 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 10 Jul 2023 12:14:34 -0400    

Since PostgresMain calls sigsetjmp, any local variables that are not  
marked "volatile" have a risk of unspecified behavior.  In practice  
this means that when control returns via longjmp, such variables might  
get reset to their values as of the time of sigsetjmp, depending on  
whether the compiler chose to put them in registers or on the stack.  
We were careful about this for "send_ready_for_query", but not the  
other local variables.  
  
In the case of the timeout_enabled flags, resetting them to  
their initial "false" states is actually good, since we do  
"disable_all_timeouts()" in the longjmp cleanup code path.  If that  
does not happen, we risk uselessly calling "disable_timeout()" later,  
which is harmless but a little bit expensive.  Let's explicitly reset  
these flags so that the behavior is correct and platform-independent.  
(This change means that we really don't need the new "volatile"  
markings after all, but let's install them anyway since any change  
in this logic could re-introduce a problem.)  
  
There is no issue for "firstchar" and "input_message" because those  
are explicitly reinitialized each time through the query processing  
loop.  To make that clearer, move them to be declared inside the loop.  
That leaves us with all the function-lifespan locals except the  
sigjmp_buf itself marked as volatile, which seems like a good policy  
to have going forward.  
  
Because of the possibility of extra disable_timeout() calls, this  
seems worth back-patching.  
  
Sergey Shinderuk and Tom Lane  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : e004cb0394402a26b7142721e59a4f8e179bd1e4    
  
author   : Peter Eisentraut <[email protected]>    
date     : Mon, 10 Jul 2023 12:05:32 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Mon, 10 Jul 2023 12:05:32 +0200    

for commit e53a611523  

commit   : 2631ebab7b18bdc079fd86107c47d6104a6b3c6e    
  
author   : Peter Eisentraut <[email protected]>    
date     : Mon, 10 Jul 2023 10:46:54 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Mon, 10 Jul 2023 10:46:54 +0200    

commit   : 55c95f24cd7c91fc80d7c0d2c842c0b633f9bdc9    
  
author   : Michael Paquier <[email protected]>    
date     : Mon, 10 Jul 2023 09:40:12 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Mon, 10 Jul 2023 09:40:12 +0900    

As coded, the code would use as a base comparison the namespace OID from  
the first object scanned in pg_depend when switching its namespace  
dependency entry to the new one, and use it as a base of comparison for  
any follow-up checks.  It would also be used as the old namespace OID to  
switch *from* for the extension's pg_depend entry.  Hence, if the first  
object scanned has a namespace different than the one stored in the  
extension, we would finish by:  
- Not checking that the extension objects map with the extension's  
schema.  
- Not switching the extension -> namespace dependency entry to the new  
namespace provided by the user, making ALTER EXTENSION ineffective.  
  
This issue exists since this command has been introduced in d9572c4 for  
relocatable extension, so backpatch all the way down to 11.  The test  
case has been provided by Heikki, that I have tweaked a bit to show the  
effects on pg_depend for the extension.  
  
Reported-by: Heikki Linnakangas  
Author: Michael Paquier, Heikki Linnakangas  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 11  

commit   : 25da5cd32f73eec9a7ea9b49fbf04d97059ad402    
  
author   : Peter Eisentraut <[email protected]>    
date     : Sun, 9 Jul 2023 10:02:15 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Sun, 9 Jul 2023 10:02:15 +0200    

commit   : 1da1cd2944701d5f6d8e4e9514a4a19b0fdf852a    
  
author   : Peter Eisentraut <[email protected]>    
date     : Sun, 9 Jul 2023 09:46:24 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Sun, 9 Jul 2023 09:46:24 +0200    

The DEFAULT parameter seems most similar to the NULL parameter, so  
move it next to it, instead of having it at the end of the parameter  
list because it was the last one added.  

commit   : 6d8b5f49f0e18a0e8a926a4315c6a70efa34036e    
  
author   : David Rowley <[email protected]>    
date     : Sun, 9 Jul 2023 16:14:47 +1200    
  
committer: David Rowley <[email protected]>    
date     : Sun, 9 Jul 2023 16:14:47 +1200    

During the PostgreSQL 14 cycle, the Memoize executor node was briefly  
called "Result Cache" until it was renamed in 83f4fcc65.  That commit  
missed one reference.  
  
Reported-by: Paul A Jungwirth  
Packpatch-through: 14, where Memoize was added  
Discussion: https://postgr.es/m/CA+renyX=40YXhsfPTzn13oNOPO3TJ12CK9GX-2P2pvnQiScefA@mail.gmail.com  

commit   : 6d8a8bb0104ccd9ba5199dc54647d58ce006324e    
  
author   : Andrew Dunstan <[email protected]>    
date     : Sat, 8 Jul 2023 12:34:25 -0400    
  
committer: Andrew Dunstan <[email protected]>    
date     : Sat, 8 Jul 2023 12:34:25 -0400    

Commit e213de8e78 fixed a problem with path lengths to a tempdir on  
Windows, but caused problems on at least some Unix systems where the  
system tempdir is on a different file system. To work around this, only  
used the system temdir for the destination of pg_replslot on Windows,  
and otherwise restore the old behaviour.  
  
Backpatch to relase 14 like the previous patch.  
  
Problem exposed by a myriad of buildfarm animals.  

commit   : 67ece2e709c44880bd634daa18c0f9d6862857f5    
  
author   : Andrew Dunstan <[email protected]>    
date     : Sat, 8 Jul 2023 11:21:58 -0400    
  
committer: Andrew Dunstan <[email protected]>    
date     : Sat, 8 Jul 2023 11:21:58 -0400    

The symlink to a longer location tripped up some Windows limit on  
buildfarm animal fairywren when running with meson, which uses slightly  
longer paths.  
  
Backpatch to all live branches to keep the script in sync.  

commit   : 1421e8f3b6fc489f66d665d2a657f1af8bcd6595    
  
author   : Peter Eisentraut <[email protected]>    
date     : Sat, 8 Jul 2023 17:24:41 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Sat, 8 Jul 2023 17:24:41 +0200    

Use of uninitialized value $content in concatenation (.) or string  

commit   : 01f1f789df5631b831dbd38b5a2b70d066f79fe2    
  
author   : Peter Eisentraut <[email protected]>    
date     : Sat, 8 Jul 2023 15:50:35 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Sat, 8 Jul 2023 15:50:35 +0200    

Reviewed-by: Amit Langote <[email protected]>  
Discussion: https://www.postgresql.org/message-id/flat/CA+HiwqE4XTdfb1nW=Ojoy_tQSRhYt-q_kb6i5d4xcKyrLC1Nbg@mail.gmail.com  

commit   : 957445996fda2d6939a8748f2a19c10b15941c5e    
  
author   : Nathan Bossart <[email protected]>    
date     : Fri, 7 Jul 2023 11:25:23 -0700    
  
committer: Nathan Bossart <[email protected]>    
date     : Fri, 7 Jul 2023 11:25:23 -0700    

This reverts the following commits: 4dbdb82513, c2122aae63,  
5b1a879943, 9e1e9d6560, ff9618e82a, 60684dd834, 4441fc704d,  
and b5d6382496.  A role with the MAINTAIN privilege may be able to  
use search_path tricks to escalate privileges to the table owner.  
Unfortunately, it is too late in the v16 development cycle to apply  
the proposed fix, i.e., restricting search_path when running  
maintenance commands.  
  
Bumps catversion.  
  
Reviewed-by: Jeff Davis  
Discussion: https://postgr.es/m/E1q7j7Y-000z1H-Hr%40gemulon.postgresql.org  
Backpatch-through: 16  

commit   : 1124cb2cf2ebc1b0adb9c5289e53ffe094ce3206    
  
author   : Tomas Vondra <[email protected]>    
date     : Fri, 7 Jul 2023 19:04:32 +0200    
  
committer: Tomas Vondra <[email protected]>    
date     : Fri, 7 Jul 2023 19:04:32 +0200    

Commit 19d8e2308b allowed a weaker check for HOT with summarizing  
indexes, but it did not update README.HOT. So do that now.  
  
Patch by Matthias van de Meent, minor changes by me. Backpatch to 16,  
where the optimization was introduced.  
  
Author: Matthias van de Meent  
Reviewed-by: Tomas Vondra  
Backpatch-through: 16  
Discussion: https://postgr.es/m/CAEze2WiEOm8V+c9kUeYp2BPhbEc5s473fUf51xNeqvSFGv44Ew@mail.gmail.com  

commit   : 727d96511ef58521bd4be0d3acb7ba88df44e762    
  
author   : Andres Freund <[email protected]>    
date     : Thu, 6 Jul 2023 08:34:17 -0700    
  
committer: Andres Freund <[email protected]>    
date     : Thu, 6 Jul 2023 08:34:17 -0700    

Also add comment to make the reasoning behind the Assert() more explicit (per  
Tom).  
  
Reported-by: Ranier Vilela  
Discussion: https://postgr.es/m/CAEudQAocXNJ6s1VLz+hMamLAQAiewRoW17OJ6-+9GACKfj6iPQ@mail.gmail.com  
Backpatch: 11-  

commit   : b94d70a632aabb02079f094b9c9a32f4f6b8c984    
  
author   : Andrew Dunstan <[email protected]>    
date     : Thu, 6 Jul 2023 12:27:40 -0400    
  
committer: Andrew Dunstan <[email protected]>    
date     : Thu, 6 Jul 2023 12:27:40 -0400    

On Windows, it's sometimes difficult to create a file with a path longer  
than 255 chars, and if it can be created it might not be seen by the  
archiver. This can be triggered by the test for tar backups with  
filenames greater than 100 bytes. So we skip that test if the path would  
exceed 255.  
  
Backpatch to all live branches.  
  
Reviewed by Daniel Gustafsson  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : bf7b70e6bf4ad07f4a46c51a7f866ef89f82404c    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Thu, 6 Jul 2023 17:25:29 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Thu, 6 Jul 2023 17:25:29 +0300    

We create a file, so we better WAL-log it. In practice, all the  
built-in index AMs and all extensions that I'm aware of write a  
metapage to the init fork, which is WAL-logged, and replay of the  
metapage implicitly creates the fork too. But if ambuildempty() didn't  
write any page, we would miss it.  
  
This can be seen with dummy_index_am. Set up replication, create a  
'dummy_index_am' index on an unlogged table, and look at the files  
created in the replica: the init fork is not created on the  
replica. Dummy_index_am doesn't do anything with the relation files,  
however, so it doesn't lead to any user-visible errors.  
  
Backpatch to all supported versions.  
  
Reviewed-by: Robert Haas  
Discussion: https://www.postgresql.org/message-id/6e5bbc08-cdfc-b2b3-9e23-1a914b9850a9%40iki.fi  

commit   : 3c1adbbf86c2cfa44ebed64bd01ed589ad0b832b    
  
author   : Amit Kapila <[email protected]>    
date     : Thu, 6 Jul 2023 08:41:30 +0530    
  
committer: Amit Kapila <[email protected]>    
date     : Thu, 6 Jul 2023 08:41:30 +0530    

This commit reverts the work done by commits 3ba59ccc89 and 72e78d831a.  
Those commits were incorrect in asserting that we never acquire any other  
heavy-weight lock after acquring page lock other than relation extension  
lock. We can acquire a lock on catalogs while doing catalog look up after  
acquring page lock.  
  
This won't impact any existing feature but we need to think some other way  
to achieve this before parallelizing other write operations or even  
improving the parallelism in vacuum (like allowing multiple workers  
for an index).  
  
Reported-by: Jaime Casanova  
Author: Amit Kapila  
Backpatch-through: 13  
Discussion: https://postgr.es/m/CAJKUy5jffnRKNvRHKQ0LynRb0RJC-o4P8Ku3x9vGAVLwDBWumQ@mail.gmail.com  

commit   : dc0b5841746c025f6e51b0a6ba0e423b2ac518f0    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Wed, 5 Jul 2023 13:13:13 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Wed, 5 Jul 2023 13:13:13 +0300    

llvm_release_context() called llvm_enter_fatal_on_oom(), but was missing  
the corresponding llvm_leave_fatal_on_oom() call. As a result, if JIT was  
used at all, we were almost always in the "fatal-on-oom" state.  
  
It only makes a difference if you use an extension written in C++, and  
run out of memory in a C++ 'new' call. In that case, you would get a  
PostgreSQL FATAL error, instead of the default behavior of throwing a  
C++ exception.  
  
Back-patch to all supported versions.  
  
Reviewed-by: Daniel Gustafsson  
Discussion: https://www.postgresql.org/message-id/[email protected]  

commit   : be8cae7e2f03f35a049e2b1f1113860fea6d0212    
  
author   : Masahiko Sawada <[email protected]>    
date     : Wed, 5 Jul 2023 14:49:58 +0900    
  
committer: Masahiko Sawada <[email protected]>    
date     : Wed, 5 Jul 2023 14:49:58 +0900    

Commit 7b64e4b3 taught DropSubscription() to drop stats entry of  
subscription that is not associated with a replication slot for apply  
worker at DROP SUBSCRIPTION but missed covering the case where the  
subscription is not associated with replication slots for both apply  
worker and tablesync worker.  
  
Also add a test to verify that the stats for slot-less subscription is  
removed at DROP SUBSCRIPTION time.  
  
Backpatch down to 15.  
  
Author: Masahiko Sawada  
Reviewed-by: Nathan Bossart, Hayato Kuroda, Melih Mutlu, Amit Kapila  
Discussion: https://postgr.es/m/CAD21AoB71zkP7uPT7JDPsZcvp0749ExEQnOJxeNKPDFisHar+w@mail.gmail.com  
Backpatch-through: 15  

commit   : eb27d3dc88879cb148ae0365394aae0ab84fa1a7    
  
author   : Daniel Gustafsson <[email protected]>    
date     : Tue, 4 Jul 2023 17:36:13 +0200    
  
committer: Daniel Gustafsson <[email protected]>    
date     : Tue, 4 Jul 2023 17:36:13 +0200    

Clear any potential stale next_phase_at value from the snapshot  
builder which otherwise may trip an assertion check ensuring  
that there is no next_phase_at value.  
  
This can be reproduced by running 80 concurrent sessions like  
the below where $c is a loop counter (assumes there has been  
1..$c databases created) :  
  
  echo "  
    CREATE TABLE replication_example(id SERIAL PRIMARY KEY,  
                                     somedata int,  
                                     text varchar(120));  
    SELECT 'init' FROM  
      pg_create_logical_replication_slot('regression_slot_$c',  
                                         'test_decoding');  
    SELECT data FROM  
      pg_logical_slot_get_changes('regression_slot_$c', NULL,  
                                  NULL, 'include-xids', '0',  
                                  'skip-empty-xacts', '1');  
  " | psql -d regress_$c >>psql.log &  
  
Backpatch down to v16.  
  
Bug: #17695  
Author: Masahiko Sawada <[email protected]>  
Reviewed-by: Alexander Lakhin <[email protected]>  
Reported-by: bowenshi <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: v16  

commit   : d431644b43fcce9b7c2f677db18452b0ee216b42    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Tue, 4 Jul 2023 17:57:03 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Tue, 4 Jul 2023 17:57:03 +0300    

If you create a table and don't insert any data into it, the relation file  
is never fsync'd. You don't lose data, because an empty table doesn't have  
any data to begin with, but if you crash and lose the file, subsequent  
operations on the table will fail with "could not open file" error.  
  
To fix, register an fsync request in mdcreate(), like we do for mdwrite().  
  
Per discussion, we probably should also fsync the containing directory  
after creating a new file. But that's a separate and much wider issue.  
  
Backpatch to all supported versions.  
  
Reviewed-by: Andres Freund, Thomas Munro  
Discussion: https://www.postgresql.org/message-id/d47d8122-415e-425c-d0a2-e0160829702d%40iki.fi  

commit   : af8f9ec66bd19a920d02b4c0eb65b3dd6057d324    
  
author   : Thomas Munro <[email protected]>    
date     : Tue, 4 Jul 2023 15:16:34 +1200    
  
committer: Thomas Munro <[email protected]>    
date     : Tue, 4 Jul 2023 15:16:34 +1200    

It's OK to be lazy about re-binning memory segments when allocating,  
because that can only leave segments in a bin that's too high.  We'll  
search higher bins if necessary while allocating next time, and  
also eventually re-bin, so no memory can become unreachable that way.  
  
However, when freeing memory, the largest contiguous range of free pages  
might go up, so we should re-bin eagerly to make sure we don't leave the  
segment in a bin that is too low for get_best_segment() to find.  
  
The re-binning code is moved into a function of its own, so it can be  
called whenever free pages are returned to the segment's free page map.  
  
Back-patch to all supported releases.  
  
Author: Dongming Liu <[email protected]>  
Reviewed-by: Robert Haas <[email protected]> (earlier version)  
Reviewed-by: Thomas Munro <[email protected]>  
Discussion: https://postgr.es/m/CAL1p7e8LzB2LSeAXo2pXCW4%2BRya9s0sJ3G_ReKOU%3DAjSUWjHWQ%40mail.gmail.com  

commit   : 12529028a4e55eb0500477d2589eec625466facf    
  
author   : Thomas Munro <[email protected]>    
date     : Mon, 3 Jul 2023 16:20:01 +1200    
  
committer: Thomas Munro <[email protected]>    
date     : Mon, 3 Jul 2023 16:20:01 +1200    

The ginfast.c code previously checked for conflicts in before locking  
the relevant buffer, leaving a window where a RW conflict could be  
missed.  Re-order.  
  
There was also a place where buffer ID and block number were confused  
while trying to predicate-lock a page, noted by visual inspection.  
  
Back-patch to all supported releases.  Fixes one more problem discovered  
with the reproducer from bug #17949, in this case when Dmitry tried  
other index types.  
  
Reported-by: Artem Anisimov <[email protected]>  
Reported-by: Dmitry Dolgov <[email protected]>  
Reviewed-by: Heikki Linnakangas <[email protected]>  
Discussion: https://postgr.es/m/17949-a0f17035294a55e2%40postgresql.org  

commit   : d03d9a2614fd58d4a9e90107f1700952333ce2a2    
  
author   : Thomas Munro <[email protected]>    
date     : Mon, 3 Jul 2023 16:18:20 +1200    
  
committer: Thomas Munro <[email protected]>    
date     : Mon, 3 Jul 2023 16:18:20 +1200    

When performing a bitmap heap scan, we don't want to miss concurrent  
writes that occurred after we observed the heap's rs_nblocks, but before  
we took predicate locks on index pages.  Therefore, we can't skip  
fetching any heap tuples that are referenced by the index, because we  
need to test them all with CheckForSerializableConflictOut().  The  
old optimization that would ignore any references to blocks >=  
rs_nblocks gets in the way of that requirement, because it means that  
concurrent writes in that window are ignored.  
  
Removing that optimization shouldn't affect correctness at any isolation  
level, because any new tuples shouldn't be visible to an MVCC snapshot.  
There also shouldn't be any error-causing references to heap blocks past  
the end, because we should have held at least an AccessShareLock on the  
table before the index scan.  It can't get smaller while our transaction  
is running.  For now, though, we'll keep the optimization at lower  
levels to avoid making unnecessary changes in a bug fix.  
  
Back-patch to all supported releases.  In release 11, the code is in a  
different place but not fundamentally different.  Fixes one aspect of  
bug #17949.  
  
Reported-by: Artem Anisimov <[email protected]>  
Reviewed-by: Dmitry Dolgov <[email protected]>  
Reviewed-by: Heikki Linnakangas <[email protected]>  
Discussion: https://postgr.es/m/17949-a0f17035294a55e2%40postgresql.org  

commit   : 0cb1fb2c9bf8fdc27044082757cde79de1a8e482    
  
author   : Thomas Munro <[email protected]>    
date     : Mon, 3 Jul 2023 16:16:27 +1200    
  
committer: Thomas Munro <[email protected]>    
date     : Mon, 3 Jul 2023 16:16:27 +1200    

When predicate-locking btrees, we have a special case for completely  
empty btrees, since there is no page to lock.  This was racy, because,  
without buffer lock held, a matching key could be inserted between the  
_bt_search() and the PredicateLockRelation() calls.  
  
Fix, by rechecking _bt_search() after taking the relation-level SIREAD  
lock, if using SERIALIZABLE isolation and an empty btree is discovered.  
  
Back-patch to all supported releases.  Fixes one aspect of bug #17949.  
  
Reported-by: Artem Anisimov <[email protected]>  
Reviewed-by: Dmitry Dolgov <[email protected]>  
Reviewed-by: Heikki Linnakangas <[email protected]>  
Discussion: https://postgr.es/m/17949-a0f17035294a55e2%40postgresql.org  

commit   : 6b488d5dc2fe4dc12e1ef15c0ea4c1a4e7170ae0    
  
author   : Tomas Vondra <[email protected]>    
date     : Mon, 3 Jul 2023 18:16:58 +0200    
  
committer: Tomas Vondra <[email protected]>    
date     : Mon, 3 Jul 2023 18:16:58 +0200    

The test inserted 70k rows into a foreign table, in order to verify  
correct behavior with more than 65535 parameters, and was added in  
response to a bug report.  
  
However, this is rather expensive, especially when running the tests  
under valgrind, CLOBBER_CACHE_ALWAYS etc. It doesn't seem worth it to  
keep running the test, so remove it from all branches (14+).  
  
Backpatch-through: 14  
Discussion: https://postgr.es/m/[email protected]  

commit   : 16152705b31d12c339e3a9ee44ed43972a6ee96c    
  
author   : Andrew Dunstan <[email protected]>    
date     : Mon, 3 Jul 2023 10:06:26 -0400    
  
committer: Andrew Dunstan <[email protected]>    
date     : Mon, 3 Jul 2023 10:06:26 -0400    

Creation of a file with a very long name can create problems on Windows  
due to its file path limits. Work around that by creating the file via a  
symlink with a shorter name.  
  
Error displayed by buildfarm animal fairywren.o  
  
Backpatch to all live branches  

commit   : c24e9ef330ac7da1d1628d21b2d5defb0ec03c54    
  
author   : Michael Paquier <[email protected]>    
date     : Mon, 3 Jul 2023 10:06:13 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Mon, 3 Jul 2023 10:06:13 +0900    

When set, this environment variable was only effective for data  
directories but not for all the other temporary files created by  
PostgreSQL::Test::Utils.  Keeping the temporary files after a successful  
run can be useful for debugging purposes.  
  
The documentation is updated to reflect the new behavior, with contents  
available in doc/ since v16 and in src/test/perl/README since v15.  
  
Author: Jacob Champion  
Reviewed-by: Daniel Gustafsson  
Discussion: https://postgr.es/m/CAAWbhmgHtDH1SGZ+Fw05CsXtE0mzTmjbuUxLB9mY9iPKgM6cUw@mail.gmail.com  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 11