PostgreSQL 15.0 (upcoming) commit log

commit   : b2d47928908d7a99b8e39198d0e8e9e0cb2b024b    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Fri, 3 Feb 2023 11:13:34 +0000    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Fri, 3 Feb 2023 11:13:34 +0000    

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

commit   : 2010d8b75a6eb0f2ce90ae24cba99775c3d343e8    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 3 Feb 2023 09:04:35 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 3 Feb 2023 09:04:35 +0100    

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

commit   : 98811323c8e9a1995b828a47504b6608f0f3f59a    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Thu, 2 Feb 2023 21:31:24 -0800    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Thu, 2 Feb 2023 21:31:24 -0800    

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

commit   : 7ae0ab0ad9704b10400a611a9af56c63304c27a5    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Fri, 3 Feb 2023 16:20:43 +1300    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Fri, 3 Feb 2023 16:20:43 +1300    

The code to get the next block number was exactly the same between these  
two functions, so let's just put it into a helper function and call that  
from both locations.  
  
Author: Melanie Plageman  
Reviewed-by: Andres Freund, David Rowley  
Discussion: https://postgr.es/m/CAAKRu_bvkhka0CZQun28KTqhuUh5ZqY=_T8QEqZqOL02rpi2bw@mail.gmail.com  

commit   : 3e577ff602fe3438ac60771c4a6d027d881619b0    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Fri, 3 Feb 2023 08:29:08 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Fri, 3 Feb 2023 08:29:08 +0530    

To interlock against concurrent drops, we use to hold ExclusiveLock on  
pg_replication_origin till xact commit. This blocks even concurrent drops  
of different origins by tablesync workers. So, instead, lock the specific  
origin to interlock against concurrent drops.  
  
This reduces the test time variability in src/test/subscription where  
multiple tables are being synced.  
  
Author: Vignesh C  
Reviewed-by: Hou Zhijie, Amit Kapila  
Discussion: https://postgr.es/m/1412708.1674417574@sss.pgh.pa.us  

commit   : 2e9f120b657e540b36843dbb075dab196e79fbfd    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Fri, 3 Feb 2023 14:26:54 +1300    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Fri, 3 Feb 2023 14:26:54 +1300    

Back-patch to 15, where in-tree CI began.  
  
Author: Justin Pryzby <pryzby@telsasoft.com>  
Discussion: https://postgr.es/m/1441145.1675300332%40sss.pgh.pa.us  

commit   : 8ca6d49f634124e2f77f5c02af244c4ca4a3b1e9    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Fri, 3 Feb 2023 12:38:42 +1300    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Fri, 3 Feb 2023 12:38:42 +1300    

Here we add heapgettup_start_page() and heapgettup_continue_page() to  
simplify the code in the heapgettup() function.  
  
Author: Melanie Plageman  
Reviewed-by: David Rowley  
Discussion: https://postgr.es/m/CAAKRu_bvkhka0CZQun28KTqhuUh5ZqY=_T8QEqZqOL02rpi2bw@mail.gmail.com  

commit   : f9bc34fcb664e93d1fa3c3873527dce6f4cc495f    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Fri, 3 Feb 2023 11:48:39 +1300    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Fri, 3 Feb 2023 11:48:39 +1300    

Backward and forward scans share much of the same page acquisition code.  
Here we consolidate that code to reduce some duplication.  
  
Additionally, add a new rs_coffset field to HeapScanDescData to track the  
offset of the current tuple.  The new field fits nicely into the padding  
between a bool and BlockNumber field and saves having to look at the last  
returned tuple to figure out which offset we should be looking at for the  
current tuple.  
  
Author: Melanie Plageman  
Reviewed-by: David Rowley  
Discussion: https://postgr.es/m/CAAKRu_bvkhka0CZQun28KTqhuUh5ZqY=_T8QEqZqOL02rpi2bw@mail.gmail.com  

commit   : cdf6518ef08ee602b94db4e5ba5887a1d7053c24    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Fri, 3 Feb 2023 10:34:56 +1300    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Fri, 3 Feb 2023 10:34:56 +1300    

In the 90s we needed to deal with computers that still had the  
pre-standard signal masking APIs.  That hasn't been relevant for a very  
long time on Unix systems, and c94ae9d8 got rid of a remaining  
dependency in our Windows porting code.  PG_SETMASK didn't expose  
save/restore functionality, so we'd already started using sigprocmask()  
directly in places, creating the visual distraction of having two ways  
to spell it.  It's not part of the API that extensions are expected to  
be using (but if they are, the change will be trivial).  It seems like a  
good time to drop the old macro and just call the standard POSIX  
function.  
  
Reviewed-by: Nathan Bossart <nathandbossart@gmail.com>  
Discussion: https://postgr.es/m/CA%2BhUKG%2BKfQgrhHP2DLTohX1WwubaCBHmTzGnAEDPZ-Gug-Xskg%40mail.gmail.com  

commit   : e0d70a91a04b942980ab06bc471d2b5b65952459    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Thu, 2 Feb 2023 08:54:38 -0500    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Thu, 2 Feb 2023 08:54:38 -0500    

Installing with plain cpan failed for me recently, as the archive it  
searched has been purged of old releases. However, you can give cpanm a  
complete URL to the exact version you want to install, so document using  
that.  

commit   : 0736fc1ceb0659a9f73699910ac56603336daeee    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Thu, 2 Feb 2023 09:41:22 +0000    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Thu, 2 Feb 2023 09:41:22 +0000    

Improve the comment explaining the choice of rscale in numeric_sqrt(),  
and ensure that the code works consistently when other values of  
NBASE/DEC_DIGITS are used.  
  
Note that, in practice, we always expect DEC_DIGITS == 4, and this  
does not change the computation in that case.  
  
Joel Jacobson and Dean Rasheed  
  
Discussion: https://postgr.es/m/06712c29-98e9-43b3-98da-f234d81c6e49%40app.fastmail.com  

commit   : 9a84f2947bf9345ad6b93ba37da63633649eaea8    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Thu, 2 Feb 2023 09:39:08 +0000    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Thu, 2 Feb 2023 09:39:08 +0000    

As noted in the comments, support for different NBASE values is really  
only of historical interest, but as long as we're keeping it, we might  
as well make sure that it compiles.  
  
Joel Jacobson  
  
Discussion: https://postgr.es/m/06712c29-98e9-43b3-98da-f234d81c6e49%40app.fastmail.com  

commit   : 117d2604c2a59eb853e894410b94b4c453f8bd43    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Thu, 2 Feb 2023 18:13:44 +1300    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Thu, 2 Feb 2023 18:13:44 +1300    

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

commit   : 9f2213a7c575bae43a2d41abc8b60770066ca81c    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Thu, 2 Feb 2023 08:15:18 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Thu, 2 Feb 2023 08:15:18 +0530    

Extend the existing developer option 'logical_replication_mode' to help  
test the parallel apply of large transactions on the subscriber.  
  
When set to 'buffered', the leader sends changes to parallel apply workers  
via a shared memory queue. When set to 'immediate', the leader serializes  
all changes to files and notifies the parallel apply workers to read and  
apply them at the end of the transaction.  
  
This helps in adding tests to cover the serialization code path in  
parallel streaming mode.  
  
Author: Hou Zhijie  
Reviewed-by: Peter Smith, Kuroda Hayato, Sawada Masahiko, Amit Kapila  
Discussion: https://postgr.es/m/CAA4eK1+wyN6zpaHUkCLorEWNx75MG0xhMwcFhvjqm2KURZEAGw@mail.gmail.com  

commit   : fb1a59de0c52609653166aafc6ce8679a9cfe54b    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Thu, 2 Feb 2023 14:17:15 +1300    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Thu, 2 Feb 2023 14:17:15 +1300    

Here we adjust heapgettup() and heapgettup_pagemode() to move the code  
that fetches the first block number to scan out into a helper function.  
This removes some code duplication.  
  
Author: Melanie Plageman  
Reviewed-by: David Rowley  
Discussion: https://postgr.es/m/CAAKRu_bvkhka0CZQun28KTqhuUh5ZqY=_T8QEqZqOL02rpi2bw@mail.gmail.com  

commit   : 253432f42661fdd67d235252949e2838aa6421fd    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 1 Feb 2023 18:14:01 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 1 Feb 2023 18:14:01 +0100    

Reviewed-by: Andres Freund <andres@anarazel.de>  
Discussion: https://www.postgresql.org/message-id/flat/07b37c70-349a-8fcd-bcc9-6c3ce0f6c2a4%40enterprisedb.com  

commit   : 38cc08546459a9052b6ed43cdb28973288db38c6    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 1 Feb 2023 15:46:04 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 1 Feb 2023 15:46:04 +0900    

As coded, the timeout given to WaitLatch() was always equal to  
PGARCH_AUTOWAKE_INTERVAL, as time() was called two times repeatedly.  
This simplification could have been done in d75288f.  
  
While on it, this adjusts a comment in pgarch.c to describe the archiver  
in a more neutral way.  
  
Author: Sravan Kumar, Nathan Bossart  
Reviewed-by: Kyotaro Horiguchi  
Discussion: https://postgr.es/m/CA+=NbjjqYE9-Lnw7H7DAiS5jebmoMikwZQb_sBP7kgBCn9q6Hg@mail.gmail.com  

commit   : fbed4bc59e362e13fb0d0e0b08c995c18c7e4d5a    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Tue, 31 Jan 2023 17:36:39 -0800    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Tue, 31 Jan 2023 17:36:39 -0800    

Thanks to Robins to find the issue and Nathan for promptly writing a test case  
to prevent future problems like this.  
  
Reported-by: Nathan Bossart <nathandbossart@gmail.com>  
Reported-by: Robins Tharakan <tharakan@gmail.com>  
Author: Nathan Bossart <nathandbossart@gmail.com>  
Discussion: https://postgr.es/m/20230130193008.GA2740781@nathanxps13  

commit   : c2891175052772b603da6d0ae634e42b63b7f274    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Wed, 1 Feb 2023 14:29:51 +1300    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Wed, 1 Feb 2023 14:29:51 +1300    

Further to commit 54e72b66e, if rmtree() fails while cleaning up in  
pg_upgrade, try again.  This gives our Windows unlink() wrapper a chance  
to reach its wait-for-the-other-process-to-go-away logic, if the first  
go around initiated the unlink of a file that a concurrently exiting  
program still has open.  
  
Discussion: https://postgr.es/m/CA%2BhUKGKCVy2%3Do%3Dd8c2Va6a_3Rpf_KkhUitkWCZ3hzuO2VwLMXA%40mail.gmail.com  

commit   : 758f44bc3a365bed6b82db098bebc26ef441ba42    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 31 Jan 2023 17:36:55 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 31 Jan 2023 17:36:55 -0500    

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

commit   : e9aaf06328c7f962f8586618981e9763d31402a3    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Wed, 1 Feb 2023 10:52:41 +1300    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Wed, 1 Feb 2023 10:52:41 +1300    

Here remove some dead code from heapgettup() and heapgettup_pagemode()  
which was trying to support NoMovementScanDirection scans.  This code can  
never be reached as standard_ExecutorRun() never calls ExecutePlan with  
NoMovementScanDirection.  
  
Additionally, plans which were scanning an unordered index would use  
NoMovementScanDirection rather than ForwardScanDirection.  There was no  
real need for this, so here we adjust this so we use ForwardScanDirection  
for unordered index scans.  A comment in pathnodes.h claimed that  
NoMovementScanDirection was used for PathKey reasons, but if that was  
true, it no longer is, per code in build_index_paths().  
  
This does change the non-text format of the EXPLAIN output so that  
unordered index scans now have a "Forward" scan direction rather than  
"NoMovement".  The text format of EXPLAIN has not changed.  
  
Author: Melanie Plageman  
Reviewed-by: Tom Lane, David Rowley  
Discussion: https://postgr.es/m/CAAKRu_bvkhka0CZQun28KTqhuUh5ZqY=_T8QEqZqOL02rpi2bw@mail.gmail.com  

commit   : 856ca51a23b56df6aab3ee9bffc66334b79be355    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 31 Jan 2023 14:32:24 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 31 Jan 2023 14:32:24 -0500    

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

commit   : eae0e20deffb0a73f7cb0e94746f94a1347e71b1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 31 Jan 2023 11:57:47 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 31 Jan 2023 11:57:47 -0500    

In commit 2489d76c4, I'd thought it'd be safe to assert that a  
PlaceHolderVar appearing in a scan-level expression has empty  
nullingrels.  However this is not so, as when we determine that a  
join relation is certainly empty we'll put its targetlist into a  
Result-with-constant-false-qual node, and nothing is done to adjust  
the nullingrels of the Vars or PHVs therein.  (Arguably, a Result  
used in this way isn't really a scan-level node, but it certainly  
isn't an upper node either ...)  
  
It's not clear this is worth any close analysis, so let's just  
take out the faulty Assert.  
  
Per report from Robins Tharakan.  I added a test case based on  
his example, just in case somebody tries to tighten this up.  
  
Discussion: https://postgr.es/m/CAEP4nAz7Enq3+DEthGG7j27DpuwSRZnW0Nh6jtNh75yErQ_nbA@mail.gmail.com  

commit   : 3db72ebcbe20debc6552500ee9ccb4b2007f12f8    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 31 Jan 2023 15:24:05 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 31 Jan 2023 15:24:05 +0900    

This commit changes the query jumbling code in queryjumblefuncs.c to be  
generated automatically based on the information of the nodes in the  
headers of src/include/nodes/ by using gen_node_support.pl.  This  
approach offers many advantages:  
- Support for query jumbling for all the utility statements, based on the  
state of their parsed Nodes and not only their query string.  This will  
greatly ease the switch to normalize the information of some DDLs, like  
SET or CALL for example (this is left unchanged and should be part of a  
separate discussion).  With this feature, the number of entries stored  
for utilities in pg_stat_statements is reduced (for example now  
"CHECKPOINT" and "checkpoint" mean the same thing with the same query  
ID).  
- Documentation of query jumbling directly in the structure definition  
of the nodes.  Since this code has been introduced in pg_stat_statements  
and then moved to code, the reasons behind the choices of what should be  
included in the jumble are rather sparse.  Note that some explanation is  
added for the most relevant parts, as a start.  
- Overall code reduction and more consistency with the other parts  
generating read, write and copy depending on the nodes.  
  
The query jumbling is controlled by a couple of new node attributes,  
documented in nodes/nodes.h:  
- custom_query_jumble, to mark a Node as having a custom  
implementation.  
- no_query_jumble, to ignore entirely a Node.  
- query_jumble_ignore, to ignore a field in a Node.  
- query_jumble_location, to mark a location in a Node, for  
normalization.  This can apply only to int fields, with "location" in  
their name (only Const as of this commit).  
  
There should be no compatibility impact on pg_stat_statements, as the  
new code applies the jumbling to the same fields for each node (its  
regression tests have no modification, for one).  
  
Some benchmark of the query jumbling between HEAD and this commit for  
SELECT and DMLs has proved that this new code does not cause a  
performance regression, with computation times close for both methods.  
For utility queries, the new method is slower than the previous method  
of calculating a hash of the query string, though we are talking about  
extra ns-level changes based on what I measured, which is unnoticeable  
even for OLTP workloads as a query ID is calculated once per query  
post-parse analysis.  
  
Author: Michael Paquier  
Reviewed-by: Peter Eisentraut  
Discussion: https://postgr.es/m/Y5BHOUhX3zTH/ig6@paquier.xyz  

commit   : 8c1cd726c5d997d5d170505ec15a2dc1dfe81d6a    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 31 Jan 2023 12:46:56 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 31 Jan 2023 12:46:56 +0900    

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

commit   : 54e72b66ed1a55c2fa558bc60d534bdc61dbb62f    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Tue, 31 Jan 2023 13:07:44 +1300    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Tue, 31 Jan 2023 13:07:44 +1300    

Switch to get_dirent_type() instead of lstat() while traversing a  
directory tree, to see if that fixes the intermittent ENOTEMPTY failures  
seen in recent pg_upgrade tests, on Windows CI.  While refactoring, also  
use AllocateDir() instead of opendir() in the backend, which knows how  
to handle descriptor pressure.  
  
Our CI system currently uses Windows Server 2019, a version known not to  
have POSIX unlink semantics enabled by default yet, unlike typical  
Windows 10 and 11 systems.  That might explain why we see this flapping  
on CI but (apparently) not in the build farm, though the frequency is  
quite low.  
  
The theory is that some directory entry must be in state  
STATUS_DELETE_PENDING, which lstat() would report as ENOENT, though  
unfortunately we don't know exactly why yet.  With this change, rmtree()  
will not skip them, and try to unlink (again).  Our unlink() wrapper  
should either wait a short time for them to go away when some other  
process closes the handle, or log a message to tell us the path of the  
problem file if not, so we can dig further.  
  
Discussion: https://postgr.es/m/20220919213217.ptqfdlcc5idk5xup%40awork3.anarazel.de  

commit   : 3bef56e11650a33f70adeb6dd442bc2b48bb9b72    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 30 Jan 2023 13:50:25 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 30 Jan 2023 13:50:25 -0500    

EquivalenceClasses are now understood as applying within a "join  
domain", which is a set of inner-joined relations (possibly underneath  
an outer join).  We no longer need to treat an EC from below an outer  
join as a second-class citizen.  
  
I have hopes of eventually being able to treat outer-join clauses via  
EquivalenceClasses, by means of only applying deductions within the  
EC's join domain.  There are still problems in the way of that, though,  
so for now the reconsider_outer_join_clause logic is still here.  
  
I haven't been able to get rid of RestrictInfo.is_pushed_down either,  
but I wonder if that could be recast using JoinDomains.  
  
I had to hack one test case in postgres_fdw.sql to make it still test  
what it was meant to, because postgres_fdw is inconsistent about  
how it deals with quals containing non-shippable expressions; see  
https://postgr.es/m/1691374.1671659838@sss.pgh.pa.us.  That should  
be improved, but I don't think it's within the scope of this patch  
series.  
  
Patch by me; thanks to Richard Guo for review.  
  
Discussion: https://postgr.es/m/830269.1656693747@sss.pgh.pa.us  

commit   : b448f1c8d83f8b65e2f0080c556ee21a7076da25    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 30 Jan 2023 13:44:36 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 30 Jan 2023 13:44:36 -0500    

Remove RestrictInfo.nullable_relids, along with a good deal of  
infrastructure that calculated it.  One use-case for it was in  
join_clause_is_movable_to, but we can now replace that usage with  
a check to see if the clause's relids include any outer join  
that can null the target relation.  The other use-case was in  
join_clause_is_movable_into, but that test can just be dropped  
entirely now that the clause's relids include outer joins.  
Furthermore, join_clause_is_movable_into should now be  
accurate enough that it will accept anything returned by  
generate_join_implied_equalities, so we can restore the Assert  
that was diked out in commit 95f4e59c3.  
  
Remove the outerjoin_delayed mechanism.  We needed this before to  
prevent quals from getting evaluated below outer joins that should  
null some of their vars.  Now that we consider varnullingrels while  
placing quals, that's taken care of automatically, so throw the  
whole thing away.  
  
Teach remove_useless_result_rtes to also remove useless FromExprs.  
Having done that, the delay_upper_joins flag serves no purpose any  
more and we can remove it, largely reverting 11086f2f2.  
  
Use constant TRUE for "dummy" clauses when throwing back outer joins.  
This improves on a hack I introduced in commit 6a6522529.  If we  
have a left-join clause l.x = r.y, and a WHERE clause l.x = constant,  
we generate r.y = constant and then don't really have a need for the  
join clause.  But we must throw the join clause back anyway after  
marking it redundant, so that the join search heuristics won't think  
this is a clauseless join and avoid it.  That was a kluge introduced  
under time pressure, and after looking at it I thought of a better  
way: let's just introduce constant-TRUE "join clauses" instead,  
and get rid of them at the end.  This improves the generated plans for  
such cases by not having to test a redundant join clause.  We can also  
get rid of the ugly hack used to mark such clauses as redundant for  
selectivity estimation.  
  
Patch by me; thanks to Richard Guo for review.  
  
Discussion: https://postgr.es/m/830269.1656693747@sss.pgh.pa.us  

commit   : 2489d76c4906f4461a364ca8ad7e0751ead8aa0d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 30 Jan 2023 13:16:20 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 30 Jan 2023 13:16:20 -0500    

Traditionally we used the same Var struct to represent the value  
of a table column everywhere in parse and plan trees.  This choice  
predates our support for SQL outer joins, and it's really a pretty  
bad idea with outer joins, because the Var's value can depend on  
where it is in the tree: it might go to NULL above an outer join.  
So expression nodes that are equal() per equalfuncs.c might not  
represent the same value, which is a huge correctness hazard for  
the planner.  
  
To improve this, decorate Var nodes with a bitmapset showing  
which outer joins (identified by RTE indexes) may have nulled  
them at the point in the parse tree where the Var appears.  
This allows us to trust that equal() Vars represent the same value.  
A certain amount of klugery is still needed to cope with cases  
where we re-order two outer joins, but it's possible to make it  
work without sacrificing that core principle.  PlaceHolderVars  
receive similar decoration for the same reason.  
  
In the planner, we include these outer join bitmapsets into the relids  
that an expression is considered to depend on, and in consequence also  
add outer-join relids to the relids of join RelOptInfos.  This allows  
us to correctly perceive whether an expression can be calculated above  
or below a particular outer join.  
  
This change affects FDWs that want to plan foreign joins.  They *must*  
follow suit when labeling foreign joins in order to match with the  
core planner, but for many purposes (if postgres_fdw is any guide)  
they'd prefer to consider only base relations within the join.  
To support both requirements, redefine ForeignScan.fs_relids as  
base+OJ relids, and add a new field fs_base_relids that's set up by  
the core planner.  
  
Large though it is, this commit just does the minimum necessary to  
install the new mechanisms and get check-world passing again.  
Follow-up patches will perform some cleanup.  (The README additions  
and comments mention some stuff that will appear in the follow-up.)  
  
Patch by me; thanks to Richard Guo for review.  
  
Discussion: https://postgr.es/m/830269.1656693747@sss.pgh.pa.us  

commit   : ec7e053a98f39a9e3c7e6d35f0d2e83933882399    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 30 Jan 2023 11:59:37 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 30 Jan 2023 11:59:37 -0500    

defGetBoolean() allows the "value" part of "option = value"  
syntax to be omitted, in which case it's taken as "true".  
This is acknowledged in our syntax summaries for relevant commands,  
but we don't seem to have documented the actual behavior anywhere.  
Do so for CREATE/ALTER PUBLICATION/SUBSCRIPTION.  Use generic  
boilerplate text for this, with the idea that we can copy-and-paste  
it into other relevant reference pages, whenever someone gets  
around to that.  
  
Peter Smith, edited a bit by me  
  
Discussion: https://postgr.es/m/CAHut+PvwjZfdGt2R8HTXgSZft=jZKymrS8KUg31pS7zqaaWKKw@mail.gmail.com  

commit   : fe9e658f4d7fbc12d2b6a74c4ee90c73e53d68ef    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Mon, 30 Jan 2023 10:04:57 +0000    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Mon, 30 Jan 2023 10:04:57 +0000    

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

commit   : 1e8b61735cfb1a4feb72cb9ea83db690fedbfef1    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Mon, 30 Jan 2023 08:02:08 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Mon, 30 Jan 2023 08:02:08 +0530    

Rename the developer option 'logical_decoding_mode' to the more flexible  
name 'logical_replication_mode' because doing so will make it easier to  
extend this option in the future to help test other areas of logical  
replication.  
  
Currently, it is used on the publisher side to allow streaming or  
serializing each change in logical decoding. In the upcoming patch, we are  
planning to use it on the subscriber. On the subscriber, it will allow  
serializing the changes to file and notifies the parallel apply workers to  
read and apply them at the end of the transaction.  
  
We discussed exposing this parameter as a subscription option but  
it did not seem advisable since it is primarily used for testing/debugging  
and there is no other such parameter. We also discussed having separate  
GUCs for publisher and subscriber but for current testing/debugging  
requirements, one GUC is sufficient.  
  
Author: Hou Zhijie  
Reviewed-by: Peter Smith, Kuroda Hayato, Sawada Masahiko, Amit Kapila  
Discussion: https://postgr.es/m/CAD21AoAy2c=Mx=FTCs+EwUsf2kQL5MmU3N18X84k0EmCXntK4g@mail.gmail.com  
Discussion: https://postgr.es/m/CAA4eK1+wyN6zpaHUkCLorEWNx75MG0xhMwcFhvjqm2KURZEAGw@mail.gmail.com  

commit   : 8d2c1913ed3df9384973399deeb75fc1e55943fe    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Sat, 28 Jan 2023 14:57:31 +1300    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Sat, 28 Jan 2023 14:57:31 +1300    

Several flags were marked volatile and in some cases used sig_atomic_t  
because they were accessed from signal handlers.  After commit 7389aad6,  
we can just use unqualified bool.  
  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Reviewed-by: Andres Freund <andres@anarazel.de>  
Discussion: https://postgr.es/m/CA%2BhUKGLMoeZNZY6gYdLUQmuoW_a8bKyLvtuZkd_zHcGVOfDzBA%40mail.gmail.com  

commit   : e4e89eb5bbfdae30349b38344e9c604411174f6b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 27 Jan 2023 12:13:41 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 27 Jan 2023 12:13:41 -0500    

Split out "ConfigOptionIsVisible" to perform the privilege  
check for GUC_SUPERUSER_ONLY GUCs (which these days can also  
be read by pg_read_all_settings role members), and move the  
should-we-show-it checks from GetConfigOptionValues to its  
sole caller.  
  
This commit also removes get_explain_guc_options's check of  
GUC_NO_SHOW_ALL, which seems to have got cargo-culted in there.  
While there's no obvious use-case for marking a GUC both  
GUC_EXPLAIN and GUC_NO_SHOW_ALL, if it were set up that way  
one would expect EXPLAIN to show it --- if that's not what  
you want, then don't set GUC_EXPLAIN.  
  
In passing, simplify the loop logic in show_all_settings.  
  
Nitin Jadhav, Bharath Rupireddy, Tom Lane  
  
Discussion: https://postgr.es/m/CAMm1aWYgfekpRK-Jz5=pM_bV+Om=ktGq1vxTZ_dr1Z6MV-qokA@mail.gmail.com  

commit   : a1c4cd6f2c8857fbb78d043a0b3c7d397e48ef2e    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 27 Jan 2023 09:38:59 -0500    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 27 Jan 2023 09:38:59 -0500    

This includes a unification of the logic used to find the excludes file  
and the typedefs file.  
  
Also, remove the dangerous and deprecated feature where the first  
non-option argument was taken as a typdefs file if it wasn't a .c or .h  
file, remove some extraneous blank lines, and improve the documentation  
somewhat.  

commit   : 8f6858064b1442f9ad057d289b0e4f018a2ad8aa    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 27 Jan 2023 10:49:17 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 27 Jan 2023 10:49:17 +0100    

We have the long-standing logic to append "postgresql" to some  
installation paths if it does not already contain "pgsql" or  
"postgres".  The existing meson implementation of that only considered  
the subdirectory under the prefix, not the prefix itself.  Fix that,  
so that it now works the same way as the implementation in  
Makefile.global.  
  
Reviewed-by: Andres Freund <andres@anarazel.de>  
Discussion: https://www.postgresql.org/message-id/a6a6de12-f705-2b33-2fd9-9743277deb08@enterprisedb.com  

commit   : 17e72ec45d313b98bd90b95bc71b4cc77c2c89c3    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 27 Jan 2023 08:42:08 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 27 Jan 2023 08:42:08 +0100    

Reported-by: Karl O. Pinc <kop@karlpinc.com>  
Discussion: https://www.postgresql.org/message-id/flat/ece84b69-8f94-8b88-925f-64207cb3a2f0@enterprisedb.com  

commit   : 456fa635a909ee36f73ca84d340521bd730f265f    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Fri, 27 Jan 2023 16:08:41 +1300    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Fri, 27 Jan 2023 16:08:41 +1300    

9d9c02ccd introduced runConditions for window functions to allow  
monotonic window function evaluation to be made more efficient when the  
window function value went beyond some value that it would never go back  
from due to its monotonic nature.  That commit added prosupport functions  
to inform the planner that row_number(), rank(), dense_rank() and some  
forms of count(*) were monotonic.  Here we add support for ntile(),  
cume_dist() and percent_rank().  
  
Reviewed-by: Melanie Plageman  
Discussion: https://postgr.es/m/CAApHDvqR+VqB8s+xR-24bzJbU8xyFrBszJ17qKgECf7cWxLCaA@mail.gmail.com  

commit   : 783d8abc3b63267194ca21b679caf8d152b93358    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 27 Jan 2023 10:19:50 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 27 Jan 2023 10:19:50 +0900    

pg_restore -l has always been able to read the TOC data of a dump even  
if its binary has no support for compression, for both compressed and  
uncompressed dumps.  5e73a60 has introduced a backward-incompatible  
behavior by switching a warning to a hard error in the code path reading  
the header data of a dump, preventing the TOC items to be listed even if  
pg_restore -l, with no support for compression, is used on a compressed  
dump.  Most modern systems should have support for zlib, but it can be  
also possible that somebody relies on the past behavior when copying  
over a dump where binaries are not built with zlib support (most likely  
some WIN32 flavors these days, though most environments should provide  
that).  
  
There is no easy way to have a regression test for this pattern, as it  
requires a mix of dump/restore commands with different compilation  
options, with and without compression.  One possibility I see here would  
be to have a command-line option that enforces a non-compression check  
for a build that supports compression, but that does not seem worth the  
cost, either.  
  
Reported-by: Justin Pryzby  
Author: Georgios Kokolatos  
Discussion: https://postgr.es/m/20230125180020.GF22427@telsasoft.com  

commit   : 3a28d78089289794fda86cdbd275fc4756c6c6aa    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 26 Jan 2023 17:09:12 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 26 Jan 2023 17:09:12 -0500    

We'd like to use TimestampDifferenceMilliseconds with the stop_time  
possibly being TIMESTAMP_INFINITY, but up to now it's disclaimed  
responsibility for overflow cases.  Define it to clamp its output to  
the range [0, INT_MAX], handling overflow correctly.  (INT_MAX rather  
than LONG_MAX seems appropriate, because the function is already  
described as being intended for calculating wait times for WaitLatch  
et al, and that infrastructure only handles waits up to INT_MAX.  
Also, this choice gets rid of cross-platform behavioral differences.)  
  
Having done that, we can replace some ad-hoc code in walreceiver.c  
with a simple call to TimestampDifferenceMilliseconds.  
  
While at it, fix some buglets in existing callers of  
TimestampDifferenceMilliseconds: basebackup_copy.c had not read the  
memo about TimestampDifferenceMilliseconds never returning a negative  
value, and postmaster.c had not read the memo about Min() and Max()  
being macros with multiple-evaluation hazards.  Neither of these  
quite seem worth back-patching.  
  
Patch by me; thanks to Nathan Bossart for review.  
  
Discussion: https://postgr.es/m/3126727.1674759248@sss.pgh.pa.us  

commit   : 24ff700f6aee2e8b915399e03934c6fe9b593d3f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 26 Jan 2023 12:51:00 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 26 Jan 2023 12:51:00 -0500    

Avoid having walreceiver code know explicitly about the precision  
and underlying datatype of TimestampTz.  (There is still one  
calculation that knows that, which should be replaced with use of  
TimestampDifferenceMilliseconds; but we need to figure out what to do  
about overflow cases first.)  
  
In support of this, provide a TimestampTzPlusSeconds macro, as well  
as TIMESTAMP_INFINITY and TIMESTAMP_MINUS_INFINITY macros.  (We could  
have used the existing DT_NOEND and DT_NOBEGIN symbols, but I judged  
those too opaque and confusing.)  
  
Move GetCurrentTimestamp calls so that it's more obvious that we  
are not using stale values of "now" anyplace.  This doesn't result  
in net more calls, and might indeed make for net fewer.  
  
Avoid having a dummy value in the WalRcvWakeupReason enum, so that  
we can hope for the compiler to catch overlooked switch cases.  
  
Nathan Bossart and Tom Lane  
  
Discussion: https://postgr.es/m/20230125235004.GA1327755@nathanxps13  

commit   : e35bb9f1582d3c2885de65a60d6b296877c7ed0e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 26 Jan 2023 11:34:17 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 26 Jan 2023 11:34:17 -0500    

Improve wording in note about tools required to build  
from the source repository.  
  
Laurenz Albe, per gripe from Riivo Kolka  
  
Discussion: https://postgr.es/m/167463493588.2667301.13267758265445155872@wrigleys.postgresql.org  

commit   : 14fb38626f3ff0f96144cd7535ce5feaba3a18a0    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Thu, 26 Jan 2023 08:14:41 -0500    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Thu, 26 Jan 2023 08:14:41 -0500    

This is required by project policy, and I overlooked the need for  
it (again) by accident.  
  
Reported by Álvaro Herrara.  
  
Discussion: http://postgr.es/m/20230126114659.x3yuypot7p6zj73c@alvherre.pgsql  

commit   : 37e267335068059ac9bd4ec5d06b493afb4b73e8    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 26 Jan 2023 11:33:01 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 26 Jan 2023 11:33:01 +0100    

This has long been deprecated.  Some of the build systems didn't even  
install it.  
  
Also remove man page.  
  
Reviewed-by: Karl O. Pinc <kop@karlpinc.com>  
Discussion: https://www.postgresql.org/message-id/flat/ece84b69-8f94-8b88-925f-64207cb3a2f0@enterprisedb.com  

commit   : 81266442fbcb19ec184134f0a256207f05026520    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 26 Jan 2023 10:48:32 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 26 Jan 2023 10:48:32 +0100    

"postgres" has long been officially preferred over "postmaster" as the  
name of the program to invoke to run the server.  Some example scripts  
and code comments still used the latter.  Change those.  
  
Discussion: https://www.postgresql.org/message-id/flat/ece84b69-8f94-8b88-925f-64207cb3a2f0@enterprisedb.com  

commit   : 6c6b4972664491de408670354fdbccc7c83a1c89    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Wed, 25 Jan 2023 22:22:27 -0800    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Wed, 25 Jan 2023 22:22:27 -0800    

This reverts commit 4d417992613949af35530b4e8e83670c4e67e1b2.  Broad  
concerns about regressions caused by eager freezing strategy have been  
raised.  Whether or not these concerns can be worked through in any time  
frame is far from certain.  
  
Discussion: https://postgr.es/m/20230126004347.gepcmyenk2csxrri@awork3.anarazel.de  

commit   : 8b5f36bb6c16c030561d83b74b8c3270dbf48b68    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Wed, 25 Jan 2023 20:23:32 -0800    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Wed, 25 Jan 2023 20:23:32 -0800    

Author: Nathan Bossart  
Discussion: https://postgr.es/m/20230114224000.GA2505377@nathanxps13  

commit   : 9d2d9728b8d546434aade4f9667a59666588edd6    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 26 Jan 2023 12:23:16 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 26 Jan 2023 12:23:16 +0900    

When auto_explain.log_verbose is on, auto_explain should print in the  
logs plans equivalent to the EXPLAIN (VERBOSE).  However, when  
compute_query_id is on, query identifiers were not showing up, being  
only handled by EXPLAIN (VERBOSE).  This brings auto_explain on par with  
EXPLAIN regarding that.  Note that like EXPLAIN, auto_explain does not  
show the query identifier when compute_query_id=regress.  
  
The change is done so as the choice of printing the query identifier is  
done in ExplainPrintPlan() rather than in ExplainOnePlan(), to avoid a  
duplication of the logic dealing with the query ID.  auto_explain is the  
only in-core caller of ExplainPrintPlan().  
  
While looking at the area, I have noticed that more consolidation  
between EXPLAIN and auto_explain would be in order for the logging of  
the plan duration and the buffer usage.  This refactoring is left as a  
future change.  
  
Author: Atsushi Torikoshi  
Reviewed-by: Justin Pryzby, Julien Rouhaud  
Discussion: https://postgr.es/m/1ea21936981f161bccfce05765c03bee@oss.nttdata.com  

commit   : ffcf6f4cfca5a4ce2ac7ff7e8fa17541a5a9caea    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Thu, 26 Jan 2023 14:50:07 +1300    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Thu, 26 Jan 2023 14:50:07 +1300    

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

commit   : 9aeff092c05820d6a9252d7a3f8db86f71f2205f    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 26 Jan 2023 09:13:39 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 26 Jan 2023 09:13:39 +0900    

This reverts commit 0ad3c60, as per feedback from Tom Lane, Robert Haas  
and Andres Freund.  The new name used for the module had little  
support.  
  
This moves back to basic_archive as module name, and we will likely use  
that as template for recovery modules, as well.  
  
Discussion: https://postgr.es/m/CA+TgmoYG5uGOp7DGFT5gzC1kKFWGjkLSj_wOQxGhfMcvVEiKGA@mail.gmail.com  

commit   : 1a8e72bff781e869e5b5dc76fa18e3ae08181656    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Wed, 25 Jan 2023 14:31:41 -0800    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Wed, 25 Jan 2023 14:31:41 -0800    

VACUUM VERBOSE/autovacuuming logging have reported on the number of  
pages frozen by VACUUM since commit d977ffd9 added that capability.  
This information is directly related to relfrozenxid advancement, so  
update an older tip from the documentation about how relfrozenxid is  
reported on by the same instrumentation code.  Now the tip directly  
mentions newly frozen pages, too.  

commit   : 4d417992613949af35530b4e8e83670c4e67e1b2    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Wed, 25 Jan 2023 14:15:38 -0800    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Wed, 25 Jan 2023 14:15:38 -0800    

Eager freezing strategy avoids large build-ups of all-visible pages.  It  
makes VACUUM trigger page-level freezing whenever doing so will enable  
the page to become all-frozen in the visibility map.  This is useful for  
tables that experience continual growth, particularly strict append-only  
tables such as pgbench's history table.  Eager freezing significantly  
improves performance stability by spreading out the cost of freezing  
over time, rather than doing most freezing during aggressive VACUUMs.  
It complements the insert autovacuum mechanism added by commit b07642db.  
  
VACUUM determines its freezing strategy based on the value of the new  
vacuum_freeze_strategy_threshold GUC (or reloption) with logged tables.  
Tables that exceed the size threshold use the eager freezing strategy.  
Unlogged tables and temp tables always use eager freezing strategy,  
since the added cost is negligible there.  Non-permanent relations won't  
incur any extra overhead in WAL written (for the obvious reason), nor in  
pages dirtied (since any extra freezing will only take place on pages  
whose PD_ALL_VISIBLE bit needed to be set either way).  
  
VACUUM uses lazy freezing strategy for logged tables that fall under the  
GUC size threshold.  Page-level freezing triggers based on the criteria  
established in commit 1de58df4, which added basic page-level freezing.  
  
Eager freezing is strictly more aggressive than lazy freezing.  Settings  
like vacuum_freeze_min_age still get applied in just the same way in  
every VACUUM, independent of the strategy in use.  The only mechanical  
difference between eager and lazy freezing strategies is that only the  
former applies its own additional criteria to trigger freezing pages.  
Note that even lazy freezing strategy will trigger freezing whenever a  
page happens to have required that an FPI be written during pruning,  
provided that the page will thereby become all-frozen in the visibility  
map afterwards (due to the FPI optimization from commit 1de58df4).  
  
The vacuum_freeze_strategy_threshold default setting is 4GB.  This is a  
relatively low setting that prioritizes performance stability.  It will  
be reviewed at the end of the Postgres 16 beta period.  
  
Author: Peter Geoghegan <pg@bowt.ie>  
Reviewed-By: Jeff Davis <pgsql@j-davis.com>  
Reviewed-By: Andres Freund <andres@anarazel.de>  
Reviewed-By: Matthias van de Meent <boekewurm+postgres@gmail.com>  
Discussion: https://postgr.es/m/CAH2-WzkFok_6EAHuK39GaW4FjEFQsY=3J0AAd6FXk93u-Xq3Fg@mail.gmail.com  

commit   : 642e8821d713d75f142ef4eda14e490ba0fb810b    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Wed, 25 Jan 2023 09:59:26 -0800    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Wed, 25 Jan 2023 09:59:26 -0800    

We undefined them to avoid warnings about macro redefinitions. But we haven't  
fully followed the necessary include order, since at least 147c2482542, in  
2011.  Recently the combination of the include order rules not being followed  
and undefining _POSIX_C_SOURCE started to cause a compile failure, starting  
with 03023a2664f. Undefining _POSIX_C_SOURCE hides clock_gettime(), which is  
referenced in an inline function as of 03023a2664f, whereas it was a macro  
before.  
  
After seeing some evidence that undefining _POSIX_C_SOURCE et al isn't  
required, I tried to build postgres with plpython on most of our supported  
platforms (except DragonFlyBSD and Illumos, but similar systems were tested),  
with/without the #undefines. No compiler warning / behavioral difference.  
  
The oldest supported python version, 3.2, defines _POSIX_C_SOURCE to 200112L  
ad _XOPEN_SOURCE to 600, whereas newer versions of python use 200809L/700  
respectively. As _POSIX_C_SOURCE/_XOPEN_SOURCE will default to the newer  
operating system on most platforms, it's possible that when using python 3.2  
new warnings would be emitted - but that seems acceptable.  
  
It's possible that this approach won't work on some older platforms. But  
getting rid of most of the include-order complexity seems promising, and it's  
an easily revertible patch if we end up having to go another way.  
  
Discussion: https://postgr.es/m/20230124165814.2njc7gnvubn2amh6@awork3.anarazel.de  

commit   : 23c12329a755ad9c70135463d3f067241daf1dcc    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Wed, 25 Jan 2023 09:59:26 -0800    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Wed, 25 Jan 2023 09:59:26 -0800    

Until now we undefined and then redefined a lot of *printf macros due to  
worries about conflicts with Python.h macro definitions. Current Python.h  
doesn't define any *printf macros, and older versions just defined snprintf,  
vsnprintf, guarded by #if defined(MS_WIN32) && !defined(HAVE_SNPRINTF).  
  
Thus we can replace the undefine/define section with a single  
 #define HAVE_SNPRINTF 1  
  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/20230124165814.2njc7gnvubn2amh6@awork3.anarazel.de  

commit   : 3b4ac33254e1291f0b3c94f1cb770137c418ce2e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 25 Jan 2023 11:48:38 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 25 Jan 2023 11:48:38 -0500    

Invent separate macros for "invalid" values of these types, so that  
we needn't embed knowledge of their representations into calling code.  
These are all zeroes anyway ATM, so this is not fixing any live bug,  
but it makes the code cleaner and more future-proof.  
  
I (tgl) also chose to move DSM_HANDLE_INVALID into dsm_impl.h,  
since it seems like it should live beside the typedef for dsm_handle.  
  
Hou Zhijie, Nathan Bossart, Kyotaro Horiguchi, Tom Lane  
  
Discussion: https://postgr.es/m/OS0PR01MB5716860B1454C34E5B179B6694C99@OS0PR01MB5716.jpnprd01.prod.outlook.com  

commit   : d7c4830abb1867ca4fb83add2a5fac558f778b6a    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 25 Jan 2023 20:00:36 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 25 Jan 2023 20:00:36 +0900    

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

commit   : 0ad3c60caf5f77edfefaf8850fbba5ea4fe28640    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 25 Jan 2023 14:36:51 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 25 Jan 2023 14:36:51 +0900    

This rename is in preparation for the introduction of recovery modules,  
where basic_wal_module will be used as a base template for the set of  
callbacks introduced.  The former name did not really reflect all that.  
  
Author: Nathan Bossart  
Discussion: https://postgr.es/m/20221227192449.GA3672473@nathanxps13  

commit   : 239b1753421ccbd52f4f628a9265c3034d38b80f    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Wed, 25 Jan 2023 14:28:01 +1300    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Wed, 25 Jan 2023 14:28:01 +1300    

Modify the new event loop code from commit 7389aad6 so that it checks  
for work requested by signal handlers even if it doesn't see a latch  
event yet.  
  
This gives priority to shutdown and reload requests where the latch will  
be reported later in the event array, or in a later call to  
WaitEventSetWait(), due to scheduling details.  In particular, this  
guarantees that a SIGHUP-then-connect sequence (as seen in  
authentication tests) causes the postmaster to process the reload before  
accepting the connection.  If the WaitEventSetWait() call saw the socket  
as ready, and the reload signal was generated before the connection,  
then the latest time the signal handler should be able to run is after  
poll/epoll_wait/kevent returns but before we check the  
pending_pm_reload_request flag.  
  
While here, also shift the handling of child exit below reload requests,  
per Tom Lane's observation that that might start new processes, so we  
should make sure we pick up new settings first.  
  
This probably explains the one-off failure of build farm animal  
malleefowl.  
  
Reported-by: Hou Zhijie <houzj.fnst@fujitsu.com>  
Reported-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/OS0PR01MB57163D3BF2AB42ECAA94E5C394C29%40OS0PR01MB5716.jpnprd01.prod.outlook.com  

commit   : 8f8f11593258d04e9a58365865f7daf123e24bb1    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Tue, 24 Jan 2023 15:15:33 -0800    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Tue, 24 Jan 2023 15:15:33 -0800    

Update some remaining comments in multixact.c that still described SLRU  
truncation as happening in the checkpointer, rather than during VACUUM.  
  
Follow-up to commit 5212d447.  
  
Shi yu, with tweaks by me.  
  
Author: Shi yu <shiy.fnst@fujitsu.com>  
Discussion: https://postgr.es/m/OSZPR01MB631066BF246F8F74E83222FCFDC69@OSZPR01MB6310.jpnprd01.prod.outlook.com  

commit   : 1249371632db9d97786edfb3d58c3e89e75b9519    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Tue, 24 Jan 2023 16:04:21 -0500    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Tue, 24 Jan 2023 16:04:21 -0500    

This makes two small changes that will improve pgindent's usefulness in  
a git hook. First, it looks for the exclude file relative to the current  
directory. And second, it applies the filters to filenames given on the  
command line as well as those found in a directory sweep.  
  
It might prove necessary to make further efforts to find the exclude  
file, and even to allow multiple exclude files, but for now this should  
be enough for most purposes.  
  
Reviewed by Jelte Fennema  

commit   : f1358ca52dd7b8cedd29c6f2f8c163914f03ea2e    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Tue, 24 Jan 2023 10:57:09 -0500    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Tue, 24 Jan 2023 10:57:09 -0500    

Previously, a CREATEROLE user without SUPERUSER could not alter  
REPLICATION users in any way, and could not set the BYPASSRLS  
attribute. However, they could manipulate the CREATEDB property  
even if they themselves did not possess it.  
  
With this change, a CREATEROLE user without SUPERUSER can set or  
clear the REPLICATION, BYPASSRLS, or CREATEDB property on a new  
role or a role that they have rights to manage if and only if  
that property is set for their own role.  
  
This implements the standard idea that you can't give permissions  
you don't have (but you can give the ones you do have). We might  
in the future want to provide more powerful ways to constrain  
what a CREATEROLE user can do - for example, to limit whether  
CONNECTION LIMIT can be set or the values to which it can be set -  
but that is left as future work.  
  
Patch by me, reviewed by Nathan Bossart, Tushar Ahuja, and Neha  
Sharma.  
  
Discussion: http://postgr.es/m/CA+TgmobX=LHg_J5aT=0pi9gJy=JdtrUVGAu0zhr-i5v5nNbJDg@mail.gmail.com  

commit   : 6c6d6ba3ee2c160b53f727cf8e612014b316d6e4    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Tue, 24 Jan 2023 09:25:36 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Tue, 24 Jan 2023 09:25:36 +0530    

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

commit   : 728f86fec65537eade8d9e751961782ddb527934    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 23 Jan 2023 19:25:23 -0800    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Mon, 23 Jan 2023 19:25:23 -0800    

In contrast to the changes to dblink and postgres_fdw, this does not fix a  
bug, as libpqwalreceiver did already process interrupts.  
  
Besides reducing code duplication, the conversion leads to libpqwalreceiver  
now using reserving file descriptors for libpq connections. While not strictly  
required for the use in walreceiver, we are also using libpqwalreceiver for  
logical replication, where it does seem more important.  
  
Even if we eventually decide to backpatch the prior commits, there'd be no  
need to backpatch this commit, due to not fixing an active bug.  
  
Reviewed-by: Thomas Munro <thomas.munro@gmail.com>  
Discussion: https://postgr.es/m/20220925232237.p6uskba2dw6fnwj2@awork3.anarazel.de  

commit   : e4602483e95bebd4da31e4ea95dc5c7f715c1e4f    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 23 Jan 2023 19:25:23 -0800    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Mon, 23 Jan 2023 19:25:23 -0800    

Until now dblink and postgres_fdw did not process interrupts during connection  
establishment. Besides preventing query cancellations etc, this can lead to  
undetected deadlocks, as global barriers are not processed.  
  
These aforementioned undetected deadlocks are the reason for the spate of CI  
test failures in the FreeBSD 'test_running' step.  
  
Fix the bug by using the helper from libpq-be-fe-helpers.h, introduced in a  
prior commit. Besides fixing the bug, this also removes duplicated code  
around reserving file descriptors.  
  
As the change is relatively large and there are no field reports of the  
problem, don't backpatch for now.  
  
Reviewed-by: Thomas Munro <thomas.munro@gmail.com>  
Discussion: https://postgr.es/m/20220925232237.p6uskba2dw6fnwj2@awork3.anarazel.de  
Backpatch:  

commit   : 28a591711d505f1f64c4f2eff5873ca2de0abede    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 23 Jan 2023 19:25:23 -0800    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Mon, 23 Jan 2023 19:25:23 -0800    

Currently dblink and postgres_fdw don't process interrupts during connection  
establishment. Besides preventing query cancellations etc, this can lead to  
undetected deadlocks, as global barriers are not processed.  
  
Libpqwalreceiver in contrast, processes interrupts during connection  
establishment. The required code is not trivial, so duplicating it into  
additional places does not seem like a good option.  
  
These aforementioned undetected deadlocks are the reason for the spate of CI  
test failures in the FreeBSD 'test_running' step.  
  
For now the helper library is just a header, as it needs to be linked into  
each extension using libpq, and it seems too small to be worth adding a  
dedicated static library for.  
  
The conversion to the helper are done in subsequent commits.  
  
Reviewed-by: Thomas Munro <thomas.munro@gmail.com>  
Discussion: https://postgr.es/m/20220925232237.p6uskba2dw6fnwj2@awork3.anarazel.de  

commit   : bc54ef4ec25a3c642f1706a49f979b7750a2817e    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 23 Jan 2023 18:04:02 -0800    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Mon, 23 Jan 2023 18:04:02 -0800    

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

commit   : 9567686ec834e50ab10ae872a8394c9a9e590b0d    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Tue, 24 Jan 2023 13:49:10 +1300    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Tue, 24 Jan 2023 13:49:10 +1300    

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

commit   : b762fed6481e722a022ac2bea02151e080c31fa6    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Tue, 24 Jan 2023 12:30:30 +1300    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Tue, 24 Jan 2023 12:30:30 +1300    

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

commit   : 8dd43894b1f5c0148dd36308fc607bfcc909e5bd    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 23 Jan 2023 21:46:30 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 23 Jan 2023 21:46:30 +0100    

7fcbf6a and 2ff6555 changed the function signature of XLogPageRead()  
but did not update the comment.  
  
XLogReaderRoutine contains up to date information about the API, so no  
need to repeat all that at XLogPageRead(), but fix the mentions of the  
no longer existing function arguments.  

commit   : 6dfacbf72b53b775e8442a7fd2fca7c24b139773    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Mon, 23 Jan 2023 19:21:22 +0000    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Mon, 23 Jan 2023 19:21:22 +0000    

This enhances the numeric type input function, adding support for  
hexadecimal, octal, and binary integers of any size, up to the limits  
of the numeric type.  
  
Since 6fcda9aba8, such non-decimal integers have been accepted by the  
parser as integer literals and passed through to numeric_in(). This  
commit gives numeric_in() the ability to handle them.  
  
While at it, simplify the handling of NaN and infinities, reducing the  
number of calls to pg_strncasecmp(), and arrange for pg_strncasecmp()  
to not be called at all for regular numbers. This gives a significant  
performance improvement for decimal inputs, more than offsetting the  
small performance hit of checking for non-decimal input.  
  
Discussion: https://postgr.es/m/CAEZATCV8XShnmT9HZy25C%2Bo78CVOFmUN5EM9FRAZ5xvYTggPMg%40mail.gmail.com  

commit   : 62e1e28bf76910ffe47ddbc5c1fade41e1a65dac    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 23 Jan 2023 13:50:49 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 23 Jan 2023 13:50:49 -0500    

At least on my machine, the initial coding of this didn't actually  
work, because interpolation of "$post_fh->filename" doesn't act  
as intended.  
  
I threw in some double quotes too, just in case anybody tries  
to run this in a path containing spaces.  

commit   : 3cece34be842178a3c5697a58e03fb4a5d576378    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 23 Jan 2023 13:33:19 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 23 Jan 2023 13:33:19 -0500    

Historically we skipped writing/reading this field, but that no  
longer works under WRITE_READ_PARSE_PLAN_TREES since we expanded  
the coverage of that option to include utility commands (787102b56).  
Remove the special case and just treat this field normally.  
  
Bump catversion out of an abundance of caution --- I do not think  
we currently ever store RangeVar nodes in the catalogs, but  
perhaps I'm wrong.  
  
Per report from Pavel Stehule.  
  
Discussion: https://postgr.es/m/CAFj8pRAYvYu-qU7-NieqRRyaQZk-yr3UjtHQ2LR62PS9M1dZMA@mail.gmail.com  

commit   : a9dc7f9419e4f6cac419e195618dceac74846c83    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 23 Jan 2023 08:40:18 -0500    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 23 Jan 2023 08:40:18 -0500    

This feature has not been covered in tests up to now.  
  
John Naylor and Andrew Dunstan  
  
Discussion: https://postgr.es/m/06005bfb-0fd7-9d08-e0e5-440f277b73b4@dunslane.net  

commit   : ee4613d2b7327512477bcf8967e28a93fd01807d    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 23 Jan 2023 08:31:37 -0500    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 23 Jan 2023 08:31:37 -0500    

The code for detecting the Ldap installation and setting up a test  
server is broken out into a reusable module that can be used  for  
additional tests to be added in later patches.  
  
Discussion: https://postgr.es/m/06005bfb-0fd7-9d08-e0e5-440f277b73b4@dunslane.net  

commit   : b90f0b57474eac3980be8146f2e45f73a05c994f    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 23 Jan 2023 07:00:06 -0500    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 23 Jan 2023 07:00:06 -0500    

This adds two modes of running pgindent, neither of which results in  
any changes being made to the source code. The --show-diff option shows  
what changes would have been made, and the --silent-diff option just  
exits with a status of 2 if any changes would be made. The second of  
these is intended for scripting use in places such as git hooks.  
  
Along the way some code cleanup is done, and a --help option is also  
added.  
  
Reviewed by Tom Lane  
  
Discussion: https://postgr.es/m/c9c9fa6d-6de6-48c2-4f8b-0fbeef026439@dunslane.net  

commit   : 0aa38db56bf459d04ed58c22f7c689c0ae14e977    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Mon, 23 Jan 2023 11:56:00 +0000    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Mon, 23 Jan 2023 11:56:00 +0000    

On platforms with 128-bit integer support, introduce a new function  
div_var_int64(), along the same lines as div_var_int() added in  
d1b307eef2 for divisors with 1 or 2 base-NBASE digits, and use it to  
speed up div_var() and div_var_fast() in a similar way when the  
divisor has 3 or 4 base-NBASE digits.  
  
This gives significant performance gains for divisors with 9-16  
decimal digits.  
  
Joel Jacobson.  
  
Discussion:  
  https://postgr.es/m/b7a5893d-af18-4c0b-8918-96de5f1bbf39%40app.fastmail.com  
  https://postgr.es/m/CAEZATCXGm%3DDyTq%3DFrcOqC0gPMVveKUYTaD5KRRoajrUTiWxVMw%40mail.gmail.com  

commit   : 009dbdea02d74c72db2d1a57d5299f94f91fa975    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Mon, 23 Jan 2023 23:08:38 +1300    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Mon, 23 Jan 2023 23:08:38 +1300    

An upcoming patch by Melanie Plageman does some refactoring work in this  
area.  Run pgindent on that file now before making any changes so that  
it's easier to maintain/evolve each of the individual patches doing the  
refactor work.  Additionally, add a few new required typedefs to the list  
to make it easier to do future pgindent runs on this file during the  
refactor work.  
  
Discussion: https://postgr.es/m/CAAKRu_YSOnhKsDyFcqJsKtBSrd32DP-jjXmv7hL0BPD-z0TGXQ@mail.gmail.com  

commit   : 236f1ea84c4ca6a29d790fac4b48eba12a74443c    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 23 Jan 2023 11:56:43 +0200    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 23 Jan 2023 11:56:43 +0200    

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

commit   : 67c5b8840fcad07eeecd9af517b9b1ff09a3cf8e    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Mon, 23 Jan 2023 21:31:46 +1300    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Mon, 23 Jan 2023 21:31:46 +1300    

Per buildfarm member mandrill, it seems that  
max_parallel_workers_per_gather may not always be set to the default value  
of 2 when the new test added in 16fd03e95 is executed.  Here let's just  
explicitly set that to 2 so that the planner never opts to use more than  
that many parallel workers.  

commit   : c31cf1c03d01ce86f20bef8c980fe56a257b3b4b    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 23 Jan 2023 13:55:18 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 23 Jan 2023 13:55:18 +0900    

This function is able to extract the full page images from a range of  
records, specified as of input arguments start_lsn and end_lsn.  Like  
the other functions of this module, an error is returned if using LSNs  
that do not reflect real system values.  All the FPIs stored in a single  
record are extracted.  
  
The module's version is bumped to 1.1.  
  
Author: Bharath Rupireddy  
Reviewed-by: Bertrand Drouvot  
Discussion: https://postgr.es/m/CALj2ACVCcvzd7WiWvD=6_7NBvVB_r6G0EGSxL4F8vosAi6Se4g@mail.gmail.com  

commit   : 16fd03e956540d1b47b743f6a84f37c54ac93dd4    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Mon, 23 Jan 2023 17:35:01 +1300    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Mon, 23 Jan 2023 17:35:01 +1300    

This adds combine, serial and deserial functions for the array_agg() and  
string_agg() aggregate functions, thus allowing these aggregates to  
partake in partial aggregations.  This allows both parallel aggregation to  
take place when these aggregates are present and also allows additional  
partition-wise aggregation plan shapes to include plans that require  
additional aggregation once the partially aggregated results from the  
partitions have been combined.  
  
Author: David Rowley  
Reviewed-by: Andres Freund, Tomas Vondra, Stephen Frost, Tom Lane  
Discussion: https://postgr.es/m/CAKJS1f9sx_6GTcvd6TMuZnNtCh0VhBzhX6FZqw17TgVFH-ga_A@mail.gmail.com  

commit   : 5a3a95385bd5a8f1a4fd50545b7efe9338581899    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 22 Jan 2023 14:08:46 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 22 Jan 2023 14:08:46 -0500    

Enforce wal_retrieve_retry_interval on a per-subscription basis,  
rather than globally, and arrange to skip that delay in case of  
an intentional worker exit.  This probably makes little difference  
in the field, where apply workers wouldn't be restarted often;  
but it has a significant impact on the runtime of our logical  
replication regression tests (even though those tests use  
artificially-small wal_retrieve_retry_interval settings already).  
  
Nathan Bossart, with mostly-cosmetic editorialization by me  
  
Discussion: https://postgr.es/m/20221122004119.GA132961@nathanxps13  

commit   : c9f7f926484d69e2806e35343af7e472fadfede7    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 21 Jan 2023 13:10:29 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 21 Jan 2023 13:10:29 -0500    

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

commit   : e52daaabf8f1bf8096b0c105e2f719d9c68be3fa    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sat, 21 Jan 2023 06:08:00 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sat, 21 Jan 2023 06:08:00 -0800    

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

commit   : 03023a2664f8950ad522385ff75ce004bc932a7c    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Fri, 20 Jan 2023 21:16:47 -0800    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Fri, 20 Jan 2023 21:16:47 -0800    

Until now we used struct timespec for instr_time on all platforms but  
windows. Using struct timespec causes a fair bit of memory (struct timeval is  
16 bytes) and runtime overhead (much more complicated additions). Instead we  
can convert the time to nanoseconds in INSTR_TIME_SET_CURRENT(), making the  
remaining operations cheaper.  
  
Representing time as int64 nanoseconds provides sufficient range, ~292 years  
relative to a starting point (depending on clock source, relative to the unix  
epoch or the system's boot time). That'd not be sufficient for calendar time  
stored on disk, but is plenty for runtime interval time measurement.  
  
On windows instr_time already is represented as cycles. It might make sense to  
represent time as cycles on other platforms as well, as using cycle  
acquisition instructions like rdtsc directly can reduce the overhead of time  
acquisition substantially. This could be done in a fairly localized manner as  
the code stands after this commit.  
  
Because the windows and non-windows paths are now more similar, use a common  
set of macros. To make that possible, most of the use of LARGE_INTEGER had to  
be removed, which looks nicer anyway.  
  
To avoid users of the API relying on the integer representation, we wrap the  
64bit integer inside struct struct instr_time.  
  
Author: Andres Freund <andres@anarazel.de>  
Author: Lukas Fittl <lukas@fittl.com>  
Author: David Geier <geidav.pg@gmail.com>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/20230113195547.k4nlrmawpijqwlsa@awork3.anarazel.de  

commit   : 25b2aba0c3a501e2af9579f1b629f155544935db    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Fri, 20 Jan 2023 21:16:47 -0800    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Fri, 20 Jan 2023 21:16:47 -0800    

These are all not necessary from a correctness POV. However, in the near  
future instr_time will be simplified to an int64, at which point gcc would  
otherwise start to warn about the changed places.  
  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/20230116023639.rn36vf6ajqmfciua@awork3.anarazel.de  

commit   : 5d29d525ffe028fdf6b2d3ff7502243e56c6c79a    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sat, 21 Jan 2023 12:17:02 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sat, 21 Jan 2023 12:17:02 +0900    

This is similar to 835d476, except that this one is to add node  
attributes related to query jumbling and avoid long lines in the headers  
and in the node structures changed by this commit.  
  
Reviewed-by: Peter Eisentraut  
Discussion: https://postgr.es/m/Y5BHOUhX3zTH/ig6@paquier.xyz  

commit   : 8eba3e3f020843a7641121e778e161b58ec2e490    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sat, 21 Jan 2023 11:48:37 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sat, 21 Jan 2023 11:48:37 +0900    

This will ease a follow-up move that will generate automatically this  
code.  The C file is renamed, for consistency with the node-related  
files whose code are generated by gen_node_support.pl:  
- queryjumble.c -> queryjumblefuncs.c  
- utils/queryjumble.h -> nodes/queryjumble.h  
  
Per a suggestion from Peter Eisentraut.  
  
Reviewed-by: Peter Eisentraut  
Discussion: https://postgr.es/m/Y5BHOUhX3zTH/ig6@paquier.xyz  

commit   : 557890920dd03b5a7839e81deeb6099bd43f3b29    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 20 Jan 2023 16:37:26 -0500    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 20 Jan 2023 16:37:26 -0500    

It creates a new predefined role.  

commit   : 6e2775e4d4e47775f0d933e4a93c148024a3bc63    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 20 Jan 2023 15:36:36 -0500    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 20 Jan 2023 15:36:36 -0500    

This provides a way to reserve connection slots for non-superusers.  
The slots reserved via the new GUC are available only to users who  
have the new predefined role pg_use_reserved_connections.  
superuser_reserved_connections remains as a final reserve in case  
reserved_connections has been exhausted.  
  
Patch by Nathan Bossart. Reviewed by Tushar Ahuja and by me.  
  
Discussion: http://postgr.es/m/20230119194601.GA4105788@nathanxps13  

commit   : fe00fec1f5d78a5cfe46ac72dc284ed4cc477be1    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 20 Jan 2023 15:32:08 -0500    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 20 Jan 2023 15:32:08 -0500    

This is in preparation for adding a new reserved_connections GUC,  
but aligning the GUC name with the variable name is also a good  
idea on general principle.  
  
Patch by Nathan Bossart. Reviewed by Tushar Ahuja and by me.  
  
Discussion: http://postgr.es/m/20230119194601.GA4105788@nathanxps13  

commit   : 6c1d5ba4867828b387799a291cea9aaee2a8e3fc    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 20 Jan 2023 15:23:04 -0500    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 20 Jan 2023 15:23:04 -0500    

Commit ea92368cd1da1e290f9ab8efb7f60cb7598fc310 made max_wal_senders  
a separate pool of backends from max_connections, but the documentation  
and error message for superuser_reserved_connections weren't updated  
at the time, and as a result are somewhat misleading. Update.  
  
This is arguably a back-patchable bug fix, but because it seems quite  
minor, no back-patch.  
  
Patch by Nathan Bossart. Reviewed by Tushar Ahuja and by me.  
  
Discussion: http://postgr.es/m/20230119194601.GA4105788@nathanxps13  

commit   : e86c8b728f3c905e5993211f6fd1d107d5a4614f    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 20 Jan 2023 20:01:59 +0100    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 20 Jan 2023 20:01:59 +0100    

The original titles only had the module name, which is not very useful  
when scanning the list.  By adding a very brief description to each  
title, the table of contents becomes friendlier.  
  
Also amend the introduction in the "additional modules" appendix, using  
the word "Extension" more extensively.  Nowadays, almost all contrib  
modules are extensions, so this is also helpful.  
  
Author: Karl O. Pinc <kop@karlpinc.com>  
Reviewed-by: Brar Piening <brar@gmx.de>  
Discussion: https://postgr.es/m/20230102180015.372995a9@slate.karlpinc.com  

commit   : d137cb52cb7fd44a3f24f3c750fbf7924a4e9532    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Thu, 19 Jan 2023 18:50:01 -0800    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Thu, 19 Jan 2023 18:50:01 -0800    

Prior patches got rid of all the uses of SHM_QUEUE. ilist.h style lists are  
more widely used and have an easier to use interface. As there are no users  
left, remove SHM_QUEUE.  
  
Reviewed-by: Thomas Munro <thomas.munro@gmail.com> (in an older version)  
Discussion: https://postgr.es/m/20221120055930.t6kl3tyivzhlrzu2@awork3.anarazel.de  
Discussion: https://postgr.es/m/20200211042229.msv23badgqljrdg2@alap3.anarazel.de  

commit   : 9600371764583c80f3d94957e3d16daa2661154b    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Thu, 19 Jan 2023 18:50:01 -0800    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Thu, 19 Jan 2023 18:50:01 -0800    

Part of a series to remove SHM_QUEUE. ilist.h style lists are more widely used  
and have an easier to use interface.  
  
Reviewed-by: Thomas Munro <thomas.munro@gmail.com> (in an older version)  
Discussion: https://postgr.es/m/20221120055930.t6kl3tyivzhlrzu2@awork3.anarazel.de  
Discussion: https://postgr.es/m/20200211042229.msv23badgqljrdg2@alap3.anarazel.de  

commit   : 7670add9f43aeb291603c7052a2610675e1924f7    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Fri, 20 Jan 2023 08:12:19 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Fri, 20 Jan 2023 08:12:19 +0530    

We were inconsistently specifying the required and optional marking for  
plugin callbacks. Additionally, this patch improves the description for  
stream_prepare callback.  
  
Author: Wang wei  
Reviewed-by: Amit Kapila  
Discussion: https://postgr.es/m/OS3PR01MB627553DAFD39ECDADD08DC909EFC9@OS3PR01MB6275.jpnprd01.prod.outlook.com  

commit   : efb6f4a4f9b627b9447f5cd8e955d43a7066c30c    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 20 Jan 2023 11:21:55 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 20 Jan 2023 11:21:55 +0900    

While pg_hba.conf has support for non-literal username matches, and  
this commit extends the capabilities that are supported for the  
PostgreSQL user listed in an ident entry part of pg_ident.conf, with  
support for:  
1. The "all" keyword, where all the requested users are allowed.  
2. Membership checks using the + prefix.  
3. Using a regex to match against multiple roles.  
  
1. is a feature that has been requested by Jelte Fennema, 2. something  
that has been mentioned independently by Andrew Dunstan, and 3. is  
something I came up with while discussing how to extend the first one,  
whose implementation is facilitated by 8fea868.  
  
This allows matching certain system users against many different  
postgres users with a single line in pg_ident.conf.  Without this, one  
would need one line for each of the postgres users that a system user  
can log in as, which can be cumbersome to maintain.  
  
Tests are added to the TAP test of peer authentication to provide  
coverage for all that.  
  
Note that this introduces a set of backward-incompatible changes to be  
able to detect the new patterns, for the following cases:  
- A role named "all".  
- A role prefixed with '+' characters, which is something that would not  
have worked in HBA entries anyway.  
- A role prefixed by a slash character, similarly to 8fea868.  
Any of these can be still be handled by using quotes in the Postgres  
role defined in an ident entry.  
  
A huge advantage of this change is that the code applies the same checks  
for the Postgres roles in HBA and ident entries, via the common routine  
check_role().  
  
**This compatibility change should be mentioned in the release notes.**  
  
Author: Jelte Fennema  
Discussion: https://postgr.es/m/DBBPR83MB0507FEC2E8965012990A80D0F7FC9@DBBPR83MB0507.EURPRD83.prod.outlook.com  

commit   : 74739d1d3ff6b408895a5908657ffb0648df3d70    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 19 Jan 2023 19:32:46 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 19 Jan 2023 19:32:46 -0500    

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

commit   : 9f1ca6ce6596f1f77adc323769f2f8303ddad14f    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Fri, 20 Jan 2023 13:07:24 +1300    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Fri, 20 Jan 2023 13:07:24 +1300    

This adjusts a few places which were appending a string constant  
containing spaces onto a StringInfo.  We have appendStringInfoSpaces for  
that job, so let's use that instead.  
  
For the change to jsonb.c's add_indent() function, appendStringInfoString  
was being called inside a loop to append 4 spaces on each loop.  This  
meant that enlargeStringInfo would get called once per loop.  Here it  
should be much more efficient to get rid of the loop and just calculate  
the number of spaces with "level * 4" and just append all the spaces in  
one go.  
  
Here we additionally adjust the appendStringInfoSpaces function so it  
makes use of memset rather than a while loop to apply the required spaces  
to the StringInfo.  One of the problems with the while loop was that it  
was incrementing one variable and decrementing another variable once per  
loop.  That's more work than what's required to get the job done.  We may  
as well use memset for this rather than trying to optimize the existing  
loop.  Some testing has shown memset is faster even for very small sizes.  
  
Discussion: https://postgr.es/m/CAApHDvp_rKkvwudBKgBHniNRg67bzXVjyvVKfX0G2zS967K43A@mail.gmail.com  

commit   : 1ca604c2018456f2da357d944e0f03c3efaeb00d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 19 Jan 2023 18:41:08 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 19 Jan 2023 18:41:08 -0500    

Sirisha Chamarthi and Kyotaro Horiguchi  
  
Discussion: https://postgr.es/m/CAKrAKeXt-=bgm=d+EDmcC9kWoikp8kbVb3LH0K3K+AGGsykpHQ@mail.gmail.com  

commit   : 5a617d75d3b31414f378dd764a11db1a08fa79bb    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 19 Jan 2023 16:21:44 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 19 Jan 2023 16:21:44 -0500    

This patch largely reverts what I did in commits c9b0c678d and  
78e73e875.  The maximum cover length limit that I added in 78e73e875  
(to band-aid over c9b0c678d's performance issues) creates too many  
user-visible behavior discrepancies, as complained of for example in  
bug #17691.  The real problem with hlCover() is not what I thought  
at the time, but more that it seems to have been designed with only  
AND tsquery semantics in mind.  It doesn't work quite right for OR,  
and even less so for NOT or phrase queries.  However, we can improve  
that situation by building a variant of TS_execute() that returns a  
list of match locations.  We already get an ExecPhraseData struct  
representing match locations for the primitive case of a simple match,  
as well as one for a phrase match; we just need to add some logic to  
combine these for AND and OR operators.  The result is a list of  
ExecPhraseDatas, which hlCover can regard as having simple AND  
semantics, so that its old algorithm works correctly.  
  
There's still a lot not to like about ts_headline's behavior, but  
I think the remaining issues have to do with the heuristics used  
in mark_hl_words and mark_hl_fragments (which, likewise, were not  
revisited when phrase search was added).  Improving those is a task  
for another day.  
  
Patch by me; thanks to Alvaro Herrera for review.  
  
Discussion: https://postgr.es/m/840.1669405935@sss.pgh.pa.us  

commit   : 44e9e34266efd42901bf7b12552f2033972d70b7    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 19 Jan 2023 12:23:20 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 19 Jan 2023 12:23:20 -0500    

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

commit   : 438e6b7240905c8055f9e221187f2ac818876169    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 19 Jan 2023 12:54:15 +0100    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 19 Jan 2023 12:54:15 +0100    

RelOptInfo.userid is the same for all relations in a given inheritance  
tree, so the code in examine_variable() and example_simple_variable()  
that repeats the ACL checks on the root parent rel instead of a given  
leaf child relations need not recompute userid too.  
  
Author: Amit Langote <amitlangote09@gmail.com>  
Reported-by: Justin Pryzby <pryzby@telsasoft.com>  
Discussion: https://postgr.es/m/20221210201753.GA27893@telsasoft.com  

commit   : 48880840f18cb75fcaecc77b5e7816b92c27157b    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 19 Jan 2023 09:45:34 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 19 Jan 2023 09:45:34 +0100    

This is a follow-up to c8ad4d81.  
  
Author: Aleksander Alekseev  
Discussion: https://www.postgresql.org/message-id/flat/CAJ7c6TM084Ai_8%3DfZaWtULJBLtT1bgzL%3Dk9vHMYom3eyZsekAA%40mail.gmail.com  

commit   : 4f74f5641d53559ec44e74d5bf552e167fdd5d20    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 19 Jan 2023 14:00:23 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 19 Jan 2023 14:00:23 +0900    

wal_retrieve_retry_interval was mentioned under an incorrect name, and  
wal_sender_timeout was not listed as affecting WAL senders in logical  
replication mode.  
  
Author: Takamichi Osumi  
Discussion: https://postgr.es/m/TYCPR01MB8373D65E6B0A769ED12EADCBEDC79@TYCPR01MB8373.jpnprd01.prod.outlook.com  

commit   : 7e8a80d1fefd1e96992652ed5a628c437971c82e    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 19 Jan 2023 13:13:05 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 19 Jan 2023 13:13:05 +0900    

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

commit   : 6ba6306256a37524bbbc76402e69ef3d32d355fd    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 19 Jan 2023 10:01:53 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 19 Jan 2023 10:01:53 +0900    

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

commit   : a3b65fb28238fe7f4a1ae9685d39ff0c11bdb9d3    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 18 Jan 2023 16:51:40 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 18 Jan 2023 16:51:40 -0500    

Turns out the compression.sql test creates a view that needs  
to be adjusted in the wake of 47bb9db75 --- except that without  
--with-lz4, it fails to create the view at all, so I'd not  
noticed this in testing.  
  
Per buildfarm member crake.  

commit   : 5ea2234670e58000c7ffde38df3bea91972bc2df    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 18 Jan 2023 15:27:29 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 18 Jan 2023 15:27:29 -0500    

This delta in expected output wasn't spotted in any previous  
testing of the patch.  Reported by Andres Freund.  
  
Discussion: https://postgr.es/m/20230118195855.7yjc4mminmv7iyy5@awork3.anarazel.de  

commit   : 12605414a7d63ccbe36de2b530847bdfc9cf7447    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Wed, 18 Jan 2023 12:15:05 -0800    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Wed, 18 Jan 2023 12:15:05 -0800    

Part of a series to remove SHM_QUEUE. ilist.h style lists are more widely used  
and have an easier to use interface.  
  
Reviewed-by: Thomas Munro <thomas.munro@gmail.com> (in an older version)  
Discussion: https://postgr.es/m/20221120055930.t6kl3tyivzhlrzu2@awork3.anarazel.de  
Discussion: https://postgr.es/m/20200211042229.msv23badgqljrdg2@alap3.anarazel.de  

commit   : 5764f611e10b126e09e37fdffbe884c44643a6ce    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Wed, 18 Jan 2023 11:41:14 -0800    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Wed, 18 Jan 2023 11:41:14 -0800    

Part of a series to remove SHM_QUEUE. ilist.h style lists are more widely used  
and have an easier to use interface.  
  
As PROC_QUEUE is now unused, remove it.  
  
Reviewed-by: Thomas Munro <thomas.munro@gmail.com> (in an older version)  
Discussion: https://postgr.es/m/20221120055930.t6kl3tyivzhlrzu2@awork3.anarazel.de  
Discussion: https://postgr.es/m/20200211042229.msv23badgqljrdg2@alap3.anarazel.de  

commit   : 51384cc40c4a72c81d2475089ab8a1cf98ea56ff    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Wed, 18 Jan 2023 11:41:14 -0800    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Wed, 18 Jan 2023 11:41:14 -0800    

These allow to test whether an element is in a list by checking whether  
prev/next are NULL. Needed to replace SHMQueueIsDetached() when converting  
from SHM_QUEUE to ilist.h style lists.  
  
Reviewed-by: Thomas Munro <thomas.munro@gmail.com>  
Discussion: https://postgr.es/m/20221120055930.t6kl3tyivzhlrzu2@awork3.anarazel.de  
Discussion: https://postgr.es/m/20200211042229.msv23badgqljrdg2@alap3.anarazel.de  

commit   : 2b16208753770318085b1201a6d101cab2697132    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Wed, 18 Jan 2023 10:22:37 -0800    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Wed, 18 Jan 2023 10:22:37 -0800    

In c8ad4d8166a dlist_member_check()'s arguments were made const. Unfortunately  
the implementation of dlist_member_check() used dlist_foreach(), which  
currently doesn't work for const lists.  
  
As a workaround, open-code the list iteration. The other check functions  
already do so.  
  
Discussion: https://postgr.es/m/20230118182214.co7dp4oahiunwg57@awork3.anarazel.de  

commit   : 47bb9db75996232ea71fc1e1888ffb0e70579b54    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 18 Jan 2023 13:23:57 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 18 Jan 2023 13:23:57 -0500    

The rule system needs "old" and/or "new" pseudo-RTEs in rule actions  
that are ON INSERT/UPDATE/DELETE.  Historically it's put such entries  
into the ON SELECT rules of views as well, but those are really quite  
vestigial.  The only thing we've used them for is to carry the  
view's relid forward to AcquireExecutorLocks (so that we can  
re-lock the view to verify it hasn't changed before re-using a plan)  
and to carry its relid and permissions data forward to execution-time  
permissions checks.  What we can do instead of that is to retain  
these fields of the RTE_RELATION RTE for the view even after we  
convert it to an RTE_SUBQUERY RTE.  This requires a tiny amount of  
extra complication in the planner and AcquireExecutorLocks, but on  
the other hand we can get rid of the logic that moves that data from  
one place to another.  
  
The principal immediate benefit of doing this, aside from a small  
saving in the pg_rewrite data for views, is that these pseudo-RTEs  
no longer trigger ruleutils.c's heuristic about qualifying variable  
names when the rangetable's length is more than 1.  That results  
in quite a number of small simplifications in regression test outputs,  
which are all to the good IMO.  
  
Bump catversion because we need to dump a few more fields of  
RTE_SUBQUERY RTEs.  While those will always be zeroes anyway in  
stored rules (because we'd never populate them until query rewrite)  
they are useful for debugging, and it seems like we'd better make  
sure to transmit such RTEs accurately in plans sent to parallel  
workers.  I don't think the executor actually examines these fields  
after startup, but someday it might.  
  
This is a second attempt at committing 1b4d280ea.  The difference  
from the first time is that now we can add some filtering rules to  
AdjustUpgrade.pm to allow cross-version upgrade testing to pass  
despite all the cosmetic changes in CREATE VIEW outputs.  
  
Amit Langote (filtering rules by me)  
  
Discussion: https://postgr.es/m/CA+HiwqEf7gPN4Hn+LoZ4tP2q_Qt7n3vw7-6fJKOf92tSEnX6Gg@mail.gmail.com  
Discussion: https://postgr.es/m/891521.1673657296@sss.pgh.pa.us  

commit   : 8d83a5d0a2673174dc478e707de1f502935391a5    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 18 Jan 2023 12:37:57 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 18 Jan 2023 12:37:57 -0500    

Avoid explicitly grouping by columns that we know are redundant  
for sorting, for example we need group by only one of x and y in  
	SELECT ... WHERE x = y GROUP BY x, y  
This comes up more often than you might think, as shown by the  
changes in the regression tests.  It's nearly free to detect too,  
since we are just piggybacking on the existing logic that detects  
redundant pathkeys.  (In some of the existing plans that change,  
it's visible that a sort step preceding the grouping step already  
didn't bother to sort by the redundant column, making the old plan  
a bit silly-looking.)  
  
To do this, build processed_groupClause and processed_distinctClause  
lists that omit any provably-redundant sort items, and consult those  
not the originals where relevant.  This means that within the  
planner, one should usually consult root->processed_groupClause or  
root->processed_distinctClause if one wants to know which columns  
are to be grouped on; but to check whether grouping or distinct-ing  
is happening at all, check non-NIL-ness of parse->groupClause or  
parse->distinctClause.  This is comparable to longstanding rules  
about handling the HAVING clause, so I don't think it'll be a huge  
maintenance problem.  
  
nodeAgg.c also needs minor mods, because it's now possible to generate  
AGG_PLAIN and AGG_SORTED Agg nodes with zero grouping columns.  
  
Patch by me; thanks to Richard Guo and David Rowley for review.  
  
Discussion: https://postgr.es/m/185315.1672179489@sss.pgh.pa.us  

commit   : d540a02a724b9643205abce8c5644a0f0908f6e3    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Wed, 18 Jan 2023 09:03:12 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Wed, 18 Jan 2023 09:03:12 +0530    

Add leader_pid to pg_stat_subscription. leader_pid is the process ID of  
the leader apply worker if this process is a parallel apply worker. If  
this field is NULL, it indicates that the process is a leader apply  
worker or a synchronization worker. The new column makes it easier to  
distinguish parallel apply workers from other kinds of workers and helps  
to identify the leader for the parallel workers corresponding to a  
particular subscription.  
  
Additionally, update the leader_pid column in pg_stat_activity as well to  
display the PID of the leader apply worker for parallel apply workers.  
  
Author: Hou Zhijie  
Reviewed-by: Peter Smith, Sawada Masahiko, Amit Kapila, Shveta Mallik  
Discussion: https://postgr.es/m/CAA4eK1+wyN6zpaHUkCLorEWNx75MG0xhMwcFhvjqm2KURZEAGw@mail.gmail.com  

commit   : 14bdb3f13de16523609d838b725540af5e23ddd3    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 18 Jan 2023 11:15:48 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 18 Jan 2023 11:15:48 +0900    

Presently, restore_command uses a different code path than  
archive_cleanup_command and recovery_end_command.  These code paths  
are similar and can be easily combined, as long as it is possible to  
identify if a command should:  
- Issue a FATAL on signal.  
- Exit immediately on SIGTERM.  
  
While on it, this removes src/common/archive.c and its associated  
header.  Since the introduction of c96de2c, BuildRestoreCommand() has  
become a simple wrapper of replace_percent_placeholders() able to call  
make_native_path().  This simplifies shell_restore.c as long as  
RestoreArchivedFile() includes a call to make_native_path().  
  
Author: Nathan Bossart  
Reviewed-by: Andres Freund, Michael Paquier  
Discussion: https://postgr.es/m/20221227192449.GA3672473@nathanxps13  

commit   : 2f31f405e1fa561db27e8dc6f7f3cb3dbd8c0c4f    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 18 Jan 2023 08:55:26 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 18 Jan 2023 08:55:26 +0900    

This makes sure that the internal logic of these functions does not  
attempt to change the value of the arguments constified, and it removes  
one unconstify() in basic_archive.c.  
  
Author: Nathan Bossart  
Reviewed-by: Andrew Dunstan, Peter Eisentraut  
Discussion: https://postgr.es/m/20230114231126.GA2580330@nathanxps13  

commit   : 09d465c397165f99c37e9002a4e7b281111d2580    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 17 Jan 2023 17:13:18 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 17 Jan 2023 17:13:18 -0500    

Avoid use of "_" in SGML IDs.  Awhile back that was actually  
disallowed by the toolchain, as a consequence of which our convention  
has been to use "-" instead.  Fix a couple of stragglers that are  
particularly inconsistent with that convention and with related IDs.  
  
This is just neatnik-ism, so no need for back-patch.  
  
Discussion: https://postgr.es/m/769446.1673478332@sss.pgh.pa.us  

commit   : 27da598961ce443e9010c19085d17dc2b6a04d56    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Tue, 17 Jan 2023 13:49:09 -0800    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Tue, 17 Jan 2023 13:49:09 -0800    

It's likely worth adding some automated way of preventing further  
omissions. We're discussing how to best do that.  
  
Reported-by: Justin Pryzby <pryzby@telsasoft.com>  
Discussion: https://postgr.es/m/20230117173509.GV9837@telsasoft.com  

commit   : 3a36ca03e423ad1e2c9f19cd0da5e7dedb48734e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 17 Jan 2023 16:00:39 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 17 Jan 2023 16:00:39 -0500    

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

commit   : 2a1d7071c4ed750abb8b39436bb89c7d152bddb8    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 17 Jan 2023 20:03:35 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 17 Jan 2023 20:03:35 +0100    

Instead of half a dozen of mostly-duplicate conditional branches,  
write one common one that can handle most catalogs.  We already have  
all the information we need, such as which system catalog corresponds  
to which catalog table and which column is the ACL column.  
  
Reviewed-by: Nathan Bossart <nathandbossart@gmail.com>  
Discussion: https://www.postgresql.org/message-id/flat/504bc485-6bd6-dd1b-fe10-e7351aeb310d@enterprisedb.com  

commit   : 13b345df6438f222daf56eee86cb272628d1f1c3    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 17 Jan 2023 20:03:35 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 17 Jan 2023 20:03:35 +0100    

This was erroneous, because AggregateRelationId has no OID, so it  
cannot be part of an extension directly.  (Aggregates are registered  
via pg_proc.)  No harm in practice, but better to make it correct.  
  
Reviewed-by: Nathan Bossart <nathandbossart@gmail.com>  
Discussion: https://www.postgresql.org/message-id/flat/504bc485-6bd6-dd1b-fe10-e7351aeb310d@enterprisedb.com  

commit   : 15eb1228800a35042ef318f941173aa8b89002d1    
  
author   : John Naylor <john.naylor@postgresql.org>    
date     : Tue, 17 Jan 2023 14:25:01 +0700    
  
committer: John Naylor <john.naylor@postgresql.org>    
date     : Tue, 17 Jan 2023 14:25:01 +0700    

Ranier Vilela  
  
Reviewed by Justin Pryzby  
Discussion: https://www.postgresql.org/message-id/CAEudQAp2R2fbbi0OHHhv_n4%3DCh0t1VtjObR9YMqtGKHJ%2BfaUFQ%40mail.gmail.com  

commit   : e29c5653434ebf6a88d009746d21ca3a59ddb69b    
  
author   : John Naylor <john.naylor@postgresql.org>    
date     : Tue, 17 Jan 2023 13:52:11 +0700    
  
committer: John Naylor <john.naylor@postgresql.org>    
date     : Tue, 17 Jan 2023 13:52:11 +0700    

Remove some code guarded by IS_MINUS() or IS_PLUS(), where the entire  
stanza is inside an else-block where both of these are false. This  
should slightly improve test coverage.  
  
While at it, remove coding that apparently assumes that unsetting a  
bit is so expensive that we have to first check if it's already set  
in the first place.  
  
Per Coverity report from Ranier Vilela  
Analysis and review by Justin Pryzby  
  
Discussion: https://www.postgresql.org/message-id/20221223010818.GP1153%40telsasoft.com  

commit   : c981d9145deae067bc67bc8f8bcd68b300ece3fe    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Tue, 17 Jan 2023 11:28:22 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Tue, 17 Jan 2023 11:28:22 +0530    

The code that decides the apply action missed to handle non-transactional  
messages and we didn't catch it in our testing as currently such messages  
are simply ignored by the apply worker. This was introduced by changes in  
commit 216a784829.  
  
While testing this, I noticed that we forgot to reset stream_xid after  
processing the stream stop message which could also result in the wrong  
apply action after the fix for non-transactional messages.  
  
In passing, change assert to elog for unexpected apply action in some of  
the routines so as to catch the problems in the production environment, if  
any.  
  
Reported-by: Tomas Vondra  
Author: Amit Kapila  
Reviewed-by: Tomas Vondra, Sawada Masahiko, Hou Zhijie  
Discussion: https://postgr.es/m/984ff689-adde-9977-affe-cd6029e850be@enterprisedb.com  
Discussion: https://postgr.es/m/CAA4eK1+wyN6zpaHUkCLorEWNx75MG0xhMwcFhvjqm2KURZEAGw@mail.gmail.com  

commit   : 4f985aba6963b8669325e1c58585d04257977fda    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Tue, 17 Jan 2023 10:39:11 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Tue, 17 Jan 2023 10:39:11 +0530    

Author: Osumi Takamichi  
Discussion: https://postgr.es/m/TYCPR01MB83737EA140C79B7D099F65E8EDC69@TYCPR01MB8373.jpnprd01.prod.outlook.com  

commit   : 0b717432ff13683f9d13f007dab1c3380cae2f0d    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 17 Jan 2023 13:41:09 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 17 Jan 2023 13:41:09 +0900    

Entries of pg-user in pg_ident.conf that are quoted and include '\1'  
allow a replacement from a subexpression in a system user regexp.  This  
commit adds a test to track this behavior and a note in the  
documentation, as it could be affected by the use of an AuthToken for  
the pg-user in the IdentLines parsed.  
  
This subject has come up in the discussion aimed at extending the  
support of pg-user in ident entries for more patterns.  
  
Author: Jelte Fennema  
Discussion: https://postgr.es/m/CAGECzQRNow4MwkBjgPxywXdJU_K3a9+Pm78JB7De3yQwwkTDew@mail.gmail.com  

commit   : da5800d5fa636c6e10c9c98402d872c76aa1c8d0    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Tue, 17 Jan 2023 16:37:06 +1300    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Tue, 17 Jan 2023 16:37:06 +1300    

In 1349d2790, we gave the planner the ability to provide ORDER BY/DISTINCT  
Aggrefs with presorted input so that nodeAgg would not have to perform  
sorts during execution.  That commit failed to properly consider the  
implications of if the Aggref had a volatile function in its ORDER  
BY/DISTINCT clause.  As it happened, this resulted in an ERROR about the  
volatile function being missing from the targetlist.  
  
Here, instead of adding the volatile function to the targetlist, we just  
never consider an Aggref with a volatile function in its ORDER BY/DISTINCT  
clause when choosing which Aggrefs we should sort by.  We do this as if we  
were to choose a plan which provided these aggregates with presorted  
input, then if there were many such aggregates which could all share the  
same sort order, then it may be surprising if they all shared the same  
sort sometimes and didn't at other times when some other set of aggregates  
were given presorted results.  We can avoid this inconsistency by just  
never providing these volatile function aggregates with presorted input.  
  
Reported-by: Dean Rasheed  
Discussion: https://postgr.es/m/CAEZATCWETioXs5kY8vT6BVguY41_wD962VDk=u_Nvd7S1UXzuQ@mail.gmail.com  

commit   : 52585f8f072ac187380f7e02183e87dcf6789ff0    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 16 Jan 2023 20:35:53 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 16 Jan 2023 20:35:53 -0500    

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

commit   : 980ae173108e353045e5ab4a842bb21e9dfe6715    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 16 Jan 2023 09:34:37 -0800    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 16 Jan 2023 09:34:37 -0800    

Tighten up the way that visibilitymap_set() is called: request that both  
the all-visible and all-frozen bits get set whenever the all-frozen bit  
is set, regardless of what we think we know about the present state of  
the all-visible bit.  Also make sure that the page level PD_ALL_VISIBLE  
flag is set in the same code path.  
  
In practice there doesn't seem to be a concrete scenario in which the  
previous approach could lead to inconsistencies.  It was almost possible  
in scenarios involving concurrent HOT updates from transactions that  
abort, but (unlike pruning) freezing can never remove XIDs > VACUUM's  
OldestXmin, even those from transactions that are known to have aborted.  
That was protective here.  
  
These issues have been around since commit a892234f83, which added the  
all-frozen bit to the VM fork.  There is no known live bug here, so no  
backpatch.  
  
In passing, add some defensive assertions to catch the issue, and stop  
reading the existing state of the VM when setting the VM in VACUUM's  
final heap pass.  We already know that affected pages must have had at  
least one LP_DEAD item before we set it LP_UNUSED, so there is no point  
in reading the VM when it is set like this.  
  
Author: Peter Geoghegan <pg@bowt.ie>  
Reviewed-By: Andres Freund <andres@anarazel.de>  
Discussion: https://postgr.es/m/CAH2-WznuNGSzF8v6OsgjaC5aYsb3cZ6HW6MLm30X0d65cmSH6A@mail.gmail.com  

commit   : 6fa66ec88ff29f5449d89e9891a00fe64afae34e    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Mon, 16 Jan 2023 10:49:59 -0500    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Mon, 16 Jan 2023 10:49:59 -0500    

Add a cross-reference from the part of the page that introdues SECURITY  
INVOKER and SECURITY DEFINER to the part of the page that talks about  
writing SECURITY DEFINER functions safely, so that users are less likely  
to miss it.  
  
Remove discussion of the pre-8.3 behavior on the theory that it's  
probably not very relevant any more, that release having gone out of  
support nearly a decade ago.  
  
Add a mention of the new createrole_self_grant GUC, which in  
certain cases might need to be set to a safe value to avoid  
unexpected consequences.  
  
Possibly this section needs major surgery rather than just these  
small tweaks, but hopefully this is at least a small step  
forward.  
  
Discussion: http://postgr.es/m/CA+Tgmoauqd1cHQjsNEoxL5O-kEO4iC9dAPyCudSvmNqPJGmy9g@mail.gmail.com  

commit   : 3cdf7502f85c9e61913e05519f88580f008b8453    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Mon, 16 Jan 2023 10:35:29 -0500    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Mon, 16 Jan 2023 10:35:29 -0500    

Update the reference pages for various ALTER commands that  
mentioned that you must be a member of role that will be the  
new owner to instead say that you must be able to SET ROLE  
to the new owner. Update ddl.sgml's generate statement on this  
topic along similar lines.  
  
Likewise, update CREATE SCHEMA and CREATE DATABASE, which  
have options to specify who will own the new objects, to say  
that you must be able to SET ROLE to the role that will own  
them.  
  
Finally, update the documentation for the GRANT statement  
itself with some general principles about how the SET option  
works and how it can be used.  
  
Patch by me, reviewed (but not fully endorsed) by Noah Misch.  
  
Discussion: http://postgr.es/m/CA+TgmoZk6VB3DQ83+DO5P_HP=M9PQAh1yj-KgeV30uKefVaWDg@mail.gmail.com  

commit   : 20428d344a2964de6aaef9984fcd472f3c65d115    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 16 Jan 2023 09:20:44 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 16 Jan 2023 09:20:44 +0100    

Most callers of BufFileRead() want to check whether they read the full  
specified length.  Checking this at every call site is very tedious.  
This patch provides additional variants BufFileReadExact() and  
BufFileReadMaybeEOF() that include the length checks.  
  
I considered changing BufFileRead() itself, but this function is also  
used in extensions, and so changing the behavior like this would  
create a lot of problems there.  The new names are analogous to the  
existing LogicalTapeReadExact().  
  
Reviewed-by: Amit Kapila <amit.kapila16@gmail.com>  
Discussion: https://www.postgresql.org/message-id/flat/f3501945-c591-8cc3-5ef0-b72a2e0eaa9c@enterprisedb.com  

commit   : 1561612e3bf3264c31618b9455d0c1003b9271ec    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 16 Jan 2023 09:20:44 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 16 Jan 2023 09:20:44 +0100    

Remove "%m" from error messages where errno would be bogus.  Add short  
read byte counts where appropriate.  
  
This is equivalent to what was done in  
7897e3bb902c557412645b82120f4d95f7474906, but some code was apparently  
developed concurrently to that and not updated accordingly.  
  
Reviewed-by: Amit Kapila <amit.kapila16@gmail.com>  
Discussion: https://www.postgresql.org/message-id/flat/f3501945-c591-8cc3-5ef0-b72a2e0eaa9c@enterprisedb.com  

commit   : 9a740f81eb02e04179d78f3df2ce671276c27b07    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 16 Jan 2023 16:31:43 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 16 Jan 2023 16:31:43 +0900    

The code specific to the execution of archive_cleanup_command,  
recovery_end_command and restore_command is moved to a new file named  
shell_restore.c.  The code is split into three functions:  
- shell_restore(), that attempts the execution of a shell-based  
restore_command.  
- shell_archive_cleanup(), for archive_cleanup_command.  
- shell_recovery_end(), for recovery_end_command.  
  
This introduces no functional changes, with failure patterns and logs  
generated in consequence being the same as before (one case actually  
generates one less DEBUG2 message "could not restore" when a restore  
command succeeds but the follow-up stat() to check the size fails, but  
that only matters with a elevel high enough).  
  
This is preparatory work for allowing recovery modules, a facility  
similar to archive modules, with callbacks shaped similarly to the  
functions introduced here.  
  
Author: Nathan Bossart  
Reviewed-by: Andres Freund, Michael Paquier  
Discussion: https://postgr.es/m/20221227192449.GA3672473@nathanxps13  

commit   : 02d3448f4f792964995b8071fa07176606e1af85    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 16 Jan 2023 13:58:07 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 16 Jan 2023 13:58:07 +0900    

While system_user was stored as an AuthToken in IdentLine, pg_user was  
stored as a plain string.  This commit changes the code as we start  
storing pg_user as an AuthToken too.  
  
This does not have any functional changes, as all the operations on  
pg_user only use the string from the AuthToken.  There is no regexp  
compiled and no check based on its quoting, yet.  This is in preparation  
of more features that intend to extend its capabilities, like support  
for regexps and group membership.  
  
Author: Jelte Fennema  
Discussion: https://postgr.es/m/CAGECzQRNow4MwkBjgPxywXdJU_K3a9+Pm78JB7De3yQwwkTDew@mail.gmail.com  

commit   : 647fa500547fdf2a967412633a9f6f21ba69e144    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 15 Jan 2023 17:32:09 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 15 Jan 2023 17:32:09 -0500    

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

commit   : 3f244d020fbf0b4f01d71e1b7620930be4bf9dc5    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 15 Jan 2023 13:14:52 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 15 Jan 2023 13:14:52 -0500    

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

commit   : 1334b79a359fb842d2d3cfe5b61ad4ccff8b82a4    
  
author   : Tatsuo Ishii <ishii@postgresql.org>    
date     : Sat, 14 Jan 2023 18:05:09 +0900    
  
committer: Tatsuo Ishii <ishii@postgresql.org>    
date     : Sat, 14 Jan 2023 18:05:09 +0900    

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

commit   : ff9618e82a466fc9c635f9f087776e57b21e4f14    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Fri, 13 Jan 2023 15:32:37 -0800    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Fri, 13 Jan 2023 15:32:37 -0800    

Commit 60684dd8 left loose ends when it came to maintaining toast  
tables or partitions.  
  
For toast tables, simply skip the privilege check if the toast table  
is an indirect target of the maintenance command, because the main  
table privileges have already been checked.  
  
For partitions, allow the maintenance command if the user has the  
MAINTAIN privilege on the partition or any parent.  
  
Also make CLUSTER emit "skipping" messages when the user doesn't have  
privileges, similar to VACUUM.  
  
Author: Nathan Bossart  
Reported-by: Pavel Luzanov  
Reviewed-by: Pavel Luzanov, Ted Yu  
Discussion: https://postgr.es/m/20230113231339.GA2422750@nathanxps13  

commit   : ff23b592ad6621563d3128b26860bcb41daf9542    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Fri, 13 Jan 2023 15:33:17 -0800    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Fri, 13 Jan 2023 15:33:17 -0800    

commit   : 250c8ee07ede8a104ae1471f6ebca204d94267dd    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Fri, 13 Jan 2023 15:23:09 -0800    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Fri, 13 Jan 2023 15:23:09 -0800    

This is in preparation for commiting a larger patch series in the area.  
  
Discussion: https://postgr.es/m/CAAKRu_bHwGEbzNxxy+MQDkrsgog6aO6iUvajJ4d6PD98gFU7+w@mail.gmail.com  

commit   : d46a9792a8ebbbed7792b26d6dc0222d2bbde223    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Fri, 13 Jan 2023 14:42:03 -0800    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Fri, 13 Jan 2023 14:42:03 -0800    

When VACUUM/ANALYZE are run on an entire database, it warns of  
skipping relations for which the user doesn't have sufficient  
privileges. That only makes sense for tables, so skip such messages  
for indexes, etc.  
  
Reviewed-by: Nathan Bossart  
Discussion: https://postgr.es/m/c0a85c2e83158560314b576b6241c8ed0aea1745.camel%40j-davis.com  

commit   : c44f6334ca6ff6d242d9eb6742441bc4e1294067    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Fri, 13 Jan 2023 14:14:54 -0800    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Fri, 13 Jan 2023 14:14:54 -0800    

The prior behavior was confusing and hard to document. For instance,  
if you had UPDATE privileges, you could lock a table in any lock mode  
except ACCESS SHARE mode.  
  
Now, if granted a privilege to lock at a given mode, one also has  
privileges to lock at a less-conflicting mode. MAINTAIN, UPDATE,  
DELETE, and TRUNCATE privileges allow any lock mode. INSERT privileges  
allow ROW EXCLUSIVE (or below). SELECT privileges allow ACCESS SHARE.  
  
Reviewed-by: Nathan Bossart  
Discussion: https://postgr.es/m/9550c76535404a83156252b25a11babb4792ea1e.camel%40j-davis.com  

commit   : b7ae03953690a1dee455ba3823cc8f71a72cbe1d    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Fri, 13 Jan 2023 14:49:23 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Fri, 13 Jan 2023 14:49:23 +0530    

We don't allow different column lists for the same table in the different  
publications of the single subscription. A publication with a column list  
except for dropped and generated columns should be considered the same as  
a publication with no column list (which implicitly includes all columns  
as part of the columns list). However, as we were not excluding the  
dropped and generated columns from the column list combining such  
publications leads to an error "cannot use different column lists for  
table ...".  
  
We decided not to backpatch this fix as there is a risk of users seeing  
this as a behavior change and also we didn't see any field report of this  
case.  
  
Author: Shi yu  
Reviewed-by: Amit Kapila  
Discussion: https://postgr.es/m/OSZPR01MB631091CCBC56F195B1B9ACB0FDFE9@OSZPR01MB6310.jpnprd01.prod.outlook.com  

commit   : dca8b01f5f1f7c83c59a16393724fbd8a29ddecb    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Fri, 13 Jan 2023 08:28:05 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Fri, 13 Jan 2023 08:28:05 +0530