PostgreSQL 17.0 commit log

Stamp 17.0.

commit   : d7ec59a63d745ba74fba0e280bbf85dc6d1caa3e    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 23 Sep 2024 16:02:53 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 23 Sep 2024 16:02:53 -0400    

Click here for diff

M configure
M configure.ac
M meson.build

Translation updates

commit   : 29d483fb33229f4322ca6cd040422ac508c678c1    
  
author   : Peter Eisentraut <[email protected]>    
date     : Mon, 23 Sep 2024 12:06:47 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Mon, 23 Sep 2024 12:06:47 +0200    

Click here for diff

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

M src/backend/po/de.po
M src/backend/po/es.po
M src/backend/po/fr.po
M src/backend/po/ru.po
M src/backend/po/sv.po
M src/bin/initdb/po/fr.po
M src/bin/initdb/po/ru.po
M src/bin/pg_amcheck/po/fr.po
M src/bin/pg_amcheck/po/ru.po
M src/bin/pg_archivecleanup/po/fr.po
M src/bin/pg_archivecleanup/po/ru.po
M src/bin/pg_basebackup/po/fr.po
M src/bin/pg_basebackup/po/ru.po
M src/bin/pg_checksums/po/fr.po
M src/bin/pg_checksums/po/ru.po
M src/bin/pg_combinebackup/po/LINGUAS
M src/bin/pg_combinebackup/po/fr.po
A src/bin/pg_combinebackup/po/ru.po
M src/bin/pg_config/po/fr.po
M src/bin/pg_config/po/ru.po
M src/bin/pg_config/po/zh_CN.po
M src/bin/pg_controldata/po/fr.po
M src/bin/pg_controldata/po/ru.po
M src/bin/pg_ctl/po/fr.po
M src/bin/pg_ctl/po/ru.po
M src/bin/pg_dump/po/fr.po
M src/bin/pg_dump/po/ru.po
M src/bin/pg_resetwal/po/fr.po
M src/bin/pg_resetwal/po/ru.po
M src/bin/pg_rewind/po/fr.po
M src/bin/pg_rewind/po/ru.po
M src/bin/pg_test_fsync/po/fr.po
M src/bin/pg_test_fsync/po/ru.po
M src/bin/pg_test_timing/po/fr.po
M src/bin/pg_test_timing/po/ru.po
M src/bin/pg_upgrade/po/fr.po
M src/bin/pg_upgrade/po/ru.po
M src/bin/pg_verifybackup/po/fr.po
M src/bin/pg_verifybackup/po/ru.po
M src/bin/pg_waldump/po/fr.po
M src/bin/pg_waldump/po/ru.po
M src/bin/pg_walsummary/po/LINGUAS
M src/bin/pg_walsummary/po/fr.po
A src/bin/pg_walsummary/po/ru.po
M src/bin/psql/po/fr.po
M src/bin/psql/po/ru.po
M src/bin/scripts/po/fr.po
M src/bin/scripts/po/ru.po
M src/interfaces/ecpg/ecpglib/po/fr.po
M src/interfaces/ecpg/ecpglib/po/ru.po
M src/interfaces/ecpg/preproc/po/fr.po
M src/interfaces/ecpg/preproc/po/ru.po
M src/interfaces/libpq/po/fr.po
M src/interfaces/libpq/po/ru.po
M src/pl/plperl/po/fr.po
M src/pl/plperl/po/ru.po
M src/pl/plpgsql/src/po/fr.po
M src/pl/plpgsql/src/po/ru.po
M src/pl/plpython/po/fr.po
M src/pl/plpython/po/ru.po
M src/pl/plpython/po/zh_CN.po
M src/pl/tcl/po/fr.po
M src/pl/tcl/po/ru.po
M src/pl/tcl/po/zh_CN.po

Doc: update 17.0 release date.

commit   : 64b61fa5d7807a98b5a51024960698894799d936    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 20 Sep 2024 16:19:34 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 20 Sep 2024 16:19:34 -0400    

Click here for diff

Also some trivial copy-editing.  

M doc/src/sgml/release-17.sgml

doc PG 17 relnotes: add major features list

commit   : 1d7cef2b60b90673eb23e26fdb58dcc3e521ba55    
  
author   : Bruce Momjian <[email protected]>    
date     : Fri, 20 Sep 2024 16:00:10 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Fri, 20 Sep 2024 16:00:10 -0400    

Click here for diff

Reported-by: Tom Lane  
  
Discussion: https://postgr.es/m/[email protected]  
  
Author: Jonathan Katz  
  
Backpatch-through: 17 only  

M doc/src/sgml/release-17.sgml

Doc: explain how to test ADMIN privilege with pg_has_role().

commit   : a47ad3a42dddf028a5bff525c83fce3035922a79    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 20 Sep 2024 15:56:34 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 20 Sep 2024 15:56:34 -0400    

Click here for diff

This has always been possible, but the syntax is a bit obscure,  
and our user-facing docs were not very helpful.  Spell it out  
more clearly.  
  
Per complaint from Dominique Devienne.  Back-patch to  
all supported branches.  
  
Discussion: https://postgr.es/m/CAFCRh-8JNEy+dV4SXFOrWca50u+d=--TO4cq=+ac1oBtfJy4AA@mail.gmail.com  

M doc/src/sgml/func.sgml

Fix nbtree pgstats accounting with parallel scans.

commit   : fb4f5e58af971aa8e9620d207be96f8056b571b6    
  
author   : Peter Geoghegan <[email protected]>    
date     : Fri, 20 Sep 2024 14:06:30 -0400    
  
committer: Peter Geoghegan <[email protected]>    
date     : Fri, 20 Sep 2024 14:06:30 -0400    

Click here for diff

Commit 5bf748b8, which enhanced nbtree ScalarArrayOp execution, made  
parallel index scans work with the new design for arrays via explicit  
scheduling of primitive index scans.  Under this scheme a parallel index  
scan with array keys will perform the same number of index descents as  
an equivalent serial index scan (barring corner cases where an  
individual parallel worker discovers that it can advance the scan's  
array keys without anybody needing to perform another descent of the  
index to get to the relevant page on the leaf level).  
  
Despite all this, the pgstats accounting wasn't updated; it continued to  
increment the total number of index scans for the rel once per _bt_first  
call, no matter the details.  As a result, the number of (primitive)  
index scans could be over-counted during parallel scans.  
  
To fix, delay incrementing the count of index scans until after we've  
established that another descent of the index (using either _bt_search  
or _bt_endpoint) is required.  That way pg_stat_user_tables.idx_scan  
always advances in the same way, regardless of whether or not the scan  
makes use of parallelism.  
  
Oversight in commit 5bf748b8, which enhanced nbtree ScalarArrayOp  
execution.  
  
Author: Peter Geoghegan <[email protected]>  
Reviewed-By: Tomas Vondra <[email protected]>  
Discussion: https://postgr.es/m/CAH2-Wz=E7XrkvscBN0U6V81NK3Q-dQOmivvbEsjG-zwEfDdFpg@mail.gmail.com  
Discussion: https://postgr.es/m/CAH2-WzkRqvaqR2CTNqTZP0z6FuL4-3ED6eQB0yx38XBNj1v-4Q@mail.gmail.com  
Backpatch: 17-, where nbtree SAOP execution was enhanced.  

M src/backend/access/nbtree/nbtsearch.c

commit   : a24cd4bf5d0f0bbe86f99eebf0fac261b1ca4536    
  
author   : Bruce Momjian <[email protected]>    
date     : Thu, 19 Sep 2024 18:05:22 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Thu, 19 Sep 2024 18:05:22 -0400    

Click here for diff

Make paragraph empty instead of removing it.  
  
Discussion: https://postgr.es/m/[email protected]  
  
Backpatch-through: 12  

M doc/src/sgml/stylesheet-fo.xsl

doc PG relnotes: document "Unresolved ID reference found" cause

commit   : ff25193e5623bf458bc19fc71f25f7ce02ffccef    
  
author   : Bruce Momjian <[email protected]>    
date     : Thu, 19 Sep 2024 12:01:59 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Thu, 19 Sep 2024 12:01:59 -0400    

Click here for diff

Backpatch-through: 12  

M doc/src/sgml/stylesheet-fo.xsl

commit   : 95fba23317e680f33c88c7d00cfbbe8b225176d5    
  
author   : Bruce Momjian <[email protected]>    
date     : Thu, 19 Sep 2024 09:47:22 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Thu, 19 Sep 2024 09:47:22 -0400    

Click here for diff

FYI, during PDF builds, this link type generates a "Unresolved ID  
reference found" warning because it is suppressed from the PDF output.  
  
Backpatch-through: 12  

M doc/src/sgml/release.sgml
M doc/src/sgml/stylesheet-fo.xsl

commit   : 681bbd07cccbbc5b3e3d94b908bb1d5431af16cc    
  
author   : Bruce Momjian <[email protected]>    
date     : Thu, 19 Sep 2024 08:45:32 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Thu, 19 Sep 2024 08:45:32 -0400    

Click here for diff

Reported-by: Andrew Dunstan  
  
Discussion: https://postgr.es/m/[email protected]  
  
Author: Andrew Dunstan  
  
Backpatch-through: 12  

M src/tools/add_commit_links.pl

psql: Fix memory leak with repeated calls of \bind

commit   : b0ae6db2088bbd1d16733b359c9c300735e9c21e    
  
author   : Michael Paquier <[email protected]>    
date     : Thu, 19 Sep 2024 16:25:07 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Thu, 19 Sep 2024 16:25:07 +0900    

Click here for diff

Calling \bind repeatedly would cause the memory allocated for the list  
of bind parameters to be leaked after each call, as the list is reset  
when beginning a single call.  
  
This issue is fixed by making the cleanup of the bind parameter list  
more aggressive, refactoring it into a single routine called after  
processing a query and before running an individual \bind.  
  
HEAD required more surgery and has been fixed by 87eeadaea143.  Issue  
introduced by 5b66de3433e2.  
  
Reported-by: Anthonin Bonnefoy  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 16  

M src/bin/psql/command.c
M src/bin/psql/common.c
M src/bin/psql/common.h

doc PG relnotes: add paragraph explaining the section symbol

commit   : 19b389c60871cd14b07dfb244a519d8cb83988cc    
  
author   : Bruce Momjian <[email protected]>    
date     : Wed, 18 Sep 2024 17:13:19 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Wed, 18 Sep 2024 17:13:19 -0400    

Click here for diff

And suppress the symbol in print mode, where the section symbol does not  
appear.  
  
Discussion: https://postgr.es/m/[email protected]  
  
Backpatch-through: 12  

M doc/src/sgml/release.sgml
M doc/src/sgml/stylesheet-fo.xsl

commit   : 120f883d7924f38e296d68738ed067f46fd1b303    
  
author   : Bruce Momjian <[email protected]>    
date     : Wed, 18 Sep 2024 16:34:52 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Wed, 18 Sep 2024 16:34:52 -0400    

Click here for diff

In print output, there are too many commit links for footnotes in the  
release notes to be useful.  
  
Reported-by: Tom Lane  
  
Discussion: https://postgr.es/m/[email protected]  
  
Backpatch-through: 12  

M doc/src/sgml/stylesheet-fo.xsl

docs: Improve the description of num_timed column in pg_stat_checkpointer.

commit   : fa3a022136fc6d7138ad217bfc8ac7e76d6d38f8    
  
author   : Fujii Masao <[email protected]>    
date     : Thu, 19 Sep 2024 02:14:10 +0900    
  
committer: Fujii Masao <[email protected]>    
date     : Thu, 19 Sep 2024 02:14:10 +0900    

Click here for diff

The previous documentation stated that num_timed reflects the number of  
scheduled checkpoints performed. However, checkpoints may be skipped  
if the server has been idle, and num_timed counts both skipped and completed  
checkpoints. This commit clarifies the description to make it clear that  
the counter includes both skipped and completed checkpoints.  
  
Back-patch to v17 where pg_stat_checkpointer was added.  
  
Author: Fujii Masao  
Reviewed-by: Alexander Korotkov  
Discussion: https://postgr.es/m/[email protected]  

M doc/src/sgml/monitoring.sgml

Update list of acknowledgments in release notes

commit   : 633b609e1c239968e80a645951a28fcded53e44b    
  
author   : Peter Eisentraut <[email protected]>    
date     : Wed, 18 Sep 2024 09:08:31 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Wed, 18 Sep 2024 09:08:31 +0200    

Click here for diff

current through 2370582ab14  

M doc/src/sgml/release-17.sgml

Don't enter parallel mode when holding interrupts.

commit   : 2370582ab14f179eb8edd748d629edf991999989    
  
author   : Noah Misch <[email protected]>    
date     : Tue, 17 Sep 2024 19:53:11 -0700    
  
committer: Noah Misch <[email protected]>    
date     : Tue, 17 Sep 2024 19:53:11 -0700    

Click here for diff

Doing so caused the leader to hang in wait_event=ParallelFinish, which  
required an immediate shutdown to resolve.  Back-patch to v12 (all  
supported versions).  
  
Francesco Degrassi  
  
Discussion: https://postgr.es/m/CAC-SaSzHUKT=vZJ8MPxYdC_URPfax+yoA1hKTcF4ROz_Q6z0_Q@mail.gmail.com  

M src/backend/optimizer/plan/planner.c
M src/test/regress/expected/select_parallel.out
M src/test/regress/sql/select_parallel.sql

Add missing query ID reporting in extended query protocol

commit   : 7db9bfc1f78b2d1d7fe0b3dd6c8036d28075086a    
  
author   : Michael Paquier <[email protected]>    
date     : Wed, 18 Sep 2024 09:59:14 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Wed, 18 Sep 2024 09:59:14 +0900    

Click here for diff

This commit adds query ID reports for two code paths when processing  
extended query protocol messages:  
- When receiving a bind message, setting it to the first Query retrieved  
from a cached cache.  
- When receiving an execute message, setting it to the first PlannedStmt  
stored in a portal.  
  
An advantage of this method is that this is able to cover all the types  
of portals handled in the extended query protocol, particularly these  
two when the report done in ExecutorStart() is not enough (neither is an  
addition in ExecutorRun(), actually, for the second point):  
- Multiple execute messages, with multiple ExecutorRun().  
- Portal with execute/fetch messages, like a query with a RETURNING  
clause and a fetch size that stores the tuples in a first execute  
message going though ExecutorStart() and ExecuteRun(), followed by one  
or more execute messages doing only fetches from the tuplestore created  
in the first message.  This corresponds to the case where  
execute_is_fetch is set, for example.  
  
Note that the query ID reporting done in ExecutorStart() is still  
necessary, as an EXECUTE requires it.  Query ID reporting is optimistic  
and more calls to pgstat_report_query_id() don't matter as the first  
report takes priority except if the report is forced.  The comment in  
ExecutorStart() is adjusted to reflect better the reality with the  
extended query protocol.  
  
The test added in pg_stat_statements is a courtesy of Robert Haas.  This  
uses psql's \bind metacommand, hence this part is backpatched down to  
v16.  
  
Reported-by:  Kaido Vaikla, Erik Wienhold  
Author: Sami Imseih  
Reviewed-by: Jian He, Andrei Lepikhov, Michael Paquier  
Discussion: https://postgr.es/m/CA+427g8DiW3aZ6pOpVgkPbqK97ouBdf18VLiHFesea2jUk3XoQ@mail.gmail.com  
Discussion: https://postgr.es/m/CA+TgmoZxtnf_jZ=VqBSyaU8hfUkkwoJCJ6ufy4LGpXaunKrjrg@mail.gmail.com  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 14  

M contrib/pg_stat_statements/Makefile
A contrib/pg_stat_statements/expected/extended.out
M contrib/pg_stat_statements/meson.build
A contrib/pg_stat_statements/sql/extended.sql
M src/backend/executor/execMain.c
M src/backend/tcop/postgres.c

Allow ReadStream to be consumed as raw block numbers.

commit   : ec1d545c8f7093537ee644bb33137fff91277463    
  
author   : Thomas Munro <[email protected]>    
date     : Wed, 18 Sep 2024 09:20:59 +1200    
  
committer: Thomas Munro <[email protected]>    
date     : Wed, 18 Sep 2024 09:20:59 +1200    

Click here for diff

Commits 041b9680 and 6377e12a changed the interface of  
scan_analyze_next_block() to take a ReadStream instead of a BlockNumber  
and a BufferAccessStrategy, and to return a value to indicate when the  
stream has run out of blocks.  
  
This caused integration problems for at least one known extension that  
uses specially encoded BlockNumber values that map to different  
underlying storage, because acquire_sample_rows() sets up the stream so  
that read_stream_next_buffer() reads blocks from the main fork of the  
relation's SMgrRelation.  
  
Provide read_stream_next_block(), as a way for such an extension to  
access the stream of raw BlockNumbers directly and forward them to its  
own ReadBuffer() calls after decoding, as it could in earlier releases.  
The new function returns the BlockNumber and BufferAccessStrategy that  
were previously passed directly to scan_analyze_next_block().  
Alternatively, an extension could wrap the stream of BlockNumbers in  
another ReadStream with a callback that performs any decoding required  
to arrive at real storage manager BlockNumber values, so that it could  
benefit from the I/O combining and concurrency provided by  
read_stream.c.  
  
Another class of table access method that does nothing in  
scan_analyze_next_block() because it is not block-oriented could use  
this function to control the number of block sampling loops.  It could  
match the previous behavior with "return read_stream_next_block(stream,  
&bas) != InvalidBlockNumber".  
  
Ongoing work is expected to provide better ANALYZE support for table  
access methods that don't behave like heapam with respect to storage  
blocks, but that will be for future releases.  
  
Back-patch to 17.  
  
Reported-by: Mats Kindahl <[email protected]>  
Reviewed-by: Mats Kindahl <[email protected]>  
Discussion: https://postgr.es/m/CA%2B14425%2BCcm07ocG97Fp%2BFrD9xUXqmBKFvecp0p%2BgV2YYR258Q%40mail.gmail.com  

M src/backend/storage/aio/read_stream.c
M src/include/storage/read_stream.h

Repair pg_upgrade for identity sequences with non-default persistence.

commit   : f7567f9e53d7a2e17023d3122b706814cdbbb6d3    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 17 Sep 2024 15:53:26 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 17 Sep 2024 15:53:26 -0400    

Click here for diff

Since we introduced unlogged sequences in v15, identity sequences  
have defaulted to having the same persistence as their owning table.  
However, it is possible to change that with ALTER SEQUENCE, and  
pg_dump tries to preserve the logged-ness of sequences when it doesn't  
match (as indeed it wouldn't for an unlogged table from before v15).  
  
The fly in the ointment is that ALTER SEQUENCE SET [UN]LOGGED fails  
in binary-upgrade mode, because it needs to assign a new relfilenode  
which we cannot permit in that mode.  Thus, trying to pg_upgrade a  
database containing a mismatching identity sequence failed.  
  
To fix, add syntax to ADD/ALTER COLUMN GENERATED AS IDENTITY to allow  
the sequence's persistence to be set correctly at creation, and use  
that instead of ALTER SEQUENCE SET [UN]LOGGED in pg_dump.  (I tried to  
make SET [UN]LOGGED work without any pg_dump modifications, but that  
seems too fragile to be a desirable answer.  This way should be  
markedly faster anyhow.)  
  
In passing, document the previously-undocumented SEQUENCE NAME option  
that pg_dump also relies on for identity sequences; I see no value  
in trying to pretend it doesn't exist.  
  
Per bug #18618 from Anthony Hsu.  
Back-patch to v15 where we invented this stuff.  
  
Discussion: https://postgr.es/m/[email protected]  

M doc/src/sgml/ref/create_table.sgml
M src/backend/commands/sequence.c
M src/backend/parser/gram.y
M src/backend/parser/parse_utilcmd.c
M src/bin/pg_dump/pg_dump.c
M src/test/regress/expected/identity.out
M src/test/regress/sql/identity.sql

Avoid parallel nbtree index scan hangs with SAOPs.

commit   : a24bffc021d99a7809da36b74b8873ef07b92ec0    
  
author   : Peter Geoghegan <[email protected]>    
date     : Tue, 17 Sep 2024 11:10:33 -0400    
  
committer: Peter Geoghegan <[email protected]>    
date     : Tue, 17 Sep 2024 11:10:33 -0400    

Click here for diff

Commit 5bf748b8, which enhanced nbtree ScalarArrayOp execution, made  
parallel index scans work with the new design for arrays via explicit  
scheduling of primitive index scans.  A backend that successfully  
scheduled the scan's next primitive index scan saved its backend local  
array keys in shared memory.  Any backend could pick up the scheduled  
primitive scan within _bt_first.  This scheme decouples scheduling a  
primitive scan from starting the scan (by performing another descent of  
the index via a _bt_search call from _bt_first) to make things robust.  
  
The scheme had a deadlock hazard, at least when the leader process  
participated in the scan.  _bt_parallel_seize had a code path that made  
backends that were not in an immediate position to start a scheduled  
primitive index scan wait for some other backend to do so instead.  
Under the right circumstances, the leader process could wait here  
forever: the leader would wait for any other backend to start the  
primitive scan, while every worker was busy waiting on the leader to  
consume tuples from the scan's tuple queue.  
  
To fix, don't wait for a scheduled primitive index scan to be started by  
some other eligible backend from within _bt_parallel_seize (when the  
calling backend isn't in a position to do so itself).  Return false  
instead, while recording that the scan has a scheduled primitive index  
scan in backend local state.  This leaves the backend in the same state  
as the existing case where a backend schedules (or tries to schedule)  
another primitive index scan from within _bt_advance_array_keys, before  
calling _bt_parallel_seize.  _bt_parallel_seize already handles that  
case by returning false without waiting, and without unsetting the  
backend local state.  Leaving the backend in this state enables it to  
start a previously scheduled primitive index scan once it gets back to  
_bt_first.  
  
Oversight in commit 5bf748b8, which enhanced nbtree ScalarArrayOp  
execution.  
  
Matthias van de Meent, with tweaks by me.  
  
Author: Matthias van de Meent <[email protected]>  
Reported-By: Tomas Vondra <[email protected]>  
Reviewed-By: Peter Geoghegan <[email protected]>  
Discussion: https://postgr.es/m/CAH2-WzmMGaPa32u9x_FvEbPTUkP5e95i=QxR8054nvCRydP-sw@mail.gmail.com  
Backpatch: 17-, where nbtree SAOP execution was enhanced.  

M src/backend/access/nbtree/nbtree.c

commit   : 054a23b67402767ec23452a9ff512025a62a80f8    
  
author   : Bruce Momjian <[email protected]>    
date     : Mon, 16 Sep 2024 13:26:37 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Mon, 16 Sep 2024 13:26:37 -0400    

Click here for diff

Reported-by: jian he  
  
Discussion: https://postgr.es/m/[email protected]  
  
Backpatch-through: 12  

M src/tools/RELEASE_CHANGES
A src/tools/add_commit_links.pl

Replace usages of xmlXPathCompile() with xmlXPathCtxtCompile().

commit   : b9645dca10995abb54a9e12bee6c9db579229c24    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 15 Sep 2024 13:33:09 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 15 Sep 2024 13:33:09 -0400    

Click here for diff

In existing releases of libxml2, xmlXPathCompile can be driven  
to stack overflow because it fails to protect itself against  
too-deeply-nested input.  While there is an upstream fix as of  
yesterday, it will take years for that to propagate into all  
shipping versions.  In the meantime, we can protect our own  
usages basically for free by calling xmlXPathCtxtCompile instead.  
  
(The actual bug is that libxml2 keeps its nesting counter in the  
xmlXPathContext, and its parsing code was willing to just skip  
counting nesting levels if it didn't have a context.  So if we supply  
a context, all is well.  It seems odd actually that it works at all  
to not supply a context, because this means that XPath parsing does  
not have access to XML namespace info.  Apparently libxml2 never  
checks namespaces until runtime?  Anyway, this seems like good  
future-proofing even if its only immediate effect is to dodge a bug.)  
  
Sadly, this hack only offers protection with libxml2 2.9.11 and newer.  
Before that there are multiple similar problems, so if you are  
processing untrusted XML it behooves you to get a newer version.  
But we have some pretty old libxml2 in the buildfarm, so it seems  
impractical to add a regression test to verify this fix.  
  
Per bug #18617 from Jingzhou Fu.  Back-patch to all supported  
versions.  
  
Discussion: https://postgr.es/m/[email protected]  
Discussion: https://gitlab.gnome.org/GNOME/libxml2/-/issues/799  

M contrib/xml2/xpath.c
M src/backend/utils/adt/xml.c

Run regression tests with timezone America/Los_Angeles.

commit   : 6283ff2018e3dfa74e5b41cceba0642a6b53ca39    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 14 Sep 2024 17:55:02 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 14 Sep 2024 17:55:02 -0400    

Click here for diff

Historically we've used timezone "PST8PDT", but the recent release  
2024b of tzdb changes the definition of that zone in a way that  
breaks many test cases concerned with dates before 1970.  Although  
we've not yet adopted 2024b into our own tree, this is already  
problematic for people using --with-system-tzdata if their platform  
has already adopted 2024b.  To work with both older and newer  
versions of tzdb, switch to using "America/Los_Angeles", accepting  
the ensuing changes in regression test results.  
  
Back-patch to all supported branches.  
  
Per report and patch from Wolfgang Walther.  
  
Discussion: https://postgr.es/m/[email protected]  

M doc/src/sgml/ref/set.sgml
M doc/src/sgml/regress.sgml
M src/test/regress/expected/date.out
M src/test/regress/expected/horology.out
M src/test/regress/expected/timestamptz.out
M src/test/regress/pg_regress.c
M src/test/regress/sql/timestamptz.sql

Add commit 7229ebe011df to .git-blame-ignore-revs.

commit   : fca91b5c903a0d810492eed5a207032f7ee6e175    
  
author   : Alvaro Herrera <[email protected]>    
date     : Sat, 14 Sep 2024 20:17:30 +0200    
  
committer: Alvaro Herrera <[email protected]>    
date     : Sat, 14 Sep 2024 20:17:30 +0200    

Click here for diff

M .git-blame-ignore-revs

doc PG 17 relnotes: adjust SGML format for commit add script

commit   : 77120dd08113dcb94c01f581408b50240bd24641    
  
author   : Bruce Momjian <[email protected]>    
date     : Sat, 14 Sep 2024 13:20:02 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Sat, 14 Sep 2024 13:20:02 -0400    

Click here for diff

Backpatch-through: 17 only  

M doc/src/sgml/release-17.sgml

commit   : 4a898075690781a95159244719d4dcef6fd153da    
  
author   : Bruce Momjian <[email protected]>    
date     : Sat, 14 Sep 2024 12:49:27 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Sat, 14 Sep 2024 12:49:27 -0400    

Click here for diff

Backpatch-through: 17 only  

M doc/src/sgml/release-17.sgml

Remove obsolete comment in pg_stat_statements.

commit   : e3b2c651bcd3230674ea4ea31c987474a00a1c98    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 14 Sep 2024 11:42:31 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 14 Sep 2024 11:42:31 -0400    

Click here for diff

Commit 76db9cb63 removed the use of multiple nesting counters,  
but missed one comment describing that arrangement.  
  
Back-patch to v17 where 76db9cb63 came in, just to avoid confusion.  
  
Julien Rouhaud  
  
Discussion: https://postgr.es/m/gfcwh3zjxc2vygltapgo7g6yacdor5s4ynr234b6v2ohhuvt7m@gr42joxalenw  

M contrib/pg_stat_statements/pg_stat_statements.c

doc PG 17 relnotes: update to current

commit   : 54497e0ed8670f52ceb8dfc5949023a61daeec59    
  
author   : Bruce Momjian <[email protected]>    
date     : Sat, 14 Sep 2024 10:38:14 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Sat, 14 Sep 2024 10:38:14 -0400    

Click here for diff

Backpatch-through: 17 only  

M doc/src/sgml/release-17.sgml

Improve meson's detection of perl build flags

commit   : dc2a660bd983f2675f357d279253256a2aef9836    
  
author   : Andrew Dunstan <[email protected]>    
date     : Sat, 14 Sep 2024 10:26:25 -0400    
  
committer: Andrew Dunstan <[email protected]>    
date     : Sat, 14 Sep 2024 10:26:25 -0400    

Click here for diff

The current method of detecting perl build flags breaks if the path to  
perl contains a space. This change makes two improvements. First,  
instead of getting a list of ldflags and ccdlflags and then trying to  
filter those out of the reported ldopts, we tell perl to suppress  
reporting those in the first instance. Second, it tells perl to parse  
those and output them, one per line. Thus any space on the option in a  
file name, for example, is preserved.  
  
Issue reported off-list by Muralikrishna Bandaru  
  
Discussion: https://postgr.es/[email protected]  
  
Backpatch to release 16.  

M meson.build

doc PG 17 relnotes: move EXPLAIN items to their own section

commit   : 984702d0ee9b196dd0a68d4202a42f0bb14562dd    
  
author   : Bruce Momjian <[email protected]>    
date     : Sat, 14 Sep 2024 09:27:21 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Sat, 14 Sep 2024 09:27:21 -0400    

Click here for diff

Reported-by: Álvaro Herrera  
  
Discussion: https://postgr.es/m/[email protected]  
  
Backpatch-through: 17 only  

M doc/src/sgml/release-17.sgml

Only define NO_THREAD_SAFE_LOCALE for MSVC plperl when required

commit   : 648397b1d409f15612b5bb6f95c5527f94e69807    
  
author   : Andrew Dunstan <[email protected]>    
date     : Sat, 14 Sep 2024 08:37:08 -0400    
  
committer: Andrew Dunstan <[email protected]>    
date     : Sat, 14 Sep 2024 08:37:08 -0400    

Click here for diff

Latest versions of Strawberry Perl define USE_THREAD_SAFE_LOCALE, and we  
therefore get a handshake error when building against such instances.  
The solution is to perform a test to see if USE_THREAD_SAFE_LOCALE is  
defined and only define NO_THREAD_SAFE_LOCALE if it isn't.  
  
Backpatch the meson.build fix back to release 16 and apply the same  
logic to Mkvcbuild.pm in releases 12 through 16.  
  
Original report of the issue from Muralikrishna Bandaru.  

M meson.build

doc PG 17 relnotes: move partition access method item

commit   : 4e7b9a1adc4191acc5cca1786312dfacc3395c5f    
  
author   : Bruce Momjian <[email protected]>    
date     : Fri, 13 Sep 2024 18:21:56 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Fri, 13 Sep 2024 18:21:56 -0400    

Click here for diff

Also clarify wording.  
  
Reported-by: Álvaro Herrera  
  
Discussion: https://postgr.es/m/[email protected]  
  
Backpatch-through: 17 only  

M doc/src/sgml/release-17.sgml

doc PG 17 relnotes: add dynamic shared memory registry item

commit   : 26cea9fb8232d0ec8b4d637e2aa9558c9c6fb4da    
  
author   : Bruce Momjian <[email protected]>    
date     : Fri, 13 Sep 2024 16:16:55 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Fri, 13 Sep 2024 16:16:55 -0400    

Click here for diff

Reported-by: Nathan Bossart  
  
Discussion: https://postgr.es/m/Ztcuwbs0FGCPOEu9@nathan  
  
Backpatch-through: 17 only  

M doc/src/sgml/release-17.sgml

Allow _h_indexbuild() to be interrupted.

commit   : 418c6a2c72d22dd3810d08cd06af6126b8bbd4b1    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 13 Sep 2024 16:16:47 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 13 Sep 2024 16:16:47 -0400    

Click here for diff

When we are building a hash index that is large enough to need  
pre-sorting (larger than either maintenance_work_mem or NBuffers),  
the initial sorting phase is interruptible, but the insertion  
phase wasn't.  Add the missing CHECK_FOR_INTERRUPTS().  
  
Per bug #18616 from Alexander Lakhin.  Back-patch to all  
supported branches.  
  
Pavel Borisov  
  
Discussion: https://postgr.es/m/[email protected]  

M src/backend/access/hash/hashsort.c

doc PG 17 relnotes: replace commit hashes with section marks

commit   : b9a65a678b68dfab47bff3c9524fc72040a26195    
  
author   : Bruce Momjian <[email protected]>    
date     : Fri, 13 Sep 2024 12:29:31 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Fri, 13 Sep 2024 12:29:31 -0400    

Click here for diff

Backpatch-through: 17 only  

M doc/src/sgml/release-17.sgml

Fix contrib/pageinspect's test for sequences.

commit   : 9b3c3c0fc2061789c10e331ab3b04913f2b09531    
  
author   : Nathan Bossart <[email protected]>    
date     : Fri, 13 Sep 2024 10:16:40 -0500    
  
committer: Nathan Bossart <[email protected]>    
date     : Fri, 13 Sep 2024 10:16:40 -0500    

Click here for diff

I managed to break this test in two different ways in commit  
05036a3155.  
  
First, the output of the new call to tuple_data_split() on the test  
sequence is dependent on endianness.  This is fixed by setting a  
special start value for the test sequence that produces the same  
output regardless of the endianness of the machine.  
  
Second, on versions older than v15, the new test case fails under  
"force_parallel_mode = regress" with the following error:  
  
	ERROR:  cannot access temporary tables during a parallel operation  
  
This is because pageinspect's disk-accessing functions are  
incorrectly marked PARALLEL SAFE on versions older than v15 (see  
commit aeaaf520f4 for details).  This one is fixed by changing the  
test sequence to be permanent.  The only reason it was previously  
marked temporary was to avoid needing a DROP SEQUENCE command at  
the end of the test.  Unlike some other tests in this file, the use  
of a permanent sequence here shouldn't result in any test  
instability like what was fixed by commit e2933a6e11.  
  
Reviewed-by: Tom Lane  
Discussion: https://postgr.es/m/ZuOKOut5hhDlf_bP%40nathan  
Backpatch-through: 12  

M contrib/pageinspect/expected/page.out
M contrib/pageinspect/sql/page.sql

commit   : 9f949c9cb25f1bb00b4c123aad80bbbd208333b0    
  
author   : Bruce Momjian <[email protected]>    
date     : Fri, 13 Sep 2024 09:42:39 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Fri, 13 Sep 2024 09:42:39 -0400    

Click here for diff

Copied from SGML comments.  
  
Discussion: https://postgr.es/m/CACJufxF+9YCDce5vzmZY6ZCEeTJsYFG-kPohT9UjKikJX30mGw@mail.gmail.com  
  
Author: jian he  
  
Backpatch-through: 17 only  

M doc/src/sgml/postgres.sgml
M doc/src/sgml/release-17.sgml

SQL/JSON: Update example in JSON_QUERY() documentation

commit   : 32ccfa0476ce1fbbe0326d87b0850894190017b5    
  
author   : Amit Langote <[email protected]>    
date     : Fri, 13 Sep 2024 16:08:13 +0900    
  
committer: Amit Langote <[email protected]>    
date     : Fri, 13 Sep 2024 16:08:13 +0900    

Click here for diff

Commit 2c27346ed684 fixed the behavior of JSON_QUERY() when WITH  
CONDITIONAL WRAPPER is used, but the documentation example wasn't  
updated to reflect this change. This commit updates the example to  
show the correct result.  
  
Per off-list report from Andreas Ulbrich.  
  
Backpatch-through: 17  

M doc/src/sgml/func.sgml

Reintroduce support for sequences in pgstattuple and pageinspect.

commit   : 6ea7f04b73661a0141fdcbfb590961b02832114d    
  
author   : Nathan Bossart <[email protected]>    
date     : Thu, 12 Sep 2024 16:31:29 -0500    
  
committer: Nathan Bossart <[email protected]>    
date     : Thu, 12 Sep 2024 16:31:29 -0500    

Click here for diff

Commit 4b82664156 restricted a number of functions provided by  
contrib modules to only relations that use the "heap" table access  
method.  Sequences always use this table access method, but they do  
not advertise as such in the pg_class system catalog, so the  
aforementioned commit also (presumably unintentionally) removed  
support for sequences from some of these functions.  This commit  
reintroduces said support for sequences to these functions and adds  
a couple of relevant tests.  
  
Co-authored-by: Ayush Vatsa  
Reviewed-by: Robert Haas, Michael Paquier, Matthias van de Meent  
Discussion: https://postgr.es/m/CACX%2BKaP3i%2Bi9tdPLjF5JCHVv93xobEdcd_eB%2B638VDvZ3i%3DcQA%40mail.gmail.com  
Backpatch-through: 12  

M contrib/pageinspect/expected/page.out
M contrib/pageinspect/heapfuncs.c
M contrib/pageinspect/sql/page.sql
M contrib/pgstattuple/expected/pgstattuple.out
M contrib/pgstattuple/pgstattuple.c
M contrib/pgstattuple/sql/pgstattuple.sql

Make jsonpath .string() be immutable for datetimes.

commit   : cc4fdfa411fa0cd6b27563c37c096bf76120659f    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 12 Sep 2024 14:30:29 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 12 Sep 2024 14:30:29 -0400    

Click here for diff

Discussion of commit ed055d249 revealed that we don't actually  
want jsonpath's .string() method to depend on DateStyle, nor  
TimeZone either, because the non-"_tz" jsonpath functions are  
supposed to be immutable.  Potentially we could allow a TimeZone  
dependency in the "_tz" variants, but it seems better to just  
uniformly define this method as returning the same string that  
jsonb text output would do.  That's easier to implement too,  
saving a couple dozen lines.  
  
Patch by me, per complaint from Peter Eisentraut.  Back-patch  
to v17 where this feature came in (in 66ea94e8e).  Also  
back-patch ed055d249 to provide test cases.  
  
Discussion: https://postgr.es/m/[email protected]  

M doc/src/sgml/func.sgml
M src/backend/utils/adt/jsonpath_exec.c
M src/test/regress/expected/horology.out
M src/test/regress/expected/jsonb_jsonpath.out
M src/test/regress/sql/horology.sql
M src/test/regress/sql/jsonb_jsonpath.sql

Doc: alphabetize aggregate function table

commit   : 2645f6d643d929007fa7d1ed6d2de5155e4d63d8    
  
author   : David Rowley <[email protected]>    
date     : Thu, 12 Sep 2024 22:37:27 +1200    
  
committer: David Rowley <[email protected]>    
date     : Thu, 12 Sep 2024 22:37:27 +1200    

Click here for diff

A few recent JSON aggregates have been added without much consideration  
to the existing order.  Put these back in alphabetical order (with the  
exception of the JSONB variant of each JSON aggregate).  
  
Author: Wolfgang Walther <[email protected]>  
Reviewed-by: Marlene Reiterer <[email protected]>  
Discussion: https://postgr.es/m/6a7b910c-3feb-4006-b817-9b4759cb6bb6%40technowledgy.de  
Backpatch-through: 16, where these aggregates were added  

M doc/src/sgml/func.sgml

SQL/JSON: Fix JSON_QUERY(... WITH CONDITIONAL WRAPPER)

commit   : 2c27346ed6848b6f5505f1c57078a7c1978ae042    
  
author   : Amit Langote <[email protected]>    
date     : Thu, 12 Sep 2024 09:36:31 +0900    
  
committer: Amit Langote <[email protected]>    
date     : Thu, 12 Sep 2024 09:36:31 +0900    

Click here for diff

Currently, when WITH CONDITIONAL WRAPPER is specified, array wrappers  
are applied even to a single SQL/JSON item if it is a scalar JSON  
value, but this behavior does not comply with the standard.  
  
To fix, apply wrappers only when there are multiple SQL/JSON items  
in the result.  
  
Reported-by: Peter Eisentraut <[email protected]>  
Author: Peter Eisentraut <[email protected]>  
Author: Amit Langote <[email protected]>  
Reviewed-by: Andrew Dunstan <[email protected]>  
Discussion: https://postgr.es/m/8022e067-818b-45d3-8fab-6e0d94d03626%40eisentraut.org  
Backpatch-through: 17  

M src/backend/utils/adt/jsonpath_exec.c
M src/test/regress/expected/sqljson_queryfuncs.out
M src/test/regress/sql/sqljson_queryfuncs.sql

Remove incorrect Assert.

commit   : 7f88e50b455d0db51847fbfe63e53802d4527f3a    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 11 Sep 2024 11:41:47 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 11 Sep 2024 11:41:47 -0400    

Click here for diff

check_agglevels_and_constraints() asserted that if we find an  
aggregate function in an EXPR_KIND_FROM_SUBSELECT expression, the  
expression must be in a LATERAL subquery.  Alexander Lakhin found a  
case where that's not so: because of the odd scoping rules for NEW/OLD  
within a rule, a reference to NEW/OLD could cause an aggregate to be  
considered top-level even though it's in an unmarked sub-select.  
The error message that would be thrown seems sufficiently on-point,  
so just remove the Assert.  (Hence, this is not a bug for production  
builds.)  
  
This Assert was added by me in commit eaccfded9 (9.3 era).  It looks  
like I put it in to cross-check that the new logic for detecting  
misplaced aggregates (using agglevelsup) caught the same cases that a  
previous check on p_lateral_active did.  So there might have been some  
related misbehavior before eaccfded9 ... but that's very ancient  
history by now, so I didn't dig any deeper.  
  
Per bug #18608 from Alexander Lakhin.  Back-patch to all supported  
branches.  
  
Discussion: https://postgr.es/m/[email protected]  

M src/backend/parser/parse_agg.c

pg_createsubscriber: minor documentation fixes

commit   : 7748c847c332c2231846d913aa81d7e20b4b0241    
  
author   : Magnus Hagander <[email protected]>    
date     : Wed, 11 Sep 2024 16:30:17 +0200    
  
committer: Magnus Hagander <[email protected]>    
date     : Wed, 11 Sep 2024 16:30:17 +0200    

Click here for diff

M doc/src/sgml/ref/pg_createsubscriber.sgml

Fix unique key checks in JSON object constructors

commit   : 78bc5f711873339df72ee7fc072e41d449fa77ea    
  
author   : Tomas Vondra <[email protected]>    
date     : Wed, 11 Sep 2024 13:21:05 +0200    
  
committer: Tomas Vondra <[email protected]>    
date     : Wed, 11 Sep 2024 13:21:05 +0200    

Click here for diff

When building a JSON object, the code builds a hash table of keys, to  
allow checking if the keys are unique. The uniqueness check and adding  
the new key happens in json_unique_check_key(), but this assumes the  
pointer to the key remains valid.  
  
Unfortunately, two places passed pointers to keys in a buffer, while  
also appending more data (additional key/value pairs) to the buffer.  
With enough data the buffer is resized by enlargeStringInfo(), which  
calls repalloc(), invalidating the earlier key pointers.  
  
Due to this the uniqueness check may fail with both false negatives and  
false positives, producing JSON objects with duplicate keys or failing  
to produce a perfectly valid JSON object.  
  
This affects multiple functions that enforce uniqueness of keys, all  
introduced in PG16 with the new SQL/JSON:  
  
- json_object_agg_unique / jsonb_object_agg_unique  
- json_object / jsonb_objectagg  
  
Existing regression tests did not detect the issue, simply because the  
initial buffer size is 1024 and the objects were small enough not to  
require the repalloc.  
  
With a sufficiently large object, AddressSanitizer reported the access  
to invalid memory immediately. So would valgrind, of course.  
  
Fixed by copying the key into the hash table memory context, and adding  
regression tests with enough data to repalloc the buffer. Backpatch to  
16, where the functions were introduced.  
  
Reported by Alexander Lakhin. Investigation and initial fix by Junwang  
Zhao, with various improvements and tests by me.  
  
Reported-by: Alexander Lakhin  
Author: Junwang Zhao, Tomas Vondra  
Backpatch-through: 16  
Discussion: https://postgr.es/m/[email protected]  
Discussion: https://postgr.es/m/CAEG8a3JjH0ReJF2_O7-8LuEbO69BxPhYeXs95_x7+H9AMWF1gw@mail.gmail.com  

M src/backend/utils/adt/json.c
M src/test/regress/expected/json.out
M src/test/regress/expected/sqljson.out
M src/test/regress/sql/json.sql
M src/test/regress/sql/sqljson.sql

Fix some whitespace issues in XMLSERIALIZE(... INDENT).

commit   : 946f150aa180ec61d37d7a41e43765b4c25ca784    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 10 Sep 2024 16:20:31 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 10 Sep 2024 16:20:31 -0400    

Click here for diff

We must drop whitespace while parsing the input, else libxml2  
will include "blank" nodes that interfere with the desired  
indentation behavior.  The end result is that we didn't indent  
nodes separated by whitespace.  
  
Also, it seems that libxml2 may add a trailing newline when working  
in DOCUMENT mode.  This is semantically insignificant, so strip it.  
  
This is in the gray area between being a bug fix and a definition  
change.  However, the INDENT option is still pretty new (since v16),  
so I think we can get away with changing this in stable branches.  
Hence, back-patch to v16.  
  
Jim Jones  
  
Discussion: https://postgr.es/m/[email protected]  

M src/backend/utils/adt/xml.c
M src/test/regress/expected/xml.out
M src/test/regress/expected/xml_1.out
M src/test/regress/expected/xml_2.out
M src/test/regress/sql/xml.sql

SQL/JSON: Avoid initializing unnecessary ON ERROR / ON EMPTY steps

commit   : 77aebe9a8d3cccd4c54b43be87a38f2bae614c76    
  
author   : Amit Langote <[email protected]>    
date     : Mon, 9 Sep 2024 11:55:38 +0900    
  
committer: Amit Langote <[email protected]>    
date     : Mon, 9 Sep 2024 11:55:38 +0900    

Click here for diff

When the ON ERROR / ON EMPTY behavior is to return NULL, returning  
NULL directly from ExecEvalJsonExprPath() suffices. Therefore, there's  
no need to create separate steps to check the error/empty flag or  
those to evaluate the the constant NULL expression.  This speeds up  
common cases because the default ON ERROR / ON EMPTY behavior for  
JSON_QUERY() and JSON_VALUE() is to return NULL.  However, these steps  
are necessary if the RETURNING type is a domain, as constraints on the  
domain may need to be checked.  
  
Reported-by: Jian He <[email protected]>  
Author: Jian He <[email protected]>  
Author: Amit Langote <[email protected]>  
Discussion: https://postgr.es/m/CACJufxEo4sUjKCYtda0_qt9tazqqKPmF1cqhW9KBOUeJFqQd2g@mail.gmail.com  
Backpatch-through: 17  

M src/backend/executor/execExpr.c
M src/backend/executor/execExprInterp.c

Fix waits of REINDEX CONCURRENTLY for indexes with predicates or expressions

commit   : cd6b2ae3e7f64c881cb0159a2f9fc8d475e06d82    
  
author   : Michael Paquier <[email protected]>    
date     : Mon, 9 Sep 2024 13:49:59 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Mon, 9 Sep 2024 13:49:59 +0900    

Click here for diff

As introduced by f9900df5f94, a REINDEX CONCURRENTLY job done for an  
index with predicates or expressions would set PROC_IN_SAFE_IC in its  
MyProc->statusFlags, causing it to be ignored by other concurrent  
operations.  
  
Such concurrent index rebuilds should never be ignored, as a predicate  
or an expression could call a user-defined function that accesses a  
different table than the table where the index is rebuilt.  
  
A test that uses injection points is added, backpatched down to 17.  
Michail has proposed a different test, but I have added something  
simpler with more coverage.  
  
Oversight in f9900df5f949.  
  
Author: Michail Nikolaev  
Discussion: https://postgr.es/m/CANtu0oj9A3kZVduFTG0vrmGnKB+DCHgEpzOp0qAyOgmks84j0w@mail.gmail.com  
Backpatch-through: 14  

M src/backend/commands/indexcmds.c
M src/test/modules/injection_points/Makefile
A src/test/modules/injection_points/expected/reindex_conc.out
M src/test/modules/injection_points/meson.build
A src/test/modules/injection_points/sql/reindex_conc.sql

Fix incorrect pg_stat_io output on 32-bit machines.

commit   : e69030cb5178347d499bbc549213e950064564fa    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 6 Sep 2024 11:57:57 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 6 Sep 2024 11:57:57 -0400    

Click here for diff

pg_stat_get_io() applied TimestampTzGetDatum twice to the  
stat_reset_timestamp value.  On 64-bit builds that's harmless because  
TimestampTzGetDatum is a no-op, but on 32-bit builds it results in  
displaying garbage in the stats_reset column of the pg_stat_io view.  
  
Bug dates to commit a9c70b46d which introduced pg_stat_io, so  
back-patch to v16 where that came in.  
  
Bertrand Drouvot  
  
Discussion: https://postgr.es/m/[email protected]  

M src/backend/utils/adt/pgstatfuncs.c

SQL/JSON: Fix default ON ERROR behavior for JSON_TABLE

commit   : 446d5ad7ae7d3bf4fd08904ae54a6399cafb4e7d    
  
author   : Amit Langote <[email protected]>    
date     : Fri, 6 Sep 2024 13:25:14 +0900    
  
committer: Amit Langote <[email protected]>    
date     : Fri, 6 Sep 2024 13:25:14 +0900    

Click here for diff

Use EMPTY ARRAY instead of EMPTY.  
  
This change does not affect the runtime behavior of JSON_TABLE(),  
which continues to return an empty relation ON ERROR. It only alters  
whether the default ON ERROR behavior is shown in the deparsed output.  
  
Reported-by: Jian He <[email protected]>  
Discussion: https://postgr.es/m/CACJufxEo4sUjKCYtda0_qt9tazqqKPmF1cqhW9KBOUeJFqQd2g@mail.gmail.com  
Backpatch-through: 17  

M src/backend/parser/parse_expr.c
M src/backend/utils/adt/ruleutils.c
M src/test/regress/expected/sqljson_jsontable.out
M src/test/regress/sql/sqljson_jsontable.sql

SQL/JSON: Fix JSON_TABLE() column deparsing

commit   : cd680b39211c5c3c88a143abcac576a22f996d7a    
  
author   : Amit Langote <[email protected]>    
date     : Fri, 6 Sep 2024 13:25:02 +0900    
  
committer: Amit Langote <[email protected]>    
date     : Fri, 6 Sep 2024 13:25:02 +0900    

Click here for diff

The deparsing code in get_json_expr_options() unnecessarily emitted  
the default column-specific ON ERROR / EMPTY behavior when the  
top-level ON ERROR behavior in JSON_TABLE was set to ERROR. Fix that  
by not overriding the column-specific default, determined based on  
the column's JsonExprOp in get_json_table_columns(), with  
JSON_BEHAVIOR_ERROR when that is the top-level ON ERROR behavior.  
  
Note that this only removes redundancy; the current deparsing output  
is not incorrect, just redundant.  
  
Reviewed-by: Jian He <[email protected]>  
Discussion: https://postgr.es/m/CACJufxEo4sUjKCYtda0_qt9tazqqKPmF1cqhW9KBOUeJFqQd2g@mail.gmail.com  
Backpatch-through: 17  

M src/backend/utils/adt/ruleutils.c
M src/test/regress/expected/sqljson_jsontable.out
M src/test/regress/sql/sqljson_jsontable.sql

commit   : eef5195f300bb9cf2864d48761c0db2ad93842c1    
  
author   : Amit Langote <[email protected]>    
date     : Fri, 6 Sep 2024 12:51:26 +0900    
  
committer: Amit Langote <[email protected]>    
date     : Fri, 6 Sep 2024 12:51:26 +0900    

Click here for diff

Reverts c88ce386c4d, 5067c230b8e, and  e4e27976a68, because a few BF  
animals didn't like one or all of them.  

M src/backend/executor/execExpr.c
M src/backend/parser/parse_expr.c
M src/backend/utils/adt/ruleutils.c
M src/test/regress/expected/sqljson_jsontable.out
M src/test/regress/sql/sqljson_jsontable.sql

SQL/JSON: Avoid initializing unnecessary ON ERROR / ON EMPTY steps

commit   : e4e27976a687dd641c1c8251fad3a90a08756df8    
  
author   : Amit Langote <[email protected]>    
date     : Fri, 6 Sep 2024 12:04:29 +0900    
  
committer: Amit Langote <[email protected]>    
date     : Fri, 6 Sep 2024 12:04:29 +0900    

Click here for diff

When the ON ERROR / ON EMPTY behavior is to return NULL, returning  
NULL directly from ExecEvalJsonExprPath() suffices. Therefore, there's  
no need to create separate steps to check the error/empty flag or  
those to evaluate the the constant NULL expression.  This speeds up  
common cases because the default ON ERROR / ON EMPTY behavior for  
JSON_QUERY() and JSON_VALUE() is to return NULL.  However, these steps  
are necessary if the RETURNING type is a domain, as constraints on the  
domain may need to be checked.  
  
Reported-by: Jian He <[email protected]>  
Author: Jian He <[email protected]>  
Author: Amit Langote <[email protected]>  
Discussion: https://postgr.es/m/CACJufxEo4sUjKCYtda0_qt9tazqqKPmF1cqhW9KBOUeJFqQd2g@mail.gmail.com  
Backpatch-through: 17  

M src/backend/executor/execExpr.c

SQL/JSON: Fix default ON ERROR behavior for JSON_TABLE

commit   : 5067c230b8ee42a01cc77dc5745bc3a78f393af3    
  
author   : Amit Langote <[email protected]>    
date     : Fri, 6 Sep 2024 10:13:03 +0900    
  
committer: Amit Langote <[email protected]>    
date     : Fri, 6 Sep 2024 10:13:03 +0900    

Click here for diff

Use EMPTY ARRAY instead of EMPTY.  
  
This change does not affect the runtime behavior of JSON_TABLE(),  
which continues to return an empty relation ON ERROR. It only alters  
whether the default ON ERROR behavior is shown in the deparsed output.  
  
Reported-by: Jian He <[email protected]>  
Discussion: https://postgr.es/m/CACJufxEo4sUjKCYtda0_qt9tazqqKPmF1cqhW9KBOUeJFqQd2g@mail.gmail.com  
Backpatch-through: 17  

M src/backend/parser/parse_expr.c
M src/backend/utils/adt/ruleutils.c
M src/test/regress/expected/sqljson_jsontable.out
M src/test/regress/sql/sqljson_jsontable.sql

SQL/JSON: Fix JSON_TABLE() column deparsing

commit   : c88ce386c4d7bfeb437ff31ec7c23c392c862e77    
  
author   : Amit Langote <[email protected]>    
date     : Fri, 6 Sep 2024 10:12:16 +0900    
  
committer: Amit Langote <[email protected]>    
date     : Fri, 6 Sep 2024 10:12:16 +0900    

Click here for diff

The deparsing code in get_json_expr_options() unnecessarily emitted  
the default column-specific ON ERROR / EMPTY behavior when the  
top-level ON ERROR behavior in JSON_TABLE was set to ERROR. Fix that  
by not overriding the column-specific default, determined based on  
the column's JsonExprOp in get_json_table_columns(), with  
JSON_BEHAVIOR_ERROR when that is the top-level ON ERROR behavior.  
  
Note that this only removes redundancy; the current deparsing output  
is not incorrect, just redundant.  
  
Reviewed-by: Jian He <[email protected]>  
Discussion: https://postgr.es/m/CACJufxEo4sUjKCYtda0_qt9tazqqKPmF1cqhW9KBOUeJFqQd2g@mail.gmail.com  
Backpatch-through: 17  

M src/backend/utils/adt/ruleutils.c
M src/test/regress/expected/sqljson_jsontable.out
M src/test/regress/sql/sqljson_jsontable.sql

Update comment about ExprState.escontext

commit   : fe323438140f69b8122e618387db1beb9ddaf5d3    
  
author   : Amit Langote <[email protected]>    
date     : Fri, 6 Sep 2024 10:12:00 +0900    
  
committer: Amit Langote <[email protected]>    
date     : Fri, 6 Sep 2024 10:12:00 +0900    

Click here for diff

The updated comment provides more helpful guidance by mentioning that  
escontext should be set when soft error handling is needed.  
  
Reported-by: Jian He <[email protected]>  
Discussion: https://postgr.es/m/CACJufxEo4sUjKCYtda0_qt9tazqqKPmF1cqhW9KBOUeJFqQd2g@mail.gmail.com  
Backpatch-through: 17  

M src/include/nodes/execnodes.h

doc PG 17 relnotes: remove tab complete for MERGE/SPLIT partit.

commit   : 35afec71aeb3723df57a6c3da1f98014b51d22e0    
  
author   : Bruce Momjian <[email protected]>    
date     : Thu, 5 Sep 2024 21:48:42 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Thu, 5 Sep 2024 21:48:42 -0400    

Click here for diff

commit 60ae37a8b  
  
Backpatch-through: 17 only  

M doc/src/sgml/release-17.sgml

Prevent mis-encoding of "trailing junk after numeric literal" errors.

commit   : 7dcbf0afa28cc8c3dd83bef0428a18ac177f129e    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 5 Sep 2024 12:42:33 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 5 Sep 2024 12:42:33 -0400    

Click here for diff

Since commit 2549f0661, we reject an identifier immediately following  
a numeric literal (without separating whitespace), because that risks  
ambiguity with hex/octal/binary integers.  However, that patch used  
token patterns like "{integer}{ident_start}", which is problematic  
because {ident_start} matches only a single byte.  If the first  
character after the integer is a multibyte character, this ends up  
with flex reporting an error message that includes a partial multibyte  
character.  That can cause assorted bad-encoding problems downstream,  
both in the report to the client and in the postmaster log file.  
  
To fix, use {identifier} not {ident_start} in the "junk" token  
patterns, so that they will match complete multibyte characters.  
This seems generally better user experience quite aside from the  
encoding problem: for "123abc" the error message will now say that  
the error appeared at or near "123abc" instead of "123a".  
  
While at it, add some commentary about why these patterns exist  
and how they work.  
  
Report and patch by Karina Litskevich; review by Pavel Borisov.  
Back-patch to v15 where the problem came in.  
  
Discussion: https://postgr.es/m/CACiT8iZ_diop=0zJ7zuY3BXegJpkKK1Av-PU7xh0EDYHsa5+=g@mail.gmail.com  

M src/backend/parser/scan.l
M src/fe_utils/psqlscan.l
M src/interfaces/ecpg/preproc/pgc.l
M src/test/regress/expected/numerology.out

Fix inconsistent LWLock tranche name "CommitTsSLRU"

commit   : 07b828e9d4aa916f1763774787440d914eea69c4    
  
author   : Michael Paquier <[email protected]>    
date     : Wed, 4 Sep 2024 10:22:19 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Wed, 4 Sep 2024 10:22:19 +0900    

Click here for diff

This term was using an inconsistent casing between the code and the  
documentation, using "CommitTsSLRU" in wait_event_names.txt and  
"CommitTSSLRU" in the code.  
  
Let's update the term in the code to reflect what's in the  
documentation, "CommitTs" being more commonly used, so as  
pg_stat_activity shows the same term as the documentation.  
  
Oversight in 53c2a97a9266.  
  
Author: Alexander Lakhin  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 17  

M src/backend/storage/lmgr/lwlock.c

Avoid installcheck failure in TAP tests using injection_points

commit   : bab1fd9277c2b1ef9ef70552d95a6e16c1f3cad4    
  
author   : Michael Paquier <[email protected]>    
date     : Wed, 4 Sep 2024 08:56:28 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Wed, 4 Sep 2024 08:56:28 +0900    

Click here for diff

These tests depend on the test module injection_points to be installed,  
but it may not be available as the contents of src/test/modules/ are not  
installed by default.  
  
This commit adds a workaround based on a scan of pg_available_extensions  
to check if the extension is available, skipping the test if it is not.  
This allows installcheck to work transparently.  
  
There are more tests impacted by this problem on HEAD, but for now this  
addresses only the tests that exist on HEAD and v17 as the release is  
close by.  
  
Reported-by: Maxim Orlov  
Discussion: https://postgr.es/m/CACG=ezZkoT-pFz6a9XnyToiuR-Wg8fGELqHLoyBodr+2h-77qA@mail.gmail.com  
Backpatch-through: 17  

M src/test/modules/test_misc/t/005_timeouts.pl
M src/test/recovery/t/041_checkpoint_at_promote.pl

Simplify makefiles exporting twice enable_injection_points

commit   : ff43b5e70d45c8d39ca7513e10c23367435c9826    
  
author   : Michael Paquier <[email protected]>    
date     : Wed, 4 Sep 2024 08:05:56 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Wed, 4 Sep 2024 08:05:56 +0900    

Click here for diff

This is confusing, as it exports twice the same variable.  Oversight in  
6782709df81f that has spread in more places afterwards.  
  
Reported-by: Alvaro Herrera, Tom Lane  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 17  

M src/test/modules/test_misc/Makefile
M src/test/recovery/Makefile

Stamp 17rc1.

commit   : 94f1474e600fdbc6b325f69903eecfeb1f69fcbd    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 2 Sep 2024 16:11:07 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 2 Sep 2024 16:11:07 -0400    

Click here for diff

M configure
M configure.ac
M meson.build

Fix warnings from msgfmt

commit   : c96176c48db0dbea2397537f6ab0e098b6b8260c    
  
author   : Peter Eisentraut <[email protected]>    
date     : Mon, 2 Sep 2024 18:03:47 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Mon, 2 Sep 2024 18:03:47 +0200    

Click here for diff

/usr/bin/msgfmt: po/fr.po: warning: PO file header fuzzy  
                           warning: older versions of msgfmt will give an error on this  
  
Apparently, not all versions of msgfmt produce this.  Quick fix for  
now, more to be researched later.  

M src/bin/pg_combinebackup/po/fr.po
M src/bin/pg_walsummary/po/fr.po

Fix rarely-run test for message wording change

commit   : e6ec1d6aabe024d0789fe53c711cd5cae47d30ea    
  
author   : Peter Eisentraut <[email protected]>    
date     : Mon, 2 Sep 2024 17:40:32 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Mon, 2 Sep 2024 17:40:32 +0200    

Click here for diff

fixup for 2e6a8047f0  
  
Reported-by: Nazir Bilal Yavuz <[email protected]>  

M src/test/modules/xid_wraparound/t/002_limits.pl

Translation updates

commit   : 986a3ac497fddac717d40b7cd90296af27f07526    
  
author   : Peter Eisentraut <[email protected]>    
date     : Mon, 2 Sep 2024 12:02:42 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Mon, 2 Sep 2024 12:02:42 +0200    

Click here for diff

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

M src/backend/po/de.po
M src/backend/po/sv.po
M src/bin/pg_amcheck/po/de.po
M src/bin/pg_amcheck/po/fr.po
M src/bin/pg_amcheck/po/ka.po
M src/bin/pg_amcheck/po/sv.po
M src/bin/pg_basebackup/po/de.po
M src/bin/pg_basebackup/po/fr.po
M src/bin/pg_basebackup/po/ka.po
M src/bin/pg_basebackup/po/sv.po
M src/bin/pg_combinebackup/po/LINGUAS
M src/bin/pg_combinebackup/po/de.po
A src/bin/pg_combinebackup/po/fr.po
M src/bin/pg_combinebackup/po/ka.po
M src/bin/pg_combinebackup/po/sv.po
M src/bin/pg_ctl/po/fr.po
M src/bin/pg_dump/po/de.po
M src/bin/pg_dump/po/es.po
M src/bin/pg_dump/po/fr.po
M src/bin/pg_dump/po/ka.po
M src/bin/pg_dump/po/sv.po
M src/bin/pg_resetwal/po/fr.po
M src/bin/pg_rewind/po/de.po
M src/bin/pg_rewind/po/fr.po
M src/bin/pg_rewind/po/ka.po
M src/bin/pg_rewind/po/sv.po
M src/bin/pg_test_fsync/po/fr.po
M src/bin/pg_test_timing/po/fr.po
M src/bin/pg_upgrade/po/de.po
M src/bin/pg_upgrade/po/fr.po
M src/bin/pg_upgrade/po/ka.po
M src/bin/pg_upgrade/po/sv.po
M src/bin/pg_verifybackup/po/de.po
M src/bin/pg_verifybackup/po/fr.po
M src/bin/pg_verifybackup/po/ka.po
M src/bin/pg_verifybackup/po/sv.po
M src/bin/pg_waldump/po/fr.po
M src/bin/pg_walsummary/po/LINGUAS
A src/bin/pg_walsummary/po/fr.po
M src/bin/psql/po/fr.po
M src/bin/scripts/po/fr.po
M src/bin/scripts/po/ka.po
M src/pl/plperl/po/fr.po
M src/pl/plpgsql/src/po/fr.po
M src/pl/tcl/po/fr.po

Fix unfairness in all-cached parallel seq scan.

commit   : 3ed3683618cb6a9b10dc5297751fa8b7fe7e36e1    
  
author   : Thomas Munro <[email protected]>    
date     : Sat, 31 Aug 2024 17:27:38 +1200    
  
committer: Thomas Munro <[email protected]>    
date     : Sat, 31 Aug 2024 17:27:38 +1200    

Click here for diff

Commit b5a9b18c introduced block streaming infrastructure with a special  
fast path for all-cached scans, and commit b7b0f3f2 connected the  
infrastructure up to sequential scans.  One of the fast path  
micro-optimizations had an unintended consequence: it interfered with  
parallel sequential scan's block range allocator (from commit 56788d21),  
which has its own ramp-up and ramp-down algorithm when handing out  
groups of pages to workers.  A scan of an all-cached table could give  
extra blocks to one worker, when others had finished.  In some plans  
(probably already very bad plans, such as the one reported by  
Alexander), the unfairness could be magnified.  
  
An internal buffer of 16 block numbers is removed, keeping just a single  
block buffer for technical reasons.  
  
Back-patch to 17.  
  
Reported-by: Alexander Lakhin <[email protected]>  
Discussion: https://postgr.es/m/63a63690-dd92-c809-0b47-af05459e95d1%40gmail.com  

M src/backend/storage/aio/read_stream.c

Stabilize 039_end_of_wal test.

commit   : 34226d4ad7efbe85e6721e40a82498dac8ec6211    
  
author   : Thomas Munro <[email protected]>    
date     : Sat, 31 Aug 2024 14:32:08 +1200    
  
committer: Thomas Munro <[email protected]>    
date     : Sat, 31 Aug 2024 14:32:08 +1200    

Click here for diff

The first test was sensitive to the insert LSN after setting up the  
catalogs, which depended on environmental things like the locales on the  
OS and usernames.  Switch to a new WAL file before the first test, as a  
simple way to put every computer into the same state.  
  
Back-patch to all supported releases.  
  
Reported-by: Anton Voloshin <[email protected]>  
Reported-by: Nathan Bossart <[email protected]>  
Reviewed-by: Tom Lane <[email protected]>  
Reviewed-by: Nathan Bossart <[email protected]>  
Discussion: https://postgr.es/m/b26aeac2-cb6d-4633-a7ea-945baae83dcf%40postgrespro.ru  

M src/test/recovery/t/039_end_of_wal.pl

Clarify restrict_nonsystem_relation_kind description.

commit   : 0776724050f47c5ff827693f498cd2604c1ea5d1    
  
author   : Masahiko Sawada <[email protected]>    
date     : Fri, 30 Aug 2024 15:06:07 -0700    
  
committer: Masahiko Sawada <[email protected]>    
date     : Fri, 30 Aug 2024 15:06:07 -0700    

Click here for diff

This change improves the description of the  
restrict_nonsystem_relation_kind parameter in guc_table.c and the  
documentation for better clarity.  
  
Backpatch to 12, where this GUC parameter was introduced.  
  
Reviewed-by: Peter Eisentraut  
Discussion: https://postgr.es/m/6a96f1af-22b4-4a80-8161-1f26606b9ee2%40eisentraut.org  
Backpatch-through: 12  

M doc/src/sgml/config.sgml
M src/backend/utils/misc/guc_tables.c

Make postgres_fdw's query_cancel test less flaky.

commit   : 8749d850f962a3fe77b637ef17de9f69e0e9389d    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 30 Aug 2024 16:47:39 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 30 Aug 2024 16:47:39 -0400    

Click here for diff

This test occasionally shows  
  
+WARNING:  could not get result of cancel request due to timeout  
  
which appears to be because the cancel request is sometimes unluckily  
sent to the remote session between queries, and then it's ignored.  
  
This patch tries to make that less probable in three ways:  
  
1. Use a test query that does not involve remote estimates, so that  
no EXPLAINs are sent.  
2. Make sure that the remote session is ready-to-go (transaction  
started, SET commands sent) before we start the timer.  
3. Increase the statement_timeout to 100ms, to give the local  
session enough time to plan and issue the query.  
  
We might have to go higher than 100ms to make this adequately  
stable in the buildfarm, but let's see how it goes.  
  
Back-patch to v17 where this test was introduced.  
  
Jelte Fennema-Nio and Tom Lane  
  
Discussion: https://postgr.es/m/[email protected]  

M contrib/postgres_fdw/expected/query_cancel.out
M contrib/postgres_fdw/sql/query_cancel.sql

Avoid inserting PlaceHolderVars in cases where pre-v16 PG did not.

commit   : b43110869fd82b549df5c6ab7ade476d6e414f37    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 30 Aug 2024 12:42:13 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 30 Aug 2024 12:42:13 -0400    

Click here for diff

Commit 2489d76c4 removed some logic from pullup_replace_vars()  
that avoided wrapping a PlaceHolderVar around a pulled-up  
subquery output expression if the expression could be proven  
to go to NULL anyway (because it contained Vars or PHVs of the  
pulled-up relation and did not contain non-strict constructs).  
But removing that logic turns out to cause performance regressions  
in some cases, because the extra PHV blocks subexpression folding,  
and will do so even if outer-join reduction later turns it into a  
no-op with no phnullingrels bits.  This can for example prevent  
an expression from being matched to an index.  
  
The reason for always adding a PHV was to ensure we had someplace  
to put the varnullingrels marker bits of the Var being replaced.  
However, it turns out we can optimize in exactly the same cases that  
the previous code did, because we can instead attach the needed  
varnullingrels bits to the contained Var(s)/PHV(s).  
  
This is not a complete solution --- it would be even better if we  
could remove PHVs after reducing them to no-ops.  It doesn't look  
practical to back-patch such an improvement, but this change seems  
safe and at least gets rid of the performance-regression cases.  
  
Per complaint from Nikhil Raj.  Back-patch to v16 where the  
problem appeared.  
  
Discussion: https://postgr.es/m/CAG1ps1xvnTZceKK24OUfMKLPvDP2vjT-d+F2AOCWbw_v3KeEgg@mail.gmail.com  

M src/backend/optimizer/prep/prepjointree.c
M src/backend/rewrite/rewriteManip.c
M src/test/regress/expected/subselect.out
M src/test/regress/sql/subselect.sql

Update list of acknowledgments in release notes

commit   : df51201f34f21ae313076e8f1a475c59a2ff2f5f    
  
author   : Peter Eisentraut <[email protected]>    
date     : Fri, 30 Aug 2024 10:03:48 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Fri, 30 Aug 2024 10:03:48 +0200    

Click here for diff

current through df80b1d6cd  

M doc/src/sgml/release-17.sgml

Remove duplicate name from list of acknowledgments

commit   : df80b1d6cd36c6cc6be7529895c0434e90e911cc    
  
author   : Peter Eisentraut <[email protected]>    
date     : Fri, 30 Aug 2024 08:38:16 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Fri, 30 Aug 2024 08:38:16 +0200    

Click here for diff

Reported-by: [email protected]  

M doc/src/sgml/release-17.sgml

Correct name in list of acknowledgments

commit   : 47b92f8fc522d3c1a75a955c32c492d752316584    
  
author   : Peter Eisentraut <[email protected]>    
date     : Fri, 30 Aug 2024 08:34:39 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Fri, 30 Aug 2024 08:34:39 +0200    

Click here for diff

Reported-by: Etsuro Fujita <[email protected]>  

M doc/src/sgml/release-17.sgml

Fix mis-deparsing of ORDER BY lists when there is a name conflict.

commit   : a7eb633563c6ba8857cf59c7b43b593614537617    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 29 Aug 2024 13:24:17 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 29 Aug 2024 13:24:17 -0400    

Click here for diff

If an ORDER BY item in SELECT is a bare identifier, the parser  
first seeks it as an output column name of the SELECT (for SQL92  
compatibility).  However, ruleutils.c is expecting the SQL99  
interpretation where such a name is an input column name.  So it's  
possible to produce an incorrect display of a view in the (admittedly  
pretty ill-advised) case where some other column is renamed in the  
SELECT output list to match an ORDER BY column.  
  
This can be fixed by table-qualifying such names in the dumped  
view text.  To avoid cluttering less-ill-advised queries, we'd  
like to do so only when there's an actual name conflict.  
That requires passing the current get_query_def call's resultDesc  
parameter down to get_variable, so that it can determine what  
the output column names are.  In hopes of reducing rather than  
increasing notational clutter in ruleutils.c, I moved that value  
into the deparse_context struct and removed it from the parameter  
lists of get_query_def's other subroutines.  
  
I made a few other cosmetic changes while at it:  
* Likewise move the colNamesVisible parameter into deparse_context.  
* Rename deparse_context's windowTList field to targetList,  
since it's no longer used only in connection with WINDOW clauses.  
* Replace the special_exprkind field with a bool inGroupBy,  
since that was all it was being used for, and the apparent  
flexibility of storing a ParseExprKind proved to be illusory.  
(We need a separate varInOrderBy field to make this patch work.)  
* Remove useless save/restore logic in get_select_query_def.  
  
In principle, this bug is quite old.  However, it seems unreachable  
before 1b4d280ea, because before that the presence of "new" and "old"  
entries in a view's rangetable caused us to always table-qualify every  
Var reference in dumped views.  Hence, back-patch to v16 where that  
came in.  
  
Per bug #18589 from Quynh Tran.  
  
Discussion: https://postgr.es/m/[email protected]  

M src/backend/utils/adt/ruleutils.c
M src/test/regress/expected/create_view.out
M src/test/regress/sql/create_view.sql

Message style improvements

commit   : f2353dd71724c0d18d5912e105f034b50494bfe9    
  
author   : Peter Eisentraut <[email protected]>    
date     : Thu, 29 Aug 2024 14:33:18 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Thu, 29 Aug 2024 14:33:18 +0200    

Click here for diff

M src/backend/access/transam/varsup.c
M src/backend/access/transam/xact.c
M src/backend/backup/basebackup_incremental.c
M src/backend/commands/copyfromparse.c
M src/backend/commands/subscriptioncmds.c
M src/backend/commands/tablecmds.c
M src/backend/postmaster/walsummarizer.c
M src/backend/replication/logical/logical.c
M src/backend/replication/logical/slotsync.c
M src/backend/replication/pgoutput/pgoutput.c
M src/backend/replication/slot.c
M src/backend/rewrite/rewriteHandler.c
M src/backend/utils/adt/jsonpath_exec.c
M src/backend/utils/misc/guc_tables.c
M src/bin/pg_basebackup/t/010_pg_basebackup.pl
M src/common/parse_manifest.c
M src/test/recovery/t/040_standby_failover_slots_sync.pl
M src/test/regress/expected/copy2.out
M src/test/regress/expected/foreign_key.out
M src/test/regress/expected/jsonb_jsonpath.out
M src/test/regress/expected/sqljson_jsontable.out
M src/test/regress/expected/sqljson_queryfuncs.out
M src/test/regress/expected/updatable_views.out

Disallow USING clause when altering type of generated column

commit   : fdbf7e46a46d2ce8a215b37870b14ee2d7cf0fda    
  
author   : Peter Eisentraut <[email protected]>    
date     : Thu, 29 Aug 2024 08:38:29 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Thu, 29 Aug 2024 08:38:29 +0200    

Click here for diff

This does not make sense.  It would write the output of the USING  
clause into the converted column, which would violate the generation  
expression.  This adds a check to error out if this is specified.  
  
There was a test for this, but that test errored out for a different  
reason, so it was not effective.  
  
Reported-by: Jian He <[email protected]>  
Reviewed-by: Yugo NAGATA <[email protected]>  
Discussion: https://www.postgresql.org/message-id/flat/c7083982-69f4-4b14-8315-f9ddb20b9834%40eisentraut.org  

M src/backend/commands/tablecmds.c
M src/test/regress/expected/generated.out

Doc: Fix the ambiguity in the description of failover slots.

commit   : 135007a1008c11e849036692ffe180dd7d4b5107    
  
author   : Amit Kapila <[email protected]>    
date     : Thu, 29 Aug 2024 08:45:41 +0530    
  
committer: Amit Kapila <[email protected]>    
date     : Thu, 29 Aug 2024 08:45:41 +0530    

Click here for diff

The failover slots ensure a seamless transition of a subscriber after the  
standby is promoted. But the docs for it also explain the behavior of  
asynchronous replication which can confuse the readers.  
  
Reported-by: Masahiro Ikeda  
Backpatch-through: 17  
Discussion: https://postgr.es/m/OS3PR01MB6390B660F4198BB9745E0526B18B2@OS3PR01MB6390.jpnprd01.prod.outlook.com  

M doc/src/sgml/logical-replication.sgml

Message style improvements

commit   : 0be079ec9706eb80f0142b0d7deba245024acdce    
  
author   : Peter Eisentraut <[email protected]>    
date     : Tue, 27 Aug 2024 16:54:10 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Tue, 27 Aug 2024 16:54:10 +0200    

Click here for diff

M src/bin/pg_amcheck/pg_amcheck.c
M src/bin/pg_amcheck/t/003_check.pl
M src/bin/pg_combinebackup/pg_combinebackup.c
M src/bin/pg_combinebackup/reconstruct.c
M src/bin/pg_dump/pg_dumpall.c
M src/bin/pg_rewind/pg_rewind.c

Fix misplaced translator comments

commit   : 203b5ceee88c377110260e8c69083ef24b54fc68    
  
author   : Peter Eisentraut <[email protected]>    
date     : Tue, 27 Aug 2024 16:15:28 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Tue, 27 Aug 2024 16:15:28 +0200    

Click here for diff

They did not immediately precede the code they were applying to.  

M src/backend/replication/logical/slotsync.c

Fix identation.

commit   : c739ae9e288c095cfe1b91ce27a2f2c075ed5da4    
  
author   : Masahiko Sawada <[email protected]>    
date     : Mon, 26 Aug 2024 16:16:09 -0700    
  
committer: Masahiko Sawada <[email protected]>    
date     : Mon, 26 Aug 2024 16:16:09 -0700    

Click here for diff

M src/backend/replication/logical/reorderbuffer.c

Fix memory counter update in ReorderBuffer.

commit   : dbed2e36625de9d4074243f60f48e04b5ed67810    
  
author   : Masahiko Sawada <[email protected]>    
date     : Mon, 26 Aug 2024 11:00:04 -0700    
  
committer: Masahiko Sawada <[email protected]>    
date     : Mon, 26 Aug 2024 11:00:04 -0700    

Click here for diff

Commit 5bec1d6bc5e changed the memory usage updates of the  
ReorderBufferTXN to zero all at once by subtracting txn->size, rather  
than updating it for each change. However, if TOAST reconstruction  
data remained in the transaction when freeing it, there were cases  
where it further subtracted the memory counter from zero, resulting in  
an assertion failure.  
  
This change calculates the memory size for each change and updates the  
memory usage to precisely the amount that has been freed.  
  
Backpatch to v17, where this was introducd.  
  
Reviewed-by: Amit Kapila, Shlok Kyal  
Discussion: https://postgr.es/m/CAD21AoAqkNUvicgKPT_dXzNoOwpPkVTg0QPPxEcWmzT0moCJ1g%40mail.gmail.com  
Backpatch-through: 17  

M contrib/test_decoding/expected/stream.out
M contrib/test_decoding/sql/stream.sql
M src/backend/replication/logical/reorderbuffer.c

Fix nbtree lookahead overflow bug.

commit   : 6749d4aabe74ca37ce351f2e318fe1b3bcf2b71c    
  
author   : Peter Geoghegan <[email protected]>    
date     : Mon, 26 Aug 2024 11:29:13 -0400    
  
committer: Peter Geoghegan <[email protected]>    
date     : Mon, 26 Aug 2024 11:29:13 -0400    

Click here for diff

Add bounds checking to nbtree's lookahead/skip-within-a-page mechanism.  
Otherwise it's possible for cases with lots of before-array-keys tuples  
to overflow an int16 variable, causing the mechanism to generate an out  
of bounds page offset number.  
  
Oversight in commit 5bf748b8, which enhanced nbtree ScalarArrayOp  
execution.  
  
Reported-By: Alexander Lakhin <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  
Backpatch: 17-, where nbtree SAOP execution was enhanced.  

M src/backend/access/nbtree/nbtutils.c

pg_upgrade: Message style improvements

commit   : 5e58107b0bb5a10b36ba4af4a9f82e6254d75e9f    
  
author   : Peter Eisentraut <[email protected]>    
date     : Mon, 26 Aug 2024 14:38:59 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Mon, 26 Aug 2024 14:38:59 +0200    

Click here for diff

M src/bin/pg_upgrade/check.c
M src/bin/pg_upgrade/info.c
M src/bin/pg_upgrade/t/003_logical_slots.pl

doc PG 17 relnotes: remove ALTER TABLE SPLIT/MERGE PARTITION

commit   : 74e3db06a01d1fe6b9f30f71e05e8438d3aaa37b    
  
author   : Bruce Momjian <[email protected]>    
date     : Sun, 25 Aug 2024 22:09:18 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Sun, 25 Aug 2024 22:09:18 -0400    

Click here for diff

Reverted in commit 84f594da358  
  
Backpatch-through: 17 only  

M doc/src/sgml/release-17.sgml

Revert support for ALTER TABLE ... MERGE/SPLIT PARTITION(S) commands

commit   : 84f594da358861cceeaeb7a97bb58f3765eeb284    
  
author   : Alexander Korotkov <[email protected]>    
date     : Sat, 24 Aug 2024 18:48:48 +0300    
  
committer: Alexander Korotkov <[email protected]>    
date     : Sat, 24 Aug 2024 18:48:48 +0300    

Click here for diff

This commit reverts 1adf16b8fb, 87c21bb941, and subsequent fixes and  
improvements including df64c81ca9, c99ef1811a, 9dfcac8e15, 885742b9f8,  
842c9b2705, fcf80c5d5f, 96c7381c4c, f4fc7cb54b, 60ae37a8bc, 259c96fa8f,  
449cdcd486, 3ca43dbbb6, 2a679ae94e, 3a82c689fd, fbd4321fd5, d53a4286d7,  
c086896625, 4e5d6c4091, 04158e7fa3.  
  
The reason for reverting is security issues related to repeatable name lookups  
(CVE-2014-0062).  Even though 04158e7fa3 solved part of the problem, there  
are still remaining issues, which aren't feasible to even carefully analyze  
before the RC deadline.  
  
Reported-by: Noah Misch, Robert Haas  
Discussion: https://postgr.es/m/20240808171351.a9.nmisch%40google.com  
Backpatch-through: 17  

M doc/src/sgml/ddl.sgml
M doc/src/sgml/ref/alter_table.sgml
M src/backend/commands/tablecmds.c
M src/backend/parser/gram.y
M src/backend/parser/parse_utilcmd.c
M src/backend/partitioning/partbounds.c
M src/backend/tcop/utility.c
M src/backend/utils/adt/ruleutils.c
M src/bin/psql/tab-complete.c
M src/include/nodes/parsenodes.h
M src/include/parser/kwlist.h
M src/include/partitioning/partbounds.h
M src/include/utils/ruleutils.h
D src/test/isolation/expected/partition-merge.out
D src/test/isolation/expected/partition-split.out
M src/test/isolation/isolation_schedule
D src/test/isolation/specs/partition-merge.spec
D src/test/isolation/specs/partition-split.spec
M src/test/modules/test_ddl_deparse/test_ddl_deparse.c
D src/test/regress/expected/partition_merge.out
D src/test/regress/expected/partition_split.out
M src/test/regress/parallel_schedule
D src/test/regress/sql/partition_merge.sql
D src/test/regress/sql/partition_split.sql
M src/tools/pgindent/typedefs.list

Add list of acknowledgments to release notes

commit   : 29e125319896aa5567d5274e8185bb7088e101ae    
  
author   : Peter Eisentraut <[email protected]>    
date     : Sat, 24 Aug 2024 16:15:13 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Sat, 24 Aug 2024 16:15:13 +0200    

Click here for diff

This contains all individuals mentioned in the commit messages during  
PostgreSQL 17 development.  
  
current through REL_17_BETA3  

M doc/src/sgml/release-17.sgml

pg_createsubscriber: Message style improvements

commit   : bf886dfdd444ffa8b8bbddd2015de893a6aefb96    
  
author   : Peter Eisentraut <[email protected]>    
date     : Sat, 24 Aug 2024 15:56:32 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Sat, 24 Aug 2024 15:56:32 +0200    

Click here for diff

M doc/src/sgml/ref/pg_createsubscriber.sgml
M src/bin/pg_basebackup/pg_createsubscriber.c

Provide feature-test macros for libpq features added in v17.

commit   : 79c3012dc2311bdaa4bb135d871d16f103a62966    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 23 Aug 2024 10:12:56 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 23 Aug 2024 10:12:56 -0400    

Click here for diff

As per the policy established in commit 6991e774e, invent macros  
that can be tested at compile time to detect presence of new libpq  
features.  This should make calling code more readable and less  
error-prone than checking the libpq version would be (especially  
since we don't expose that at compile time; the server version is  
an unreliable substitute).  
  
Discussion: https://postgr.es/m/[email protected]  

M src/interfaces/libpq/libpq-fe.h

Fix attach of a previously-detached injection point.

commit   : 6b1f78d90b5f2475d968e16febee8f9d43730d63    
  
author   : Noah Misch <[email protected]>    
date     : Thu, 22 Aug 2024 00:07:04 -0700    
  
committer: Noah Misch <[email protected]>    
date     : Thu, 22 Aug 2024 00:07:04 -0700    

Click here for diff

It's normal for the name in a free slot to match the new name.  The  
max_inuse mechanism kept simple cases from reaching the problem.  The  
problem could appear when index 0 was the previously-detached entry and  
index 1 is in use.  Back-patch to v17, where this code first appeared.  

M src/backend/utils/misc/injection_point.c

Avoid repeated table name lookups in createPartitionTable()

commit   : f636ab41aba215eaa3303e21a10f12d81357f1f6    
  
author   : Alexander Korotkov <[email protected]>    
date     : Thu, 22 Aug 2024 09:50:48 +0300    
  
committer: Alexander Korotkov <[email protected]>    
date     : Thu, 22 Aug 2024 09:50:48 +0300    

Click here for diff

Currently, createPartitionTable() opens newly created table using its name.  
This approach is prone to privilege escalation attack, because we might end  
up opening another table than we just created.  
  
This commit address the issue above by opening newly created table by its  
OID.  It appears to be tricky to get a relation OID out of ProcessUtility().  
We have to extend TableLikeClause with new newRelationOid field, which is  
filled within ProcessUtility() to be further accessed by caller.  
  
Security: CVE-2014-0062  
Reported-by: Noah Misch  
Discussion: https://postgr.es/m/20240808171351.a9.nmisch%40google.com  
Reviewed-by: Pavel Borisov, Dmitry Koval  

M src/backend/commands/tablecmds.c
M src/backend/parser/gram.y
M src/backend/tcop/utility.c
M src/include/nodes/parsenodes.h

Disallow creating binary-coercible casts involving range types.

commit   : 2366ab246a32fa2f10523768926dcf6afe42080f    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 21 Aug 2024 12:00:03 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 21 Aug 2024 12:00:03 -0400    

Click here for diff

For a long time we have forbidden binary-coercible casts to or from  
composite and array types, because such a cast cannot work correctly:  
the type OID embedded in the value would need to change, but it won't  
in a binary coercion.  That reasoning applies equally to range types,  
but we overlooked installing a similar restriction here when we  
invented range types.  Do so now.  
  
Given the lack of field complaints, we won't change this in stable  
branches, but it seems not too late for v17.  
  
Per discussion of a problem noted by Peter Eisentraut.  
  
Discussion: https://postgr.es/m/[email protected]  

M src/backend/commands/functioncmds.c

doc: remove llvm-config search from configure documentation

commit   : 0c7ec3b3a03b90c6d8afaff01635ed9060d5414d    
  
author   : Peter Eisentraut <[email protected]>    
date     : Wed, 21 Aug 2024 15:11:21 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Wed, 21 Aug 2024 15:11:21 +0200    

Click here for diff

As of 4dd29b6833, we no longer attempt to locate any other llvm-config  
variant than plain llvm-config in configure-based builds; update the  
documentation accordingly. (For Meson-based builds, we still use Meson's  
LLVMDependencyConfigTool [0], which runs through a set of possible  
suffixes [1], so no need to update the documentation there.)  
  
[0]: https://github.com/mesonbuild/meson/blob/7d28ff29396f9d7043204de8ddc52226b9903811/mesonbuild/dependencies/dev.py#L184  
[1]: https://github.com/mesonbuild/meson/blob/7d28ff29396f9d7043204de8ddc52226b9903811/mesonbuild/environment.py#L183  
  
Author: Ole Peder Brandtzæg <[email protected]>  
Discussion: https://www.postgresql.org/message-id/20240518224601.gtisttjerylukjr5%40samfundet.no  

M doc/src/sgml/installation.sgml

Don't advance origin during apply failure.

commit   : 915aafe82a7c31e9f7452e8cedf6371c318388bd    
  
author   : Amit Kapila <[email protected]>    
date     : Wed, 21 Aug 2024 09:08:16 +0530    
  
committer: Amit Kapila <[email protected]>    
date     : Wed, 21 Aug 2024 09:08:16 +0530    

Click here for diff

We advance origin progress during abort on successful streaming and  
application of ROLLBACK in parallel streaming mode. But the origin  
shouldn't be advanced during an error or unsuccessful apply due to  
shutdown. Otherwise, it will result in a transaction loss as such a  
transaction won't be sent again by the server.  
  
Reported-by: Hou Zhijie  
Author: Hayato Kuroda and Shveta Malik  
Reviewed-by: Amit Kapila  
Backpatch-through: 16  
Discussion: https://postgr.es/m/TYAPR01MB5692FAC23BE40C69DA8ED4AFF5B92@TYAPR01MB5692.jpnprd01.prod.outlook.com  

M src/backend/replication/logical/worker.c
M src/backend/utils/error/elog.c
M src/include/utils/elog.h
M src/test/subscription/t/021_twophase.pl

Minor wording change in table "JSON Creation Functions"

commit   : 5effd5970429cdac56c8219eb4c0b8b047cac320    
  
author   : Alvaro Herrera <[email protected]>    
date     : Tue, 20 Aug 2024 17:53:40 -0400    
  
committer: Alvaro Herrera <[email protected]>    
date     : Tue, 20 Aug 2024 17:53:40 -0400    

Click here for diff

For readability.  Backpatch to 16.  
  
Author: Erik Wienhold <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  

M doc/src/sgml/func.sgml

Fix a couple of wait event descriptions.

commit   : effc4c9a666cdb19822d7062ba1ef67ddddffb42    
  
author   : Nathan Bossart <[email protected]>    
date     : Tue, 20 Aug 2024 13:43:20 -0500    
  
committer: Nathan Bossart <[email protected]>    
date     : Tue, 20 Aug 2024 13:43:20 -0500    

Click here for diff

The descriptions for ProcArrayGroupUpdate and XactGroupUpdate claim  
that these events mean we are waiting for the group leader "at end  
of a parallel operation," but neither pertains to parallel  
operations.  This commit reverts these descriptions to their  
wording before commit 3048898e73, i.e., "end of a parallel  
operation" is changed to "transaction end."  
  
Author: Sameer Kumar  
Reviewed-by: Amit Kapila  
Discussion: https://postgr.es/m/CAGPeHmh6UMrKQHKCmX%2B5vV5TH9P%3DKw9en3k68qEem6J%3DyrZPUA%40mail.gmail.com  
Backpatch-through: 13  

M src/backend/utils/activity/wait_event_names.txt

Document limit on the number of out-of-line values per table

commit   : 667401dd40c8b99bd91e91f5540defdcb7a4438e    
  
author   : John Naylor <[email protected]>    
date     : Tue, 20 Aug 2024 10:02:34 +0700    
  
committer: John Naylor <[email protected]>    
date     : Tue, 20 Aug 2024 10:02:34 +0700    

Click here for diff

Document the hard limit stemming from the size of an OID, and also  
mention the perfomance impact that occurs before the hard limit  
is reached.  
  
Jakub Wartak and Robert Haas  
Backpatch to all supported versions  
  
Discussion: https://postgr.es/m/CAKZiRmwWhp2yxjqJLwbBjHdfbJBcUmmKMNAZyBjjtpgM9AMatQ%40mail.gmail.com  

M doc/src/sgml/limits.sgml

doc: Improve vague pg_createsubscriber description

commit   : ef3aa800e884ba30f21ed1f36bdc587e67df39e5    
  
author   : Bruce Momjian <[email protected]>    
date     : Mon, 19 Aug 2024 18:27:21 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Mon, 19 Aug 2024 18:27:21 -0400    

Click here for diff

Discussion: https://postgr.es/m/[email protected]  
  
Author: Euler Taveira  
  
Backpatch-through: 17  

M doc/src/sgml/ref/pg_createsubscriber.sgml

Avoid failure to open dropped detached partition

commit   : 11f1218ce81ef3ce98389754456ca9365fa10dbe    
  
author   : Alvaro Herrera <[email protected]>    
date     : Mon, 19 Aug 2024 16:09:10 -0400    
  
committer: Alvaro Herrera <[email protected]>    
date     : Mon, 19 Aug 2024 16:09:10 -0400    

Click here for diff

When a partition is detached and immediately dropped, a prepared  
statement could try to compute a new partition descriptor that includes  
it.  This leads to this kind of error:  
ERROR:  could not open relation with OID 457639  
  
Avoid this by skipping the partition in expand_partitioned_rtentry if it  
doesn't exist.  
  
Noted by me while investigating bug #18559.  Kuntal Gosh helped to  
identify the exact failure.  
  
Backpatch to 14, where DETACH CONCURRENTLY was introduced.  
  
Author: Álvaro Herrera <[email protected]>  
Reviewed-by: Kuntal Ghosh <[email protected]>  
Reviewed-by: Junwang Zhao <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  

M src/backend/optimizer/util/inherit.c

Explain dropdb can't use syscache because of TOAST

commit   : de8770b47f1f763378d9d130d69e3a7b8a54684a    
  
author   : Tomas Vondra <[email protected]>    
date     : Mon, 19 Aug 2024 13:31:51 +0200    
  
committer: Tomas Vondra <[email protected]>    
date     : Mon, 19 Aug 2024 13:31:51 +0200    

Click here for diff

Add a comment explaining dropdb() can't rely on syscache. The issue with  
flattened rows was fixed by commit 0f92b230f88b, but better to have  
a clear explanation why the systable scan is necessary. The other places  
doing in-place updates on pg_database have the same comment.  
  
Suggestion and patch by Yugo Nagata. Backpatch to 12, same as the fix.  
  
Author: Yugo Nagata  
Backpatch-through: 12  
Discussion: https://postgr.es/m/CAJTYsWWNkCt+-UnMhg=BiCD3Mh8c2JdHLofPxsW3m2dkDFw8RA@mail.gmail.com  

M src/backend/commands/dbcommands.c

Fix regression in TLS session ticket disabling

commit   : 19021d28cdf0e84ebc498382826b936df62f5dba    
  
author   : Daniel Gustafsson <[email protected]>    
date     : Mon, 19 Aug 2024 12:55:11 +0200    
  
committer: Daniel Gustafsson <[email protected]>    
date     : Mon, 19 Aug 2024 12:55:11 +0200    

Click here for diff

Commit 274bbced disabled session tickets for TLSv1.3 on top of the  
already disabled TLSv1.2 session tickets, but accidentally caused  
a regression where TLSv1.2 session tickets were incorrectly sent.  
Fix by unconditionally disabling TLSv1.2 session tickets and only  
disable TLSv1.3 tickets when the right version of OpenSSL is used.  
  
Backpatch to all supported branches.  
  
Reported-by: Cameron Vogt <[email protected]>  
Reported-by: Fire Emerald <[email protected]>  
Reviewed-by: Jacob Champion <[email protected]>  
Discussion: https://postgr.es/m/DM6PR16MB3145CF62857226F350C710D1AB852@DM6PR16MB3145.namprd16.prod.outlook.com  
Backpatch-through: v12  

M src/backend/libpq/be-secure-openssl.c

Fix harmless LC_COLLATE[_MASK] confusion.

commit   : 1cc73d15ea58ddc15f91269493811cef99987cb8    
  
author   : Thomas Munro <[email protected]>    
date     : Mon, 19 Aug 2024 21:21:03 +1200    
  
committer: Thomas Munro <[email protected]>    
date     : Mon, 19 Aug 2024 21:21:03 +1200    

Click here for diff

Commit ca051d8b101 called newlocale(LC_COLLATE, ...) instead of  
newlocale(LC_COLLATE_MASK, ...), in code reached only on FreeBSD.  They  
have the same value on that OS, explaining why it worked.  Fix.  
  
Back-patch to 14, where ca051d8b101 landed.  

M src/backend/utils/adt/pg_locale.c

Fix more holes with SLRU code in need of int64 for segment numbers

commit   : b7935bc10b78f3a44567d304df87fad3d53102dd    
  
author   : Michael Paquier <[email protected]>    
date     : Mon, 19 Aug 2024 12:34:52 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Mon, 19 Aug 2024 12:34:52 +0900    

Click here for diff

This is a continuation of c9e24573905b, containing changes included into  
the proposed patch that have been missed in the actual commit.  I have  
managed to miss these diffs while doing a rebase of the original patch.  
  
Thanks to Noah Misch, Peter Eisentraut and Alexander Korotkov for the  
pokes.  
  
Discussion: https://postgr.es/m/[email protected]  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 17  

M src/backend/access/transam/multixact.c
M src/backend/access/transam/slru.c

Search for SLRU page only in its own bank

commit   : fad0da271e006015fcc25724aca2871d6dec04f5    
  
author   : Alvaro Herrera <[email protected]>    
date     : Sun, 18 Aug 2024 20:49:57 -0400    
  
committer: Alvaro Herrera <[email protected]>    
date     : Sun, 18 Aug 2024 20:49:57 -0400    

Click here for diff

One of the two slot scans in SlruSelectLRUPage was not walking only the  
slots in the specific bank where the buffer could be; change it to do  
that.  
  
Oversight in 53c2a97a9266.  
  
Author: Sergey Sargsyan <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  

M src/backend/access/transam/slru.c

ci: Upgrade MacPorts version to 2.10.1.

commit   : 4b6aa0cffc04e8a5e1e876f3ba8cb11bd61ac40b    
  
author   : Thomas Munro <[email protected]>    
date     : Mon, 19 Aug 2024 11:47:37 +1200    
  
committer: Thomas Munro <[email protected]>    
date     : Mon, 19 Aug 2024 11:47:37 +1200    

Click here for diff

MacPorts version 2.9.3 started failing in our ci_macports_packages.sh  
script, for reasons not fully determined, but plausibly linked to the  
release of 2.10.1.  2.10.1 seems to work, so let's switch to it.  
  
Back-patch to 15, where CI began.  
  
Reported-by: Peter Eisentraut <[email protected]>  
Discussion: https://postgr.es/m/81f104e8-f0a9-43c0-85bd-2bbbf590a5b8%40eisentraut.org  

M src/tools/ci/ci_macports_packages.sh

Fix DROP DATABASE for databases with many ACLs

commit   : d1da80115004af2a2093479556b45d2fbcfcd571    
  
author   : Tomas Vondra <[email protected]>    
date     : Mon, 19 Aug 2024 00:04:41 +0200    
  
committer: Tomas Vondra <[email protected]>    
date     : Mon, 19 Aug 2024 00:04:41 +0200    

Click here for diff

Commit c66a7d75e652 modified DROP DATABASE so that if interrupted, the  
database is known to be in an invalid state and can only be dropped.  
This is done by setting a flag using an in-place update, so that it's  
not lost in case of rollback.  
  
For databases with many ACLs, this may however fail like this:  
  
  ERROR:  wrong tuple length  
  
This happens because with many ACLs, the pg_database.datacl attribute  
gets TOASTed. The dropdb() code reads the tuple from the syscache, which  
means it's detoasted. But the in-place update expects the tuple length  
to match the on-disk tuple.  
  
Fixed by reading the tuple from the catalog directly, not from syscache.  
  
Report and fix by Ayush Tiwari. Backpatch to 12. The DROP DATABASE fix  
was backpatched to 11, but 11 is EOL at this point.  
  
Reported-by: Ayush Tiwari  
Author: Ayush Tiwari  
Reviewed-by: Tomas Vondra  
Backpatch-through: 12  
Discussion: https://postgr.es/m/CAJTYsWWNkCt+-UnMhg=BiCD3Mh8c2JdHLofPxsW3m2dkDFw8RA@mail.gmail.com  

M src/backend/commands/dbcommands.c

docs: fix incorrect plpgsql error message

commit   : a95f13cbfb1f11955c11972ee41cd5c065246d4b    
  
author   : Bruce Momjian <[email protected]>    
date     : Fri, 16 Aug 2024 22:50:54 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Fri, 16 Aug 2024 22:50:54 -0400    

Click here for diff

Change "$1" to "username".  
  
Reported-by: [email protected]  
  
Discussion: https://postgr.es/m/[email protected]  
  
Backpatch-through: 12  

M doc/src/sgml/plpgsql.sgml

doc PG 17 relnotes: fix incorrect reference to huge_page_status

commit   : 35af4bd9519bbed6796f291e2d35cf3feffd4a86    
  
author   : Bruce Momjian <[email protected]>    
date     : Fri, 16 Aug 2024 13:11:23 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Fri, 16 Aug 2024 13:11:23 -0400    

Click here for diff

Reported-by: Justin Pryzby  
  
Discussion: https://postgr.es/m/ZrTOaaxuG3JRSvwM@pryzbyj2023  
  
Backpatch-through: 17 only  

M doc/src/sgml/release-17.sgml

doc PG 17 relnotes: improve text for pg_walfile_name*()

commit   : 6b84ae65fb9af2152ac26675635459069647d555    
  
author   : Bruce Momjian <[email protected]>    
date     : Fri, 16 Aug 2024 13:01:34 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Fri, 16 Aug 2024 13:01:34 -0400    

Click here for diff

Reported-by: Yugo Nagata  
  
Discussion: https://postgr.es/m/[email protected]  
  
Backpatch-through: 17 only  

M doc/src/sgml/release-17.sgml

doc PG 17 relnotes: fix pg_statistic_ext.stxstattarget ref.

commit   : 0ed4a84b7cb632d23cec3b8fc92775c91ae3af7f    
  
author   : Bruce Momjian <[email protected]>    
date     : Fri, 16 Aug 2024 12:53:02 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Fri, 16 Aug 2024 12:53:02 -0400    

Click here for diff

Reported-by: Kisoon Kwon  
  
Discussion: https://postgr.es/m/CAGOrKoVhjP_AeKGgzxWjRwdPqKL5Y-3TcVZoaz0bVTPwU8Yz+g@mail.gmail.com  
  
Backpatch-through: 17 only  

M doc/src/sgml/release-17.sgml

Remove incidental md5() function use from test

commit   : 47b47a5617fa0c49e5d8788d5f1150c21485f3ff    
  
author   : Peter Eisentraut <[email protected]>    
date     : Fri, 16 Aug 2024 17:14:32 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Fri, 16 Aug 2024 17:14:32 +0200    

Click here for diff

To allow test to pass in OpenSSL FIPS mode, similar to 657f5f223e, for  
a new test that has been added since.  
  
Reviewed-by: Tomas Vondra <[email protected]>  
Discussion: https://www.postgresql.org/message-id/[email protected]  

M contrib/pageinspect/expected/brin.out
M contrib/pageinspect/sql/brin.sql

Relax fsyncing at end of a bulk load that was not WAL-logged

commit   : 68f199cea3b190ba0bc2c83d92d17e7e1792a141    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Fri, 16 Aug 2024 14:45:37 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Fri, 16 Aug 2024 14:45:37 +0300    

Click here for diff

And improve the comments.  
  
Backpatch to v17 where this was introduced.  
  
Reviewed-by: Noah Misch  
Discussion: https://www.postgresql.org/message-id/[email protected]  

M src/backend/storage/smgr/bulk_write.c

Fix doc typo: unicode_assigned() return type.

commit   : 225483238d3e46669c9d73f8faead7aff567c856    
  
author   : Jeff Davis <[email protected]>    
date     : Wed, 14 Aug 2024 19:05:39 -0700    
  
committer: Jeff Davis <[email protected]>    
date     : Wed, 14 Aug 2024 19:05:39 -0700    

Click here for diff

Reported-by: Hironobu SUZUKI  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 17  

M doc/src/sgml/func.sgml

Use errmsg_internal for debug messages

commit   : 253c49e07599b8df5a51af69035f7d136de55c3a    
  
author   : Peter Eisentraut <[email protected]>    
date     : Tue, 13 Aug 2024 10:01:49 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Tue, 13 Aug 2024 10:01:49 +0200    

Click here for diff

Some newer code was applying this inconsistently.  

M src/backend/postmaster/walsummarizer.c

Fix creation of partition descriptor during concurrent detach+drop

commit   : 0820f80622ed415a88d2c79b04d292ae79023f50    
  
author   : Alvaro Herrera <[email protected]>    
date     : Mon, 12 Aug 2024 18:17:56 -0400    
  
committer: Alvaro Herrera <[email protected]>    
date     : Mon, 12 Aug 2024 18:17:56 -0400    

Click here for diff

If a partition undergoes DETACH CONCURRENTLY immediately followed by  
DROP, this could cause a problem for a concurrent transaction  
recomputing the partition descriptor when running a prepared statement,  
because it tries to dereference a pointer to a tuple that's not found in  
a catalog scan.  
  
The existing retry logic added in commit dbca3469ebf8 is sufficient to  
cope with the overall problem, provided we don't try to dereference a  
non-existant heap tuple.  
  
Arguably, the code in RelationBuildPartitionDesc() has been wrong all  
along, since no check was added in commit 898e5e3290a7 against receiving  
a NULL tuple from the catalog scan; that bug has only become  
user-visible with DETACH CONCURRENTLY which was added in branch 14.  
Therefore, even though there's no known mechanism to cause a crash  
because of this, backpatch the addition of such a check to all supported  
branches.  In branches prior to 14, this would cause the code to fail  
with a "missing relpartbound for relation XYZ" error instead of  
crashing; that's okay, because there are no reports of such behavior  
anyway.  
  
Author: Kuntal Ghosh <[email protected]>  
Reviewed-by: Junwang Zhao <[email protected]>  
Reviewed-by: Tender Wang <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  

M src/backend/partitioning/partdesc.c

Log more info when wait-for-catchup tests time out.

commit   : e57296ed4867b3a3734db9ca621223c30eebb90d    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 12 Aug 2024 13:18:36 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 12 Aug 2024 13:18:36 -0400    

Click here for diff

Cluster.pm's wait_for_catchup and allied subroutines don't provide  
enough information to diagnose the problem when a wait times out.  
In hopes of debugging some intermittent buildfarm failures, let's  
dump the ending state of the relevant system view when that happens.  
  
Add this to v17 too, but not stable branches.  
  
Discussion: https://postgr.es/m/[email protected]  

M src/test/perl/PostgreSQL/Test/Cluster.pm

Suppress Coverity warnings about Asserts in get_name_for_var_field.

commit   : aed881386aa6a6a542e46d14d3505e4e6f9310a0    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 11 Aug 2024 12:24:56 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 11 Aug 2024 12:24:56 -0400    

Click here for diff

Coverity thinks dpns->plan could be null at these points.  That  
shouldn't really be possible, but it's easy enough to modify the  
Asserts so they'd not core-dump if it were true.  
  
These are new in b919a97a6.  Back-patch to v13; the v12 version  
of the patch didn't have these Asserts.  

M src/backend/utils/adt/ruleutils.c

Allow adjusting session_authorization and role in parallel workers.

commit   : 2b8d33f66c134b5f1b0a94a7e40af2fbb6a086b7    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 10 Aug 2024 15:51:28 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 10 Aug 2024 15:51:28 -0400    

Click here for diff

The code intends to allow GUCs to be set within parallel workers  
via function SET clauses, but not otherwise.  However, doing so fails  
for "session_authorization" and "role", because the assign hooks for  
those attempt to set the subsidiary "is_superuser" GUC, and that call  
falls foul of the "not otherwise" prohibition.  We can't switch to  
using GUC_ACTION_SAVE for this, so instead add a new GUC variable  
flag GUC_ALLOW_IN_PARALLEL to mark is_superuser as being safe to set  
anyway.  (This is okay because is_superuser has context PGC_INTERNAL  
and thus only hard-wired calls can change it.  We'd need more thought  
before applying the flag to other GUCs; but maybe there are other  
use-cases.)  This isn't the prettiest fix perhaps, but other  
alternatives we thought of would be much more invasive.  
  
While here, correct a thinko in commit 059de3ca4: when rejecting  
a GUC setting within a parallel worker, we should return 0 not -1  
if the ereport doesn't longjmp.  (This seems to have no consequences  
right now because no caller cares, but it's inconsistent.)  Improve  
the comments to try to forestall future confusion of the same kind.  
  
Despite the lack of field complaints, this seems worth back-patching.  
Thanks to Nathan Bossart for the idea to invent a new flag,  
and for review.  
  
Discussion: https://postgr.es/m/[email protected]  

M src/backend/utils/misc/guc.c
M src/backend/utils/misc/guc_tables.c
M src/include/utils/guc.h
M src/test/regress/expected/select_parallel.out
M src/test/regress/sql/select_parallel.sql

Lower minimum maintenance_work_mem to 64kB

commit   : 2eda3df9ad532a051976937cfc17d6c52bbdacd6    
  
author   : John Naylor <[email protected]>    
date     : Tue, 6 Aug 2024 20:38:33 +0700    
  
committer: John Naylor <[email protected]>    
date     : Tue, 6 Aug 2024 20:38:33 +0700    

Click here for diff

Since the introduction of TID store, vacuum uses far less memory in  
the common case than in versions 16 and earlier. Invoking multiple  
rounds of index vacuuming in turn requires a much larger table. It'd  
be a good idea anyway to cover this case in regression testing, and a  
lower limit is less painful for slow buildfarm animals. The reason to  
do it now is to re-enable coverage of the bugfix in commit 83c39a1f7f.  
  
For consistency, give autovacuum_work_mem the same treatment.  
  
Suggested by Andres Freund  
Tested by Melanie Plageman  
Backpatch to v17, where TID store was introduced  
  
Discussion: https://postgr.es/m/[email protected]  
Discussion: https://postgr.es/m/20240722164745.fvaoh6g6zprisqgp%40awork3.anarazel.de  

M src/backend/postmaster/autovacuum.c
M src/backend/utils/misc/guc_tables.c
M src/backend/utils/misc/postgresql.conf.sample

doc: Fix name of CRC algorithm in "Reliability" section.

commit   : 6bec76faa4bd7eda34f213f0831d77506d66147c    
  
author   : Nathan Bossart <[email protected]>    
date     : Fri, 9 Aug 2024 10:52:37 -0500    
  
committer: Nathan Bossart <[email protected]>    
date     : Fri, 9 Aug 2024 10:52:37 -0500    

Click here for diff

This section claims we use CRC-32 for WAL records and two-phase  
state files, but we've actually used CRC-32C since v9.5 (commit  
5028f22f6e).  Fix that.  
  
Reviewed-by: Robert Haas  
Discussion: https://postgr.es/m/ZrUFpLP-w2zTAHqq%40nathan  
Backpatch-through: 12  

M doc/src/sgml/wal.sgml

Fix "failed to find plan for subquery/CTE" errors in EXPLAIN.

commit   : 81a12a4477533d7722bd6b6dac88b0e798f8e85b    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 9 Aug 2024 11:21:39 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 9 Aug 2024 11:21:39 -0400    

Click here for diff

To deparse a reference to a field of a RECORD-type output of a  
subquery, EXPLAIN normally digs down into the subquery's plan to try  
to discover exactly which anonymous RECORD type is meant.  However,  
this can fail if the subquery has been optimized out of the plan  
altogether on the grounds that no rows could pass the WHERE quals,  
which has been possible at least since 3fc6e2d7f.  There isn't  
anything remaining in the plan tree that would help us, so fall back  
to printing the field name as "fN" for the N'th column of the record.  
(This will actually be the right thing some of the time, since it  
matches the column names we assign to RowExprs.)  
  
In passing, fix a comment typo in create_projection_plan, which  
I noticed while experimenting with an alternative fix for this.  
  
Per bug #18576 from Vasya B.  Back-patch to all supported branches.  
  
Richard Guo and Tom Lane  
  
Discussion: https://postgr.es/m/[email protected]  

M src/backend/optimizer/plan/createplan.c
M src/backend/utils/adt/ruleutils.c
M src/test/regress/expected/rowtypes.out
M src/test/regress/sql/rowtypes.sql

Refuse ATTACH of a table referenced by a foreign key

commit   : 344f9f5e2b181331ead4b7bcd792216ecc5f2946    
  
author   : Alvaro Herrera <[email protected]>    
date     : Thu, 8 Aug 2024 19:35:13 -0400    
  
committer: Alvaro Herrera <[email protected]>    
date     : Thu, 8 Aug 2024 19:35:13 -0400    

Click here for diff

Trying to attach a table as a partition which is already on the  
referenced side of a foreign key on the partitioned table that it is  
being attached to, leads to strange behavior: we try to clone the  
foreign key from the parent to the partition, but this new FK points to  
the partition itself, and the mix of pg_constraint rows and triggers  
doesn't behave well.  
  
Rather than trying to untangle the mess (which might be possible given  
sufficient time), I opted to forbid the ATTACH.  This doesn't seem a  
problematic restriction, given that we already fail to create the  
foreign key if you do it the other way around, that is, having the  
partition first and the FK second.  
  
Backpatch to all supported branches.  
  
Reported-by: Alexander Lakhin <[email protected]>  
Reviewed-by: Tender Wang <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  

M src/backend/commands/tablecmds.c
M src/test/regress/expected/foreign_key.out
M src/test/regress/sql/foreign_key.sql

Refactor error messages to reduce duplication

commit   : 28b953f26343105ebf3a1a212092e2c3c0bb0914    
  
author   : Alvaro Herrera <[email protected]>    
date     : Thu, 8 Aug 2024 15:17:11 -0400    
  
committer: Alvaro Herrera <[email protected]>    
date     : Thu, 8 Aug 2024 15:17:11 -0400    

Click here for diff

I also took the liberty of changing  
  
	errmsg("COPY DEFAULT only available using COPY FROM")  
to  
	errmsg("COPY %s cannot be used with %s", "DEFAULT", "COPY TO")  
  
because the original wording is unlike all other messages that indicate  
option incompatibility.  This message was added by commit 9f8377f7a279  
(16-era), in whose development thread there was no discussion on this  
point.  
  
Backpatch to 17.  

M src/backend/commands/copy.c
M src/backend/commands/copyfrom.c
M src/backend/commands/copyto.c
M src/test/regress/expected/copy2.out

Fix pg_rewind debug output to print the source timeline history

commit   : a7bf3e66852743503eb32cb38d93c0740dcca00a    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Thu, 8 Aug 2024 10:20:25 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Thu, 8 Aug 2024 10:20:25 +0300    

Click here for diff

getTimelineHistory() is called twice, to read the source and the  
target timeline history files. However, the loop to print the file  
with the --debug option used the wrong variable when dealing with the  
source. As a result, the source's history was always printed as empty.  
  
Spotted while debugging bug #18575, but this does not fix that bug,  
just the debugging output. Backpatch to all supported versions.  
  
Discussion: https://www.postgresql.org/message-id/[email protected]  

M src/bin/pg_rewind/pg_rewind.c

Revert ECPG's use of pnstrdup()

commit   : e9e05c655069139ff1533497073d980994dde290    
  
author   : Peter Eisentraut <[email protected]>    
date     : Wed, 7 Aug 2024 09:21:07 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Wed, 7 Aug 2024 09:21:07 +0200    

Click here for diff

Commit 0b9466fce added a dependency on fe_memutils' pnstrdup() inside  
informix.c.  This adds an exit() path in a library, which we don't  
want.  (Unlike libpq, the ecpg libraries don't have an automated check  
for that, but it makes sense to keep them to a similar standard.)  The  
ecpg code can already handle failure results from the *strdup() call  
by itself.  
  
Author: Jacob Champion <[email protected]>  
Discussion: https://www.postgresql.org/message-id/CAOYmi+=pg=W5L1h=3MEP_EB24jaBu2FyATrLXqQHGe7cpuvwyg@mail.gmail.com  

M src/interfaces/ecpg/compatlib/informix.c

Fix names of "Visual Studio" and Meson in a documentation sentence.

commit   : 75345f6985f2d202e43b4fd5ad9e73908c257445    
  
author   : Noah Misch <[email protected]>    
date     : Wed, 7 Aug 2024 11:43:08 -0700    
  
committer: Noah Misch <[email protected]>    
date     : Wed, 7 Aug 2024 11:43:08 -0700    

Click here for diff

Commit 3cffe7946c268be91a340ec9a27081cb93d67d35 missed this.  Back-patch  
to v17, which introduced this.  
  
Discussion: https://postgr.es/m/CAJ7c6TM7ct0EjoCQaLSVYoxxnEw4xCUFebWj77GktWsqEdyCtQ@mail.gmail.com  

M doc/src/sgml/installation.sgml

Fix edge case in plpgsql's make_callstmt_target().

commit   : 0dd33a6fcab746d518cec56d2bc0d8ec0edffd32    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 7 Aug 2024 12:54:39 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 7 Aug 2024 12:54:39 -0400    

Click here for diff

If the plancache entry for the CALL statement is already stale,  
it's possible for us to fetch an old procedure OID out of it,  
and then fail with "cache lookup failed for function NNN".  
In ordinary usage this never happens because make_callstmt_target  
is called just once immediately after building the plancache  
entry.  It can be forced however by setting up an erroneous CALL  
(that causes make_callstmt_target itself to report an error),  
then dropping/recreating the target procedure, then repeating  
the erroneous CALL.  
  
To fix, use SPI_plan_get_cached_plan() to fetch the plancache's  
plan, rather than assuming we can use SPI_plan_get_plan_sources().  
This shouldn't add any noticeable overhead in the normal case,  
and in the stale-plan case we'd have had to replan anyway a little  
further down.  
  
The other callers of SPI_plan_get_plan_sources() seem OK, because  
either they don't need up-to-date plans or they know that the  
query was just (re) planned.  But add some commentary in hopes  
of not falling into this trap again.  
  
Per bug #18574 from Song Hongyu.  Back-patch to v14 where this coding  
was introduced.  (Older branches have comparable code, but it's run  
after any required replanning, so there's no issue.)  
  
Discussion: https://postgr.es/m/[email protected]  

M src/backend/executor/spi.c
M src/pl/plpgsql/src/pl_exec.c

Refactor/reword some error messages to avoid duplicates

commit   : 899f39ea25f2ee63a0c557f3908e15b280a4367a    
  
author   : Alvaro Herrera <[email protected]>    
date     : Wed, 7 Aug 2024 11:30:36 -0400    
  
committer: Alvaro Herrera <[email protected]>    
date     : Wed, 7 Aug 2024 11:30:36 -0400    

Click here for diff

Also, remove brackets around "EMPTY [ ARRAY ]".  An error message is  
not the place to state that a keyword is optional.  
  
Backpatch to 17.  

M src/backend/executor/execExprInterp.c
M src/backend/parser/parse_expr.c
M src/backend/parser/parse_jsontable.c
M src/test/regress/expected/sqljson_jsontable.out
M src/test/regress/expected/sqljson_queryfuncs.out

Make fallback MD5 implementation thread-safe on big-endian systems

commit   : ffac8ac48e409bbc7c2d9a4b37a1c39908ca24eb    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Wed, 7 Aug 2024 10:43:52 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Wed, 7 Aug 2024 10:43:52 +0300    

Click here for diff

Replace a static scratch buffer with a local variable, because a  
static buffer makes the function not thread-safe. This function is  
used in client-code in libpq, so it needs to be thread-safe. It was  
until commit b67b57a966, which replaced the implementation with the  
one from pgcrypto.  
  
Backpatch to v14, where we switched to the new implementation.  
  
Reviewed-by: Robert Haas, Michael Paquier  
Discussion: https://www.postgresql.org/message-id/[email protected]  

M src/common/md5.c

Stamp 17beta3.

commit   : b18b3a8150dbb150124bd345e000d6dc92f3d6dd    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 5 Aug 2024 16:03:01 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 5 Aug 2024 16:03:01 -0400    

Click here for diff

M configure
M configure.ac
M meson.build

Restrict accesses to non-system views and foreign tables during pg_dump.

commit   : fdf218f1d52b2c93145f16b28b8374703ae4ef19    
  
author   : Masahiko Sawada <[email protected]>    
date     : Mon, 5 Aug 2024 06:05:30 -0700    
  
committer: Masahiko Sawada <[email protected]>    
date     : Mon, 5 Aug 2024 06:05:30 -0700    

Click here for diff

When pg_dump retrieves the list of database objects and performs the  
data dump, there was possibility that objects are replaced with others  
of the same name, such as views, and access them. This vulnerability  
could result in code execution with superuser privileges during the  
pg_dump process.  
  
This issue can arise when dumping data of sequences, foreign  
tables (only 13 or later), or tables registered with a WHERE clause in  
the extension configuration table.  
  
To address this, pg_dump now utilizes the newly introduced  
restrict_nonsystem_relation_kind GUC parameter to restrict the  
accesses to non-system views and foreign tables during the dump  
process. This new GUC parameter is added to back branches too, but  
these changes do not require cluster recreation.  
  
Back-patch to all supported branches.  
  
Reviewed-by: Noah Misch  
Security: CVE-2024-7348  
Backpatch-through: 12  

M contrib/postgres_fdw/expected/postgres_fdw.out
M contrib/postgres_fdw/sql/postgres_fdw.sql
M doc/src/sgml/config.sgml
M doc/src/sgml/ref/pg_dump.sgml
M src/backend/foreign/foreign.c
M src/backend/optimizer/plan/createplan.c
M src/backend/optimizer/util/plancat.c
M src/backend/rewrite/rewriteHandler.c
M src/backend/tcop/postgres.c
M src/backend/utils/misc/guc_tables.c
M src/bin/pg_dump/pg_dump.c
M src/include/tcop/tcopprot.h
M src/include/utils/guc_hooks.h
M src/test/regress/expected/create_view.out
M src/test/regress/sql/create_view.sql

Translation updates

commit   : 91099bb287ff71c970c72b81e6a190d80a92e760    
  
author   : Peter Eisentraut <[email protected]>    
date     : Mon, 5 Aug 2024 12:12:32 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Mon, 5 Aug 2024 12:12:32 +0200    

Click here for diff

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

M src/backend/po/de.po
M src/backend/po/es.po
M src/backend/po/ja.po
M src/backend/po/pt_BR.po
M src/backend/po/sv.po
M src/bin/initdb/po/es.po
M src/bin/initdb/po/fr.po
M src/bin/initdb/po/pt_BR.po
M src/bin/initdb/po/sv.po
M src/bin/initdb/po/zh_CN.po
M src/bin/pg_amcheck/po/es.po
M src/bin/pg_amcheck/po/fr.po
M src/bin/pg_amcheck/po/sv.po
M src/bin/pg_archivecleanup/po/es.po
M src/bin/pg_archivecleanup/po/fr.po
M src/bin/pg_archivecleanup/po/ka.po
M src/bin/pg_archivecleanup/po/sv.po
M src/bin/pg_archivecleanup/po/zh_CN.po
M src/bin/pg_basebackup/po/de.po
M src/bin/pg_basebackup/po/ja.po
M src/bin/pg_basebackup/po/ka.po
M src/bin/pg_basebackup/po/sv.po
M src/bin/pg_checksums/po/es.po
M src/bin/pg_checksums/po/fr.po
M src/bin/pg_checksums/po/ka.po
M src/bin/pg_checksums/po/sv.po
M src/bin/pg_combinebackup/po/LINGUAS
M src/bin/pg_combinebackup/po/de.po
A src/bin/pg_combinebackup/po/es.po
M src/bin/pg_combinebackup/po/ja.po
M src/bin/pg_combinebackup/po/ka.po
A src/bin/pg_combinebackup/po/sv.po
M src/bin/pg_config/po/es.po
M src/bin/pg_config/po/fr.po
M src/bin/pg_config/po/ka.po
M src/bin/pg_config/po/sv.po
M src/bin/pg_controldata/po/es.po
M src/bin/pg_controldata/po/fr.po
M src/bin/pg_controldata/po/ka.po
M src/bin/pg_controldata/po/sv.po
M src/bin/pg_controldata/po/zh_TW.po
M src/bin/pg_ctl/po/es.po
M src/bin/pg_ctl/po/ja.po
M src/bin/pg_ctl/po/ka.po
M src/bin/pg_ctl/po/sv.po
M src/bin/pg_dump/po/es.po
M src/bin/pg_dump/po/ka.po
M src/bin/pg_dump/po/sv.po
M src/bin/pg_resetwal/po/es.po
M src/bin/pg_resetwal/po/ka.po
M src/bin/pg_resetwal/po/sv.po
M src/bin/pg_rewind/po/es.po
M src/bin/pg_rewind/po/sv.po
M src/bin/pg_test_fsync/po/es.po
M src/bin/pg_test_fsync/po/ka.po
M src/bin/pg_test_fsync/po/sv.po
M src/bin/pg_test_timing/po/es.po
M src/bin/pg_test_timing/po/ka.po
M src/bin/pg_test_timing/po/sv.po
M src/bin/pg_upgrade/po/es.po
M src/bin/pg_upgrade/po/sv.po
M src/bin/pg_verifybackup/po/es.po
M src/bin/pg_verifybackup/po/ka.po
M src/bin/pg_verifybackup/po/sv.po
M src/bin/pg_waldump/po/es.po
M src/bin/pg_waldump/po/ka.po
M src/bin/pg_waldump/po/sv.po
M src/bin/pg_walsummary/po/LINGUAS
A src/bin/pg_walsummary/po/es.po
M src/bin/pg_walsummary/po/ka.po
A src/bin/pg_walsummary/po/sv.po
M src/bin/psql/po/cs.po
M src/bin/psql/po/el.po
M src/bin/psql/po/es.po
M src/bin/psql/po/it.po
M src/bin/psql/po/ja.po
M src/bin/psql/po/ru.po
M src/bin/psql/po/sv.po
M src/bin/psql/po/uk.po
M src/bin/scripts/po/es.po
M src/bin/scripts/po/fr.po
M src/bin/scripts/po/ko.po
M src/bin/scripts/po/pt_BR.po
M src/bin/scripts/po/sv.po
M src/bin/scripts/po/zh_CN.po
M src/interfaces/ecpg/ecpglib/po/es.po
M src/interfaces/ecpg/ecpglib/po/sv.po
M src/interfaces/ecpg/preproc/po/es.po
M src/interfaces/ecpg/preproc/po/fr.po
M src/interfaces/ecpg/preproc/po/ja.po
M src/interfaces/ecpg/preproc/po/sv.po
M src/interfaces/libpq/po/es.po
M src/interfaces/libpq/po/fr.po
M src/interfaces/libpq/po/sv.po
M src/pl/plperl/po/es.po
M src/pl/plperl/po/sv.po
M src/pl/plpgsql/src/po/es.po
M src/pl/plpgsql/src/po/sv.po
M src/pl/plpython/po/es.po
M src/pl/plpython/po/sv.po
M src/pl/tcl/po/es.po
M src/pl/tcl/po/ja.po
M src/pl/tcl/po/sv.po

Fix name of "Visual Studio" in documentation.

commit   : c175c9202d730df366f21c1aaac1a165bb98c065    
  
author   : Noah Misch <[email protected]>    
date     : Fri, 2 Aug 2024 12:49:56 -0700    
  
committer: Noah Misch <[email protected]>    
date     : Fri, 2 Aug 2024 12:49:56 -0700    

Click here for diff

Back-patch to v17, which introduced this.  
  
Aleksander Alekseev  
  
Discussion: https://postgr.es/m/CAJ7c6TM7ct0EjoCQaLSVYoxxnEw4xCUFebWj77GktWsqEdyCtQ@mail.gmail.com  

M doc/src/sgml/installation.sgml

Fix NLS file reference in pg_createsubscriber

commit   : ca264553485e3a4e5955e108e571baf0c68c641d    
  
author   : Alvaro Herrera <[email protected]>    
date     : Fri, 2 Aug 2024 12:05:38 -0400    
  
committer: Alvaro Herrera <[email protected]>    
date     : Fri, 2 Aug 2024 12:05:38 -0400    

Click here for diff

pg_createsubscriber is referring to a non-existent message translation  
file, causing NLS to not work correctly. This command should use the  
same file as pg_basebackup.  
  
Author: Kyotaro Horiguchi <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  

M src/bin/pg_basebackup/pg_createsubscriber.c

pg_createsubscriber: Fix bogus error message

commit   : 8c6ba6e6a834030c80d7e0d2fa28101e9e17a993    
  
author   : Alvaro Herrera <[email protected]>    
date     : Fri, 2 Aug 2024 12:01:10 -0400    
  
committer: Alvaro Herrera <[email protected]>    
date     : Fri, 2 Aug 2024 12:01:10 -0400    

Click here for diff

Also some desultory style improvement  

M src/bin/pg_basebackup/pg_createsubscriber.c

pg_createsubscriber: Rename option --socket-directory to --socketdir

commit   : 83737ef89c69dcf61ecc40cc11aac80e78f46c5a    
  
author   : Peter Eisentraut <[email protected]>    
date     : Thu, 1 Aug 2024 12:09:56 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Thu, 1 Aug 2024 12:09:56 +0200    

Click here for diff

For consistency with the equivalent option in pg_upgrade.  
  
Reviewed-by: Hayato Kuroda <[email protected]>  
Reviewed-by: Euler Taveira <[email protected]>  
Discussion: https://www.postgresql.org/message-id/flat/1ed82b9b-8e20-497d-a2f8-aebdd793d595%40eisentraut.org  

M doc/src/sgml/ref/pg_createsubscriber.sgml
M src/bin/pg_basebackup/pg_createsubscriber.c
M src/bin/pg_basebackup/t/040_pg_createsubscriber.pl

Update comment in portal.h.

commit   : eb39497eed2983caff4a2bb808c8bc1e378b4f68    
  
author   : Etsuro Fujita <[email protected]>    
date     : Thu, 1 Aug 2024 17:45:00 +0900    
  
committer: Etsuro Fujita <[email protected]>    
date     : Thu, 1 Aug 2024 17:45:00 +0900    

Click here for diff

We store tuples into the portal's tuple store for a PORTAL_ONE_MOD_WITH  
query as well.  
  
Back-patch to all supported branches.  
  
Reviewed by Andy Fan.  
  
Discussion: https://postgr.es/m/CAPmGK14HVYBZYZtHabjeCd-e31VT%3Dwx6rQNq8QfehywLcpZ2Hw%40mail.gmail.com  

M src/include/utils/portal.h

Revert "Allow parallel workers to cope with a newly-created session user ID."

commit   : 630b81d5cc00fa8bf1cb7e861a3778ed3080e621    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 31 Jul 2024 20:54:31 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 31 Jul 2024 20:54:31 -0400    

Click here for diff

This reverts commit 5887dd4894db5ac1c6411615160555ac6e57e49b.  
  
Some buildfarm animals are failing with "cannot change  
"client_encoding" during a parallel operation".  It looks like  
assign_client_encoding is unhappy at being asked to roll back a  
client_encoding setting after a parallel worker encounters a  
failure.  There must be more to it though: why didn't I see this  
during local testing?  In any case, it's clear that moving the  
RestoreGUCState() call is not as side-effect-free as I thought.  
Given that the bug f5f30c22e intended to fix has gone unreported  
for years, it's not something that's urgent to fix; I'm not  
willing to risk messing with it further with only days to our  
next release wrap.  

M src/backend/access/transam/parallel.c
M src/backend/commands/variable.c
M src/test/regress/expected/select_parallel.out
M src/test/regress/sql/select_parallel.sql

Allow parallel workers to cope with a newly-created session user ID.

commit   : 5887dd4894db5ac1c6411615160555ac6e57e49b    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 31 Jul 2024 18:54:10 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 31 Jul 2024 18:54:10 -0400    

Click here for diff

Parallel workers failed after a sequence like  
	BEGIN;  
	CREATE USER foo;  
	SET SESSION AUTHORIZATION foo;  
because check_session_authorization could not see the uncommitted  
pg_authid row for "foo".  This is because we ran RestoreGUCState()  
in a separate transaction using an ordinary just-created snapshot.  
The same disease afflicts any other GUC that requires catalog lookups  
and isn't forgiving about the lookups failing.  
  
To fix, postpone RestoreGUCState() into the worker's main transaction  
after we've set up a snapshot duplicating the leader's.  This affects  
check_transaction_isolation and check_transaction_deferrable, which  
think they should only run during transaction start.  Make them  
act like check_transaction_read_only, which already knows it should  
silently accept the value when InitializingParallelWorker.  
  
Per bug #18545 from Andrey Rachitskiy.  Back-patch to all  
supported branches, because this has been wrong for awhile.  
  
Discussion: https://postgr.es/m/[email protected]  

M src/backend/access/transam/parallel.c
M src/backend/commands/variable.c
M src/test/regress/expected/select_parallel.out
M src/test/regress/sql/select_parallel.sql

Doc: mention executor memory usage for enable_partitionwise* GUCs

commit   : 3256722d7b7ff64918a0e5fdf6140de355147fe6    
  
author   : David Rowley <[email protected]>    
date     : Thu, 1 Aug 2024 01:26:16 +1200    
  
committer: David Rowley <[email protected]>    
date     : Thu, 1 Aug 2024 01:26:16 +1200    

Click here for diff

Prior to this commit, the docs for enable_partitionwise_aggregate and  
enable_partitionwise_join mentioned the additional overheads enabling  
these causes for the query planner, but they mentioned nothing about the  
possible surge in work_mem-consuming executor nodes that could end up in  
the final plan.  Dimitrios reported the OOM killer intervened on his  
query as a result of using enable_partitionwise_aggregate=on.  
  
Here we adjust the docs to mention the possible increase in the number of  
work_mem-consuming executor nodes that can appear in the final plan as a  
result of enabling these GUCs.  
  
Reported-by: Dimitrios Apostolou  
Reviewed-by: Ashutosh Bapat  
Discussion: https://postgr.es/m/3603c380-d094-136e-e333-610914fb3e80%40gmx.net  
Discussion: https://postgr.es/m/CAApHDvoZ0_yqwPFEpb6h261L76BUpmh5GxBQq0LeRzQ5Jh3zzg@mail.gmail.com  
Backpatch-through: 12, oldest supported version  

M doc/src/sgml/config.sgml

Relax check for return value from second call of pg_strnxfrm().

commit   : 10fdc67f81972a03eee928a3b0ae226a78243fad    
  
author   : Jeff Davis <[email protected]>    
date     : Tue, 30 Jul 2024 16:23:20 -0700    
  
committer: Jeff Davis <[email protected]>    
date     : Tue, 30 Jul 2024 16:23:20 -0700    

Click here for diff

strxfrm() is not guaranteed to return the exact number of bytes needed  
to store the result; it may return a higher value.  
  
Discussion: https://postgr.es/m/[email protected]  
Reviewed-by: Heikki Linnakangas  
Backpatch-through: 16  

M src/backend/access/hash/hashfunc.c
M src/backend/utils/adt/pg_locale.c
M src/backend/utils/adt/varchar.c

Preserve tz when converting to jsonb timestamptz

commit   : 0d57dc2f9137de47534cc4db115e182e4093b945    
  
author   : Andrew Dunstan <[email protected]>    
date     : Tue, 30 Jul 2024 07:57:16 -0400    
  
committer: Andrew Dunstan <[email protected]>    
date     : Tue, 30 Jul 2024 07:57:16 -0400    

Click here for diff

This removes an inconsistency in the treatment of different datatypes by  
the jsonpath timestamp_tz() function. Conversions from data types that  
are not timestamp-aware, such as date and timestamp, are now treated  
consistently with conversion from those that are such as timestamptz.  
  
Author: David Wheeler  
Reviewed-by: Junwang Zhao and Jeevan Chalke  
  
Discussion: https://postgr.es/m/7DE080CE-6D8C-4794-9BD1-7D9699172FAB%40justatheory.com  
  
Backpatch to release 17.  

M src/backend/utils/adt/jsonpath_exec.c
M src/test/regress/expected/jsonb_jsonpath.out

pg_createsubscriber: Remove obsolete comment

commit   : 71795d1cb41b8144ae8b84bee1e60cfc8321cfd1    
  
author   : Peter Eisentraut <[email protected]>    
date     : Tue, 30 Jul 2024 12:21:20 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Tue, 30 Jul 2024 12:21:20 +0200    

Click here for diff

This comment should have been removed by commit b9639138262.  There is  
no replication slot check on the primary anymore.  
  
Author: Euler Taveira <[email protected]>  
Discussion: https://www.postgresql.org/message-id/[email protected]  

M src/bin/pg_basebackup/pg_createsubscriber.c

Stabilize xid_wraparound tests

commit   : 787ea8c9d812e5ae76b7a8981e5f93cee80c8a36    
  
author   : Andrew Dunstan <[email protected]>    
date     : Tue, 30 Jul 2024 06:17:48 -0400    
  
committer: Andrew Dunstan <[email protected]>    
date     : Tue, 30 Jul 2024 06:17:48 -0400    

Click here for diff

The tests had a race condition if autovacuum was set to off. Instead we  
create all the tables we are interested in with autovacuum disabled, so  
they are only ever touched when in danger of wraparound.  
  
Discussion: https://postgr.es/m/[email protected]  
  
Masahiko Sawada (slightly tweaked by me)  
  
Backpatch to release 17 where these tests were introduced.  

M src/test/modules/xid_wraparound/t/001_emergency_vacuum.pl
M src/test/modules/xid_wraparound/t/002_limits.pl
M src/test/modules/xid_wraparound/t/003_wraparounds.pl

pg_createsubscriber: Fix an unpredictable recovery wait time.

commit   : e5ba6a5ab62ce05e2a762b4d26f0fd0c52c7b521    
  
author   : Amit Kapila <[email protected]>    
date     : Tue, 30 Jul 2024 14:17:30 +0530    
  
committer: Amit Kapila <[email protected]>    
date     : Tue, 30 Jul 2024 14:17:30 +0530    

Click here for diff

The problem is that the tool is using the LSN returned by  
pg_create_logical_replication_slot() as recovery_target_lsn. This LSN is  
ahead of the current WAL position and the recovery waits until the  
publisher writes a WAL record to reach the target and ends the recovery.  
On idle systems, this wait time is unpredictable and could lead to failure  
in promoting the subscriber. To avoid that, insert a harmless WAL record.  
  
Reported-by: Alexander Lakhin and Tom Lane  
Diagnosed-by: Hayato Kuroda  
Author: Euler Taveira  
Reviewed-by: Hayato Kuroda, Amit Kapila  
Backpatch-through: 17  
Discussion: https://postgr.es/m/2377319.1719766794%40sss.pgh.pa.us  
Discussion: https://postgr.es/m/CA+TgmoYcY+Wb67NAwaHT7MvxCSeV86oSc+va9hHKaasE42ukyw@mail.gmail.com  

M src/bin/pg_basebackup/pg_createsubscriber.c

SQL/JSON: Fix casting for integer EXISTS columns in JSON_TABLE

commit   : f95c5090d975c3f552823f1f6895193d5da19825    
  
author   : Amit Langote <[email protected]>    
date     : Tue, 30 Jul 2024 10:12:23 +0900    
  
committer: Amit Langote <[email protected]>    
date     : Tue, 30 Jul 2024 10:12:23 +0900    

Click here for diff

The current method of coercing the boolean result value of  
JsonPathExists() to the target type specified for an EXISTS column,  
which is to call the type's input function via json_populate_type(),  
leads to an error when the target type is integer, because the  
integer input function doesn't recognize boolean literal values as  
valid.  
  
Instead use the boolean-to-integer cast function for coercion in that  
case so that using integer or domains thereof as type for EXISTS  
columns works. Note that coercion for ON ERROR values TRUE and FALSE  
already works like that because the parser creates a cast expression  
including the cast function, but the coercion of the actual result  
value is not handled by the parser.  
  
Tests by Jian He.  
  
Reported-by: Jian He <[email protected]>  
Author: Jian He <[email protected]>  
Author: Amit Langote <[email protected]>  
Discussion: https://postgr.es/m/CACJufxEo4sUjKCYtda0_qt9tazqqKPmF1cqhW9KBOUeJFqQd2g@mail.gmail.com  
Backpatch-through: 17  

M src/backend/executor/execExpr.c
M src/backend/executor/execExprInterp.c
M src/include/executor/execExpr.h
M src/test/regress/expected/sqljson_jsontable.out
M src/test/regress/sql/sqljson_jsontable.sql

SQL/JSON: Some fixes to JsonBehavior expression casting

commit   : 847ee701bd3a6d222ab8f67923e308ee1a70a2f8    
  
author   : Amit Langote <[email protected]>    
date     : Tue, 30 Jul 2024 10:37:56 +0900    
  
committer: Amit Langote <[email protected]>    
date     : Tue, 30 Jul 2024 10:37:56 +0900    

Click here for diff

1. Remove the special case handling when casting the JsonBehavior  
   expressions to types with typmod, like 86d33987 did for the casting  
   of SQL/JSON constructor functions.  
  
2. Fix casting for fixed-length character and bit string types by  
   using assignment-level casts.  This is again similar to what  
   86d33987 did, but for ON ERROR / EMPTY expressions.  
  
3. Use runtime coercion for the boolean ON ERROR constants so that  
   using fixed-length character string types, for example, for an  
   EXISTS column doesn't cause a "value too long for type  
   character(n)" when the parser tries to coerce the default ON ERROR  
   value "false" to that type, that is, even when clause is not  
   specified.  
  
4. Simplify the conditions of when to use runtime coercion vs  
   creating the cast expression in the parser itself.  jsonb-valued  
   expressions are now always coerced at runtime and boolean  
   expressions too if the target type is a string type for the  
   reasons mentioned above.  
  
New tests are from a patch that Jian He posted.  Outputs of some  
existing tests change because the coercion now happens at runtime  
instead of at parse time.  
  
Reported-by: Jian He <[email protected]>  
Author: Jian He <[email protected]>  
Author: Amit Langote <[email protected]>  
Discussion: https://postgr.es/m/CACJufxEo4sUjKCYtda0_qt9tazqqKPmF1cqhW9KBOUeJFqQd2g@mail.gmail.com  
Backpatch-through: 17  

M src/backend/parser/parse_expr.c
M src/test/regress/expected/sqljson_jsontable.out
M src/test/regress/expected/sqljson_queryfuncs.out
M src/test/regress/sql/sqljson_jsontable.sql
M src/test/regress/sql/sqljson_queryfuncs.sql

Detach syslogger from shared memory

commit   : f208a16035fc5d18cee0e7e2fbf176616905f9b0    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Mon, 29 Jul 2024 22:21:34 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Mon, 29 Jul 2024 22:21:34 +0300    

Click here for diff

Commit aafc05de1b removed the calls to detach from shared memory from  
syslogger startup. That was not intentional, so put them back.  
  
Author: Rui Zhao  
Reviewed-by: Aleksander Alekseev  
Backpatch-through: 17  
Discussion: https://www.postgresql.org/message-id/[email protected]  

M src/backend/postmaster/launch_backend.c

Count individual SQL commands in pg_restore's --transaction-size mode.

commit   : 81db073a287842cbf0a17cb32108b214a335670b    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 29 Jul 2024 12:17:24 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 29 Jul 2024 12:17:24 -0400    

Click here for diff

The initial implementation in commit 959b38d77 counted one action  
per TOC entry (except for some special cases for multi-blob BLOBS  
entries).  This assumes that TOC entries are all about equally  
complex, but it turns out that that assumption doesn't hold up very  
well in binary-upgrade mode.  For example, even after the previous  
commit I was able to cause backend bloat with tables having many  
inherited constraints.  There may be other cases too.  (Since no  
serious problems have been reported with --single-transaction mode,  
we can conclude that the backend copes well with psql's regular  
restore scripts; but before 959b38d77 we never ran binary-upgrade  
restores with multi-command transactions.)  
  
To fix, count multi-command TOC entries as N actions, allowing the  
transaction size to be scaled down when we hit a complex TOC entry.  
Rather than add a SQL parser to pg_restore, approximate "multi  
command" by counting semicolons in the TOC entry's defn string.  
This will be fooled by semicolons appearing in string literals ---  
but the error is in the conservative direction, so it doesn't seem  
worth working harder.  The biggest risk is with function/procedure  
TOC entries, but we can just explicitly skip those.  
  
(This is undoubtedly a hack, and maybe someday we'll be able to  
revert it after fixing the backend's bloat issues or rethinking  
what pg_dump emits in binary upgrade mode.  But that surely isn't  
a project for v17.)  
  
Thanks to Alexander Korotkov for the let's-count-semicolons idea.  
  
Per report from Justin Pryzby.  Back-patch to v17 where txn_size mode  
was introduced.  
  
Discussion: https://postgr.es/m/ZqEND4ZcTDBmcv31@pryzbyj2023  

M src/bin/pg_dump/pg_backup_archiver.c

Reduce number of commands dumpTableSchema emits for binary upgrade.

commit   : 2fa989e6a3407b9da625e1524c8694bc028e25ba    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 29 Jul 2024 11:53:49 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 29 Jul 2024 11:53:49 -0400    

Click here for diff

Avoid issuing a separate SQL UPDATE command for each column when  
directly manipulating pg_attribute contents in binary upgrade mode.  
With the separate updates, we triggered a relcache invalidation with  
each update.  For a table with N columns, that causes O(N^2) relcache  
bloat in txn_size mode because the table's newly-created relcache  
entry can't be flushed till end of transaction.  Reducing the number  
of commands should make it marginally faster as well as avoiding that  
problem.  
  
While at it, likewise avoid issuing a separate UPDATE on pg_constraint  
for each inherited constraint.  This is less exciting, first because  
inherited (non-partitioned) constraints are relatively rare, and  
second because the backend has a good deal of trouble anyway with  
restoring tables containing many such constraints, due to  
MergeConstraintsIntoExisting being horribly inefficient.  But it seems  
more consistent to do it this way here too, and it surely can't hurt.  
  
In passing, fix one place in dumpTableSchema that failed to use ONLY  
in ALTER TABLE.  That's not a live bug, but it's inconsistent.  
Also avoid silently casting away const from string literals.  
  
Per report from Justin Pryzby.  Back-patch to v17 where txn_size mode  
was introduced.  
  
Discussion: https://postgr.es/m/ZqEND4ZcTDBmcv31@pryzbyj2023  

M src/bin/pg_dump/pg_dump.c
M src/bin/pg_dump/t/002_pg_dump.pl

Fix incorrect return value for pg_size_pretty(bigint)

commit   : 1e020258e53c87c697615390c42a191344bbb909    
  
author   : David Rowley <[email protected]>    
date     : Sun, 28 Jul 2024 22:23:32 +1200    
  
committer: David Rowley <[email protected]>    
date     : Sun, 28 Jul 2024 22:23:32 +1200    

Click here for diff

pg_size_pretty(bigint) would return the value in bytes rather than PB  
for the smallest-most bigint value.  This happened due to an incorrect  
assumption that the absolute value of -9223372036854775808 could be  
stored inside a signed 64-bit type.  
  
Here we fix that by instead storing that value in an unsigned 64-bit type.  
  
This bug does exist in versions prior to 15 but the code there is  
sufficiently different and the bug seems sufficiently non-critical that  
it does not seem worth risking backpatching further.  
  
Author: Joseph Koshakow <[email protected]>  
Discussion: https://postgr.es/m/CAAvxfHdTsMZPWEHUrZ=h3cky9Ccc3Mtx2whUHygY+ABP-mCmUw@mail.gmail.com  
Backpatch-through: 15  

M src/backend/utils/adt/dbsize.c
M src/test/regress/expected/dbsize.out
M src/test/regress/sql/dbsize.sql

libpq: Use strerror_r instead of strerror

commit   : 821fbd63eab0c35c034e83d278da7244cf1be463    
  
author   : Peter Eisentraut <[email protected]>    
date     : Sun, 28 Jul 2024 09:12:00 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Sun, 28 Jul 2024 09:12:00 +0200    

Click here for diff

Commit 453c4687377 introduced a use of strerror() into libpq, but that  
is not thread-safe.  Fix by using strerror_r() instead.  
  
In passing, update some of the code comments added by 453c4687377, as  
we have learned more about the reason for the change in OpenSSL that  
started this.  
  
Reviewed-by: Daniel Gustafsson <[email protected]>  
Discussion: Discussion: https://postgr.es/m/[email protected]  

M src/backend/libpq/be-secure-openssl.c
M src/interfaces/libpq/fe-secure-openssl.c

doc PG 17 relnotes: add "()" to PQsocketPoll mention

commit   : 7525e4c62f99aca910566ddb0749dbaf944904c5    
  
author   : Bruce Momjian <[email protected]>    
date     : Sun, 28 Jul 2024 04:10:11 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Sun, 28 Jul 2024 04:10:11 -0400    

Click here for diff

Backpatch-through: 17 only  

M doc/src/sgml/release-17.sgml

Support falling back to non-preferred readline implementation with meson

commit   : ed9d0446320050b5506861c0b583e0a24c7cb9d7    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Sat, 27 Jul 2024 13:53:16 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Sat, 27 Jul 2024 13:53:16 +0300    

Click here for diff

To build with -Dreadline=enabled one can use either readline or  
libedit. The -Dlibedit_preferred flag is supposed to control the order  
of names to lookup.  This works fine when either both libraries are  
present or -Dreadline is set to auto. However, explicitly enabling  
readline with only libedit present, but not setting libedit_preferred,  
or alternatively enabling readline with only readline present, but  
setting libedit_preferred, too, are both broken. This is because  
cc.find_library will throw an error for a not found dependency as soon  
as the first required dependency is checked, thus it's impossible to  
fallback to the alternative.  
  
Here we only check the second of the two dependencies for  
requiredness, thus we only fail when none of the two can be found.  
  
Author: Wolfgang Walther  
Reviewed-by: Nazir Bilal Yavuz, Alvaro Herrera, Peter Eisentraut  
Reviewed-by: Tristan Partin  
Discussion: https://www.postgresql.org/message-id/[email protected]  
Backpatch: 16-, where meson support was added  

M meson.build

Support absolute bindir/libdir in regression tests with meson

commit   : eb6765d57cfabc63bdb02375ec2e788783b88a0f    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Sat, 27 Jul 2024 13:53:14 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Sat, 27 Jul 2024 13:53:14 +0300    

Click here for diff

Passing an absolute bindir/libdir will install the binaries and  
libraries to <build>/tmp_install/<bindir> and  
<build>/tmp_install/<libdir> respectively.  
  
This path is correctly passed to the regression test suite via  
configure/make, but not via meson, yet. This is because the "/"  
operator in the following expression throws away the whole left side  
when the right side is an absolute path:  
  
    test_install_location / get_option('libdir')  
  
This was already correctly handled for dir_prefix, which is likely  
absolute as well. This patch handles both bindir and libdir in the  
same way - prefixing absolute paths with the tmp_install path  
correctly.  
  
Author: Wolfgang Walther  
Reviewed-by: Nazir Bilal Yavuz, Alvaro Herrera, Peter Eisentraut  
Reviewed-by: Tristan Partin  
Discussion: https://www.postgresql.org/message-id/[email protected]  
Backpatch: 16-, where meson support was added  

M meson.build

Fallback to clang in PATH with meson

commit   : a32ffeebfa63dd3e6ee8f9498a7e59ebd8abba8d    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Sat, 27 Jul 2024 13:53:11 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Sat, 27 Jul 2024 13:53:11 +0300    

Click here for diff

Some distributions put clang into a different path than the llvm  
binary path.  
  
For example, this is the case on NixOS / nixpkgs, which failed to find  
clang with meson before this patch.  
  
Author: Wolfgang Walther  
Reviewed-by: Nazir Bilal Yavuz, Alvaro Herrera, Peter Eisentraut  
Reviewed-by: Tristan Partin  
Discussion: https://www.postgresql.org/message-id/[email protected]  
Backpatch: 16-, where meson support was added  

M meson.build

Fallback to uuid for ossp-uuid with meson

commit   : 469b97c52413adc85bab7d7ee6e0a9cb5adddf30    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Sat, 27 Jul 2024 13:53:08 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Sat, 27 Jul 2024 13:53:08 +0300    

Click here for diff

The upstream name for the ossp-uuid package / pkg-config file is  
"uuid". Many distributions change this to be "ossp-uuid" to not  
conflict with e2fsprogs.  
  
This lookup fails on distributions which don't change this name, for  
example NixOS / nixpkgs. Both "ossp-uuid" and "uuid" are also checked  
in configure.ac.  
  
Author: Wolfgang Walther  
Reviewed-by: Nazir Bilal Yavuz, Alvaro Herrera, Peter Eisentraut  
Reviewed-by: Tristan Partin  
Discussion: https://www.postgresql.org/message-id/[email protected]  
Backpatch: 16-, where meson support was added  

M meson.build

Fix more holes with SLRU code in need of int64 for segment numbers

commit   : e367a413b09fece55ce4e08872ce79f328941ddd    
  
author   : Michael Paquier <[email protected]>    
date     : Sat, 27 Jul 2024 07:16:59 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Sat, 27 Jul 2024 07:16:59 +0900    

Click here for diff

This is a continuation of 3937cadfd438, taking care of more areas I have  
managed to miss previously.  
  
Reported-by: Noah Misch  
Reviewed-by: Noah Misch  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 17  

M src/backend/access/transam/multixact.c

Wait for WAL summarization to catch up before creating .partial file.

commit   : 53b327f83ea2c820b26a9b51f49f498221bc4379    
  
author   : Robert Haas <[email protected]>    
date     : Fri, 26 Jul 2024 14:50:21 -0400    
  
committer: Robert Haas <[email protected]>    
date     : Fri, 26 Jul 2024 14:50:21 -0400    

Click here for diff

When a standby is promoted, CleanupAfterArchiveRecovery() may decide  
to rename the final WAL file from the old timeline by adding ".partial"  
to the name. If WAL summarization is enabled and this file is renamed  
before its partial contents are summarized, WAL summarization breaks:  
the summarizer gets stuck at that point in the WAL stream and just  
errors out.  
  
To fix that, first make the startup process wait for WAL summarization  
to catch up before renaming the file. Generally, this should be quick,  
and if it's not, the user can shut off summarize_wal and try again.  
To make this fix work, also teach the WAL summarizer that after a  
promotion has occurred, no more WAL can appear on the previous  
timeline: previously, the WAL summarizer wouldn't switch to the new  
timeline until we actually started writing WAL there, but that meant  
that when the startup process was waiting for the WAL summarizer, it  
was waiting for an action that the summarizer wasn't yet prepared to  
take.  
  
In the process of fixing these bugs, I realized that the logic to wait  
for WAL summarization to catch up was spread out in a way that made  
it difficult to reuse properly, so this code refactors things to make  
it easier.  
  
Finally, add a test case that would have caught this bug and the  
previously-fixed bug that WAL summarization sometimes needs to back up  
when the timeline changes.  
  
Discussion: https://postgr.es/m/CA+TgmoZGEsZodXC4f=XZNkAeyuDmWTSkpkjCEOcF19Am0mt_OA@mail.gmail.com  

M src/backend/access/transam/xlog.c
M src/backend/backup/basebackup_incremental.c
M src/backend/postmaster/walsummarizer.c
M src/bin/pg_combinebackup/meson.build
A src/bin/pg_combinebackup/t/008_promote.pl
M src/include/access/xlog.h
M src/include/postmaster/walsummarizer.h

Fix indentation.

commit   : f2af1f4559ea74a6133ac36df3204c12e8d12ed3    
  
author   : Robert Haas <[email protected]>    
date     : Fri, 26 Jul 2024 11:58:52 -0400    
  
committer: Robert Haas <[email protected]>    
date     : Fri, 26 Jul 2024 11:58:52 -0400    

Click here for diff

M src/backend/postmaster/walsummarizer.c

Fix macro placement in pg_config.h.in

commit   : 1272cfb7277f723e01657d4090241f5750b8f932    
  
author   : Daniel Gustafsson <[email protected]>    
date     : Fri, 26 Jul 2024 16:25:56 +0200    
  
committer: Daniel Gustafsson <[email protected]>    
date     : Fri, 26 Jul 2024 16:25:56 +0200    

Click here for diff

Commit 274bbced85383e831dde accidentally placed the pg_config.h.in  
for SSL_CTX_set_num_tickets on the wrong line wrt where autoheader  
places it.  Fix by re-arranging and backpatch to the same level as  
the original commit.  
  
Reported-by: Marina Polyakova <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: v12  

M src/include/pg_config.h.in

Allow WAL summarization to back up when timeline changes.

commit   : c7cfbc5157fec24704ea102f113d97193ffe5f7f    
  
author   : Robert Haas <[email protected]>    
date     : Fri, 26 Jul 2024 09:50:31 -0400    
  
committer: Robert Haas <[email protected]>    
date     : Fri, 26 Jul 2024 09:50:31 -0400    

Click here for diff

The old code believed that it was not possible to switch timelines  
without first replaying all of the WAL from the old timeline, but  
that turns out to be false, as demonstrated by an example from Fujii  
Masao. As a result, it assumed that summarization would always  
continue from the LSN where summarization previously ended. But in  
fact, when a timeline switch occurs without replaying all the WAL  
from the previous timeline, we can need to back up to an earlier  
LSN. Adjust accordingly.  
  
Discussion: https://postgr.es/m/CA+TgmoZGEsZodXC4f=XZNkAeyuDmWTSkpkjCEOcF19Am0mt_OA@mail.gmail.com  

M src/backend/postmaster/walsummarizer.c

pg_createsubscriber: Message style improvements

commit   : c0c005070817352e217baa430b04161890d9af5a    
  
author   : Peter Eisentraut <[email protected]>    
date     : Fri, 26 Jul 2024 14:45:13 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Fri, 26 Jul 2024 14:45:13 +0200    

Click here for diff

Refactor some messages, improve quoting.  

M src/bin/pg_basebackup/pg_createsubscriber.c

Fix using injection points at backend startup in EXEC_BACKEND mode

commit   : f19beba3e3acfd804d678af3f768bee069038486    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Fri, 26 Jul 2024 14:55:04 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Fri, 26 Jul 2024 14:55:04 +0300    

Click here for diff

Commit 86db52a506 changed the locking of injection points to use only  
atomic ops and spinlocks, to make it possible to define injection  
points in processes that don't have a PGPROC entry (yet). However, it  
didn't work in EXEC_BACKEND mode, because the pointer to shared memory  
area was not initialized until the process "attaches" to all the  
shared memory structs. To fix, pass the pointer to the child process  
along with other global variables that need to be set up early.  
  
Backpatch-through: 17  

M src/backend/postmaster/launch_backend.c
M src/backend/utils/misc/injection_point.c
M src/include/utils/injection_point.h

Fix fallback behavior when server sends an ERROR early at startup

commit   : f06a632a77ed27aab087d62bd76bc52be3a2ac6f    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Fri, 26 Jul 2024 14:52:08 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Fri, 26 Jul 2024 14:52:08 +0300    

Click here for diff

With sslmode=prefer, the desired behavior is to completely fail the  
connection attempt, *not* fall back to a plaintext connection, if the  
server responds to the SSLRequest with an error ('E') response instead  
of rejecting SSL with an 'N' response. This was broken in commit  
05fd30c0e7.  
  
Reported-by: Jacob Champion  
Reviewed-by: Michael Paquier  
Discussion: https://www.postgresql.org/message-id/CAOYmi%2Bnwvu21mJ4DYKUa98HdfM_KZJi7B1MhyXtnsyOO-PB6Ww%40mail.gmail.com  
Backpatch-through: 17  

M src/interfaces/libpq/fe-connect.c

Disable all TLS session tickets

commit   : 3df7f44a8c7c456c0a0d4d02a1167e972dc24eaa    
  
author   : Daniel Gustafsson <[email protected]>    
date     : Fri, 26 Jul 2024 11:09:45 +0200    
  
committer: Daniel Gustafsson <[email protected]>    
date     : Fri, 26 Jul 2024 11:09:45 +0200    

Click here for diff

OpenSSL supports two types of session tickets for TLSv1.3, stateless  
and stateful. The option we've used only turns off stateless tickets  
leaving stateful tickets active. Use the new API introduced in 1.1.1  
to disable all types of tickets.  
  
Backpatch to all supported versions.  
  
Reviewed-by: Heikki Linnakangas <[email protected]>  
Reported-by: Andres Freund <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: v12  

M configure
M configure.ac
M meson.build
M src/backend/libpq/be-secure-openssl.c
M src/include/pg_config.h.in

SQL/JSON: Remove useless code in ExecInitJsonExpr()

commit   : 8a1a4087bd5fd09f42bcca2c91ff7eceaa2a0eab    
  
author   : Amit Langote <[email protected]>    
date     : Fri, 26 Jul 2024 16:37:59 +0900    
  
committer: Amit Langote <[email protected]>    
date     : Fri, 26 Jul 2024 16:37:59 +0900    

Click here for diff

The code was for adding an unconditional JUMP to the next step,  
which is unnecessary processing.  
  
Reported-by: Jian He <[email protected]>  
Discussion: https://postgr.es/m/CACJufxEo4sUjKCYtda0_qt9tazqqKPmF1cqhW9KBOUeJFqQd2g@mail.gmail.com  
Backpatch-through: 17  

M src/backend/executor/execExpr.c

SQL/JSON: Respect OMIT QUOTES when RETURNING domains over jsonb

commit   : 3c3ccd4ca80136939abf97a7c19b67486dfda3af    
  
author   : Amit Langote <[email protected]>    
date     : Fri, 26 Jul 2024 16:08:13 +0900    
  
committer: Amit Langote <[email protected]>    
date     : Fri, 26 Jul 2024 16:08:13 +0900    

Click here for diff

populate_domain() didn't take into account the omit_quotes flag passed  
down to json_populate_type() by ExecEvalJsonCoercion() and that led  
to incorrect behavior when the RETURNING type is a domain over  
jsonb.  Fix that by passing the flag by adding a new function  
parameter to populate_domain().  
  
Reported-by: Jian He <[email protected]>  
Discussion: https://postgr.es/m/CACJufxEo4sUjKCYtda0_qt9tazqqKPmF1cqhW9KBOUeJFqQd2g@mail.gmail.com  
Backpatch-through: 17  

M src/backend/utils/adt/jsonfuncs.c
M src/test/regress/expected/sqljson_queryfuncs.out
M src/test/regress/sql/sqljson_queryfuncs.sql

SQL/JSON: Improve error-handling of JsonBehavior expressions

commit   : d1dc4ae5608d9c0e83d5b5d32de238a7ac3d9a1a    
  
author   : Amit Langote <[email protected]>    
date     : Fri, 26 Jul 2024 16:00:16 +0900    
  
committer: Amit Langote <[email protected]>    
date     : Fri, 26 Jul 2024 16:00:16 +0900    

Click here for diff

Instead of returning a NULL when the JsonBehavior expression value  
could not be coerced to the RETURNING type, throw the error message  
informing the user that it is the JsonBehavior expression that caused  
the error with the actual coercion error message shown in its DETAIL  
line.  
  
Discussion: https://postgr.es/m/CACJufxEo4sUjKCYtda0_qt9tazqqKPmF1cqhW9KBOUeJFqQd2g@mail.gmail.com  
Backpatch-through: 17  

M src/backend/executor/execExprInterp.c
M src/test/regress/expected/sqljson_jsontable.out
M src/test/regress/expected/sqljson_queryfuncs.out

SQL/JSON: Fix error-handling of some JsonBehavior expressions

commit   : 79fa052e78804667739bee3f3e220f0ef6783b2c    
  
author   : Amit Langote <[email protected]>    
date     : Fri, 26 Jul 2024 15:59:27 +0900    
  
committer: Amit Langote <[email protected]>    
date     : Fri, 26 Jul 2024 15:59:27 +0900    

Click here for diff

To ensure that the errors of executing a JsonBehavior expression that  
is coerced in the parser are caught instead of being thrown directly,  
pass ErrorSaveContext to ExecInitExprRec() when initializing it.  
Also, add a EEOP_JSONEXPR_COERCION_FINISH step to handle the errors  
that are caught that way.  
  
Discussion: https://postgr.es/m/CACJufxEo4sUjKCYtda0_qt9tazqqKPmF1cqhW9KBOUeJFqQd2g@mail.gmail.com  
Backpatch-through: 17  

M src/backend/executor/execExpr.c
M src/backend/executor/execExprInterp.c
M src/test/regress/expected/sqljson_jsontable.out
M src/test/regress/expected/sqljson_queryfuncs.out

Doc: fix misleading syntax synopses for targetlists.

commit   : facd89587141451107278601dd4d4a8c4ba5e8a8    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 25 Jul 2024 19:52:08 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 25 Jul 2024 19:52:08 -0400    

Click here for diff

In the syntax synopses for SELECT, INSERT, UPDATE, etc,  
SELECT ... and RETURNING ... targetlists were missing { ... }  
braces around an OR (|) operator.  That allows misinterpretation  
which could lead to confusion.  
  
David G. Johnston, per gripe from [email protected].  
  
Discussion: https://postgr.es/m/[email protected]  

M doc/src/sgml/ref/delete.sgml
M doc/src/sgml/ref/insert.sgml
M doc/src/sgml/ref/merge.sgml
M doc/src/sgml/ref/select.sgml
M doc/src/sgml/ref/select_into.sgml
M doc/src/sgml/ref/update.sgml

Document restrictions regarding incremental backups and standbys.

commit   : de8b098ce567526e4da7d6e51cfe0fb132123ad7    
  
author   : Robert Haas <[email protected]>    
date     : Thu, 25 Jul 2024 15:45:06 -0400    
  
committer: Robert Haas <[email protected]>    
date     : Thu, 25 Jul 2024 15:45:06 -0400    

Click here for diff

If you try to take an incremental backup on a standby and there hasn't  
been much system activity, it might fail. Document why this happens.  
Also add a hint to the error message you get, to make it more likely  
that users will understand what has gone wrong.  
  
Laurenz Albe and Robert Haas  
  
Discussion: https://postgr.es/m/[email protected]  

M doc/src/sgml/backup.sgml
M src/backend/backup/basebackup_incremental.c

pg_createsubscriber: Message improvements

commit   : 6622da8d3c7153fce58a35448f37a8869681625c    
  
author   : Peter Eisentraut <[email protected]>    
date     : Thu, 25 Jul 2024 15:25:42 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Thu, 25 Jul 2024 15:25:42 +0200    

Click here for diff

Objects are typically "in" a database, not "on".  

M src/bin/pg_basebackup/pg_createsubscriber.c
M src/bin/pg_basebackup/t/040_pg_createsubscriber.pl

Remove useless unconstify() call

commit   : b5006abcdc18f19b6f2d5a2dfa99302666aa6d63    
  
author   : Peter Eisentraut <[email protected]>    
date     : Thu, 25 Jul 2024 11:38:05 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Thu, 25 Jul 2024 11:38:05 +0200    

Click here for diff

This should have been part of 67c0ef9752 but was apparently forgotten  
there.  

M src/bin/pg_dump/compress_gzip.c

ci: Pin MacPorts version to 2.9.3.

commit   : 5f03da8518ce0df9da2079730b36957e159d3c1e    
  
author   : Thomas Munro <[email protected]>    
date     : Thu, 25 Jul 2024 14:46:01 +1200    
  
committer: Thomas Munro <[email protected]>    
date     : Thu, 25 Jul 2024 14:46:01 +1200    

Click here for diff

Commit d01ce180 invented a new way to find the latest MacPorts version.  
By bad luck, a new beta release has just been published, and it seems  
to lack some packages we need.  Go back to searching for this specific  
version for now.  We still search with a pattern so that we can find the  
package for the running version of macOS, but for now we always look for  
2.9.3.  The code to do that had been anticipated already in a commented  
out line, I just didn't expect to have to use it so soon...  
  
Also include the whole MacPorts installation script in the cache key, so  
that changes to the script cause a fresh installation.  This should make  
it a bit easier to reason about the effect of changes on cached state in  
github accounts using CI, when we make adjustments.  
  
Back-patch to 15, like d01ce180.  
  
Discussion: https://postgr.es/m/CA%2BhUKGLqJdv6RcwyZ_0H7khxtLTNJyuK%2BvDFzv3uwYbn8hKH6A%40mail.gmail.com  

M .cirrus.tasks.yml
M src/tools/ci/ci_macports_packages.sh

ci: Upgrade macOS version from 13 to 14.

commit   : f8c1bb2bb90dc023224f414d67fd9d8bf30b455a    
  
author   : Thomas Munro <[email protected]>    
date     : Thu, 25 Jul 2024 11:26:48 +1200    
  
committer: Thomas Munro <[email protected]>    
date     : Thu, 25 Jul 2024 11:26:48 +1200    

Click here for diff

1.  Previously we were using ghcr.io/cirruslabs/macos-XXX-base:latest  
images, but Cirrus has started ignoring that and using a particular  
image, currently ghcr.io/cirruslabs/macos-runner:sonoma, for github  
accounts using free CI resources (as opposed to dedicated runner  
machines, as cfbot uses).  Let's just ask for that image anyway, to stay  
in sync.  
  
2.  Instead of hard-coding a MacPorts installation URL, deduce it from  
the running macOS version and the available releases.  This removes the  
need to keep the ci_macports_packages.sh in sync with .cirrus.task.yml,  
and to advance the MacPorts version from time to time.  
  
3.  Change the cache key we use to cache the whole macports installation  
across builds to include the OS major version, to trigger a fresh  
installation when appropriate.  
  
Back-patch to 15 where CI began.  
  
Reviewed-by: Andres Freund <[email protected]>  
Discussion: https://postgr.es/m/CA%2BhUKGLqJdv6RcwyZ_0H7khxtLTNJyuK%2BvDFzv3uwYbn8hKH6A%40mail.gmail.com  

M .cirrus.tasks.yml
M src/tools/ci/ci_macports_packages.sh

pg_upgrade: Retrieve subscription count more efficiently.

commit   : 73de50e13e397da8e98ed59b0fe63a00051a7128    
  
author   : Nathan Bossart <[email protected]>    
date     : Wed, 24 Jul 2024 11:30:33 -0500    
  
committer: Nathan Bossart <[email protected]>    
date     : Wed, 24 Jul 2024 11:30:33 -0500    

Click here for diff

Presently, pg_upgrade obtains the number of subscriptions in the  
to-be-upgraded cluster by first querying pg_subscription in every  
database for the number of subscriptions in only that database.  
Then, in count_old_cluster_subscriptions(), it adds all the values  
collected in the first step.  This is expensive, especially when  
there are many databases.  
  
Fortunately, there is a better way to retrieve the subscription  
count.  Since pg_subscription is a shared catalog, we only need to  
connect to a single database and query it once.  This commit  
modifies pg_upgrade to use that approach, which also allows us to  
trim several lines of code.  In passing, move the call to  
get_db_subscription_count(), which has been renamed to  
get_subscription_count(), from get_db_rel_and_slot_infos() to the  
dedicated >= v17 section in check_and_dump_old_cluster().  
  
We may be able to make similar improvements to  
get_old_cluster_logical_slot_infos(), but that is left as a future  
exercise.  
  
Reviewed-by: Michael Paquier, Amit Kapila  
Discussion: https://postgr.es/m/ZprQJv_TxccN3tkr%40nathan  
Backpatch-through: 17  

M src/bin/pg_upgrade/check.c
M src/bin/pg_upgrade/info.c
M src/bin/pg_upgrade/pg_upgrade.h

Fix a missing article in the documentation

commit   : 0cc57dca298c86403b6d6bb647f99d542f9d3dca    
  
author   : Alvaro Herrera <[email protected]>    
date     : Wed, 24 Jul 2024 14:13:55 +0200    
  
committer: Alvaro Herrera <[email protected]>    
date     : Wed, 24 Jul 2024 14:13:55 +0200    

Click here for diff

Per complaint from Grant Gryczan.  
  
It's a very old typo; backpatch all the way back.  
  
Author: Laurenz Albe <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  

M doc/src/sgml/parallel.sgml

Reset relhassubclass upon attaching table as a partition

commit   : 2b22543a440d2fa72a1918950d6e67dc1e71b271    
  
author   : Alvaro Herrera <[email protected]>    
date     : Wed, 24 Jul 2024 12:38:18 +0200    
  
committer: Alvaro Herrera <[email protected]>    
date     : Wed, 24 Jul 2024 12:38:18 +0200    

Click here for diff

We don't allow inheritance parents as partitions, and have checks to  
prevent this; but if a table _was_ in the past an inheritance parents  
and all their children are removed, the pg_class.relhassubclass flag  
may remain set, which confuses the partition pruning code (most  
obviously, it results in an assertion failure; in production builds it  
may be worse.)  
  
Fix by resetting relhassubclass on attach.  
  
Backpatch to all supported versions.  
  
Reported-by: Alexander Lakhin <[email protected]>  
Reviewed-by: Tom Lane <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  

M src/backend/catalog/heap.c
M src/test/regress/expected/alter_table.out
M src/test/regress/sql/alter_table.sql

Doc: Fix the mistakes in the subscription's failover option.

commit   : 20aaa634f72ad9617e34546fafbbda3a3832ee45    
  
author   : Amit Kapila <[email protected]>    
date     : Wed, 24 Jul 2024 15:30:58 +0530    
  
committer: Amit Kapila <[email protected]>    
date     : Wed, 24 Jul 2024 15:30:58 +0530    

Click here for diff

The documentation incorrectly stated that users could not alter the  
subscription's failover option when the two-phase commit is enabled.  
  
The steps to confirm that the standby server is ready for failover were  
incorrect.  
  
Author: Shveta Malik, Hou Zhijie  
Reviewed-by: Amit Kapila  
Discussion: https://postgr.es/m/OS0PR01MB571657B72F8D75BD858DCCE394AD2@OS0PR01MB5716.jpnprd01.prod.outlook.com  
Discussion: https://postgr.es/m/CAJpy0uBBk+OZXXqQ00Gai09XR+mDi2=9sMBYY0F+BedoFivaMA@mail.gmail.com  

M doc/src/sgml/logical-replication.sgml
M doc/src/sgml/ref/alter_subscription.sgml

Detect integer overflow in array_set_slice().

commit   : 657e54a05859d51e0afb6e44557b5e8622ecd1fe    
  
author   : Nathan Bossart <[email protected]>    
date     : Tue, 23 Jul 2024 21:59:02 -0500    
  
committer: Nathan Bossart <[email protected]>    
date     : Tue, 23 Jul 2024 21:59:02 -0500    

Click here for diff

When provided an empty initial array, array_set_slice() fails to  
check for overflow when computing the new array's dimensions.  
While such overflows are ordinarily caught by ArrayGetNItems(),  
commands with the following form are accepted:  
  
	INSERT INTO t (i[-2147483648:2147483647]) VALUES ('{}');  
  
To fix, perform the hazardous computations using overflow-detecting  
arithmetic routines.  As with commit 18b585155a, the added test  
cases generate errors that include a platform-dependent value, so  
we again use psql's VERBOSITY parameter to suppress printing the  
message text.  
  
Reported-by: Alexander Lakhin  
Author: Joseph Koshakow  
Reviewed-by: Jian He  
Discussion: https://postgr.es/m/31ad2cd1-db94-bdb3-f91a-65ffdb4bef95%40gmail.com  
Backpatch-through: 12  

M src/backend/utils/adt/arrayfuncs.c
M src/test/regress/expected/arrays.out
M src/test/regress/sql/arrays.sql

commit   : 165ea79a60774a0e287bfc5dc07363194c6d58df    
  
author   : Michael Paquier <[email protected]>    
date     : Tue, 23 Jul 2024 17:59:20 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Tue, 23 Jul 2024 17:59:20 +0900    

Click here for diff

clog.c, async.c and predicate.c included some SLRU page numbers still  
handled as 4-byte integers, while int64 should be used for this purpose.  
  
These holes have been introduced in 4ed8f0913bfd, that has introduced  
the use of 8-byte integers for SLRU page numbers, still forgot about the  
code paths updated by this commit.  
  
Reported-by: Noah Misch  
Author: Aleksander Alekseev, Michael Paquier  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 17  

M src/backend/access/transam/clog.c
M src/backend/commands/async.c
M src/backend/storage/lmgr/predicate.c

Improve comments in slru.{c,h} about segment name format

commit   : 3b279d89cb5c86fa7ac6faaebb3ddadb2dbe0ca8    
  
author   : Michael Paquier <[email protected]>    
date     : Tue, 23 Jul 2024 16:55:09 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Tue, 23 Jul 2024 16:55:09 +0900    

Click here for diff

slru.h described incorrectly how SLRU segment names are formatted  
depending on the segment number and if long or short segment names are  
used.  This commit closes the gap with a better description, fitting  
with the reality.  
  
Reported-by: Noah Misch  
Author: Aleksander Alekseev  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 17  

M src/backend/access/transam/slru.c
M src/include/access/slru.h

Doc: improve description of plpgsql's FETCH and MOVE commands.

commit   : db46016304dc1f9ea402eee6d392f704050467df    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 22 Jul 2024 19:43:12 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 22 Jul 2024 19:43:12 -0400    

Click here for diff

We were not being clear about which variants of the "direction"  
clause are permitted in MOVE.  Also, the text seemed to be  
written with only the FETCH/MOVE NEXT case in mind, so it  
didn't apply very well to other variants.  
  
Also, document that "MOVE count IN cursor" only works if count  
is a constant.  This is not the whole truth, because some other  
cases such as a parenthesized expression will also work, but  
we want to push people to use "MOVE FORWARD count" instead.  
The constant case is enough to cover what we allow in plain SQL,  
and that seems sufficient to claim support for.  
  
Update a comment in pl_gram.y claiming that we don't document  
that point.  
  
Per gripe from Philipp Salvisberg.  
  
Discussion: https://postgr.es/m/[email protected]  

M doc/src/sgml/plpgsql.sgml
M src/pl/plpgsql/src/pl_gram.y

Revert "Test that vacuum removes tuples older than OldestXmin"

commit   : 1a3e90948b50abef3a075c5b1d1c59a9d631a187    
  
author   : Melanie Plageman <[email protected]>    
date     : Mon, 22 Jul 2024 16:32:43 -0400    
  
committer: Melanie Plageman <[email protected]>    
date     : Mon, 22 Jul 2024 16:32:43 -0400    

Click here for diff

This reverts commit 80c34692e8e674e3b2f150f248ef2002ae2ac3a7.  
  
This test proved to be unstable on the buildfarm, timing out before the  
standby could catch up on 32-bit machines where more rows were required  
and failing to reliably trigger multiple index vacuum rounds on 64-bit  
machines where fewer rows should be required.  
  
Because the instability is only known to be present on versions of  
Postgres with TIDStore used for dead TID storage by vacuum, this is only  
being reverted on master and REL_17_STABLE.  
  
As having this coverage may be valuable, there is a discussion on the  
thread of possible ways to stabilize the test. If that happens, a fixed  
test can be committed again.  
  
Backpatch-through: 17  
Reported-by: Tom Lane  
  
Discussion: https://postgr.es/m/614152.1721580711%40sss.pgh.pa.us  

M src/test/recovery/meson.build
D src/test/recovery/t/043_vacuum_horizon_floor.pl

Initialize wal_level in the initial checkpoint record.

commit   : e7dabbcebd445b67a5413d48458b5cf5b4c7930a    
  
author   : Robert Haas <[email protected]>    
date     : Mon, 22 Jul 2024 15:32:43 -0400    
  
committer: Robert Haas <[email protected]>    
date     : Mon, 22 Jul 2024 15:32:43 -0400    

Click here for diff

As per Coverity and Tom Lane, commit 402b586d0 (back-patched to v17  
as 2b5819e2b) forgot to initialize this new structure member in this  
code path.  

M src/backend/access/transam/xlog.c

Add missing call to ConditionVariableCancelSleep().

commit   : 6c8d2ea7a5fb7f85e5f64994affa33e79c19ddd3    
  
author   : Robert Haas <[email protected]>    
date     : Wed, 17 Jul 2024 14:53:00 -0400    
  
committer: Robert Haas <[email protected]>    
date     : Wed, 17 Jul 2024 14:53:00 -0400    

Click here for diff

After calling ConditionVariableSleep() or ConditionVariableTimedSleep()  
one or more times, code is supposed to call ConditionVariableCancelSleep()  
to remove itself from the waitlist. This code neglected to do so.  
As far as I know, that had no observable consequences, but let's make  
the code correct.  
  
Discussion: http://postgr.es/m/CA+TgmoYW8eR+KN6zhVH0sin7QH6AvENqw_bkN-bB4yLYKAnsew@mail.gmail.com  

M src/backend/postmaster/walsummarizer.c

postgres_fdw: Split out the query_cancel test to its own file

commit   : d329a515f490202635443a0a79e974a5019f65a4    
  
author   : Alvaro Herrera <[email protected]>    
date     : Mon, 22 Jul 2024 12:49:57 +0200    
  
committer: Alvaro Herrera <[email protected]>    
date     : Mon, 22 Jul 2024 12:49:57 +0200    

Click here for diff

This allows us to skip it in Cygwin, where it's reportedly flaky because  
of platform bugs or something.  
  
Backpatch to 17, where the test was introduced by commit 2466d6654f85.  
  
Reported-by: Alexander Lakhin <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  

M contrib/postgres_fdw/Makefile
M contrib/postgres_fdw/expected/postgres_fdw.out
A contrib/postgres_fdw/expected/query_cancel.out
A contrib/postgres_fdw/expected/query_cancel_1.out
M contrib/postgres_fdw/meson.build
M contrib/postgres_fdw/sql/postgres_fdw.sql
A contrib/postgres_fdw/sql/query_cancel.sql

meson: Add dependency lookups via names used by cmake

commit   : 9ac6995d6b1f11eefbf69b61bc4378b814d46dec    
  
author   : Andres Freund <[email protected]>    
date     : Sat, 20 Jul 2024 13:51:08 -0700    
  
committer: Andres Freund <[email protected]>    
date     : Sat, 20 Jul 2024 13:51:08 -0700    

Click here for diff

Particularly on windows it's useful to look up dependencies via cmake, instead  
of pkg-config. Meson supports doing so. Unfortunately the dependency names  
used by various projects often differs between their pkg-config and cmake  
files.  
  
This would look a lot neater if we could rely on meson >= 0.60.0...  
  
Reviewed-by: Tristan Partin <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  
Backpatch: 16-, where meson support was added  

M meson.build

meson: Add support for detecting ossp-uuid without pkg-config

commit   : 1213875b3a994bcede9c302ac85745e709afdfab    
  
author   : Andres Freund <[email protected]>    
date     : Sat, 20 Jul 2024 13:51:08 -0700    
  
committer: Andres Freund <[email protected]>    
date     : Sat, 20 Jul 2024 13:51:08 -0700    

Click here for diff

This is necessary as ossp-uuid on windows installs neither a pkg-config nor a  
cmake dependency information. Nor is there another supported uuid  
implementation available on windows.  
  
Reported-by: Dave Page <[email protected]>  
Reviewed-by: Tristan Partin <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  
Backpatch: 16-, where meson support was added  

M meson.build

meson: Add support for detecting gss without pkg-config

commit   : a850701c7ddfebc5c2bd528a9423739458212bc1    
  
author   : Andres Freund <[email protected]>    
date     : Sat, 20 Jul 2024 13:51:08 -0700    
  
committer: Andres Freund <[email protected]>    
date     : Sat, 20 Jul 2024 13:51:08 -0700    

Click here for diff

This is required as MIT Kerberos does provide neither pkg-config nor cmake  
dependency information on windows.  
  
Reported-by: Dave Page <[email protected]>  
Reviewed-by: Tristan Partin <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  
Backpatch: 16-, where meson support was added  

M meson.build

meson: Add missing argument to gssapi.h check

commit   : 5b707bb507bdc9b8bf120db1a0f7dad4cdb78e46    
  
author   : Andres Freund <[email protected]>    
date     : Sat, 20 Jul 2024 13:51:08 -0700    
  
committer: Andres Freund <[email protected]>    
date     : Sat, 20 Jul 2024 13:51:08 -0700    

Click here for diff

These were missing since the initial introduction of the meson based build, in  
e6927270cd18. As-is this is unlikely to cause an issue, but a future commit  
will add support for detecting gssapi without use of dependency(), which could  
fail due to this.  
  
Discussion: https://postgr.es/m/[email protected]  
Backpatch: 16-, where the meson based build was added  

M meson.build

Correctly check updatability of columns targeted by INSERT...DEFAULT.

commit   : 041a00c4803b982d8433d6e3161ca61e73050658    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 20 Jul 2024 13:40:15 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 20 Jul 2024 13:40:15 -0400    

Click here for diff

If a view has some updatable and some non-updatable columns, we failed  
to verify updatability of any columns for which an INSERT or UPDATE  
on the view explicitly specifies a DEFAULT item (unless the view has  
a declared default for that column, which is rare anyway, and one  
would almost certainly not write one for a non-updatable column).  
This would lead to an unexpected "attribute number N not found in  
view targetlist" error rather than the intended error.  
  
Per bug #18546 from Alexander Lakhin.  This bug is old, so back-patch  
to all supported branches.  
  
Discussion: https://postgr.es/m/[email protected]  

M src/backend/rewrite/rewriteHandler.c
M src/test/regress/expected/updatable_views.out
M src/test/regress/sql/updatable_views.sql

Add overflow checks to money type.

commit   : 3764ee47f78c5a332ee6720bdf2e72c8fc9aac35    
  
author   : Nathan Bossart <[email protected]>    
date     : Fri, 19 Jul 2024 11:52:32 -0500    
  
committer: Nathan Bossart <[email protected]>    
date     : Fri, 19 Jul 2024 11:52:32 -0500    

Click here for diff

None of the arithmetic functions for the the money type handle  
overflow.  This commit introduces several helper functions with  
overflow checking and makes use of them in the money type's  
arithmetic functions.  
  
Fixes bug #18240.  
  
Reported-by: Alexander Lakhin  
Author: Joseph Koshakow  
Discussion: https://postgr.es/m/18240-c5da758d7dc1ecf0%40postgresql.org  
Discussion: https://postgr.es/m/CAAvxfHdBPOyEGS7s%2Bxf4iaW0-cgiq25jpYdWBqQqvLtLe_t6tw%40mail.gmail.com  
Backpatch-through: 12  

M src/backend/utils/adt/cash.c
M src/test/regress/expected/money.out
M src/test/regress/sql/money.sql

Test that vacuum removes tuples older than OldestXmin

commit   : 80c34692e8e674e3b2f150f248ef2002ae2ac3a7    
  
author   : Melanie Plageman <[email protected]>    
date     : Fri, 19 Jul 2024 10:40:42 -0400    
  
committer: Melanie Plageman <[email protected]>    
date     : Fri, 19 Jul 2024 10:40:42 -0400    

Click here for diff

If vacuum fails to prune a tuple killed before OldestXmin, it will  
decide to freeze its xmax and later error out in pre-freeze checks.  
  
Add a test reproducing this scenario to the recovery suite which creates  
a table on a primary, updates the table to generate dead tuples for  
vacuum, and then, during the vacuum, uses a replica to force  
GlobalVisState->maybe_needed on the primary to move backwards and  
precede the value of OldestXmin set at the beginning of vacuuming the  
table.  
  
This commit is separate from the fix in case there are test stability  
issues.  
  
Author: Melanie Plageman  
Reviewed-by: Peter Geoghegan  
Discussion: https://postgr.es/m/CAAKRu_apNU2MPBK96V%2BbXjTq0RiZ-%3DA4ZTaysakpx9jxbq1dbQ%40mail.gmail.com  

M src/test/recovery/meson.build
A src/test/recovery/t/043_vacuum_horizon_floor.pl

Ensure vacuum removes all visibly dead tuples older than OldestXmin

commit   : fd4f12df5e46793a651f2d0a272f88a6cf4b358c    
  
author   : Melanie Plageman <[email protected]>    
date     : Fri, 19 Jul 2024 10:40:39 -0400    
  
committer: Melanie Plageman <[email protected]>    
date     : Fri, 19 Jul 2024 10:40:39 -0400    

Click here for diff

If vacuum fails to remove a tuple with xmax older than  
VacuumCutoffs->OldestXmin and younger than GlobalVisState->maybe_needed,  
it may attempt to freeze the tuple's xmax and then ERROR out in  
pre-freeze checks with "cannot freeze committed xmax".  
  
Fix this by having vacuum always remove tuples older than OldestXmin.  
  
It is possible for GlobalVisState->maybe_needed to precede OldestXmin if  
maybe_needed is forced to go backward while vacuum is running. This can  
happen if a disconnected standby with a running transaction older than  
VacuumCutoffs->OldestXmin reconnects to the primary after vacuum  
initially calculates GlobalVisState and OldestXmin.  
  
In back branches starting with 14, the first version using  
GlobalVisState, failing to remove tuples older than OldestXmin during  
pruning caused vacuum to infinitely loop in lazy_scan_prune(), as  
investigated on this [1] thread. After 1ccc1e05ae removed the retry loop  
in lazy_scan_prune() and stopped comparing tuples to OldestXmin, the  
hang could no longer happen, but we could still attempt to freeze dead  
tuples with xmax older than OldestXmin -- resulting in an ERROR.  
  
Fix this by always removing dead tuples with xmax older than  
VacuumCutoffs->OldestXmin. This is okay because the standby won't replay  
the tuple removal until the tuple is removable. Thus, the worst that can  
happen is a recovery conflict.  
  
[1] https://postgr.es/m/20240415173913.4zyyrwaftujxthf2%40awork3.anarazel.de#1b216b7768b5bd577a3d3d51bd5aadee  
  
Back-patch through 14  
  
Author: Melanie Plageman  
Reviewed-by: Peter Geoghegan, Robert Haas, Andres Freund, Heikki Linnakangas, and Noah Misch  
Discussion: https://postgr.es/m/CAAKRu_bDD7oq9ZwB2OJqub5BovMG6UjEYsoK2LVttadjEqyRGg%40mail.gmail.com  

M src/backend/access/heap/pruneheap.c
M src/backend/access/heap/vacuumlazy.c

Move resowner from common JitContext to LLVM specific

commit   : b0a8a7ddd3fbfcdd910b3ee8c7fc5e83d421bfeb    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Fri, 19 Jul 2024 10:27:06 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Fri, 19 Jul 2024 10:27:06 +0300    

Click here for diff

Only the LLVM specific code uses it since resource owners were made  
extensible in commit b8bff07daa85c837a2747b4d35cd5a27e73fb7b2. This is  
new in v17, so backpatch there to keep the branches from diverging  
just yet.  
  
Author: Andreas Karlsson <[email protected]>  
Discussion: https://www.postgresql.org/message-id/[email protected]  

M src/backend/jit/llvm/llvmjit.c
M src/include/jit/jit.h
M src/include/jit/llvmjit.h

postgres_fdw: Avoid "cursor can only scan forward" error.

commit   : 935fe79ea1fb76e32807ebc18f46bbbb9b1cf9b2    
  
author   : Etsuro Fujita <[email protected]>    
date     : Fri, 19 Jul 2024 13:15:01 +0900    
  
committer: Etsuro Fujita <[email protected]>    
date     : Fri, 19 Jul 2024 13:15:01 +0900    

Click here for diff

Commit d844cd75a disallowed rewind in a non-scrollable cursor to resolve  
anomalies arising from such a cursor operation.  However, this failed to  
take into account the assumption in postgres_fdw that when rescanning a  
foreign relation, it can rewind the cursor created for scanning the  
foreign relation without specifying the SCROLL option, regardless of its  
scrollability, causing this error when it tried to do such a rewind in a  
non-scrollable cursor.  Fix by modifying postgres_fdw to instead  
recreate the cursor, regardless of its scrollability, when rescanning  
the foreign relation.  (If we had a way to check its scrollability, we  
could improve this by rewinding it if it is scrollable and recreating it  
if not, but we do not have it, so this commit modifies it to recreate it  
in any case.)  
  
Per bug #17889 from Eric Cyr.  Devrim Gunduz also reported this problem.  
Back-patch to v15 where that commit enforced the prohibition.  
  
Reviewed by Tom Lane.  
  
Discussion: https://postgr.es/m/17889-e8c39a251d258dda%40postgresql.org  
Discussion: https://postgr.es/m/b415ac3255f8352d1ea921cf3b7ba39e0587768a.camel%40gunduz.org  

M contrib/postgres_fdw/expected/postgres_fdw.out
M contrib/postgres_fdw/postgres_fdw.c
M contrib/postgres_fdw/sql/postgres_fdw.sql

Propagate query IDs of utility statements in functions

commit   : 38e271d3c2e8c3bfa4d57fd81c3e47b40f1f5eb3    
  
author   : Michael Paquier <[email protected]>    
date     : Fri, 19 Jul 2024 10:21:21 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Fri, 19 Jul 2024 10:21:21 +0900    

Click here for diff

For utility statements defined within a function, the query tree is  
copied to a PlannedStmt as utility commands do not require planning.  
However, the query ID was missing from the information passed down.  
  
This leads to plugins relying on the query ID like pg_stat_statements to  
not be able to track utility statements within function calls.  Tests  
are added to check this behavior, depending on pg_stat_statements.track.  
  
This is an old bug.  Now, query IDs for utilities are compiled using  
their parsed trees rather than the query string since v16  
(3db72ebcbe20), leading to less bloat with utilities, so backpatch down  
only to this version.  
  
Author: Anthonin Bonnefoy  
Discussion: https://postgr.es/m/CAO6_XqrGp-uwBqi3vBPLuRULKkddjC7R5QZCgsFren=8E+m2Sg@mail.gmail.com  
Backpatch-through: 16  

M contrib/pg_stat_statements/expected/level_tracking.out
M contrib/pg_stat_statements/sql/level_tracking.sql
M src/backend/executor/functions.c

Do not summarize WAL if generated with wal_level=minimal.

commit   : 2b5819e2b4d6c69676c61ee799fd9590be2308ce    
  
author   : Robert Haas <[email protected]>    
date     : Thu, 18 Jul 2024 12:09:48 -0400    
  
committer: Robert Haas <[email protected]>    
date     : Thu, 18 Jul 2024 12:09:48 -0400    

Click here for diff

To do this, we must include the wal_level in the first WAL record  
covered by each summary file; so add wal_level to struct Checkpoint  
and the payload of XLOG_CHECKPOINT_REDO and XLOG_END_OF_RECOVERY.  
  
This, in turn, requires bumping XLOG_PAGE_MAGIC and, since the  
Checkpoint is also stored in the control file, also  
PG_CONTROL_VERSION. It's not great to do that so late in the release  
cycle, but the alternative seems to ship v17 without robust  
protections against this scenario, which could result in corrupted  
incremental backups.  
  
A side effect of this patch is that, when a server with  
wal_level=replica is started with summarize_wal=on for the first time,  
summarization will no longer begin with the oldest WAL that still  
exists in pg_wal, but rather from the first checkpoint after that.  
This change should be harmless, because a WAL summary for a partial  
checkpoint cycle can never make an incremental backup possible when  
it would otherwise not have been.  
  
Report by Fujii Masao. Patch by me. Review and/or testing by Jakub  
Wartak and Fujii Masao.  
  
Discussion: http://postgr.es/m/[email protected]  

M doc/src/sgml/config.sgml
M doc/src/sgml/func.sgml
M src/backend/access/rmgrdesc/xlogdesc.c
M src/backend/access/transam/xlog.c
M src/backend/postmaster/walsummarizer.c
M src/bin/pg_combinebackup/meson.build
A src/bin/pg_combinebackup/t/007_wal_level_minimal.pl
M src/include/access/xlog_internal.h
M src/include/catalog/pg_control.h

Doc: fix minor syntax error in example.

commit   : 4cbd8c60223bd28aacb38f8c8921fc5b8a704fcd    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 17 Jul 2024 15:17:52 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 17 Jul 2024 15:17:52 -0400    

Click here for diff

The CREATE TABLE option is GENERATED BY DEFAULT *AS* IDENTITY.  
  
Per bug #18543 from Ondřej Navrátil.  Seems to have crept in  
in a37bb7c13, so back-patch to v17 where that was added.  
  
Discussion: https://postgr.es/m/[email protected]  

M doc/src/sgml/ddl.sgml

Use PqMsg_* macros in more places.

commit   : 925479b8d83c2fc819e05bf67335255c13d8e8de    
  
author   : Nathan Bossart <[email protected]>    
date     : Wed, 17 Jul 2024 10:51:00 -0500    
  
committer: Nathan Bossart <[email protected]>    
date     : Wed, 17 Jul 2024 10:51:00 -0500    

Click here for diff

Commit f4b54e1ed9, which introduced macros for protocol characters,  
missed updating a few places.  It also did not introduce macros for  
messages sent from parallel workers to their leader processes.  
This commit adds a new section in protocol.h for those.  
  
Author: Aleksander Alekseev  
Discussion: https://postgr.es/m/CAJ7c6TNTd09AZq8tGaHS3LDyH_CCnpv0oOz2wN1dGe8zekxrdQ%40mail.gmail.com  
Backpatch-through: 17  

M src/backend/access/common/printtup.c
M src/backend/commands/explain.c
M src/backend/replication/walsender.c
M src/backend/tcop/postgres.c
M src/backend/utils/activity/backend_progress.c
M src/include/libpq/protocol.h

Avoid error in recovery test if history file is not yet present

commit   : 5d797c896fcf0ef04e4fc3354bc94512e8886cb2    
  
author   : Andrew Dunstan <[email protected]>    
date     : Wed, 17 Jul 2024 10:35:50 -0400    
  
committer: Andrew Dunstan <[email protected]>    
date     : Wed, 17 Jul 2024 10:35:50 -0400    

Click here for diff

Error was detected when testing use of libpq sessions instead of psql  
for polling queries.  
  
Discussion: https://postgr.es/m/[email protected]  
  
Backpatch to all live branches  

M src/test/recovery/t/002_archiving.pl

SQL/JSON: Rethink c2d93c3802b

commit   : 2177306a64137f50158d0d1ce7c4196ff8f05350    
  
author   : Amit Langote <[email protected]>    
date     : Wed, 17 Jul 2024 17:10:57 +0900    
  
committer: Amit Langote <[email protected]>    
date     : Wed, 17 Jul 2024 17:10:57 +0900    

Click here for diff

This essentially reverts c2d93c3802b except tests. The problem with  
c2d93c3802b was that it only changed the casting behavior for types  
with typmod, and had coding issues noted in the post-commit review.  
  
This commit changes coerceJsonFuncExpr() to use assignment-level casts  
instead of explicit casts to coerce the result of JSON constructor  
functions to the specified or the default RETURNING type.  Using  
assignment-level casts fixes the problem that using explicit casts was  
leading to the wrong typmod / length coercion behavior -- truncating  
results longer than the specified length instead of erroring out --  
which c2d93c3802b aimed to solve.  
  
That restricts the set of allowed target types to string types, the  
same set that's currently allowed.  
  
Discussion: https://postgr.es/m/[email protected]  

M src/backend/parser/parse_expr.c

When creating materialized views, use REFRESH to load data.

commit   : b4da732fd64e936970f38c792f8b32c4bdf2bcd5    
  
author   : Jeff Davis <[email protected]>    
date     : Tue, 16 Jul 2024 15:41:22 -0700    
  
committer: Jeff Davis <[email protected]>    
date     : Tue, 16 Jul 2024 15:41:22 -0700    

Click here for diff

Previously, CREATE MATERIALIZED VIEW ... WITH DATA populated the MV  
the same way as CREATE TABLE ... AS.  
  
Instead, reuse the REFRESH logic, which locks down security-restricted  
operations and restricts the search_path. This reduces the chance that  
a subsequent refresh will fail.  
  
Reported-by: Noah Misch  
Backpatch-through: 17  
Discussion: https://postgr.es/m/[email protected]  

M src/backend/commands/createas.c
M src/backend/commands/matview.c
M src/include/commands/matview.h
M src/test/regress/expected/namespace.out

SQL/JSON: Fix a paragraph in JSON_TABLE documentation

commit   : b6ed3cf4b07bfff1f166a239b34a75d818458006    
  
author   : Amit Langote <[email protected]>    
date     : Tue, 16 Jul 2024 14:11:10 +0900    
  
committer: Amit Langote <[email protected]>    
date     : Tue, 16 Jul 2024 14:11:10 +0900    

Click here for diff

Using <replaceable>text</replaceable> inside parantheses is not a  
common or good style, so rephrase a sentence to avoid that style.  
Also rephrase the text in that paragraph a bit while at it.  
  
Reported-by: Marcos Pegoraro <[email protected]>  
Author: Jian He <[email protected]>  
Reviewed-by: Daniel Gustafsson <[email protected]>  
Reviewed-by: Peter Eisentraut <[email protected]>  
Discussion: https://postgr.es/m/CAB-JLwZqH3Yec6Kz-4-+pa0ZG9QJBsxjJZwYcMZYzEDR_fXnKw@mail.gmail.com  

M doc/src/sgml/func.sgml

Fix bad indentation introduced in 43cd30bcd1c

commit   : ff3cae4875d3391c591ac5d22693f27f056e62d2    
  
author   : Andres Freund <[email protected]>    
date     : Mon, 15 Jul 2024 15:17:37 -0700    
  
committer: Andres Freund <[email protected]>    
date     : Mon, 15 Jul 2024 15:17:37 -0700    

Click here for diff

Oops.  
  
Reported-by: Nathan Bossart <[email protected]>  
Discussion: https://postgr.es/m/ZpVZB9rH5tHllO75@nathan  
Backpatch: 12-, like 43cd30bcd1c  

M src/backend/utils/misc/guc.c

Add missing RestrictSearchPath() calls.

commit   : a15b0edb5dd9d2a3731f374b576485799c00431c    
  
author   : Jeff Davis <[email protected]>    
date     : Mon, 15 Jul 2024 12:08:00 -0700    
  
committer: Jeff Davis <[email protected]>    
date     : Mon, 15 Jul 2024 12:08:00 -0700    

Click here for diff

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

M src/backend/commands/indexcmds.c

ci: Upgrade to Debian Bookworm

commit   : bd40ffd8afd28bea6768b8fd46d02b0ccab3c93a    
  
author   : Andres Freund <[email protected]>    
date     : Mon, 15 Jul 2024 09:26:01 -0700    
  
committer: Andres Freund <[email protected]>    
date     : Mon, 15 Jul 2024 09:26:01 -0700    

Click here for diff

Bullseye is getting long in the tooth, upgrade to the current stable version.  
  
Backpatch to all versions with CI support, we don't want to generate CI images  
for multiple Debian versions.  
  
Author: Nazir Bilal Yavuz <[email protected]>  
Discussion: https://postgr.es/m/CAN55FZ0fY5EFHXLKCO_%3Dp4pwFmHRoVom_qSE_7B48gpchfAqzw%40mail.gmail.com  
Backpatch: 15-, where CI was added  

M .cirrus.tasks.yml

Fix type confusion in guc_var_compare()

commit   : 9b047cc0b2c22b667d5452124a381b33d5a9ff4a    
  
author   : Andres Freund <[email protected]>    
date     : Mon, 15 Jul 2024 09:26:01 -0700    
  
committer: Andres Freund <[email protected]>    
date     : Mon, 15 Jul 2024 09:26:01 -0700    

Click here for diff

Before this change guc_var_compare() cast the input arguments to  
const struct config_generic *.  That's not quite right however, as the input  
on one side is often just a char * on one side.  
  
Instead just use char *, the first field in config_generic.  
  
This fixes a -Warray-bounds warning with some versions of gcc. While the  
warning is only known to be triggered for <= 15, the issue the warning points  
out seems real, so apply the fix everywhere.  
  
Author: Nazir Bilal Yavuz <[email protected]>  
Reported-by: Erik Rijkers <[email protected]>  
Suggested-by: Andres Freund <[email protected]>  
Discussion: https://postgr.es/m/a74a1a0d-0fd2-3649-5224-4f754e8f91aa%40xs4all.nl  

M src/backend/utils/misc/guc.c

Doc: minor improvements for plpgsql "Transaction Management" section.

commit   : 34f457e99a86845e7c1826686921f0daa6a02dfd    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 15 Jul 2024 11:59:43 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 15 Jul 2024 11:59:43 -0400    

Click here for diff

Point out that savepoint commands cannot be issued in PL/pgSQL,  
and suggest that exception blocks can usually be used instead.  
  
Add a caveat to the discussion of cursor loops vs. transactions,  
pointing out that any locks taken by the cursor query will be lost  
at COMMIT.  This is implicit in what's already said, but the existing  
text leaves the distinct impression that the auto-hold behavior is  
transparent, which it's not really.  
  
Per a couple of recent complaints (one unsigned, and one in bug #18531  
from Dzmitry Jachnik).  Back-patch to v17, just so this makes it into  
current docs in less than a year-and-a-half.  
  
Discussion: https://postgr.es/m/[email protected]  
Discussion: https://postgr.es/m/[email protected]  

M doc/src/sgml/plpgsql.sgml

Use atomics to avoid locking in InjectionPointRun()

commit   : b8bf76cbde39da45224a764e73002196cf011a51    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Mon, 15 Jul 2024 10:21:16 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Mon, 15 Jul 2024 10:21:16 +0300    

Click here for diff

This allows using injection points without having a PGPROC, like early  
at backend startup, or in the postmaster.  
  
The injection points facility is new in v17, so backpatch there.  
  
Reviewed-by: Michael Paquier <[email protected]>  
Disussion: https://www.postgresql.org/message-id/[email protected]  

M src/backend/utils/misc/injection_point.c
M src/tools/pgindent/typedefs.list

Fix unstable tests in partition_merge.sql and partition_split.sql.

commit   : 6a700da46e6279a0df6a996fd19c5aabdf7a4b56    
  
author   : Fujii Masao <[email protected]>    
date     : Mon, 15 Jul 2024 14:09:30 +0900    
  
committer: Fujii Masao <[email protected]>    
date     : Mon, 15 Jul 2024 14:09:30 +0900    

Click here for diff

The tests added by commit c086896625 were unstable due to  
missing schema names when checking pg_tables and pg_indexes.  
  
Backpatch to v17.  
  
Reported by buildfarm.  

M src/test/regress/expected/partition_merge.out
M src/test/regress/expected/partition_split.out
M src/test/regress/sql/partition_merge.sql
M src/test/regress/sql/partition_split.sql

Fix tablespace handling in MERGE/SPLIT partition commands.

commit   : 929390e4d860b641f72aece70280e66114bffbd0    
  
author   : Fujii Masao <[email protected]>    
date     : Mon, 15 Jul 2024 13:11:51 +0900    
  
committer: Fujii Masao <[email protected]>    
date     : Mon, 15 Jul 2024 13:11:51 +0900    

Click here for diff

As commit ca4103025d stated, new partitions without a specified tablespace  
should inherit the parent relation's tablespace. However, previously,  
ALTER TABLE MERGE PARTITIONS and ALTER TABLE SPLIT PARTITION commands  
always created new partitions in the default tablespace, ignoring  
the parent's tablespace. This commit ensures new partitions inherit  
the parent's tablespace.  
  
Backpatch to v17 where these commands were introduced.  
  
Author: Fujii Masao  
Reviewed-by: Masahiko Sawada  
Discussion: https://postgr.es/m/[email protected]  

M doc/src/sgml/ref/alter_table.sgml
M src/backend/commands/tablecmds.c
M src/test/regress/expected/partition_merge.out
M src/test/regress/expected/partition_split.out
M src/test/regress/sql/partition_merge.sql
M src/test/regress/sql/partition_split.sql

Avoid unhelpful internal error for incorrect recursive-WITH queries.

commit   : cf588e10f664be37a0804e9a8662facd0e163800    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 14 Jul 2024 13:49:46 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 14 Jul 2024 13:49:46 -0400    

Click here for diff

checkWellFormedRecursion would issue "missing recursive reference"  
if a WITH RECURSIVE query contained a single self-reference but  
that self-reference was inside a top-level WITH, ORDER BY, LIMIT,  
etc, rather than inside the second arm of the UNION as expected.  
We already intended to throw more-on-point errors for such cases,  
but those error checks must be done before examining the UNION arm  
in order to have the desired results.  So this patch need only  
move some code (and improve the comments).  
  
Per bug #18536 from Alexander Lakhin.  Back-patch to all supported  
branches.  
  
Discussion: https://postgr.es/m/[email protected]  

M src/backend/parser/parse_cte.c
M src/test/regress/expected/with.out
M src/test/regress/sql/with.sql

Use correct collate.windows.win1252.out

commit   : 5ea9f66616801d0b4be6ce49c74e45bb4f325359    
  
author   : Andrew Dunstan <[email protected]>    
date     : Sat, 13 Jul 2024 16:19:10 -0400    
  
committer: Andrew Dunstan <[email protected]>    
date     : Sat, 13 Jul 2024 16:19:10 -0400    

Click here for diff

I inadvertently missed backporting this to Release 17 from commit 291c420747  
  
per offlist reminder from Alexander Lakhin.  

M src/test/regress/expected/collate.windows.win1252.out

Fix new assertion for MERGE view_name ... DO NOTHING.

commit   : 0d3b35c367c21fcfe437b689919bf153f85e2e25    
  
author   : Noah Misch <[email protected]>    
date     : Sat, 13 Jul 2024 08:09:33 -0700    
  
committer: Noah Misch <[email protected]>    
date     : Sat, 13 Jul 2024 08:09:33 -0700    

Click here for diff

Such queries don't expand automatically updatable views, and ModifyTable  
uses the wholerow attribute unconditionally.  The user-visible behavior  
is fine, so change to more-specific assertions.  Commit  
d5f788b41dc2cbdde6e7694c70dda54d829a5ed5 added the wrong assertion.  
Back-patch to v17, where commit 5f2e179bd31e5f5803005101eb12a8d7bf8db8f3  
introduced MERGE view_name.  
  
Reported by Alexander Lakhin.  
  
Discussion: https://postgr.es/m/[email protected]  

M src/backend/executor/nodeModifyTable.c
M src/test/regress/expected/updatable_views.out
M src/test/regress/sql/updatable_views.sql

Don't lose partitioned table reltuples=0 after relhassubclass=f.

commit   : f5bb46fb2e65f951fe22c166756dab9743b33a8a    
  
author   : Noah Misch <[email protected]>    
date     : Sat, 13 Jul 2024 08:09:33 -0700    
  
committer: Noah Misch <[email protected]>    
date     : Sat, 13 Jul 2024 08:09:33 -0700    

Click here for diff

ANALYZE sets relhassubclass=f when a partitioned table no longer has  
partitions.  An ANALYZE doing that proceeded to apply the inplace update  
of pg_class.reltuples to the old pg_class tuple instead of the new  
tuple, losing that reltuples=0 change if the ANALYZE committed.  
Non-partitioning inheritance trees were unaffected.  Back-patch to v14,  
where commit 375aed36ad83f0e021e9bdd3a0034c0c992c66dc introduced  
maintenance of partitioned table pg_class.reltuples.  
  
Reported by Alexander Lakhin.  
  
Discussion: https://postgr.es/m/[email protected]  

M src/backend/commands/analyze.c
M src/test/regress/expected/vacuum.out
M src/test/regress/sql/vacuum.sql

Make sure to run pg_isready on correct port

commit   : dd12eb33aff94dabee03d32a98d80dfa434805a6    
  
author   : Andrew Dunstan <[email protected]>    
date     : Fri, 12 Jul 2024 18:29:15 -0400    
  
committer: Andrew Dunstan <[email protected]>    
date     : Fri, 12 Jul 2024 18:29:15 -0400    

Click here for diff

The current code can have pg_isready unexpectedly succeed if there is a  
server running on the default port. To avoid this we delay running the  
test until after a node has been created but before it starts, and then  
use that node's port, so we are fairly sure there is nothing running on  
the port.  
  
Backpatch to all live branches.  

M src/bin/scripts/t/080_pg_isready.pl

Fix lost Windows socket EOF events.

commit   : 3c1c82d4066e19a2841fb5f0529452de0d4d65b2    
  
author   : Thomas Munro <[email protected]>    
date     : Sat, 13 Jul 2024 14:59:46 +1200    
  
committer: Thomas Munro <[email protected]>    
date     : Sat, 13 Jul 2024 14:59:46 +1200    

Click here for diff

Winsock only signals an FD_CLOSE event once if the other end of the  
socket shuts down gracefully.  Because each WaitLatchOrSocket() call  
constructs and destroys a new event handle every time, with unlucky  
timing we can lose it and hang.  We get away with this only if the other  
end disconnects non-gracefully, because FD_CLOSE is repeatedly signaled  
in that case.  
  
To fix this design flaw in our Windows socket support fundamentally,  
we'd probably need to rearchitect it so that a single event handle  
exists for the lifetime of a socket, or switch to completely different  
multiplexing or async I/O APIs.  That's going to be a bigger job  
and probably wouldn't be back-patchable.  
  
This brute force kludge closes the race by explicitly polling with  
MSG_PEEK before sleeping.  
  
Back-patch to all supported releases.  This should hopefully clear up  
some random build farm and CI hang failures reported over the years.  It  
might also allow us to try using graceful shutdown in more places again  
(reverted in commit 29992a6) to fix instability in the transmission of  
FATAL error messages, but that isn't done by this commit.  
  
Reported-by: Tom Lane <[email protected]>  
Tested-by: Alexander Lakhin <[email protected]>  
Discussion: https://postgr.es/m/176008.1715492071%40sss.pgh.pa.us  

M src/backend/storage/ipc/latch.c

Add ORDER BY to new test query

commit   : 0340eefd9ba4a6bbaaac07a78c058ffff181fc11    
  
author   : Alvaro Herrera <[email protected]>    
date     : Fri, 12 Jul 2024 13:44:19 +0200    
  
committer: Alvaro Herrera <[email protected]>    
date     : Fri, 12 Jul 2024 13:44:19 +0200    

Click here for diff

Per buildfarm.  

M src/test/regress/expected/constraints.out
M src/test/regress/sql/constraints.sql

Fix ALTER TABLE DETACH for inconsistent indexes

commit   : 30ca4e1ab1ffc1d7c4d5fe4afc800d946a585d96    
  
author   : Alvaro Herrera <[email protected]>    
date     : Fri, 12 Jul 2024 12:54:01 +0200    
  
committer: Alvaro Herrera <[email protected]>    
date     : Fri, 12 Jul 2024 12:54:01 +0200    

Click here for diff

When a partitioned table has an index that doesn't support a constraint,  
but a partition has an equivalent index that does, then a DETACH  
operation would misbehave: a crash in assertion-enabled systems (because  
we fail to find the constraint in the parent that we expect to), or a  
broken coninhcount value (-1) in production systems (because we blindly  
believe that we've successfully detached the parent).  
  
While we should reject an ATTACH of a partition with such an index, we  
have failed to do so in existing releases, so adding an error in stable  
releases might break the (unlikely) existing applications that rely on  
this behavior.  At this point I don't even want to reject them in  
master, because it'd break pg_upgrade if such databases exist, and there  
would be no easy way to fix existing databases without expensive index  
rebuilds.  
  
(Later on we could add ALTER TABLE ... ADD CONSTRAINT USING INDEX to  
partitioned tables, which would allow the user to fix such patterns.  At  
that point we could add more restrictions to prevent the problem from  
its root.)  
  
Also, add a test case that leaves one table in this condition, so that  
we can verify that pg_upgrade continues to work if we later decide to  
change the policy on the master branch.  
  
Backpatch to all supported branches.  
  
Co-authored-by: Tender Wang <[email protected]>  
Reported-by: Alexander Lakhin <[email protected]>  
Reviewed-by: Tender Wang <[email protected]>  
Reviewed-by: Michael Paquier <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  

M src/backend/commands/tablecmds.c
M src/test/regress/expected/constraints.out
M src/test/regress/sql/constraints.sql

Fix unstable test in 040_pg_createsubscriber.

commit   : ae4e072bad5ff254a4fcfe876aae849acdaf8c3d    
  
author   : Amit Kapila <[email protected]>    
date     : Fri, 12 Jul 2024 09:35:46 +0530    
  
committer: Amit Kapila <[email protected]>    
date     : Fri, 12 Jul 2024 09:35:46 +0530    

Click here for diff

The slot synchronization failed because the local slot's (created during  
slot synchronization) catalog_xmin on standby is ahead of remote slot.  
This happens because the INSERT before slot synchronization results in the  
generation of a new xid that could be replicated to the standby. Now  
before the xmin of the physical slot on the primary catches up via  
hot_standby_feedback, the test has created a logical slot that got some  
prior value of catalog_xmin.  
  
To fix this we could try to ensure that the physical slot's catalog_xmin  
is caught up to latest value before creating a logical slot but we took a  
simpler path to move the INSERT after synchronizing the logical slot.  
  
Reported-by: Alexander Lakhin as per buildfarm  
Diagnosed-by: Amit Kapila, Hou Zhijie, Alexander Lakhin  
Author: Hou Zhijie  
Backpatch-through: 17  
Discussion: https://postgr.es/m/[email protected]  

M src/bin/pg_basebackup/t/040_pg_createsubscriber.pl

Fix possibility of logical decoding partial transaction changes.

commit   : 068674f4ab44f2c891b6841432687958e8e9c9a6    
  
author   : Masahiko Sawada <[email protected]>    
date     : Thu, 11 Jul 2024 22:48:21 +0900    
  
committer: Masahiko Sawada <[email protected]>    
date     : Thu, 11 Jul 2024 22:48:21 +0900    

Click here for diff

When creating and initializing a logical slot, the restart_lsn is set  
to the latest WAL insertion point (or the latest replay point on  
standbys). Subsequently, WAL records are decoded from that point to  
find the start point for extracting changes in the  
DecodingContextFindStartpoint() function. Since the initial  
restart_lsn could be in the middle of a transaction, the start point  
must be a consistent point where we won't see the data for partial  
transactions.  
  
Previously, when not building a full snapshot, serialized snapshots  
were restored, and the SnapBuild jumps to the consistent state even  
while finding the start point. Consequently, the slot's restart_lsn  
and confirmed_flush could be set to the middle of a transaction. This  
could lead to various unexpected consequences. Specifically, there  
were reports of logical decoding decoding partial transactions, and  
assertion failures occurred because only subtransactions were decoded  
without decoding their top-level transaction until decoding the commit  
record.  
  
To resolve this issue, the changes prevent restoring the serialized  
snapshot and jumping to the consistent state while finding the start  
point.  
  
On v17 and HEAD, a flag indicating whether snapshot restores should be  
skipped has been added to the SnapBuild struct, and SNAPBUILD_VERSION  
has been bumpded.  
  
On backbranches, the flag is stored in the LogicalDecodingContext  
instead, preserving on-disk compatibility.  
  
Backpatch to all supported versions.  
  
Reported-by: Drew Callahan  
Reviewed-by: Amit Kapila, Hayato Kuroda  
Discussion: https://postgr.es/m/2444AA15-D21B-4CCE-8052-52C7C2DAFE5C%40amazon.com  
Backpatch-through: 12  

M contrib/test_decoding/Makefile
A contrib/test_decoding/expected/skip_snapshot_restore.out
M contrib/test_decoding/meson.build
A contrib/test_decoding/specs/skip_snapshot_restore.spec
M src/backend/replication/logical/logical.c
M src/backend/replication/logical/snapbuild.c
M src/include/replication/snapbuild.h

Make our back branches compatible with libxml2 2.13.x.

commit   : a9747be272889833958ec6d93e3034baab569d2f    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 10 Jul 2024 20:15:52 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 10 Jul 2024 20:15:52 -0400    

Click here for diff

This back-patches HEAD commits 066e8ac6e, 6082b3d5d, e7192486d,  
and 896cd266f into supported branches.  Changes:  
  
* Use xmlAddChildList not xmlAddChild in XMLSERIALIZE  
(affects v16 and up only).  This was a flat-out coding mistake  
that we got away with due to lax checking in previous versions  
of xmlAddChild.  
  
* Use xmlParseInNodeContext not xmlParseBalancedChunkMemory.  
This is to dodge a bug in xmlParseBalancedChunkMemory in libxm2  
releases 2.13.0-2.13.2.  While that bug is now fixed upstream and  
will probably never be seen in any production-oriented distro, it is  
currently a problem on some more-bleeding-edge-friendly platforms.  
  
* Suppress "chunk is not well balanced" errors from libxml2,  
unless it is the only error.  This eliminates an error-reporting  
discrepancy between 2.13 and older releases.  This error is  
almost always redundant with previous errors, if not flat-out  
inappropriate, which is why 2.13 changed the behavior and why  
nobody's likely to miss it.  
  
Erik Wienhold and Tom Lane, per report from Frank Streitzig.  
  
Discussion: https://postgr.es/m/trinity-b0161630-d230-4598-9ebc-7a23acdb37cb-1720186432160@3c-app-gmx-bap25  
Discussion: https://postgr.es/m/trinity-361ba18b-541a-4fe7-bc63-655ae3a7d599-1720259822452@3c-app-gmx-bs01  

M src/backend/utils/adt/xml.c
M src/test/regress/expected/xml.out
M src/test/regress/expected/xml_2.out

Use diff's --strip-trailing-cr flag where appropriate on Windows

commit   : 4506d18a9891c70ce977047e2b4ffc05bef65165    
  
author   : Andrew Dunstan <[email protected]>    
date     : Wed, 10 Jul 2024 09:53:47 -0400    
  
committer: Andrew Dunstan <[email protected]>    
date     : Wed, 10 Jul 2024 09:53:47 -0400    

Click here for diff

Test result files might be checked out using Unix or Windows style line  
endings, depening on git flags, so on Windows we use the  
--strip-trailing-cr flag to tell diff to ignore line endings  
differences.  
  
The flag is added to the diff invocation for the test_json_parser module  
tests and the pg_bsd_indent tests. in pg_regress.c we replace the  
current use of the "-w" flag, which ignore all white space differences,  
with this one which only ignores line end differences.  
  
Discussion: https://postgr.es/m/[email protected]  

M src/test/modules/test_json_parser/t/003_test_semantic.pl
M src/test/regress/pg_regress.c
M src/tools/pg_bsd_indent/t/001_pg_bsd_indent.pl

doc: Update track_io_timing documentation to mention pg_stat_io.

commit   : 0248762b2a8e5c825ab845797aa14647c74be166    
  
author   : Fujii Masao <[email protected]>    
date     : Wed, 10 Jul 2024 15:56:07 +0900    
  
committer: Fujii Masao <[email protected]>    
date     : Wed, 10 Jul 2024 15:56:07 +0900    

Click here for diff

The I/O timing information collected when track_io_timing is  
enabled is now documented to appear in the pg_stat_io view,  
which was previously not mentioned.  
  
This commit also enhances the description of track_io_timing  
to clarify that it monitors not only block read and write  
but also block extend and fsync operations. Additionally,  
the description of track_wal_io_timing has been improved  
to mention both WAL write and WAL fsync monitoring.  
  
Backpatch to v16 where pg_stat_io was added.  
  
Author: Hajime Matsunaga  
Reviewed-by: Melanie Plageman, Nazir Bilal Yavuz, Fujii Masao  
Discussion: https://postgr.es/m/TYWPR01MB10742EE4A6F34C33061429D38A4D52@TYWPR01MB10742.jpnprd01.prod.outlook.com  

M doc/src/sgml/config.sgml
M doc/src/sgml/monitoring.sgml

Prevent CRLF conversion of inputs in json_parser test module

commit   : e72f787ea6b287ed624c1f5be71eb13e405b1577    
  
author   : Andrew Dunstan <[email protected]>    
date     : Tue, 9 Jul 2024 17:29:48 -0400    
  
committer: Andrew Dunstan <[email protected]>    
date     : Tue, 9 Jul 2024 17:29:48 -0400    

Click here for diff

Do this by opening the file in PG_BINARY_R mode. This prevents us from  
getting wrong byte count from stat().  
  
Per complaint from Andres Freund  
  
Discussion: https://postgr.es/m/[email protected]  
  
Backpatch to rlease 17 where this code was introduced  

M src/test/modules/test_json_parser/test_json_parser_incremental.c
M src/test/modules/test_json_parser/test_json_parser_perf.c

Fix missing invalidations for search_path cache.

commit   : d3e076549b99d1130053223adb9c1fa909d75dc0    
  
author   : Jeff Davis <[email protected]>    
date     : Tue, 9 Jul 2024 11:27:10 -0700    
  
committer: Jeff Davis <[email protected]>    
date     : Tue, 9 Jul 2024 11:27:10 -0700    

Click here for diff

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

M src/backend/catalog/namespace.c

SQL/JSON: Various improvements to SQL/JSON query function docs

commit   : ce416fadb4b694ba32e228b8296d8f10f39640c0    
  
author   : Amit Langote <[email protected]>    
date     : Tue, 9 Jul 2024 16:12:22 +0900    
  
committer: Amit Langote <[email protected]>    
date     : Tue, 9 Jul 2024 16:12:22 +0900    

Click here for diff

1. Remove the keyword SELECT from the examples to be consistent  
with the examples of other JSON-related functions listed on the  
same page.  
  
2. Add <synopsis> tags around the functions' syntax definition  
  
3. Capitalize function names in the syntax synopsis and the examples  
  
4. Use <itemizedlist> lists for dividing the descriptions of  
   individual functions into bullet points  
  
5. Significantly rewrite the description of wrapper clauses of  
   JSON_QUERY  
  
6. Significantly rewrite the descriptions of ON ERROR / EMPTY  
   clauses of JSON_QUERY() and JSON_VALUE() functions  
  
7. Add a note about how JSON_VALUE() and JSON_QUERY() differ when  
   returning a JSON null result  
  
8. Move the description of the PASSING clause from the descriptions  
   of individual functions into the top paragraph  
  
And other miscellaneous text improvements, typo fixes.  
  
Suggested-by: Thom Brown <[email protected]>  
Suggested-by: David G. Johnston <[email protected]>  
Reviewed-by: Jian He <[email protected]>  
Reviewed-by: Erik Rijkers <[email protected]>  
Discussion: https://postgr.es/m/CAA-aLv7Dfy9BMrhUZ1skcg=OdqysWKzObS7XiDXdotJNF0E44Q@mail.gmail.com  
Discussion: https://postgr.es/m/CAKFQuwZNxNHuPk44zDF7z8qZec1Aof10aA9tWvBU5CMhEKEd8A@mail.gmail.com  

M doc/src/sgml/func.sgml

Fix limit block handling in pg_wal_summary_contents().

commit   : ab4129091ccc15c3e899878e8bd6733577f83bba    
  
author   : Fujii Masao <[email protected]>    
date     : Tue, 9 Jul 2024 09:26:54 +0900    
  
committer: Fujii Masao <[email protected]>    
date     : Tue, 9 Jul 2024 09:26:54 +0900    

Click here for diff

Previously, pg_wal_summary_contents() had two issues,  
causing discrepancies between pg_wal_summary_contents()  
and the pg_walsummary command on the same WAL summary file:  
  
(1) It did not emit the limit block when that's the only data for  
     a particular relation fork.  
(2) It emitted the same limit block multiple times if the list of  
     block numbers was long enough.  
  
This commit fixes these issues.  
  
Backpatch to v17 where pg_wal_summary_contents() was added.  
  
Author: Fujii Masao  
Reviewed-by: Robert Haas  
Discussion: https://postgr.es/m/[email protected]  

M src/backend/backup/walsummaryfuncs.c

commit   : d3e213ae1359f0bcfa9c446166d187811a7db8bc    
  
author   : Andrew Dunstan <[email protected]>    
date     : Mon, 8 Jul 2024 13:46:21 -0400    
  
committer: Andrew Dunstan <[email protected]>    
date     : Mon, 8 Jul 2024 13:46:21 -0400    

Click here for diff

This reverts commit e9f15bc9. Instead of a hacky solution that didn't  
work on Windows, we avoid trying to move the directory possibly across  
drives, and instead remove it and recreate it in the new location.  
  
Discussion: https://postgr.es/m/[email protected]  
  
Backpatch to release 14 like the previous patch.  

M src/bin/pg_basebackup/t/010_pg_basebackup.pl

Choose ports for test servers less likely to result in conflicts

commit   : e68cf81bfea4561518d6b890f75e7aad70b6fbb1    
  
author   : Andrew Dunstan <[email protected]>    
date     : Mon, 8 Jul 2024 11:18:06 -0400    
  
committer: Andrew Dunstan <[email protected]>    
date     : Mon, 8 Jul 2024 11:18:06 -0400    

Click here for diff

If we choose ports in the range typically used for ephemeral ports there  
is a danger of encountering a port conflict due to a race condition  
between the time we choose the port in a range below that typically used  
to allocate ephemeral ports, but higher than the range typically used by  
well known services.  
  
Author: Jelte Fenema-Nio, with some editing by me.  
  
Discussion: https://postgr.es/m/[email protected]  
  
Backpatch to all live branches (12 and up)  

M src/test/perl/PostgreSQL/Test/Cluster.pm

Force nodes for SSL tests to start in TCP mode

commit   : e4754f780f5e8917dbddc1c92036deb259143433    
  
author   : Andrew Dunstan <[email protected]>    
date     : Mon, 8 Jul 2024 05:51:26 -0400    
  
committer: Andrew Dunstan <[email protected]>    
date     : Mon, 8 Jul 2024 05:51:26 -0400    

Click here for diff

Currently they are started in unix socket mode in ost cases, and then  
converted to run in TCP mode. This can result in port collisions, and  
there is no virtue in startng in unix socket mode, so start as we will  
be going on.  
  
Discussion: https://postgr.es/m/[email protected]  
  
Backpatch to all live branches (12 and up).  

M src/test/ssl/t/SSL/Server.pm

Fix scale clamping in numeric round() and trunc().

commit   : 7a8977d2587f48c545acd9dab9c76ad24eb09eea    
  
author   : Dean Rasheed <[email protected]>    
date     : Mon, 8 Jul 2024 17:51:23 +0100    
  
committer: Dean Rasheed <[email protected]>    
date     : Mon, 8 Jul 2024 17:51:23 +0100    

Click here for diff

The numeric round() and trunc() functions clamp the scale argument to  
the range between +/- NUMERIC_MAX_RESULT_SCALE (2000), which is much  
smaller than the actual allowed range of type numeric. As a result,  
they return incorrect results when asked to round/truncate more than  
2000 digits before or after the decimal point.  
  
Fix by using the correct upper and lower scale limits based on the  
actual allowed (and documented) range of type numeric.  
  
While at it, use the new NUMERIC_WEIGHT_MAX constant instead of  
SHRT_MAX in all other overflow checks, and fix a comment thinko in  
power_var() introduced by e54a758d24 -- the minimum value of  
ln_dweight is -NUMERIC_DSCALE_MAX (-16383), not -SHRT_MAX, though this  
doesn't affect the point being made in the comment, that the resulting  
local_rscale value may exceed NUMERIC_MAX_DISPLAY_SCALE (1000).  
  
Back-patch to all supported branches.  
  
Dean Rasheed, reviewed by Joel Jacobson.  
  
Discussion: https://postgr.es/m/CAEZATCXB%2BrDTuMjhK5ZxcouufigSc-X4tGJCBTMpZ3n%3DxxQuhg%40mail.gmail.com  

M src/backend/utils/adt/numeric.c
M src/test/regress/expected/numeric.out
M src/test/regress/sql/numeric.sql

Typo fix

commit   : d4f8517b0b9436fa3478851024870d8ee0b67801    
  
author   : Amit Langote <[email protected]>    
date     : Mon, 8 Jul 2024 22:11:57 +0900    
  
committer: Amit Langote <[email protected]>    
date     : Mon, 8 Jul 2024 22:11:57 +0900    

Click here for diff

Reported-by: Junwang Zhao <[email protected]>  
Discussion: https://postgr.es/m/CAEG8a3KPi=LayiTwJ11ikF7bcqnZUrcj8NgX0V8nO1mQKZ9GfQ@mail.gmail.com  
Backpatch-through: 17  

M src/common/jsonapi.c

Fix outdated comment after removal of direct SSL fallback

commit   : 5afebbe529abc896d4a3c5a092427c28f6be21ab    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Mon, 8 Jul 2024 12:44:45 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Mon, 8 Jul 2024 12:44:45 +0300    

Click here for diff

The option to fall back from direct SSL to negotiated SSL or a  
plaintext connection was removed in commit fb5718f35f.  
  
Discussion: https://www.postgresql.org/message-id/[email protected]  

M src/interfaces/libpq/fe-connect.c

Fix right-anti-joins when the inner relation is proven unique

commit   : cccab85c2bea213ff03f47a9262d0d78275bd2af    
  
author   : Richard Guo <[email protected]>    
date     : Mon, 8 Jul 2024 10:17:12 +0900    
  
committer: Richard Guo <[email protected]>    
date     : Mon, 8 Jul 2024 10:17:12 +0900    

Click here for diff

For an inner_unique join, we always assume that the executor will stop  
scanning for matches after the first match.  Therefore, for a mergejoin  
that is inner_unique and whose mergeclauses are sufficient to identify a  
match, we set the skip_mark_restore flag to true, indicating that the  
executor need not do mark/restore calls.  However, merge-right-anti-join  
did not get this memo and continues scanning the inner side for matches  
after the first match.  If there are duplicates in the outer scan, we  
may incorrectly skip matching some inner tuples, which can lead to wrong  
results.  
  
Here we fix this issue by ensuring that merge-right-anti-join also  
advances to next outer tuple after the first match in inner_unique  
cases.  This also saves cycles by avoiding unnecessary scanning of inner  
tuples after the first match.  
  
Although hash-right-anti-join does not suffer from this wrong results  
issue, we apply the same change to it as well, to help save cycles for  
the same reason.  
  
Per bug #18522 from Antti Lampinen, and bug #18526 from Feliphe Pozzer.  
Back-patch to v16 where right-anti-join was introduced.  
  
Author: Richard Guo  
Discussion: https://postgr.es/m/[email protected]  

M src/backend/executor/nodeHashjoin.c
M src/backend/executor/nodeMergejoin.c
M src/test/regress/expected/join.out
M src/test/regress/sql/join.sql

Re-enable autoruns for for cmd.exe on Windows

commit   : fa1a63dffcd7113d990b3a50d7e697c7852dc9c5    
  
author   : Michael Paquier <[email protected]>    
date     : Mon, 8 Jul 2024 09:35:10 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Mon, 8 Jul 2024 09:35:10 +0900    

Click here for diff

This acts as a revert of b83747a8a65b and 9886744a361b.  As pointed out  
by Noah, HEAD and REL_17_STABLE are in a weird state where the code  
paths adding /D would limit the spawn of child processes, but we still  
have code paths where the spawn of more than one child process would be  
possible.  
  
Let's remove these /D switches for now, to bring back the code into a  
state consistent with how autorun is configured on a Windows host.  
  
Reported-by: Noah Misch  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 17  

M src/bin/pg_ctl/pg_ctl.c
M src/test/regress/pg_regress.c

Fix incorrect sentinel byte logic in GenerationRealloc()

commit   : 84a9d38006280f092b2b3f14841e4156c7a6e80d    
  
author   : David Rowley <[email protected]>    
date     : Sat, 6 Jul 2024 14:00:06 +1200    
  
committer: David Rowley <[email protected]>    
date     : Sat, 6 Jul 2024 14:00:06 +1200    

Click here for diff

This only affects MEMORY_CONTEXT_CHECKING builds.  
  
This fixes an off-by-one issue in GenerationRealloc() where the  
fast-path code which tries to reuse the existing allocation if the  
existing chunk is >= the new requested size.  The code there thought it  
was always ok to use the existing chunk, but when oldsize == size there  
isn't enough space to store the sentinel byte.  If both sizes matched  
exactly set_sentinel() would overwrite the first byte beyond the chunk  
and then subsequent GenerationRealloc() calls could then fail the  
Assert(chunk->requested_size < oldsize) check which is trying to ensure  
the chunk is large enough to store the sentinel.  
  
The same issue does not exist in aset.c as the sentinel checking code  
only adds a sentinel byte if there's enough space in the chunk.  
  
Reported-by: Alexander Lakhin <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 16, where the problem was introduced by 0e480385e  

M src/backend/utils/mmgr/generation.c

Cope with <regex.h> name clashes.

commit   : 9c273679b36b2c7c9ae13889ec6a5a3892842a6b    
  
author   : Thomas Munro <[email protected]>    
date     : Sat, 6 Jul 2024 10:24:49 +1200    
  
committer: Thomas Munro <[email protected]>    
date     : Sat, 6 Jul 2024 10:24:49 +1200    

Click here for diff

macOS 15's SDK pulls in headers related to <regex.h> when we include  
<xlocale.h>.  This causes our own regex_t implementation to clash with  
the OS's regex_t implementation.  Luckily our function names already had  
pg_ prefixes, but the macros and typenames did not.  
  
Include <regex.h> explicitly on all POSIX systems, and fix everything  
that breaks.  Then we can prove that we are capable of fully hiding and  
replacing the system regex API with our own.  
  
1.  Deal with standard-clobbering macros by undefining them all first.  
POSIX says they are "symbolic constants".  If they are macros, this  
allows us to redefine them.  If they are enums or variables, our macros  
will hide them.  
  
2.  Deal with standard-clobbering types by giving our types pg_  
prefixes, and then using macros to redirect xxx_t -> pg_xxx_t.  
  
After including our "regex/regex.h", the system <regex.h> is hidden,  
because we've replaced all the standard names.  The PostgreSQL source  
tree and extensions can continue to use standard prefix-less type and  
macro names, but reach our implementation, if they included our  
"regex/regex.h" header.  
  
Back-patch to all supported branches, so that macOS 15's tool chain can  
build them.  
  
Reported-by: Stan Hu <[email protected]>  
Suggested-by: Tom Lane <[email protected]>  
Tested-by: Aleksander Alekseev <[email protected]>  
Discussion: https://postgr.es/m/CAMBWrQnEwEJtgOv7EUNsXmFw2Ub4p5P%2B5QTBEgYwiyjy7rAsEQ%40mail.gmail.com  

M src/include/regex/regex.h
M src/tools/pgindent/typedefs.list

doc PG 17 relnotes: fix psql connection cancelation item

commit   : 8af6958957f4762a52314d12c2bba14fccb35a51    
  
author   : Bruce Momjian <[email protected]>    
date     : Fri, 5 Jul 2024 16:51:56 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Fri, 5 Jul 2024 16:51:56 -0400    

Click here for diff

Reported-by: Matthias van de Meent  
  
Discussion: https://postgr.es/m/CAEze2WiprrENrFQqeXij2XyLAdoZaFTFLGC8sE=V8c1yrWn+2A@mail.gmail.com  
  
Backpatch-through: 17 only  

M doc/src/sgml/release-17.sgml

Doc: small improvements in discussion of geometric data types.

commit   : 7f9c71519143b6aec71df068e022ddbe33bcc0d3    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 4 Jul 2024 13:23:32 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 4 Jul 2024 13:23:32 -0400    

Click here for diff

State explicitly that the coordinates in our geometric data types are  
float8.  Also explain that polygons store their bounding box.  
  
While here, fix the table of geometric data types to show type  
"line"'s size correctly: it's 24 bytes not 32.  This has somehow  
escaped notice since that table was made in 1998.  
  
Per suggestion from Sebastian Skałacki.  The size error seems  
important enough to justify back-patching.  
  
Discussion: https://postgr.es/m/[email protected]  

M doc/src/sgml/datatype.sgml

Fix copy/paste mistake in comment

commit   : e72f841cbec12b60dbfcde6e4aaeec8ecab987c4    
  
author   : Alvaro Herrera <[email protected]>    
date     : Thu, 4 Jul 2024 13:57:47 +0200    
  
committer: Alvaro Herrera <[email protected]>    
date     : Thu, 4 Jul 2024 13:57:47 +0200    

Click here for diff

Backpatch to 17  
  
Author: Yugo NAGATA <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  

M src/interfaces/libpq/fe-cancel.c

Remove bogus assertion in pg_atomic_monotonic_advance_u64

commit   : 3a9d0d774d90c41bd60a8fb85685092d3e0bc30f    
  
author   : Alvaro Herrera <[email protected]>    
date     : Thu, 4 Jul 2024 13:25:31 +0200    
  
committer: Alvaro Herrera <[email protected]>    
date     : Thu, 4 Jul 2024 13:25:31 +0200    

Click here for diff

This code wanted to ensure that the 'exchange' variable passed to  
pg_atomic_compare_exchange_u64 has correct alignment, but apparently  
platforms don't actually require anything that doesn't come naturally.  
  
While messing with pg_atomic_monotonic_advance_u64: instead of using  
Max() to determine the value to return, just use  
pg_atomic_compare_exchange_u64()'s return value to decide; also, use  
pg_atomic_compare_exchange_u64 instead of the _impl version; also remove  
the unnecessary underscore at the end of variable name "target".  
  
Backpatch to 17, where this code was introduced by commit bf3ff7bf83bc.  
  
Reported-by: Alexander Lakhin <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  

M src/include/port/atomics.h
M src/include/port/atomics/arch-ppc.h
M src/include/port/atomics/arch-x86.h
M src/include/port/atomics/generic-gcc.h
M src/include/port/atomics/generic-sunpro.h

doc: Specify when ssl_prefer_server_ciphers was added

commit   : 1c9acb14ae0c16dacb9d2823b59589e8f523d1a6    
  
author   : Daniel Gustafsson <[email protected]>    
date     : Thu, 4 Jul 2024 12:10:12 +0200    
  
committer: Daniel Gustafsson <[email protected]>    
date     : Thu, 4 Jul 2024 12:10:12 +0200    

Click here for diff

The ssl_prefer_server_ciphers setting is quite important from a  
security point of view, so simply stating that older versions  
doesn't have it isn't very helpful.  This adds the version when  
the GUC was added to help readers.  
  
Backpatch to all supported versions since this setting has been  
around since 9.4.  
  
Reviewed-by: Peter Eisentraut <[email protected]>  
Reviewed-by: Tom Lane <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: v12  

M doc/src/sgml/config.sgml

SQL/JSON: Fix some obsolete comments.

commit   : 290a6d800d90d36a4a1d45655c944695102fabd1    
  
author   : Amit Langote <[email protected]>    
date     : Fri, 28 Jun 2024 15:09:59 +0900    
  
committer: Amit Langote <[email protected]>    
date     : Fri, 28 Jun 2024 15:09:59 +0900    

Click here for diff

JSON_OBJECT(), JSON_OBJETAGG(), JSON_ARRAY(), and JSON_ARRAYAGG()  
added in 7081ac46ace are not transformed into direct calls to  
user-defined functions as the comments claim. Fix by mentioning  
instead that they are transformed into JsonConstructorExpr nodes,  
which may call them, for example, for the *AGG() functions.  
  
Reported-by: Alexander Lakhin <[email protected]>  
Discussion: https://postgr.es/m/058c856a-e090-ac42-ff00-ffe394f52a87%40gmail.com  
Backpatch-through: 16  

M src/backend/parser/parse_expr.c

Fix typo in GetRunningTransactionData()

commit   : 619f76cce11dc51458eb4ea81b0e48d15d0b2d07    
  
author   : Alexander Korotkov <[email protected]>    
date     : Thu, 4 Jul 2024 02:05:27 +0300    
  
committer: Alexander Korotkov <[email protected]>    
date     : Thu, 4 Jul 2024 02:05:27 +0300    

Click here for diff

e85662df44 made GetRunningTransactionData() calculate the oldest running  
transaction id within the current database.  However, because of the typo,  
the new code uses oldestRunningXid instead of oldestDatabaseRunningXid  
in comparison before updating oldestDatabaseRunningXid.  This commit fixes  
that issue.  
  
Reported-by: Noah Misch  
Discussion: https://postgr.es/m/20240630231816.bf.nmisch%40google.com  
Backpatch-through: 17  

M src/backend/storage/ipc/procarray.c

Avoid 0-length memcpy to NULL with EXEC_BACKEND

commit   : 95219c020c3c8c59079f264386141065865a810e    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Wed, 3 Jul 2024 15:58:14 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Wed, 3 Jul 2024 15:58:14 +0300    

Click here for diff

memcpy(NULL, src, 0) is forbidden by POSIX, even though every  
production version of libc allows it. Let's be tidy.  
  
Per report from Thomas Munro, running UBSan with EXEC_BACKEND.  
Backpatch to v17, where this code was added.  
  
Discussion: https://www.postgresql.org/message-id/CA%2BhUKG%2Be-dV7YWBzfBZXsgovgRuX5VmvmOT%[email protected]  

M src/backend/postmaster/launch_backend.c

Tighten check for --forkchild argument when spawning child process

commit   : 1906b1e0ad96010f2ab07f96e36488e0dc058594    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Wed, 3 Jul 2024 15:53:30 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Wed, 3 Jul 2024 15:53:30 +0300    

Click here for diff

Commit aafc05de1b removed all the other --fork* arguments. Altough  
this is inconsequential, backpatch to v17 since this is new.  
  
Author: Nathan Bossart  
Discussion: https://www.postgresql.org/message-id/ZnCCEN0l3qWv-XpW@nathan  

M src/backend/main/main.c

Fix the testcase introduced in commit 81d20fbf7a.

commit   : 14387ab0650377a0a349a3d2d57b8cb9d0a067c5    
  
author   : Amit Kapila <[email protected]>    
date     : Wed, 3 Jul 2024 14:57:07 +0530    
  
committer: Amit Kapila <[email protected]>    
date     : Wed, 3 Jul 2024 14:57:07 +0530    

Click here for diff

The failed test was syncing failover replication slot to standby to test  
that we remove such slots after the standby is converted to subscriber by  
pg_createsubscriber.  
  
In one of the buildfarm members, the sync of the slot failed because the  
LSN on the standby was before the syncslot's LSN. We need to wait for  
standby to catch up before trying to sync the slot with  
pg_sync_replication_slots().  
  
The other buildfarm failed because autovacuum generated a xid which is  
replicated to the standby at some random point making slots at primary  
lag behind standby during slot sync.  
  
Both these failures wouldn't have occurred if we had used built-in  
slotsync worker as it would have waited for the standby to sync with  
primary but for this test, it is sufficient to use  
pg_sync_replication_slots().  
  
Reported-by: Alexander Lakhin as per buildfarm  
Author: Kuroda Hayato  
Reviewed-by: Amit Kapila  
Backpatch-through: 17  
Discussion: https://postgr.es/m/[email protected]  
Discussion: https://postgr.es/m/OSBPR01MB25528300C71FDD83EA1DCA12F5DD2@OSBPR01MB2552.jpnprd01.prod.outlook.com  

M src/bin/pg_basebackup/t/040_pg_createsubscriber.pl

Drop pre-existing subscriptions from the converted subscriber.

commit   : 622cb84d69be91931568bee180cae7c484a7f026    
  
author   : Amit Kapila <[email protected]>    
date     : Tue, 2 Jul 2024 11:20:06 +0530    
  
committer: Amit Kapila <[email protected]>    
date     : Tue, 2 Jul 2024 11:20:06 +0530    

Click here for diff

We don't need the pre-existing subscriptions on the newly formed  
subscriber by using pg_createsubscriber. The apply workers corresponding  
to these subscriptions can connect to other publisher nodes and either get  
some unwarranted data or can lead to ERRORs in connecting to such nodes.  
  
Author: Kuroda Hayato  
Reviewed-by: Amit Kapila, Shlok Kyal, Vignesh C  
Backpatch-through: 17  
Discussion: https://postgr.es/m/OSBPR01MB25526A30A1FBF863ACCDDA3AF5C92@OSBPR01MB2552.jpnprd01.prod.outlook.com  

M src/bin/pg_basebackup/pg_createsubscriber.c
M src/bin/pg_basebackup/t/040_pg_createsubscriber.pl

Remove unused structure member in pg_createsubscriber.c.

commit   : ca522e2a896cf65339fd24e1e80eb8dcf6ad6729    
  
author   : Amit Kapila <[email protected]>    
date     : Tue, 2 Jul 2024 10:15:11 +0530    
  
committer: Amit Kapila <[email protected]>    
date     : Tue, 2 Jul 2024 10:15:11 +0530    

Click here for diff

Author: Kuroda Hayato  
Backpatch-through: 17  
Discussion: https://postgr.es/m/OSBPR01MB25526A30A1FBF863ACCDDA3AF5C92@OSBPR01MB2552.jpnprd01.prod.outlook.com  

M src/bin/pg_basebackup/pg_createsubscriber.c

Update release notes to reflect recent commit 0f934b0739.

commit   : 58c5f60eb8ced48eef05dcb16a6133d7d07c519f    
  
author   : Amit Kapila <[email protected]>    
date     : Tue, 2 Jul 2024 09:17:41 +0530    
  
committer: Amit Kapila <[email protected]>    
date     : Tue, 2 Jul 2024 09:17:41 +0530    

Click here for diff

Author: Hou Zhijie  
Discussion: https://postgr.es/m/[email protected]  
Discussion: https://postgr.es/m/OS3PR01MB57187B959C1ECC78B0C7C91A94D32@OS3PR01MB5718.jpnprd01.prod.outlook.com  

M doc/src/sgml/release-17.sgml

Preserve CurrentMemoryContext across notify and sinval interrupts.

commit   : 31f8d620b287258a34a35c25868896a46deea14f    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 1 Jul 2024 12:21:07 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 1 Jul 2024 12:21:07 -0400    

Click here for diff

ProcessIncomingNotify is called from the main processing loop that  
normally runs in MessageContext.  That outer-loop code assumes that  
whatever it allocates will be cleaned up when we're done processing  
the current client message --- but if we service a notify interrupt,  
then whatever gets allocated before the next switch into  
MessageContext will be permanently leaked in TopMemoryContext,  
because CommitTransactionCommand sets CurrentMemoryContext to  
TopMemoryContext.  There are observable leaks associated with  
(at least) encoding conversion of incoming queries and parameters  
attached to Bind messages.  
  
sinval catchup interrupts have a similar problem.  There might be  
others, but I've not identified any other clear cases.  
  
To fix, take care to save and restore CurrentMemoryContext across  
the Start/CommitTransactionCommand calls in these functions.  
  
Per bug #18512 from wizardbrony.  Commit to back branches only;  
in HEAD, this was dealt with by the riskier but more thoroughgoing  
approach in commit 1afe31f03.  
  
Discussion: https://postgr.es/m/[email protected]  

M src/backend/commands/async.c
M src/backend/storage/ipc/sinval.c

Fix copy-paste mistake in PQcancelCreate

commit   : 6d2ac554911d874e4d0609f5b2c5f34a1226ee0c    
  
author   : Alvaro Herrera <[email protected]>    
date     : Mon, 1 Jul 2024 13:58:22 +0200    
  
committer: Alvaro Herrera <[email protected]>    
date     : Mon, 1 Jul 2024 13:58:22 +0200    

Click here for diff

When an OOM occurred, this function was incorrectly setting a status of  
CONNECTION_BAD on the passed in PGconn instead of on the newly created  
PGcancelConn.  
  
Mistake introduced with 61461a300c1c.  Backpatch to 17.  
  
Author: Jelte Fennema-Nio <[email protected]>  
Reported-by: Noah Misch <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  

M src/interfaces/libpq/fe-cancel.c

Rename standby_slot_names to synchronized_standby_slots.

commit   : 0f934b0739ad28e8e20d8ad22ca80538544ce28a    
  
author   : Amit Kapila <[email protected]>    
date     : Mon, 1 Jul 2024 11:02:04 +0530    
  
committer: Amit Kapila <[email protected]>    
date     : Mon, 1 Jul 2024 11:02:04 +0530    

Click here for diff

The standby_slot_names GUC allows the specification of physical standby  
slots that must be synchronized before the logical walsenders associated  
with logical failover slots. However, for this purpose, the GUC name is  
too generic.  
  
Author: Hou Zhijie  
Reviewed-by: Bertrand Drouvot, Masahiko Sawada  
Backpatch-through: 17  
Discussion: https://postgr.es/m/[email protected]  

M doc/src/sgml/config.sgml
M doc/src/sgml/func.sgml
M doc/src/sgml/logical-replication.sgml
M doc/src/sgml/logicaldecoding.sgml
M doc/src/sgml/release-17.sgml
M src/backend/replication/logical/slotsync.c
M src/backend/replication/slot.c
M src/backend/replication/walsender.c
M src/backend/utils/misc/guc_tables.c
M src/backend/utils/misc/postgresql.conf.sample
M src/include/replication/slot.h
M src/include/replication/walsender_private.h
M src/include/utils/guc_hooks.h
M src/test/recovery/t/040_standby_failover_slots_sync.pl
M src/tools/pgindent/typedefs.list

Further weaken new pg_createsubscriber test on Windows.

commit   : 55c309fc5b08c39f9d27b2a2fa098fde69368b58    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 30 Jun 2024 23:20:57 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 30 Jun 2024 23:20:57 -0400    

Click here for diff

Also omit backslashes (\) in the generated database names on Windows.  
As before, perhaps we can revert this after updating affected  
buildfarm animals.  
  
Discussion: https://postgr.es/m/[email protected]  

M src/bin/pg_basebackup/t/040_pg_createsubscriber.pl

Adapt REL_17_STABLE to its new status as a stable branch

commit   : 10ee893d786a34e7e1b7c5ac49b529ef5f28af0d    
  
author   : Michael Paquier <[email protected]>    
date     : Mon, 1 Jul 2024 08:05:35 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Mon, 1 Jul 2024 08:05:35 +0900    

Click here for diff

Per the checklist in RELEASE_CHANGES for the creation of a new stable  
branch, this commit does the following things:  
- Arm gen_node_support.pl's nodetag ABI stability, based on the contents  
of nodetags.h.  
- Update URLs of top-level README and Makefile to point to the new  
stable version.  
  
In passing, this fixes an incorrect comment in release-17.sgml.  

M Makefile
M README.md
M doc/src/sgml/release-17.sgml
M src/backend/nodes/gen_node_support.pl

Run pgperltidy

commit   : 7dcc6f8e6d7a0eb0ce90802311278723843b4bbd    
  
author   : Michael Paquier <[email protected]>    
date     : Mon, 1 Jul 2024 07:35:01 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Mon, 1 Jul 2024 07:35:01 +0900    

Click here for diff

This is required before the creation of a new branch.  pgindent is  
clean, as well as is reformat-dat-files.  
  
perltidy version is v20230309, as documented in pgindent's README.  

M src/bin/pg_basebackup/t/040_pg_createsubscriber.pl
M src/bin/pg_combinebackup/t/003_timeline.pl
M src/bin/pg_combinebackup/t/004_manifest.pl
M src/bin/pg_combinebackup/t/005_integrity.pl
M src/bin/pg_combinebackup/t/006_db_file_copy.pl
M src/bin/pg_rewind/t/003_extrafiles.pl
M src/bin/pg_verifybackup/t/003_corruption.pl
M src/test/recovery/t/009_twophase.pl

Temporarily(?) weaken new pg_createsubscriber test on Windows.

commit   : 54508209178bc73a497c460bd0ffd1645dceb1a2    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 30 Jun 2024 17:33:06 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 30 Jun 2024 17:33:06 -0400    

Click here for diff

Don't include double-quotes (") in the generated database names  
on Windows.  Doing so tickles a bug in older versions of IPC::Run,  
which fail to quote command line arguments correctly for that  
platform.  Possibly we can revert this after updating affected  
buildfarm animals.  
  
Discussion: https://postgr.es/m/[email protected]  

M src/bin/pg_basebackup/t/040_pg_createsubscriber.pl

Add PG_TEST_PG_COMBINEBACKUP_MODE

commit   : 35a7b288b975f8b13084307c4b610e3bed5ca046    
  
author   : Tomas Vondra <[email protected]>    
date     : Sun, 30 Jun 2024 19:26:12 +0200    
  
committer: Tomas Vondra <[email protected]>    
date     : Sun, 30 Jun 2024 19:26:12 +0200    

Click here for diff

Introduces an environment variable PG_TEST_PG_COMBINEBACKUP_MODE, that  
determines copy mode used by pg_combinebackup in TAP tests. Defaults to  
"--copy" but may be set to "--clone" or "--copy-file-range" to use the  
alternative stategies.  
  
Reported-by: Peter Eisentraut  
Discussion: https://postgr.es/m/48da4a1f-ccd9-4988-9622-24f37b1de2b4%40eisentraut.org  

M src/bin/pg_combinebackup/t/002_compare_backups.pl
M src/bin/pg_combinebackup/t/003_timeline.pl
M src/bin/pg_combinebackup/t/004_manifest.pl
M src/bin/pg_combinebackup/t/005_integrity.pl
M src/bin/pg_combinebackup/t/006_db_file_copy.pl
M src/test/perl/PostgreSQL/Test/Cluster.pm

Add pg_combinebackup --copy option

commit   : a9577bae6b5c88c6865597aacd33b93d1b17e497    
  
author   : Tomas Vondra <[email protected]>    
date     : Sun, 30 Jun 2024 19:20:02 +0200    
  
committer: Tomas Vondra <[email protected]>    
date     : Sun, 30 Jun 2024 19:20:02 +0200    

Click here for diff

Introduces --copy as an alternative to --clone and --copy-file-range.  
This option simply picks the default mode to copy files, as if none of  
the options was specified. This makes pg_combinebackup options more  
consistent with pg_upgrade, and it makes testing simpler.  
  
Reported-by: Peter Eisentraut  
Discussion: https://postgr.es/m/48da4a1f-ccd9-4988-9622-24f37b1de2b4%40eisentraut.org  

M doc/src/sgml/ref/pg_combinebackup.sgml
M src/bin/pg_combinebackup/pg_combinebackup.c

Add headers needed by pg_combinebackup --clone

commit   : e99e840b82756bc6858222d97453639cef929b53    
  
author   : Tomas Vondra <[email protected]>    
date     : Sun, 30 Jun 2024 19:02:00 +0200    
  
committer: Tomas Vondra <[email protected]>    
date     : Sun, 30 Jun 2024 19:02:00 +0200    

Click here for diff

The code for file cloning existed, but was not reachable as it relied on  
constants from missing headers. Due to that, on Linux --clone always  
failed with  
  
  error: file cloning not supported on this platform  
  
Fixed by including the missing headers to relevant places. Adding the  
headers revealed a couple compile errors in copy_file_clone(), so fix  
those too.  
  
Reported-by: Peter Eisentraut  
Discussion: https://postgr.es/m/48da4a1f-ccd9-4988-9622-24f37b1de2b4%40eisentraut.org  

M src/bin/pg_combinebackup/copy_file.c
M src/bin/pg_combinebackup/pg_combinebackup.c

Make pg_createsubscriber warn if publisher has two-phase commit enabled.

commit   : 917754557cc0002bb042341720a7ce18fe5b0a09    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 30 Jun 2024 14:24:14 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 30 Jun 2024 14:24:14 -0400    

Click here for diff

pg_createsubscriber currently always sets up logical replication  
with two-phase commit disabled.  Improving that is not going to  
happen for v17.  In the meantime, document the deficiency, and  
adjust pg_createsubscriber so that it will emit a warning if  
the source installation has max_prepared_transactions > 0.  
  
Hayato Kuroda (some mods by Amit Kapila and me), per complaint from  
Noah Misch  
  
Discussion: https://postgr.es/m/[email protected]  

M doc/src/sgml/ref/pg_createsubscriber.sgml
M src/bin/pg_basebackup/pg_createsubscriber.c

Make pg_createsubscriber more wary about quoting connection parameters.

commit   : b3f5ccebd79d9c7b73f4e04611cdf31fdf87420b    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 30 Jun 2024 13:45:24 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 30 Jun 2024 13:45:24 -0400    

Click here for diff

The original coding here could fail with database names, user names,  
etc that contain spaces or other special characters.  
  
As partial test coverage, extend the 040_pg_createsubscriber.pl  
test script so that it uses a generated database name containing  
funny characters.  
  
Hayato Kuroda (some mods by me), per complaint from Noah Misch  
  
Discussion: https://postgr.es/m/[email protected]  

M src/bin/pg_basebackup/pg_createsubscriber.c
M src/bin/pg_basebackup/t/040_pg_createsubscriber.pl

Fix .gitignore for new injection suite.

commit   : db0c96cc18aec417101e37e59fcc53d4bf647915    
  
author   : Noah Misch <[email protected]>    
date     : Fri, 28 Jun 2024 11:17:50 -0700    
  
committer: Noah Misch <[email protected]>    
date     : Fri, 28 Jun 2024 11:17:50 -0700    

Click here for diff

Commit c35f419d6efbdf1a050250d84b687e6705917711 missed this.  

M src/test/modules/injection_points/.gitignore

Remove configuration-dependent output from new inplace-inval test.

commit   : b99414de90520e9605dff9cb645a2a228876862f    
  
author   : Noah Misch <[email protected]>    
date     : Fri, 28 Jun 2024 09:33:40 -0700    
  
committer: Noah Misch <[email protected]>    
date     : Fri, 28 Jun 2024 09:33:40 -0700    

Click here for diff

Per buildfarm members prion and trilobite.  Back-patch to v12 (all  
supported versions), like commit  
0844b3968985447ed0a6937cfc8639e379da2fe6.  
  
Strategy reviewed by Tom Lane.  
  
Discussion: https://postgr.es/m/[email protected]  

M src/test/isolation/expected/inplace-inval.out
M src/test/isolation/specs/inplace-inval.spec

pgindent, because I forgot to do that.

commit   : b48f275f18d7da4f4863888ad047cbd699698880    
  
author   : Robert Haas <[email protected]>    
date     : Fri, 28 Jun 2024 10:45:51 -0400    
  
committer: Robert Haas <[email protected]>    
date     : Fri, 28 Jun 2024 10:45:51 -0400    

Click here for diff

Commit 065583cf460f980a182498941ac52810f709a897 should have  
included these changes.  

M src/backend/postmaster/walsummarizer.c

SQL/JSON: Always coerce JsonExpr result at runtime

commit   : 716bd12d22c53d1943d41309f2dd061ec601dd5e    
  
author   : Amit Langote <[email protected]>    
date     : Fri, 28 Jun 2024 21:58:13 +0900    
  
committer: Amit Langote <[email protected]>    
date     : Fri, 28 Jun 2024 21:58:13 +0900    

Click here for diff

Instead of looking up casts at parse time for converting the result  
of JsonPath* query functions to the specified or the default  
RETURNING type, always perform the conversion at runtime using either  
the target type's input function or the function  
json_populate_type().  
  
There are two motivations for this change:  
  
1. json_populate_type() coerces to types with typmod such that any  
   string values that exceed length limit cause an error instead of  
   silent truncation, which is necessary to be standard-conforming.  
  
2. It was possible to end up with a cast expression that doesn't  
   support soft handling of errors causing bugs in the of handling  
   ON ERROR clause.  
  
JsonExpr.coercion_expr which would store the cast expression is no  
longer necessary, so remove.  
  
Bump catversion because stored rules change because of the above  
removal.  
  
Reported-by: Alvaro Herrera <[email protected]>  
Reviewed-by: Jian He <[email protected]>  
Discussion: Discussion: https://postgr.es/m/202405271326.5a5rprki64aw%40alvherre.pgsql  

M src/backend/executor/execExpr.c
M src/backend/executor/execExprInterp.c
M src/backend/jit/llvm/llvmjit_expr.c
M src/backend/nodes/nodeFuncs.c
M src/backend/parser/parse_expr.c
M src/backend/utils/adt/jsonfuncs.c
M src/include/catalog/catversion.h
M src/include/executor/execExpr.h
M src/include/nodes/execnodes.h
M src/include/nodes/primnodes.h
M src/include/utils/jsonfuncs.h
M src/test/regress/expected/sqljson_jsontable.out
M src/test/regress/expected/sqljson_queryfuncs.out
M src/test/regress/sql/sqljson_jsontable.sql
M src/test/regress/sql/sqljson_queryfuncs.sql

SQL/JSON: Fix coercion of constructor outputs to types with typmod

commit   : c2d93c3802b205d135d1ae1d7ac167d74e08a274    
  
author   : Amit Langote <[email protected]>    
date     : Fri, 28 Jun 2024 21:37:14 +0900    
  
committer: Amit Langote <[email protected]>    
date     : Fri, 28 Jun 2024 21:37:14 +0900    

Click here for diff

Ensure SQL/JSON constructor functions that allow specifying the  
target type using the RETURNING clause perform implicit cast to  
that type.  This ensures that output values that exceed the specified  
length produce an error rather than being  silently truncated. This  
behavior conforms to the SQL standard.  
  
Reported-by: Alvaro Herrera <[email protected]>  
Reviewed-by: Jian He <[email protected]>  
Discussion: https://postgr.es/m/202405271326.5a5rprki64aw%40alvherre.pgsql  

M src/backend/parser/parse_expr.c
M src/test/regress/expected/sqljson.out
M src/test/regress/sql/sqljson.sql

Prevent summarizer hang when summarize_wal turned off and back on.

commit   : 065583cf460f980a182498941ac52810f709a897    
  
author   : Robert Haas <[email protected]>    
date     : Tue, 25 Jun 2024 15:42:36 -0400    
  
committer: Robert Haas <[email protected]>    
date     : Tue, 25 Jun 2024 15:42:36 -0400    

Click here for diff

Before this commit, when the WAL summarizer started up or recovered  
from an error, it would resume summarization from wherever it left  
off. That was OK normally, but wrong if summarize_wal=off had been  
turned off temporary, allowing some WAL to be removed, and then turned  
back on again. In such cases, the WAL summarizer would simply hang  
forever. This commit changes the reinitialization sequence for WAL  
summarizer to rederive the starting position in the way we were  
already doing at initial startup, fixing the problem.  
  
Per report from Israel Barth Rubio. Reviewed by Tom Lane.  
  
Discussion: http://postgr.es/m/CA+TgmoYN6x=YS+FoFOS6=nr6=qkXZFWhdiL7k0oatGwug2hcuA@mail.gmail.com  

M src/backend/access/transam/xlog.c
M src/backend/postmaster/walsummarizer.c
M src/include/postmaster/walsummarizer.h

SQL/JSON: Validate values in ON ERROR/EMPTY clauses

commit   : 55e56c84da99fe7becda2194563f48bb3083c2d1    
  
author   : Amit Langote <[email protected]>    
date     : Fri, 28 Jun 2024 13:59:57 +0900    
  
committer: Amit Langote <[email protected]>    
date     : Fri, 28 Jun 2024 13:59:57 +0900    

Click here for diff

Currently, the grammar allows any supported values in the ON ERROR  
and ON EMPTY clauses for SQL/JSON functions, regardless of whether  
the values are appropriate for the function. This commit ensures  
that during parse analysis, the provided value is checked for  
validity for the given function and throws a syntax error if it is  
not.  
  
While at it, this fixes some omissions in the documentation of the  
ON ERROR/EMPTY clauses for JSON_TABLE().  
  
Reported-by: Jian He <[email protected]>  
Reviewed-by: Jian He <[email protected]>  
Discussion: https://postgr.es/m/CACJufxFgWGqpESSYzyJ6tSurr3vFYBSNEmCfkGyB_dMdptFnZQ%40mail.gmail.com  

M doc/src/sgml/func.sgml
M src/backend/parser/parse_expr.c
M src/backend/parser/parse_jsontable.c
M src/test/regress/expected/sqljson_jsontable.out
M src/test/regress/expected/sqljson_queryfuncs.out
M src/test/regress/sql/sqljson_jsontable.sql
M src/test/regress/sql/sqljson_queryfuncs.sql

SQL/JSON: Prevent ON EMPTY for EXISTS columns in JSON_TABLE()

commit   : e3c1393efc31ac70de7b68e9a283ec3f2d7f9bd2    
  
author   : Amit Langote <[email protected]>    
date     : Fri, 28 Jun 2024 13:59:13 +0900    
  
committer: Amit Langote <[email protected]>    
date     : Fri, 28 Jun 2024 13:59:13 +0900    

Click here for diff

Due to an oversight in de3600452b61, the ON EMPTY clause was  
incorrectly allowed in the EXISTS column. Fix the grammar to prevent  
this.  
  
Discussion: https://postgr.es/m/CA%2BHiwqHh3YDXTpccgAo4CdfV9Mhy%2Bmg%3Doh6t8rfM5uLW1BJN4g%40mail.gmail.com  

M src/backend/parser/gram.y
M src/test/regress/expected/sqljson_jsontable.out
M src/test/regress/sql/sqljson_jsontable.sql

Update modules/injection_points/.gitignore

commit   : 0ad8153c1f4c7129ff19e8a41d142001d35c8514    
  
author   : Michael Paquier <[email protected]>    
date     : Fri, 28 Jun 2024 13:41:39 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Fri, 28 Jun 2024 13:41:39 +0900    

Click here for diff

Thinko in c35f419d6efb, where an isolation test has been added to the  
module.  

M src/test/modules/injection_points/.gitignore

Fix comments in heaptuple.c

commit   : 526b54ece3f6b0bc474c0498d94780a38a6648a2    
  
author   : Michael Paquier <[email protected]>    
date     : Fri, 28 Jun 2024 13:30:47 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Fri, 28 Jun 2024 13:30:47 +0900    

Click here for diff

Since e27f4ee0a701, fastgetattr() and heap_getattr() are not macros, but  
inlined functions.  
  
Author: Junwang Zhao  
Reviewed-by: Stepan Neretin  
Discussion: https://postgr.es/m/CAEG8a3JS-JKWWyOcM7BU=vPqFXa3W7mZSHnvc3CBqx=tC+3SCA@mail.gmail.com  

M src/backend/access/common/heaptuple.c

Improve locking around InjectionPointRun()

commit   : d85fc4be11b38afd6d3abb586a6799299ed29470    
  
author   : Michael Paquier <[email protected]>    
date     : Fri, 28 Jun 2024 12:31:29 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Fri, 28 Jun 2024 12:31:29 +0900    

Click here for diff

As coded, an injection point could be loaded into the local cache  
without the LWLock InjectionPointLock taken, hence a point detached and  
re-attached concurrently of a point running calling InjectionPointRun()  
may finish by loading a callback it did no set initially.  Based on all  
the cases discussed until now on the lists, it is fine to delay the lock  
release until the callback is run, so let's do that.  
  
While on it, remove a useless LWLockRelease() called before an error in  
InjectionPointAttach().  
  
Per discussion with Heikki Linnakangas and Noah Misch.  
  
Discussion: https://postgr.es/m/[email protected]  

M src/backend/utils/misc/injection_point.c

Remove comment about xl_heap_inplace "AT END OF STRUCT".

commit   : 4a7f91b3d3141e8898211a5b145b3c210b05c288    
  
author   : Noah Misch <[email protected]>    
date     : Thu, 27 Jun 2024 19:21:06 -0700    
  
committer: Noah Misch <[email protected]>    
date     : Thu, 27 Jun 2024 19:21:06 -0700    

Click here for diff

Commit 2c03216d831160bedd72d45f712601b6f7d03f1c moved the tuple data  
from there to the buffer-0 data.  Back-patch to v12 (all supported  
versions), the plan for the next change to this struct.  
  
Discussion: https://postgr.es/m/[email protected]  

M src/include/access/heapam_xlog.h

Cope with inplace update making catcache stale during TOAST fetch.

commit   : f9f47f0d93d1a493a3365625f96026c7b18d7cf5    
  
author   : Noah Misch <[email protected]>    
date     : Thu, 27 Jun 2024 19:21:06 -0700    
  
committer: Noah Misch <[email protected]>    
date     : Thu, 27 Jun 2024 19:21:06 -0700    

Click here for diff

This extends ad98fb14226ae6456fbaed7990ee7591cbe5efd2 to invals of  
inplace updates.  Trouble requires an inplace update of a catalog having  
a TOAST table, so only pg_database was at risk.  (The other catalog on  
which core code performs inplace updates, pg_class, has no TOAST table.)  
Trouble would require something like the inplace-inval.spec test.  
Consider GRANT ... ON DATABASE fetching a stale row from cache and  
discarding a datfrozenxid update that vac_truncate_clog() has already  
relied upon.  Back-patch to v12 (all supported versions).  
  
Reviewed (in an earlier version) by Robert Haas.  
  
Discussion: https://postgr.es/m/[email protected]  
Discussion: https://postgr.es/m/[email protected]  

M src/backend/catalog/catalog.c
M src/backend/utils/cache/catcache.c
M src/include/catalog/catalog.h

AccessExclusiveLock new relations just after assigning the OID.

commit   : 5b823b179e5e8ab32f140658698ca08f8c83f06e    
  
author   : Noah Misch <[email protected]>    
date     : Thu, 27 Jun 2024 19:21:05 -0700    
  
committer: Noah Misch <[email protected]>    
date     : Thu, 27 Jun 2024 19:21:05 -0700    

Click here for diff

This has no user-visible, important consequences, since other sessions'  
catalog scans can't find the relation until we commit.  However, this  
unblocks introducing a rule about locks required to heap_update() a  
pg_class row.  CREATE TABLE has been acquiring this lock eventually, but  
it can heap_update() pg_class.relchecks earlier.  create_toast_table()  
has been acquiring only ShareLock.  Back-patch to v12 (all supported  
versions), the plan for the commit relying on the new rule.  
  
Reviewed (in an earlier version) by Robert Haas.  
  
Discussion: https://postgr.es/m/[email protected]  

M src/backend/catalog/heap.c

Lock before setting relhassubclass on RELKIND_PARTITIONED_INDEX.

commit   : 0cecc908e9749101b5e93ba58d76a62c9f226f9e    
  
author   : Noah Misch <[email protected]>    
date     : Thu, 27 Jun 2024 19:21:05 -0700    
  
committer: Noah Misch <[email protected]>    
date     : Thu, 27 Jun 2024 19:21:05 -0700    

Click here for diff

Commit 5b562644fec696977df4a82790064e8287927891 added a comment that  
SetRelationHasSubclass() callers must hold this lock.  When commit  
17f206fbc824d2b4b14480199ca9ff7dea417eda extended use of this column to  
partitioned indexes, it didn't take the lock.  As the latter commit  
message mentioned, we currently never reset a partitioned index to  
relhassubclass=f.  That largely avoids harm from the lock omission.  The  
cause for fixing this now is to unblock introducing a rule about locks  
required to heap_update() a pg_class row.  This might cause more  
deadlocks.  It gives minor user-visible benefits:  
  
- If an ALTER INDEX SET TABLESPACE runs concurrently with ALTER TABLE  
  ATTACH PARTITION or CREATE PARTITION OF, one transaction blocks  
  instead of failing with "tuple concurrently updated".  (Many cases of  
  DDL concurrency still fail that way.)  
  
- Match ALTER INDEX ATTACH PARTITION in choosing to lock the index.  
  
While not user-visible today, we'll need this if we ever make something  
set the flag to false for a partitioned index, like ANALYZE does today  
for tables.  Back-patch to v12 (all supported versions), the plan for  
the commit relying on the new rule.  In back branches, add  
LockOrStrongerHeldByMe() instead of adding a LockHeldByMe() parameter.  
  
Reviewed (in an earlier version) by Robert Haas.  
  
Discussion: https://postgr.es/m/[email protected]  

M src/backend/catalog/index.c
M src/backend/commands/indexcmds.c
M src/backend/commands/tablecmds.c
M src/backend/storage/lmgr/lmgr.c
M src/backend/storage/lmgr/lock.c
M src/include/storage/lmgr.h
M src/include/storage/lock.h

Lock owned sequences during ALTER TABLE SET { LOGGED | UNLOGGED }.

commit   : f88cdb36c457f673a1966a22883ce47e565a37db    
  
author   : Noah Misch <[email protected]>    
date     : Thu, 27 Jun 2024 19:21:05 -0700    
  
committer: Noah Misch <[email protected]>    
date     : Thu, 27 Jun 2024 19:21:05 -0700    

Click here for diff

These commands already make the persistence of owned sequences follow  
owned table persistence changes.  They didn't lock those sequences.  
They lost the effect of nextval() calls that other sessions make after  
the ALTER TABLE command, before the ALTER TABLE transaction commits.  
Fix by acquiring the same lock that ALTER SEQUENCE SET { LOGGED |  
UNLOGGED } acquires.  This might cause more deadlocks.  Back-patch to  
v15, where commit 344d62fb9a978a72cf8347f0369b9ee643fd0b31 introduced  
unlogged sequences.  
  
Reviewed (in an earlier version) by Robert Haas.  
  
Discussion: https://postgr.es/m/[email protected]  

M src/backend/commands/sequence.c

Expand comments and add an assertion in nodeModifyTable.c.

commit   : d5f788b41dc2cbdde6e7694c70dda54d829a5ed5    
  
author   : Noah Misch <[email protected]>    
date     : Thu, 27 Jun 2024 19:21:05 -0700    
  
committer: Noah Misch <[email protected]>    
date     : Thu, 27 Jun 2024 19:21:05 -0700    

Click here for diff

Most comments concern RELKIND_VIEW.  One addresses the ExecUpdate()  
"tupleid" parameter.  A later commit will rely on these facts, but they  
hold already.  Back-patch to v12 (all supported versions), the plan for  
that commit.  
  
Reviewed (in an earlier version) by Robert Haas.  
  
Discussion: https://postgr.es/m/[email protected]  

M src/backend/executor/nodeModifyTable.c

Add an injection_points isolation test suite.

commit   : c35f419d6efbdf1a050250d84b687e6705917711    
  
author   : Noah Misch <[email protected]>    
date     : Thu, 27 Jun 2024 19:21:05 -0700    
  
committer: Noah Misch <[email protected]>    
date     : Thu, 27 Jun 2024 19:21:05 -0700    

Click here for diff

Make the isolation harness recognize injection_points wait events as a  
type of blocked state.  Test an extant inplace-update bug.  
  
Reviewed by Robert Haas and Michael Paquier.  
  
Discussion: https://postgr.es/m/[email protected]  

M src/backend/access/heap/heapam.c
M src/backend/utils/adt/waitfuncs.c
M src/test/modules/injection_points/Makefile
A src/test/modules/injection_points/expected/inplace.out
M src/test/modules/injection_points/meson.build
A src/test/modules/injection_points/specs/inplace.spec

Create waitfuncs.c for pg_isolation_test_session_is_blocked().

commit   : abfbd13af0e971e8789bc89e7c83ad53a85fa74b    
  
author   : Noah Misch <[email protected]>    
date     : Thu, 27 Jun 2024 19:21:05 -0700    
  
committer: Noah Misch <[email protected]>    
date     : Thu, 27 Jun 2024 19:21:05 -0700    

Click here for diff

The next commit makes the function inspect an additional non-lock  
contention source, so it no longer fits in lockfuncs.c.  
  
Reviewed by Robert Haas.  
  
Discussion: https://postgr.es/m/[email protected]  

M src/backend/utils/adt/Makefile
M src/backend/utils/adt/lockfuncs.c
M src/backend/utils/adt/meson.build
A src/backend/utils/adt/waitfuncs.c

Add wait event type "InjectionPoint", a custom type like "Extension".

commit   : bb93640a681c2cc709e9836e169c8f3eb556df57    
  
author   : Noah Misch <[email protected]>    
date     : Thu, 27 Jun 2024 19:21:05 -0700    
  
committer: Noah Misch <[email protected]>    
date     : Thu, 27 Jun 2024 19:21:05 -0700    

Click here for diff

Both injection points and customization of type "Extension" are new in  
v17, so this just changes a detail of an unreleased feature.  
  
Reported by Robert Haas.  Reviewed by Michael Paquier.  
  
Discussion: https://postgr.es/m/CA+TgmobfMU5pdXP36D5iAwxV5WKE_vuDLtp_1QyH+H5jMMt21g@mail.gmail.com  

M doc/src/sgml/monitoring.sgml
M doc/src/sgml/xfunc.sgml
M src/backend/storage/ipc/ipci.c
M src/backend/utils/activity/generate-wait_event_types.pl
M src/backend/utils/activity/wait_event.c
M src/backend/utils/activity/wait_event_funcs.c
M src/backend/utils/activity/wait_event_names.txt
M src/include/storage/lwlocklist.h
M src/include/utils/wait_event.h
M src/test/modules/injection_points/injection_points.c
M src/test/regress/expected/sysviews.out
M src/test/regress/sql/sysviews.sql
M src/tools/pgindent/typedefs.list

Improve test coverage for changes to inplace-updated catalogs.

commit   : 0844b3968985447ed0a6937cfc8639e379da2fe6    
  
author   : Noah Misch <[email protected]>    
date     : Thu, 27 Jun 2024 19:21:05 -0700    
  
committer: Noah Misch <[email protected]>    
date     : Thu, 27 Jun 2024 19:21:05 -0700    

Click here for diff

This covers both regular and inplace changes, since bugs arise at their  
intersection.  Where marked, these witness extant bugs.  Back-patch to  
v12 (all supported versions).  
  
Reviewed (in an earlier version) by Robert Haas.  
  
Discussion: https://postgr.es/m/[email protected]  

M src/bin/pgbench/t/001_pgbench_with_server.pl
M src/test/isolation/expected/eval-plan-qual.out
A src/test/isolation/expected/inplace-inval.out
A src/test/isolation/expected/intra-grant-inplace-db.out
A src/test/isolation/expected/intra-grant-inplace.out
M src/test/isolation/isolation_schedule
M src/test/isolation/specs/eval-plan-qual.spec
A src/test/isolation/specs/inplace-inval.spec
A src/test/isolation/specs/intra-grant-inplace-db.spec
A src/test/isolation/specs/intra-grant-inplace.spec
M src/test/recovery/t/027_stream_regress.pl
A src/test/regress/expected/database.out
M src/test/regress/expected/merge.out
M src/test/regress/parallel_schedule
A src/test/regress/sql/database.sql
M src/test/regress/sql/merge.sql

Make TAP todo_start effects the same under Meson and prove_check.

commit   : 22a4b104ba70f6f486197ab28a28cd9bcdd4f4ad    
  
author   : Noah Misch <[email protected]>    
date     : Thu, 27 Jun 2024 19:21:04 -0700    
  
committer: Noah Misch <[email protected]>    
date     : Thu, 27 Jun 2024 19:21:04 -0700    

Click here for diff

This could have caused spurious failures only on SPARC Linux, because  
today's only todo_start tests for that platform.  Back-patch to v16,  
where Meson support first appeared.  
  
Reviewed by Robert Haas.  
  
Discussion: https://postgr.es/m/[email protected]  

M src/tools/testwrap

SQL/JSON: Document behavior when input document is not jsonb

commit   : 473a352fb393519f22cd4d31839ad3d74b1aeea1    
  
author   : Amit Langote <[email protected]>    
date     : Fri, 28 Jun 2024 09:42:13 +0900    
  
committer: Amit Langote <[email protected]>    
date     : Fri, 28 Jun 2024 09:42:13 +0900    

Click here for diff

The input document to functions JSON_EXISTS(), JSON_QUERY(),  
JSON_VALUE(), and JSON_TABLE() can be specified as character or  
UTF8-encoded bytea strings. These are automatically converted to  
jsonb with an implicit cast before being passed to the jsonpath  
machinery.  
  
In the current implementation, errors that occur when parsing the  
specified string into a valid JSON document are thrown  
unconditionally. This means they are not subject to the explicit or  
implicit ON ERROR clause of those functions, which is a standard-  
conforming behavior.  Add a note to the documentation to mention  
that.  
  
Reported-by: Markus Winand  
Discussion: https://postgr.es/m/F7DD1442-265C-4220-A603-CB0DEB77E91D%40winand.at  

M doc/src/sgml/func.sgml

Avoid crashing when a JIT-inlined backend function throws an error.

commit   : 5d6c64d290978dab76c00460ba809156874be035    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 27 Jun 2024 14:43:59 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 27 Jun 2024 14:43:59 -0400    

Click here for diff

errfinish() assumes that the __FUNC__ and __FILE__ arguments it's  
passed are compile-time constant strings that can just be pointed  
to rather than physically copied.  However, it's possible for LLVM  
to generate code in which those pointers point into a dynamically  
loaded code segment.  If that segment gets unloaded before we're  
done with the ErrorData struct, we have dangling pointers that  
will lead to SIGSEGV.  In simple cases that won't happen, because we  
won't unload LLVM code before end of transaction.  But it's possible  
to happen if the error is thrown within end-of-transaction code run by  
_SPI_commit or _SPI_rollback, because since commit 2e517818f those  
functions clean up by ending the transaction and starting a new one.  
  
Rather than fixing this by adding pstrdup() overhead to every  
elog/ereport sequence, let's fix it by copying the risky pointers  
in CopyErrorData().  That solves it for _SPI_commit/_SPI_rollback  
because they use that function to preserve the error data across  
the transaction end/restart sequence; and it seems likely that  
any other code doing something similar would need to do that too.  
  
I'm suspicious that this behavior amounts to an LLVM bug (or a  
bug in our use of it?), because it implies that string constant  
references that should be pointer-equal according to a naive  
understanding of C semantics will sometimes not be equal.  
However, even if it is a bug and someday gets fixed, we'll have  
to cope with the current behavior for a long time to come.  
  
Report and patch by me.  Back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/[email protected]  

M src/backend/utils/error/elog.c

Fix MVCC bug with prepared xact with subxacts on standby

commit   : cbfbda78413a5b2f4807e029407dcc98a0e63162    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Thu, 27 Jun 2024 21:06:32 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Thu, 27 Jun 2024 21:06:32 +0300    

Click here for diff

We did not recover the subtransaction IDs of prepared transactions  
when starting a hot standby from a shutdown checkpoint. As a result,  
such subtransactions were considered as aborted, rather than  
in-progress. That would lead to hint bits being set incorrectly, and  
the subtransactions suddenly becoming visible to old snapshots when  
the prepared transaction was committed.  
  
To fix, update pg_subtrans with prepared transactions's subxids when  
starting hot standby from a shutdown checkpoint. The snapshots taken  
from that state need to be marked as "suboverflowed", so that we also  
check the pg_subtrans.  
  
Backport to all supported versions.  
  
Discussion: https://www.postgresql.org/message-id/[email protected]  

M src/backend/access/transam/twophase.c
M src/backend/access/transam/xlog.c
M src/backend/storage/ipc/procarray.c
M src/backend/storage/ipc/standby.c
M src/include/storage/standby.h
M src/test/recovery/t/009_twophase.pl
M src/tools/pgindent/typedefs.list

tests: Trim newline from result returned by BackgroundPsql->query

commit   : ecbf6ac51df27275fb0db493bf163ef98ac00c6a    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Thu, 27 Jun 2024 21:06:27 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Thu, 27 Jun 2024 21:06:27 +0300    

Click here for diff

This went unnoticed, because only a few existing callers of  
BackgroundPsql->query used the result, and the ones that did were not  
bothered by an extra newline. I noticed because I was about to add a  
new test that checks the result.  
  
Backport to all supported versions, since I just backported the  
BackgroundPsql facility to all supported versions too.  

M src/test/perl/PostgreSQL/Test/BackgroundPsql.pm

Fix thinkos in comments

commit   : a2dff271ebe2a0547d46e90dcb02c088cf2f031c    
  
author   : Alvaro Herrera <[email protected]>    
date     : Thu, 27 Jun 2024 19:51:47 +0200    
  
committer: Alvaro Herrera <[email protected]>    
date     : Thu, 27 Jun 2024 19:51:47 +0200    

Click here for diff

The first one was noticed by Tender Wang and introduced with  
8aba9322511f; the other one was newly introduced with dbca3469ebf8.  

M src/backend/executor/execPartition.c

Drop the temporary tuple slots allocated by pgoutput.

commit   : 3e53492aa7084bceaa92757c90e067d79768797e    
  
author   : Amit Kapila <[email protected]>    
date     : Thu, 27 Jun 2024 11:35:00 +0530    
  
committer: Amit Kapila <[email protected]>    
date     : Thu, 27 Jun 2024 11:35:00 +0530    

Click here for diff

In pgoutput, when converting the child table's tuple format to match the  
parent table's, we temporarily create a new slot to store the converted  
tuple. However, we missed to drop such temporary slots, leading to  
resource leakage.  
  
Reported-by: Bowen Shi  
Author: Hou Zhijie  
Reviewed-by: Amit Kapila  
Backpatch-through: 15  
Discussion: https://postgr.es/m/CAM_vCudv8dc3sjWiPkXx5F2b27UV7_YRKRbtSCcE-pv=cVACGA@mail.gmail.com  

M src/backend/replication/pgoutput/pgoutput.c

Fix overflow with pgstats DSA reference count

commit   : 7467939ea226ebc5608285486501b136b642c02b    
  
author   : Michael Paquier <[email protected]>    
date     : Thu, 27 Jun 2024 09:44:47 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Thu, 27 Jun 2024 09:44:47 +0900    

Click here for diff

When pgstats is initialized for a backend, it uses dsa_attach_in_place()  
without a "segment" provided.  Hence, no callback is registered to  
automatically release the DSA attached once a backend exits.  Not doing  
any cleanup causes the reference count of the pgstats DSA to  
continuously increment, at some point overflowing it (the more the  
number of connections, the faster it is to reach this state).  Once the  
reference count overflows and then gets back to 0, new backends are not  
able to attach to the pgstats DSA, failing startup.  
  
This issue is resolved by adding in the pgstats shutdown hook a call to  
dsa_release_in_place(), ensuring that the DSA attached at backend  
startup is correctly released, keeping the reference count at bay.  
  
The author of this patch has been able to see this issue on a server  
with a long uptime and a high connection turnover.  
  
Issue introduced by 5891c7a8ed8f, so backpatch down to 15.  
  
Author: Anthonin Bonnefoy  
Discussion: https://postgr.es/m/CAO6_XqqJbJBL=M7Ym13TcB4Xnq58vRa2jcC+gwEPBgbAda6B1Q@mail.gmail.com  
Backpatch-through: 15  

M src/backend/utils/activity/pgstat_shmem.c

Fix bugs in MultiXact truncation

commit   : b1ffe3ff0b7ed87b34ae0fc6eba71bf032e41b59    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Fri, 21 Jun 2024 18:31:15 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Fri, 21 Jun 2024 18:31:15 +0300    

Click here for diff

1. TruncateMultiXact() performs the SLRU truncations in a critical  
section. Deleting the SLRU segments calls ForwardSyncRequest(), which  
will try to compact the request queue if it's full  
(CompactCheckpointerRequestQueue()). That in turn allocates memory,  
which is not allowed in a critical section. Backtrace:  
  
    TRAP: failed Assert("CritSectionCount == 0 || (context)->allowInCritSection"), File: "../src/backend/utils/mmgr/mcxt.c", Line: 1353, PID: 920981  
    postgres: autovacuum worker template0(ExceptionalCondition+0x6e)[0x560a501e866e]  
    postgres: autovacuum worker template0(+0x5dce3d)[0x560a50217e3d]  
    postgres: autovacuum worker template0(ForwardSyncRequest+0x8e)[0x560a4ffec95e]  
    postgres: autovacuum worker template0(RegisterSyncRequest+0x2b)[0x560a50091eeb]  
    postgres: autovacuum worker template0(+0x187b0a)[0x560a4fdc2b0a]  
    postgres: autovacuum worker template0(SlruDeleteSegment+0x101)[0x560a4fdc2ab1]  
    postgres: autovacuum worker template0(TruncateMultiXact+0x2fb)[0x560a4fdbde1b]  
    postgres: autovacuum worker template0(vac_update_datfrozenxid+0x4b3)[0x560a4febd2f3]  
    postgres: autovacuum worker template0(+0x3adf66)[0x560a4ffe8f66]  
    postgres: autovacuum worker template0(AutoVacWorkerMain+0x3ed)[0x560a4ffe7c2d]  
    postgres: autovacuum worker template0(+0x3b1ead)[0x560a4ffecead]  
    postgres: autovacuum worker template0(+0x3b620e)[0x560a4fff120e]  
    postgres: autovacuum worker template0(+0x3b3fbb)[0x560a4ffeefbb]  
    postgres: autovacuum worker template0(+0x2f724e)[0x560a4ff3224e]  
    /lib/x86_64-linux-gnu/libc.so.6(+0x27c8a)[0x7f62cc642c8a]  
    /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x85)[0x7f62cc642d45]  
    postgres: autovacuum worker template0(_start+0x21)[0x560a4fd16f31]  
  
To fix, bail out in CompactCheckpointerRequestQueue() without doing  
anything, if it's called in a critical section. That covers the above  
call path, as well as any other similar cases where  
RegisterSyncRequest might be called in a critical section.  
  
2. After fixing that, another problem became apparent: Autovacuum  
process doing that truncation can deadlock with the checkpointer  
process. TruncateMultiXact() sets "MyProc->delayChkptFlags |=  
DELAY_CHKPT_START". If the sync request queue is full and cannot be  
compacted, the process will repeatedly sleep and retry, until there is  
room in the queue. However, if the checkpointer is trying to start a  
checkpoint at the same time, and is waiting for the DELAY_CHKPT_START  
processes to finish, the queue will never shrink.  
  
More concretely, the autovacuum process is stuck here:  
  
    #0  0x00007fc934926dc3 in epoll_wait () from /lib/x86_64-linux-gnu/libc.so.6  
    #1  0x000056220b24348b in WaitEventSetWaitBlock (set=0x56220c2e4b50, occurred_events=0x7ffe7856d040, nevents=1, cur_timeout=<optimized out>) at ../src/backend/storage/ipc/latch.c:1570  
    #2  WaitEventSetWait (set=0x56220c2e4b50, timeout=timeout@entry=10, occurred_events=<optimized out>, occurred_events@entry=0x7ffe7856d040, nevents=nevents@entry=1,  
        wait_event_info=wait_event_info@entry=150994949) at ../src/backend/storage/ipc/latch.c:1516  
    #3  0x000056220b243224 in WaitLatch (latch=<optimized out>, latch@entry=0x0, wakeEvents=wakeEvents@entry=40, timeout=timeout@entry=10, wait_event_info=wait_event_info@entry=150994949)  
        at ../src/backend/storage/ipc/latch.c:538  
    #4  0x000056220b26cf46 in RegisterSyncRequest (ftag=ftag@entry=0x7ffe7856d0a0, type=type@entry=SYNC_FORGET_REQUEST, retryOnError=true) at ../src/backend/storage/sync/sync.c:614  
    #5  0x000056220af9db0a in SlruInternalDeleteSegment (ctl=ctl@entry=0x56220b7beb60 <MultiXactMemberCtlData>, segno=segno@entry=11350) at ../src/backend/access/transam/slru.c:1495  
    #6  0x000056220af9dab1 in SlruDeleteSegment (ctl=ctl@entry=0x56220b7beb60 <MultiXactMemberCtlData>, segno=segno@entry=11350) at ../src/backend/access/transam/slru.c:1566  
    #7  0x000056220af98e1b in PerformMembersTruncation (oldestOffset=<optimized out>, newOldestOffset=<optimized out>) at ../src/backend/access/transam/multixact.c:3006  
    #8  TruncateMultiXact (newOldestMulti=newOldestMulti@entry=3221225472, newOldestMultiDB=newOldestMultiDB@entry=4) at ../src/backend/access/transam/multixact.c:3201  
    #9  0x000056220b098303 in vac_truncate_clog (frozenXID=749, minMulti=<optimized out>, lastSaneFrozenXid=749, lastSaneMinMulti=3221225472) at ../src/backend/commands/vacuum.c:1917  
    #10 vac_update_datfrozenxid () at ../src/backend/commands/vacuum.c:1760  
    #11 0x000056220b1c3f76 in do_autovacuum () at ../src/backend/postmaster/autovacuum.c:2550  
    #12 0x000056220b1c2c3d in AutoVacWorkerMain (startup_data=<optimized out>, startup_data_len=<optimized out>) at ../src/backend/postmaster/autovacuum.c:1569  
  
and the checkpointer is stuck here:  
  
    #0  0x00007fc9348ebf93 in clock_nanosleep () from /lib/x86_64-linux-gnu/libc.so.6  
    #1  0x00007fc9348fe353 in nanosleep () from /lib/x86_64-linux-gnu/libc.so.6  
    #2  0x000056220b40ecb4 in pg_usleep (microsec=microsec@entry=10000) at ../src/port/pgsleep.c:50  
    #3  0x000056220afb43c3 in CreateCheckPoint (flags=flags@entry=108) at ../src/backend/access/transam/xlog.c:7098  
    #4  0x000056220b1c6e86 in CheckpointerMain (startup_data=<optimized out>, startup_data_len=<optimized out>) at ../src/backend/postmaster/checkpointer.c:464  
  
To fix, add AbsorbSyncRequests() to the loops where the checkpointer  
waits for DELAY_CHKPT_START or DELAY_CHKPT_COMPLETE operations to  
finish.  
  
Backpatch to v14. Before that, SLRU deletion didn't call  
RegisterSyncRequest, which avoided this failure. I'm not sure if there  
are other similar scenarios on older versions, but we haven't had  
any such reports.  
  
Discussion: https://www.postgresql.org/message-id/[email protected]  

M src/backend/access/transam/xlog.c
M src/backend/postmaster/checkpointer.c

doc PG 17 relnotes: fix system catalog name mistake

commit   : f92fd1830715ac2039443756475169a45cae2874    
  
author   : Bruce Momjian <[email protected]>    
date     : Wed, 26 Jun 2024 15:08:06 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Wed, 26 Jun 2024 15:08:06 -0400    

Click here for diff

Reported-by: David G. Johnston  
  
Discussion: https://postgr.es/m/CAKFQuwYgkaOuao4DXuQwhbg+vyu4Xb5TGpuDNDOfMa0AftyweQ@mail.gmail.com  
  
Backpatch-through: master  

M doc/src/sgml/release-17.sgml

doc PG 17 relnotes: add item about pg_collation column renames

commit   : d537b2e037e580b03c284bf3fcb02be6c3d5c8f2    
  
author   : Bruce Momjian <[email protected]>    
date     : Wed, 26 Jun 2024 13:13:46 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Wed, 26 Jun 2024 13:13:46 -0400    

Click here for diff

Reported-by: David G. Johnston  
  
Discussion: https://postgr.es/m/CAKFQuwYRw30QaWrSsL57k3L_=zdQ4JTgY9pGnnhm42B7fGJX1A@mail.gmail.com  
  
Backpatch-through: master  

M doc/src/sgml/release-17.sgml

Use PqMsg_* macros in fe-auth.c.

commit   : 32f07991b728c25bcd2543ef22ec96105e558477    
  
author   : Nathan Bossart <[email protected]>    
date     : Wed, 26 Jun 2024 11:25:38 -0500    
  
committer: Nathan Bossart <[email protected]>    
date     : Wed, 26 Jun 2024 11:25:38 -0500    

Click here for diff

Commit f4b54e1ed9, which introduced macros for protocol characters,  
missed updating a few places in fe-auth.c.  
  
Author: Jelte Fennema-Nio  
Discussion: https://postgr.es/m/CAGECzQSoPHtZ4xe0raJ6FYSEiPPS%2BYWXBhOGo%2BY1YecLgknF3g%40mail.gmail.com  

M src/interfaces/libpq/fe-auth.c

Fix nbtree array unsatisfied inequality check.

commit   : 486c2ea25c5e7e248c31b2dbb5db8ebcd3c7d813    
  
author   : Peter Geoghegan <[email protected]>    
date     : Wed, 26 Jun 2024 10:45:52 -0400    
  
committer: Peter Geoghegan <[email protected]>    
date     : Wed, 26 Jun 2024 10:45:52 -0400    

Click here for diff

_bt_advance_array_keys didn't take sufficient care at the point where it  
decides whether to start a new primitive index scan based on a call to  
_bt_check_compare against finaltup (a call with the scan direction  
flipped around).  The final decision was conditioned on rules about how  
the scan key offset sktrig that initially triggered array advancement  
(passed to _bt_advance_array_keys from its _bt_checkkeys caller)  
compared to the offset set by its own _bt_check_compare finaltup call.  
This approach was faulty, in that it allowed _bt_advance_array_keys to  
incorrectly start a new primitive index scan, that landed on the same  
leaf page (on assert-enabled builds it led to an assertion failure).  
  
In general, scans with array keys are expected to never have to read the  
same leaf page more than once (barring cases involving cursors, and  
cases where the scan restores a marked position for the inner side of a  
merge join).  This principle was established by commit 5bf748b8.  
  
To fix, make the final decision based on whether the scan key offset set  
by the _bt_check_compare finaltup call is an offset to an inequality  
strategy scan key.  An unsatisfied required inequality strategy scan key  
indicates that all of the scan's required equality strategy scan keys  
must also be satisfied by finaltup (not just by caller's tuple), and  
that there is a decent chance that _bt_first will be able to reposition  
the scan to a position many leaf pages ahead of the current leaf page.  
  
Oversight in commit 5bf748b8.  
  
Discussion: https://postgr.es/m/CAH2-Wz=DyHbcg7o6zXqzyiin8WE8vzk4tvU8Lrnh-a=EAvO0TQ@mail.gmail.com  

M src/backend/access/nbtree/nbtutils.c

Fix partition pruning setup during DETACH CONCURRENTLY

commit   : dbca3469ebf8ac523f401dd0c2eaffd9df64078f    
  
author   : Alvaro Herrera <[email protected]>    
date     : Wed, 26 Jun 2024 13:40:26 +0200    
  
committer: Alvaro Herrera <[email protected]>    
date     : Wed, 26 Jun 2024 13:40:26 +0200    

Click here for diff

When detaching partition in concurrent mode, it's possible for partition  
descriptors to not match the set that was recently seen when the plan  
was made, causing an assertion failure or (in production builds) failure  
to construct a working plan.  The case that was reported involves  
prepared statements, but I think it may be possible to hit this bug  
without that too.  
  
The problem is that CreatePartitionPruneState is constructing a  
PartitionPruneState under the assumption that new partitions can be  
added, but never removed, but it turns out that this isn't true: a  
prepared statement gets replanned when the DETACH CONCURRENTLY session  
sends out its invalidation message, but if the invalidation message  
arrives after ExecInitAppend started, we would build a partition  
descriptor without the partition, and then CreatePartitionPruneState  
would refuse to work with it.  
  
CreatePartitionPruneState already contains code to deal with the new  
descriptor having more partitions than before (and behaving for the  
extra partitions as if they had been pruned), but doesn't have code to  
deal with less partitions than before, and it is naïve about the case  
where the number of partitions is the same.  We could simply add that a  
new stanza for less partitions than before, and in simple testing it  
works to do that; but it's possible to press the test scripts even  
further and hit the case where one partition is added and a partition is  
removed quickly enough that we see the same number of partitions, but  
they don't actually match, causing hangs during execution.  
  
To cope with both these problems, we now memcmp() the arrays of  
partition OIDs, and do a more elaborate mapping (relying on the fact  
that both OID arrays are in partition-bounds order) if they're not  
identical.  
  
This fix was already pushed in backbranches earlier.  
  
Reported-by: yajun Hu <[email protected]>  
Reviewed-by: Tender Wang <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  

M src/backend/executor/execPartition.c

Improve comment in gram.y.

commit   : 1bf29f51fa1a15bd5d28e64070e6e8d105338fc3    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 25 Jun 2024 17:53:41 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 25 Jun 2024 17:53:41 -0400    

Click here for diff

"As so-and-so" isn't bad English, but it has a faintly archaic  
whiff to it, and confuses some non-native speakers.  Write  
"Like so-and-so" instead.  
  
Per complaint from Tatsuo Ishii.  
  
Discussion: https://postgr.es/m/20240623.130154.1867056921698616251.t-ishii@sranhm.sra.co.jp.sranhm  

M src/backend/parser/gram.y

Stamp 17beta2.

commit   : 23c5a0e7d43bc925c6001538f04a458933a11fc1    
  
author   : Joe Conway <[email protected]>    
date     : Mon, 24 Jun 2024 17:24:14 -0400    
  
committer: Joe Conway <[email protected]>    
date     : Mon, 24 Jun 2024 17:24:14 -0400    

Click here for diff

M configure
M configure.ac
M meson.build

Revert "Fix partition pruning setup during DETACH CONCURRENTLY"

commit   : b0ea16528cda1f3a993bbfeb2b93eed9762af4e6    
  
author   : Alvaro Herrera <[email protected]>    
date     : Mon, 24 Jun 2024 17:20:21 +0200    
  
committer: Alvaro Herrera <[email protected]>    
date     : Mon, 24 Jun 2024 17:20:21 +0200    

Click here for diff

This reverts commit 27162a64b386; this branch is in code freeze due to a  
nearing release.  We can commit again after the release is out.  
  
Discussion: https://postgr.es/m/[email protected]  

M src/backend/executor/execPartition.c

Fix partition pruning setup during DETACH CONCURRENTLY

commit   : 27162a64b386a1f639a4f2b96c7cc3b1db192d92    
  
author   : Alvaro Herrera <[email protected]>    
date     : Mon, 24 Jun 2024 15:56:32 +0200    
  
committer: Alvaro Herrera <[email protected]>    
date     : Mon, 24 Jun 2024 15:56:32 +0200    

Click here for diff

When detaching partition in concurrent mode, it's possible for partition  
descriptors to not match the set that was recently seen when the plan  
was made, causing an assertion failure or (in production builds) failure  
to construct a working plan.  The case that was reported involves  
prepared statements, but I think it may be possible to hit this bug  
without that too.  
  
The problem is that CreatePartitionPruneState is constructing a  
PartitionPruneState under the assumption that new partitions can be  
added, but never removed, but it turns out that this isn't true: a  
prepared statement gets replanned when the DETACH CONCURRENTLY session  
sends out its invalidation message, but if the invalidation message  
arrives after ExecInitAppend started, we would build a partition  
descriptor without the partition, and then CreatePartitionPruneState  
would refuse to work with it.  
  
CreatePartitionPruneState already contains code to deal with the new  
descriptor having more partitions than before (and behaving for the  
extra partitions as if they had been pruned), but doesn't have code to  
deal with less partitions than before, and it is naïve about the case  
where the number of partitions is the same.  We could simply add that a  
new stanza for less partitions than before, and in simple testing it  
works to do that; but it's possible to press the test scripts even  
further and hit the case where one partition is added and a partition is  
removed quickly enough that we see the same number of partitions, but  
they don't actually match, causing hangs during execution.  
  
To cope with both these problems, we now memcmp() the arrays of  
partition OIDs, and do a more elaborate mapping (relying on the fact  
that both OID arrays are in partition-bounds order) if they're not  
identical.  
  
Backpatch to 14, where DETACH CONCURRENTLY appeared.  
  
Reported-by: yajun Hu <[email protected]>  
Reviewed-by: Tender Wang <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  

M src/backend/executor/execPartition.c

Translation updates

commit   : f7f4e7e6fa576761f5330963cb7af686957589b4    
  
author   : Peter Eisentraut <[email protected]>    
date     : Mon, 24 Jun 2024 13:11:27 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Mon, 24 Jun 2024 13:11:27 +0200    

Click here for diff

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

M src/backend/po/de.po
M src/backend/po/es.po
M src/backend/po/ja.po
M src/backend/po/ka.po
M src/bin/initdb/po/de.po
M src/bin/initdb/po/ja.po
M src/bin/initdb/po/ka.po
M src/bin/pg_amcheck/po/de.po
M src/bin/pg_amcheck/po/ja.po
M src/bin/pg_amcheck/po/ka.po
M src/bin/pg_archivecleanup/po/de.po
M src/bin/pg_basebackup/po/de.po
M src/bin/pg_basebackup/po/ja.po
M src/bin/pg_basebackup/po/ka.po
M src/bin/pg_checksums/po/de.po
M src/bin/pg_combinebackup/po/de.po
M src/bin/pg_combinebackup/po/ja.po
M src/bin/pg_combinebackup/po/ka.po
M src/bin/pg_config/po/de.po
M src/bin/pg_controldata/po/de.po
M src/bin/pg_controldata/po/ja.po
M src/bin/pg_ctl/po/de.po
M src/bin/pg_dump/po/de.po
M src/bin/pg_dump/po/ja.po
M src/bin/pg_dump/po/ka.po
M src/bin/pg_resetwal/po/de.po
M src/bin/pg_rewind/po/de.po
M src/bin/pg_rewind/po/ja.po
M src/bin/pg_rewind/po/ka.po
M src/bin/pg_test_fsync/po/de.po
M src/bin/pg_test_fsync/po/ja.po
M src/bin/pg_test_timing/po/de.po
M src/bin/pg_upgrade/po/de.po
M src/bin/pg_upgrade/po/ja.po
M src/bin/pg_upgrade/po/ka.po
M src/bin/pg_verifybackup/po/de.po
M src/bin/pg_verifybackup/po/ja.po
M src/bin/pg_verifybackup/po/ka.po
M src/bin/pg_waldump/po/de.po
M src/bin/pg_walsummary/po/de.po
M src/bin/pg_walsummary/po/ja.po
M src/bin/psql/po/de.po
M src/bin/psql/po/ja.po
M src/bin/psql/po/ka.po
M src/bin/scripts/po/de.po
M src/bin/scripts/po/ja.po
M src/bin/scripts/po/ka.po
M src/interfaces/libpq/po/de.po
M src/interfaces/libpq/po/ja.po
M src/interfaces/libpq/po/ka.po
M src/pl/tcl/po/de.po
M src/pl/tcl/po/ja.po
M src/pl/tcl/po/ka.po

Remove extra comment at TableAmRoutine.scan_analyze_next_block

commit   : 70a845c04a47645b58f8276a6b3ab201ea8ec426    
  
author   : Alexander Korotkov <[email protected]>    
date     : Sat, 22 Jun 2024 16:13:08 +0300    
  
committer: Alexander Korotkov <[email protected]>    
date     : Sat, 22 Jun 2024 16:13:08 +0300    

Click here for diff

The extra comment was accidentally copied here by 6377e12a from  
heapam_scan_analyze_next_block().  
  
Reported-by: Matthias van de Meent  
Discussion: https://postgr.es/m/CAEze2WjC5PiweG-4oe0hB_Zr59iF3tRE1gURm8w4Cg5b6JEBGw%40mail.gmail.com  

M src/include/access/tableam.h

commit   : a8ffa32377a765fc8d3c4354cdd5a258f596c810    
  
author   : Bruce Momjian <[email protected]>    
date     : Fri, 21 Jun 2024 12:08:14 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Fri, 21 Jun 2024 12:08:14 -0400    

Click here for diff

Backpatch-through: master  

M doc/src/sgml/release-17.sgml

Fix relcache invalidation when relfilelocator is updated

commit   : 441ef5e1badcc3695de4a865cffb30f0e5057893    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Fri, 21 Jun 2024 17:13:10 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Fri, 21 Jun 2024 17:13:10 +0300    

Click here for diff

In commit af0e7deb4a, I removed a call to RelationCloseSmgr(), because  
the dangling SMgrRelation was no longer an issue. However, we still  
need the call when the relation's relfilelocator changes, so that the  
new relfilelocator takes effect immediately.  
  
Reported-by: Alexander Lakhin <[email protected]>  
Discussion: https://www.postgresql.org/message-id/987b1c8c-8c91-4847-ca0e-879f421680ff%40gmail.com  

M src/backend/utils/cache/relcache.c

commit   : 90fe7b74df976324d7c0b3d203b25b7333447ca3    
  
author   : Bruce Momjian <[email protected]>    
date     : Fri, 21 Jun 2024 10:11:12 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Fri, 21 Jun 2024 10:11:12 -0400    

Click here for diff

Backpatch-through: master  

M doc/src/sgml/release-17.sgml

Add doc entry for the new GUC paramenter enable_group_by_reordering

commit   : 82e79ee46b1c880cb7376cf4399c9883c1ddfaea    
  
author   : Alexander Korotkov <[email protected]>    
date     : Fri, 21 Jun 2024 15:39:13 +0300    
  
committer: Alexander Korotkov <[email protected]>    
date     : Fri, 21 Jun 2024 15:39:13 +0300    

Click here for diff

0452b461bc4 adds alternative orderings of group-by keys during the query  
optimization. This new feature is controlled by the new GUC parameter  
enable_group_by_reordering, which accidentally came without the documentation.  
This commit adds the missing documentation for that GUC.  
  
Reported-by: Bruce Momjian  
Discussion: https://postgr.es/m/ZnDx2FYlba_OafQd%40momjian.us  
Author: Andrei Lepikhov  
Reviewed-by: Pavel Borisov, Alexander Korotkov  

M doc/src/sgml/config.sgml

Prevent access of uninitialized memory in radix tree nodes

commit   : fd49e8f32325c675d9bb6e26fcdbe9754249932f    
  
author   : John Naylor <[email protected]>    
date     : Fri, 21 Jun 2024 14:59:11 +0700    
  
committer: John Naylor <[email protected]>    
date     : Fri, 21 Jun 2024 14:59:11 +0700    

Click here for diff

RT_NODE_16_SEARCH_EQ() performs comparisions using vector registers  
on x64-64 and aarch64. We apply a mask to the resulting bitfield  
to eliminate irrelevant bits that may be set. This ensures correct  
behavior, but Valgrind complains of the partially-uninitialised  
values. So far the warnings have only occurred on aarch64, which  
explains why this hasn't been seen earlier.  
  
To fix this warning, initialize the whole fixed-sized part of the nodes  
upon allocation, rather than just do the minimum initialization to  
function correctly. The initialization for node48 is a bit different  
in that the 256-byte slot index array must be populated with "invalid  
index" rather than zero. Experimentation has shown that compilers  
tend to emit code that uselessly memsets that array twice. To avoid  
pessimizing this path, swap the order of the slot_idxs[] and isset[]  
arrays so we can initialize with two non-overlapping memset calls.  
  
Reported by Tomas Vondra  
Analysis and patch by Tom Lane, reviewed by Masahiko Sawada. I  
investigated the behavior of memset calls to overlapping regions,  
leading to the above tweaks to node48 as discussed in the thread.  
  
Discussion: https://postgr.es/m/120c63ad-3d12-415f-a7bf-3da451c31bf6%40enterprisedb.com  

M src/include/lib/radixtree.h

pg_combinebackup: Error message improvements

commit   : c5c82123d3050c3a5eef0f51e9783f1cc5004ba0    
  
author   : Peter Eisentraut <[email protected]>    
date     : Fri, 21 Jun 2024 09:40:44 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Fri, 21 Jun 2024 09:40:44 +0200    

Click here for diff

Make the wordings of some file-related error messages more like those  
used in other files.  

M src/bin/pg_combinebackup/backup_label.c
M src/bin/pg_combinebackup/copy_file.c
M src/bin/pg_combinebackup/load_manifest.c
M src/bin/pg_combinebackup/pg_combinebackup.c
M src/bin/pg_combinebackup/reconstruct.c
M src/bin/pg_combinebackup/write_manifest.c

Remove redundant newlines from error messages

commit   : aea79883c57a522f0234d135fe0a3de19178a964    
  
author   : Peter Eisentraut <[email protected]>    
date     : Fri, 21 Jun 2024 09:29:34 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Fri, 21 Jun 2024 09:29:34 +0200    

Click here for diff

M src/bin/pg_combinebackup/pg_combinebackup.c

Fix make build on MinGW

commit   : 58445651dbc6182e1ff4100f6428ba6a261407f9    
  
author   : Peter Eisentraut <[email protected]>    
date     : Fri, 21 Jun 2024 08:17:23 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Fri, 21 Jun 2024 08:17:23 +0200    

Click here for diff

Revert a couple of the simplifications done in commit 721856ff24b  
because platforms without ln -s, where LN_S='cp -pR', such as MinGW,  
required the specific previous incantations.  
  
Reported-by: Noah Misch <[email protected]>  
Discussion: https://www.postgresql.org/message-id/[email protected]  

M src/backend/Makefile

parse_manifest: Use const char *

commit   : 02bbc3c83aec597e4b8c873916e9e29f3d02b132    
  
author   : Peter Eisentraut <[email protected]>    
date     : Fri, 21 Jun 2024 07:50:02 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Fri, 21 Jun 2024 07:50:02 +0200    

Click here for diff

This adapts the manifest parsing code to take advantage of the  
const-ified jsonapi.  
  
Reviewed-by: Andrew Dunstan <[email protected]>  
Discussion: https://www.postgresql.org/message-id/flat/f732b014-f614-4600-a437-dba5a2c3738b%40eisentraut.org  

M src/backend/backup/basebackup_incremental.c
M src/bin/pg_combinebackup/load_manifest.c
M src/bin/pg_combinebackup/load_manifest.h
M src/bin/pg_verifybackup/pg_verifybackup.c
M src/common/parse_manifest.c
M src/include/common/parse_manifest.h

jsonapi: Use const char *

commit   : 15cd9a3881b030a1a4bddc809f038f86ec27e66d    
  
author   : Peter Eisentraut <[email protected]>    
date     : Fri, 21 Jun 2024 07:50:02 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Fri, 21 Jun 2024 07:50:02 +0200    

Click here for diff

Apply const qualifiers to char * arguments and fields throughout the  
jsonapi.  This allows the top-level APIs such as  
pg_parse_json_incremental() to declare their input argument as const.  
It also reduces the number of unconstify() calls.  
  
Reviewed-by: Andrew Dunstan <[email protected]>  
Discussion: https://www.postgresql.org/message-id/flat/f732b014-f614-4600-a437-dba5a2c3738b%40eisentraut.org  

M src/backend/utils/adt/jsonfuncs.c
M src/common/jsonapi.c
M src/include/common/jsonapi.h

jsonapi: Use size_t

commit   : 0b06bf9fa972e2964401622f1bb4c611dbe92bd5    
  
author   : Peter Eisentraut <[email protected]>    
date     : Fri, 21 Jun 2024 07:50:02 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Fri, 21 Jun 2024 07:50:02 +0200    

Click here for diff

Use size_t instead of int for object sizes in the jsonapi.  This makes  
the API better self-documenting.  
  
Reviewed-by: Andrew Dunstan <[email protected]>  
Discussion: https://www.postgresql.org/message-id/flat/f732b014-f614-4600-a437-dba5a2c3738b%40eisentraut.org  

M src/common/jsonapi.c
M src/common/parse_manifest.c
M src/include/common/jsonapi.h
M src/include/common/parse_manifest.h

Doc: Generated columns are skipped for logical replication.

commit   : 7a089f6e6a14ca3a5dc8822c393c6620279968b9    
  
author   : Amit Kapila <[email protected]>    
date     : Fri, 21 Jun 2024 09:55:25 +0530    
  
committer: Amit Kapila <[email protected]>    
date     : Fri, 21 Jun 2024 09:55:25 +0530    

Click here for diff

Add a note in docs that generated columns are skipped for logical  
replication.  
  
Author: Peter Smith  
Reviewed-by: Peter Eisentraut  
Backpatch-through: 12  
Discussion: https://postgr.es/m/CAHut+PuXb1GLQztQkoWzYjSwkAZZ0dgCJaAHyJtZF3kmtcL=kA@mail.gmail.com  

M doc/src/sgml/ddl.sgml

doc PG 17 relnotes: remove mention of undocumented GUC

commit   : 95cabf542f04b634303f899600ea62fb256a08c2    
  
author   : Bruce Momjian <[email protected]>    
date     : Thu, 20 Jun 2024 19:53:01 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Thu, 20 Jun 2024 19:53:01 -0400    

Click here for diff

GUC is trace_connection_negotiation.  If it is undocumented, we should  
not mention it in the release notes.  
  
Backpatch-through: master  

M doc/src/sgml/release-17.sgml

Don't throw an error if a queued AFTER trigger no longer exists.

commit   : e6d0d16adf7fb7e715314d5068db4b875c3edf00    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 20 Jun 2024 14:21:36 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 20 Jun 2024 14:21:36 -0400    

Click here for diff

afterTriggerInvokeEvents and AfterTriggerExecute have always  
treated it as an error if the trigger OID mentioned in a queued  
after-trigger event can't be found.  However, that fails to  
account for the edge case where the trigger's been dropped in  
the current transaction since queueing the event.  There seems  
no very good reason to disallow that case, so instead silently  
do nothing if the trigger OID can't be found.  
  
This does give up a little bit of bug-detection ability, but I don't  
recall that these error messages have ever actually revealed a bug,  
so it seems mostly theoretical.  Alternatives such as marking  
pending events DONE at the time of dropping a trigger would be  
complicated and perhaps introduce bugs of their own.  
  
Per bug #18517 from Alexander Lakhin.  Back-patch to all  
supported branches.  
  
Discussion: https://postgr.es/m/[email protected]  

M src/backend/commands/trigger.c
M src/test/regress/expected/triggers.out
M src/test/regress/sql/triggers.sql

pg_combinebackup: Fix small mistake in --help output

commit   : ab4346ebbfef44db857321d74bc0c31e03a72514    
  
author   : Peter Eisentraut <[email protected]>    
date     : Thu, 20 Jun 2024 11:49:01 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Thu, 20 Jun 2024 11:49:01 +0200    

Click here for diff

It was not showing that the --output option takes an argument.  

M src/bin/pg_combinebackup/pg_combinebackup.c

pg_createsubscriber: Indent --help output correctly

commit   : d048a327890851f37c8a0d0b8522cb8064ad7cfc    
  
author   : Peter Eisentraut <[email protected]>    
date     : Thu, 20 Jun 2024 11:42:40 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Thu, 20 Jun 2024 11:42:40 +0200    

Click here for diff

It was using 1 space indent instead of the 2 spaces used everywhere  
else.  

M src/bin/pg_basebackup/pg_createsubscriber.c

pg_dump: Fix weird error message composition

commit   : 3639d08e2f36f76e9a626c60b534c7fe204f329c    
  
author   : Peter Eisentraut <[email protected]>    
date     : Thu, 20 Jun 2024 11:36:38 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Thu, 20 Jun 2024 11:36:38 +0200    

Click here for diff

The previous way could make it look like "stdin" was the actual input  
file name.  Write it as two separate messages instead.  

M src/bin/pg_dump/filter.c

Fix redundancy in error messages

commit   : 16a3415440ecf2f5cd02848fc05cbfe040ce14c2    
  
author   : Peter Eisentraut <[email protected]>    
date     : Thu, 20 Jun 2024 11:17:21 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Thu, 20 Jun 2024 11:17:21 +0200    

Click here for diff

pg_log_error() already prints the program name, so we don't need to  
print it again inside the message.  

M src/bin/pg_combinebackup/pg_combinebackup.c
M src/bin/pg_walsummary/pg_walsummary.c

Unify some error messages

commit   : 95b44bb025b5d13c673662af68a218bd1873861f    
  
author   : Peter Eisentraut <[email protected]>    
date     : Thu, 20 Jun 2024 11:10:26 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Thu, 20 Jun 2024 11:10:26 +0200    

Click here for diff

M contrib/pg_prewarm/autoprewarm.c
M src/backend/postmaster/bgworker.c

meson: Fix import library name in Windows

commit   : c61c0cb3a99285db36806b592bd8c540c98757e5    
  
author   : Peter Eisentraut <[email protected]>    
date     : Thu, 20 Jun 2024 08:09:28 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Thu, 20 Jun 2024 08:09:28 +0200    

Click here for diff

This changes the import library name from 'postgres.exe.lib' to  
'postgres.lib', which is what it was with the old MSVC build system.  
Extension builds use that name.  
  
Bug: #18513  
Reported-by: Muralikrishna Bandaru <[email protected]>  

M meson.build
M src/backend/meson.build

Fix comment in pg_upgrade.h.

commit   : 832dc19ea681a54c153228a96112bea68dbff022    
  
author   : Nathan Bossart <[email protected]>    
date     : Wed, 19 Jun 2024 16:12:18 -0500    
  
committer: Nathan Bossart <[email protected]>    
date     : Wed, 19 Jun 2024 16:12:18 -0500    

Click here for diff

Contrary to what the comment for the "check" struct member claims,  
'pg_upgrade --check' performs only the checks and does not ask the  
user for permission to make changes.  
  
Reviewed-by: Daniel Gustafsson  
Discussion: https://postgr.es/m/ZnHk7ci5IuTWVc_c%40nathan  

M src/bin/pg_upgrade/pg_upgrade.h

SQL/JSON: Correctly enforce the default ON EMPTY behavior

commit   : 03ec203164119f11f0eab4c83c97a8527e2b108d    
  
author   : Amit Langote <[email protected]>    
date     : Wed, 19 Jun 2024 15:22:59 +0900    
  
committer: Amit Langote <[email protected]>    
date     : Wed, 19 Jun 2024 15:22:59 +0900    

Click here for diff

Currently, when the ON EMPTY clause is not present, the ON ERROR  
clause (implicit or explicit) dictates the behavior when jsonpath  
evaluation in ExecEvalJsonExprPath() results in an empty sequence.  
That is an oversight in the commit 6185c9737c.  
  
This commit fixes things so that a NULL is returned instead in that  
case which is the default behavior when the ON EMPTY clause is not  
present.  
  
Reported-by: Markus Winand  
Discussion: https://postgr.es/m/F7DD1442-265C-4220-A603-CB0DEB77E91D%40winand.at  

M src/backend/parser/parse_expr.c
M src/test/regress/expected/sqljson_jsontable.out
M src/test/regress/expected/sqljson_queryfuncs.out
M src/test/regress/sql/sqljson_jsontable.sql
M src/test/regress/sql/sqljson_queryfuncs.sql

SQL/JSON: Correct jsonpath variable name matching

commit   : 0f271e8e8d9c8db0ea86c0d12b3221009b81d8bf    
  
author   : Amit Langote <[email protected]>    
date     : Wed, 19 Jun 2024 15:22:06 +0900    
  
committer: Amit Langote <[email protected]>    
date     : Wed, 19 Jun 2024 15:22:06 +0900    

Click here for diff

Previously, GetJsonPathVar() allowed a jsonpath expression to  
reference any prefix of a PASSING variable's name. For example, the  
following query would incorrectly work:  
  
SELECT JSON_QUERY(context_item, jsonpath '$xy' PASSING val AS xyz);  
  
The fix ensures that the length of the variable name mentioned in a  
jsonpath expression matches exactly with the name of the PASSING  
variable before comparing the strings using strncmp().  
  
Reported-by: Alvaro Herrera (off-list)  
Discussion: https://postgr.es/m/CA+HiwqFGkLWMvELBH6E4SQ45qUHthgcRH6gCJL20OsYDRtFx_w@mail.gmail.com  

M src/backend/executor/execExpr.c
M src/backend/utils/adt/jsonpath_exec.c
M src/include/utils/jsonpath.h
M src/test/regress/expected/sqljson_queryfuncs.out
M src/test/regress/sql/sqljson_queryfuncs.sql

doc PG 17 relnotes: properly wrap SGML text

commit   : 5e05a0e9924e97c24be13c75e4ba12c60bd0e4ad    
  
author   : Bruce Momjian <[email protected]>    
date     : Tue, 18 Jun 2024 22:41:49 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Tue, 18 Jun 2024 22:41:49 -0400    

Click here for diff

Backpatch-through: master  

M doc/src/sgml/release-17.sgml

commit   : 5ade0b8f80cdbb715bc3904ac7d4281a75817911    
  
author   : Bruce Momjian <[email protected]>    
date     : Tue, 18 Jun 2024 22:09:41 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Tue, 18 Jun 2024 22:09:41 -0400    

Click here for diff

Also slightly improve markup instructions.  Indentation is still needed.  
  
Backpatch-through: master  

M doc/src/sgml/release-17.sgml
M doc/src/sgml/release.sgml

Fix possible Assert failure in cost_memoize_rescan

commit   : aa901a37cf8aaf36b0dabaaea42ea3d068fe3448    
  
author   : David Rowley <[email protected]>    
date     : Wed, 19 Jun 2024 10:20:24 +1200    
  
committer: David Rowley <[email protected]>    
date     : Wed, 19 Jun 2024 10:20:24 +1200    

Click here for diff

In cost_memoize_rescan(), when calculating the hit_ratio using the calls  
and ndistinct estimations, if the value that was set in  
MemoizePath.calls had not been processed through clamp_row_est(), then it  
was possible that it was set to some non-integer value which could result  
in ndistinct being 1 higher than calls due to estimate_num_groups()  
performing clamp_row_est() on its input_rows.  This could result in  
hit_ratio values slightly below 0.0, which would cause an Assert failure.  
  
The value of MemoizePath.calls comes from the final parameter in the  
create_memoize_path() function, of which we only have one true caller of.  
That caller passes outer_path->rows.  All the core code I looked at  
always seems to call clamp_row_est() on the Path.rows, so there might  
have been no issues with any core Paths causing troubles here.  The bug  
report was about a CustomPath with a non-clamped row estimated.  
  
The misbehavior as a result of this seems to be mostly limited to the  
Assert() failing.  Aside from that, it seems the Memoize costs would  
just come out slightly higher than they should have, which is likely  
fairly harmless.  
  
Reported-by: Kohei KaiGai <[email protected]>  
Discussion: https://postgr.es/m/CAOP8fzZnTU+N64UYJYogb1hN-5hFP+PwTb3m_cnGAD7EsQwrKw@mail.gmail.com  
Reviewed-by: Richard Guo  
Backpatch-through: 14, where Memoize was introduced  

M src/backend/optimizer/util/pathnode.c

Fix incorrect punctuation in error message

commit   : 5603e119f4bd4818f8fa432ffc177c3caf9efeb6    
  
author   : Peter Eisentraut <[email protected]>    
date     : Tue, 18 Jun 2024 14:53:11 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Tue, 18 Jun 2024 14:53:11 +0200    

Click here for diff

M src/backend/utils/adt/timestamp.c
M src/test/regress/expected/window.out

Fix typo in 029_stats_restart.pl

commit   : ae482a7ec521e09bb0dbfc261da6e6170a5ac29f    
  
author   : Michael Paquier <[email protected]>    
date     : Tue, 18 Jun 2024 12:51:36 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Tue, 18 Jun 2024 12:51:36 +0900    

Click here for diff

Oversight in 16acf7f1aaea, where the test has been introduced.  Issue  
noticed while scanning this area of the tree.  

M src/test/recovery/t/029_stats_restart.pl

doc PG 17 relnotes: update to current

commit   : 82ed67a5fe826044bf361ad0425283d05f3dcf95    
  
author   : Bruce Momjian <[email protected]>    
date     : Mon, 17 Jun 2024 15:05:05 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Mon, 17 Jun 2024 15:05:05 -0400    

Click here for diff

Backpatch-through: master  

M doc/src/sgml/release-17.sgml

doc PG 17 relnotes: Fix sslnegotation typo

commit   : a6685c5e362eab5d04b8ffe65fff7cfbd21b6034    
  
author   : Andres Freund <[email protected]>    
date     : Mon, 17 Jun 2024 11:53:07 -0700    
  
committer: Andres Freund <[email protected]>    
date     : Mon, 17 Jun 2024 11:53:07 -0700    

Click here for diff

I was confused with copy-pasting the parameter name didn't work...  

M doc/src/sgml/release-17.sgml

Fix insertion of SP-GiST REDIRECT tuples during REINDEX CONCURRENTLY.

commit   : 92c49d1062f7094f56b80c603233fa4a0ffe2f8b    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 17 Jun 2024 14:30:59 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 17 Jun 2024 14:30:59 -0400    

Click here for diff

Reconstruction of an SP-GiST index by REINDEX CONCURRENTLY may  
insert some REDIRECT tuples.  This will typically happen in  
a transaction that lacks an XID, which leads either to assertion  
failure in spgFormDeadTuple or to insertion of a REDIRECT tuple  
with zero xid.  The latter's not good either, since eventually  
VACUUM will apply GlobalVisTestIsRemovableXid() to the zero xid,  
resulting in either an assertion failure or a garbage answer.  
  
In practice, since REINDEX CONCURRENTLY locks out index scans  
till it's done, it doesn't matter whether it inserts REDIRECTs  
or PLACEHOLDERs; and likewise it doesn't matter how soon VACUUM  
reduces such a REDIRECT to a PLACEHOLDER.  So in non-assert builds  
there's no observable problem here, other than perhaps a little  
index bloat.  But it's not behaving as intended.  
  
To fix, remove the failing Assert in spgFormDeadTuple, acknowledging  
that we might sometimes insert a zero XID; and guard VACUUM's  
GlobalVisTestIsRemovableXid() call with a test for valid XID,  
ensuring that we'll reduce such a REDIRECT the first time VACUUM  
sees it.  (Versions before v14 use TransactionIdPrecedes here,  
which won't fail on zero xid, so they really have no bug at all  
in non-assert builds.)  
  
Another solution could be to not create REDIRECTs at all during  
REINDEX CONCURRENTLY, making the relevant code paths treat that  
case like index build (which likewise knows that no concurrent  
index scans can be happening).  That would allow restoring the  
Assert in spgFormDeadTuple, but we'd still need the VACUUM change  
because redirection tuples with zero xid may be out there already.  
But there doesn't seem to be a nice way for spginsert() to tell that  
it's being called in REINDEX CONCURRENTLY without some API changes,  
so we'll leave that as a possible future improvement.  
  
In HEAD, also rename the SpGistState.myXid field to redirectXid,  
which seems less misleading (since it might not in fact be our  
transaction's XID) and is certainly less uninformatively generic.  
  
Per bug #18499 from Alexander Lakhin.  Back-patch to all supported  
branches.  
  
Discussion: https://postgr.es/m/[email protected]  

M src/backend/access/spgist/spgutils.c
M src/backend/access/spgist/spgvacuum.c
M src/backend/access/spgist/spgxlog.c
M src/include/access/spgist_private.h
M src/include/access/spgxlog.h

Remove recordExtensionInitPriv[Worker]'s ownerId argument.

commit   : ba26d156636c84a9674e49dbdfe788b6291985f2    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 17 Jun 2024 13:00:53 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 17 Jun 2024 13:00:53 -0400    

Click here for diff

In the wake of the previous commit, we're not doing anything  
with that argument.  Hence, revert the portions of 534287403  
that added that argument and taught the callers to pass it.  
Passing the ownerId requires additional syscache lookups in  
some code paths, which'd be fine if we were doing anything  
useful with the info, but it seems inadvisable if we're not.  
  
Committed separately since there's some thought that we might  
want to un-revert this in future, in case it's decided that  
storing the original owner ID explicitly in pg_init_privs  
is worth doing.  
  
Discussion: https://postgr.es/m/CAMT0RQSVgv48G5GArUvOVhottWqZLrvC5wBzBa4HrUdXe9VRXw@mail.gmail.com  

M src/backend/catalog/aclchk.c

Improve tracking of role dependencies of pg_init_privs entries.

commit   : 35dd40d34cbdf5aa3e0f5b3493c33d00abb26456    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 17 Jun 2024 12:55:10 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 17 Jun 2024 12:55:10 -0400    

Click here for diff

Commit 534287403 invented SHARED_DEPENDENCY_INITACL entries in  
pg_shdepend, but installed them only for non-owner roles mentioned  
in a pg_init_privs entry.  This turns out to be the wrong thing,  
because there is nothing to cue REASSIGN OWNED to go and update  
pg_init_privs entries when the object's ownership is reassigned.  
That leads to leaving dangling entries in pg_init_privs, as  
reported by Hannu Krosing.  Instead, install INITACL entries for  
all roles mentioned in pg_init_privs entries (except pinned roles),  
and change ALTER OWNER to not touch them, just as it doesn't  
touch pg_init_privs entries.  
  
REASSIGN OWNED will now substitute the new owner OID for the old  
in pg_init_privs entries.  This feels like perhaps not quite the  
right thing, since pg_init_privs ought to be a historical record  
of the state of affairs just after CREATE EXTENSION.  However,  
it's hard to see what else to do, if we don't want to disallow  
dropping the object's original owner.  In any case this is  
better than the previous do-nothing behavior, and we're unlikely  
to come up with a superior solution in time for v17.  
  
While here, tighten up some coding rules about how ACLs in  
pg_init_privs should never be null or empty.  There's not any  
obvious reason to allow that, and perhaps asserting that it's  
not so will catch some bugs.  (We were previously inconsistent  
on the point, with some code paths taking care not to store  
empty ACLs and others not.)  
  
This leaves recordExtensionInitPrivWorker not doing anything  
with its ownerId argument, but we'll deal with that separately.  
  
catversion bump forced because of change of expected contents  
of pg_shdepend when pg_init_privs entries exist.  
  
Discussion: https://postgr.es/m/CAMT0RQSVgv48G5GArUvOVhottWqZLrvC5wBzBa4HrUdXe9VRXw@mail.gmail.com  

M doc/src/sgml/catalogs.sgml
M src/backend/catalog/aclchk.c
M src/backend/catalog/pg_shdepend.c
M src/backend/utils/adt/acl.c
M src/include/catalog/catversion.h
M src/include/catalog/dependency.h
M src/include/utils/acl.h
M src/test/modules/test_pg_dump/expected/test_pg_dump.out
M src/test/modules/test_pg_dump/sql/test_pg_dump.sql

Teach jsonpath string() to unwrap in lax mode

commit   : 653d3969bb013f14c4a6884a253ad9676caf8166    
  
author   : Andrew Dunstan <[email protected]>    
date     : Mon, 17 Jun 2024 10:31:29 -0400    
  
committer: Andrew Dunstan <[email protected]>    
date     : Mon, 17 Jun 2024 10:31:29 -0400    

Click here for diff

This was an ommission in commit 66ea94e, and brings it into compliance  
with both other methods and the standard.  
  
Per complaint from David Wheeler.  
  
Author: David Wheeler, Jeevan Chalke  
Reviewed-by: Chapman Flack  
  
Discussion: https://postgr.es/m/[email protected]  

M doc/src/sgml/func.sgml
M src/backend/utils/adt/jsonpath_exec.c
M src/test/regress/expected/jsonb_jsonpath.out
M src/test/regress/sql/jsonb_jsonpath.sql

pg_createsubscriber: Remove failover replication slots on subscriber

commit   : 81d20fbf7a03f5e385700c90aec883c96b32ddc6    
  
author   : Peter Eisentraut <[email protected]>    
date     : Mon, 17 Jun 2024 12:12:49 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Mon, 17 Jun 2024 12:12:49 +0200    

Click here for diff

After running pg_createsubscriber, these replication slots have no use  
on subscriber, so drop them.  
  
Author: Euler Taveira <[email protected]>  
Reviewed-by: Hayato Kuroda <[email protected]>  
Discussion: https://www.postgresql.org/message-id/776c5cac-5ef5-4001-b1bc-5b698bc0c62a%40app.fastmail.com  

M doc/src/sgml/ref/pg_createsubscriber.sgml
M src/bin/pg_basebackup/pg_createsubscriber.c
M src/bin/pg_basebackup/t/040_pg_createsubscriber.pl

pg_createsubscriber: Remove replication slot check on primary

commit   : b96391382626306c301b67cbd2d28313d96741f3    
  
author   : Peter Eisentraut <[email protected]>    
date     : Mon, 17 Jun 2024 10:48:17 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Mon, 17 Jun 2024 10:48:17 +0200    

Click here for diff

It used to check if the replication slot exists and is active on  
primary.  This check might fail on slow hosts because the replication  
slot might not be active at the time of this check.  
  
The current code obtains the replication slot name from the  
primary_slot_name on standby and assumes the replication slot exists  
and is active on primary.  If it doesn't exist, this tool will log an  
error and continue.  
  
Author: Euler Taveira <[email protected]>  
Reviewed-by: Hayato Kuroda <[email protected]>  
Discussion: https://www.postgresql.org/message-id/776c5cac-5ef5-4001-b1bc-5b698bc0c62a%40app.fastmail.com  

M src/bin/pg_basebackup/pg_createsubscriber.c

pg_createsubscriber: Only --recovery-timeout controls the end of recovery process

commit   : 04c8634c0c4d636540c9283efdd695558403dc4e    
  
author   : Peter Eisentraut <[email protected]>    
date     : Mon, 17 Jun 2024 09:42:51 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Mon, 17 Jun 2024 09:42:51 +0200    

Click here for diff

It used to check if the target server is connected to the primary  
server (send required WAL) to rapidly react when the process won't  
succeed.  This code is not enough to guarantee that the recovery  
process will complete.  There is a window between the walreceiver  
shutdown and the pg_is_in_recovery() returns false that can reach  
NUM_CONN_ATTEMPTS attempts and fails.  
  
Instead, rely only on the --recovery-timeout option to give up the  
process after the specified number of seconds.  
  
This should help with buildfarm failures on slow machines.  
  
Author: Euler Taveira <[email protected]>  
Reviewed-by: Hayato Kuroda <[email protected]>  
Discussion: https://www.postgresql.org/message-id/776c5cac-5ef5-4001-b1bc-5b698bc0c62a%40app.fastmail.com  

M doc/src/sgml/ref/pg_createsubscriber.sgml
M src/bin/pg_basebackup/pg_createsubscriber.c
M src/bin/pg_basebackup/t/040_pg_createsubscriber.pl

Make regress function make_tuple_indirect() able to handle plain attributes

commit   : 8f1888eb6d6023b80525fbf7a8a1053daa6eb31e    
  
author   : Michael Paquier <[email protected]>    
date     : Mon, 17 Jun 2024 14:26:27 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Mon, 17 Jun 2024 14:26:27 +0900    

Click here for diff

The function has been introduced in 368202501539 to test at a low level  
the new kinds of external toast datums, and would fail on OOM when  
dealing with a plain storage attribute.  The existing tests of  
indirect_toast do not test this case, still the error generated was  
confusing.  
  
Author: Alexander Lakhin  
Discussion: https://postgr.es/m/[email protected]  

M src/test/regress/regress.c

doc: Mention modules/injection_points as example for injection points

commit   : faaa0d279899f037b4a6472a00fcd14a321e64c7    
  
author   : Michael Paquier <[email protected]>    
date     : Mon, 17 Jun 2024 13:49:40 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Mon, 17 Jun 2024 13:49:40 +0900    

Click here for diff

This should have been added in 49cd2b93d7db, that introduced the module.  
  
Reported-by: Jian He  
Discussion: https://postgr.es/m/CACJufxF+Vfj2Oz2kBR5v1bjHeZxvs63cLogm70v9Uto1Rqiieg@mail.gmail.com  

M doc/src/sgml/xfunc.sgml

Add Windows file version information to test_json_parser programs.

commit   : 645bda2a7155fff57cc3da2ab923202187c72957    
  
author   : Noah Misch <[email protected]>    
date     : Sun, 16 Jun 2024 12:29:30 -0700    
  
committer: Noah Misch <[email protected]>    
date     : Sun, 16 Jun 2024 12:29:30 -0700    

Click here for diff

M src/test/modules/test_json_parser/Makefile

Remove use of %z in sscanf.

commit   : 8866ed9560576de9dec628d5bfdb1571ec8d8ef0    
  
author   : Noah Misch <[email protected]>    
date     : Sun, 16 Jun 2024 12:29:25 -0700    
  
committer: Noah Misch <[email protected]>    
date     : Sun, 16 Jun 2024 12:29:25 -0700    

Click here for diff

As in 9d7ded0f4277f5c0063eca8e871a34e2355a8371, it causes warnings on  
some MinGW compilers.  

M src/test/modules/test_json_parser/test_json_parser_incremental.c

Convert confusing macros in multixact.c to static inline functions

commit   : 0099b9408e8c74158976c888854e0caafd6c052a    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Sun, 16 Jun 2024 20:47:07 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Sun, 16 Jun 2024 20:47:07 +0300    

Click here for diff

The macros were confused about the argument data types. All the  
arguments were called 'xid', and some of the macros included casts to  
TransactionId, even though the arguments were actually either  
MultiXactIds or MultiXactOffsets. It compiles to the same thing,  
because TransactionId, MultiXactId and MultiXactOffset are all  
typedefs of uint32, but it was highly misleading.  
  
Author: Maxim Orlov <[email protected]>  
Discussion: https://www.postgresql.org/message-id/CACG%3DezbLUG-OD1osAW3OchOMxZtdxHh2itYR9Zhh-a13wEBEQw%40mail.gmail.com  
Discussion: https://www.postgresql.org/message-id/ff143b24-a093-40da-9833-d36b83726bdf%40iki.fi  

M src/backend/access/transam/multixact.c

doc: fix typo in create role manual.

commit   : 92aff003d7f20810d7c8fbe13cbe5fb041cc6242    
  
author   : Tatsuo Ishii <[email protected]>    
date     : Sun, 16 Jun 2024 16:21:46 +0900    
  
committer: Tatsuo Ishii <[email protected]>    
date     : Sun, 16 Jun 2024 16:21:46 +0900    

Click here for diff

There was a small mistake in the create role manual.  
  
Author: Satoru Koizumi  
Reviewed-by: David G. Johnston  
Discussion: https://postgr.es/m/flat/20240616.112523.1208348667552014162.t-ishii%40sranhm.sra.co.jp  
Backpatch-through: 16  

M doc/src/sgml/ref/create_role.sgml

Clean out column-level pg_init_privs entries when dropping tables.

commit   : 76618097a6c027ec603a3dd143f61098e3fb9794    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 14 Jun 2024 16:20:35 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 14 Jun 2024 16:20:35 -0400    

Click here for diff

DeleteInitPrivs did not get the memo about how, when dropping a  
whole object (with subid == 0), you should drop entries relating  
to its sub-objects too.  This is visible in the test_pg_dump test  
case if one drops the extension at the end: the entry for  
	GRANT SELECT(col1) ON regress_pg_dump_table TO public;  
was still present in pg_init_privs afterwards, although it was  
pointing to a dangling table OID.  
  
Noted while fooling with a fix for REASSIGN OWNED for pg_init_privs  
entries.  This bug is aboriginal in the pg_init_privs feature  
though, and there seems no reason not to back-patch the fix.  

M src/backend/catalog/dependency.c
M src/test/modules/test_pg_dump/expected/test_pg_dump.out
M src/test/modules/test_pg_dump/sql/test_pg_dump.sql

Fix misc_sanity test to accept SHARED_DEPENDENCY_INITACL entries.

commit   : 01aa88f71208c2af143b044553b89df4438de33e    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 14 Jun 2024 15:29:09 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 14 Jun 2024 15:29:09 -0400    

Click here for diff

Oversight in 534287403.  We missed this up to now because the  
core regression tests create no such entries (at least up to  
this test), so the only way to see the failure is to do  
"make installcheck" in an installation where some other DB  
has such entries.  I happened to do that just now ...  

M src/test/regress/expected/misc_sanity.out
M src/test/regress/sql/misc_sanity.sql

Reintroduce dead tuple counter in pg_stat_progress_vacuum.

commit   : f1affb67055c9b3f31a7ee7eb521a9ba64fff488    
  
author   : Masahiko Sawada <[email protected]>    
date     : Fri, 14 Jun 2024 10:08:15 +0900    
  
committer: Masahiko Sawada <[email protected]>    
date     : Fri, 14 Jun 2024 10:08:15 +0900    

Click here for diff

Commit 667e65aac3 changed both num_dead_tuples and max_dead_tuples  
columns to dead_tuple_bytes and max_dead_tuple_bytes columns,  
respectively. But as per discussion, the number of dead tuples  
collected still provides meaningful insights for users.  
  
This commit reintroduces the column for the count of dead tuples,  
renamed as num_dead_item_ids. It avoids confusion with the number of  
dead tuples removed by VACUUM, which includes dead heap-only tuples  
but excludes any pre-existing LP_DEAD items left behind by  
opportunistic pruning.  
  
Bump catalog version.  
  
Reviewed-by: Peter Geoghegan, Álvaro Herrera, Andrey Borodin  
Discussion: https://postgr.es/m/CAD21AoBL5sJE9TRWPyv%2Bw7k5Ee5QAJqDJEDJBUdAaCzGWAdvZw%40mail.gmail.com  

M doc/src/sgml/monitoring.sgml
M src/backend/access/heap/vacuumlazy.c
M src/backend/catalog/system_views.sql
M src/include/catalog/catversion.h
M src/include/commands/progress.h
M src/test/regress/expected/rules.out

Fix parsing of ignored operators in websearch_to_tsquery().

commit   : 56a8296212b68267dc2bddeb1fb40a893b1aadb3    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 13 Jun 2024 20:34:42 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 13 Jun 2024 20:34:42 -0400    

Click here for diff

The manual says clearly that punctuation in the input of  
websearch_to_tsquery() is ignored, except for the special cases  
of dashes and quotes.  However, this failed for cases like  
"(foo bar) or something", or in general an ISOPERATOR character  
in front of the "or".  We'd switch back to WAITOPERAND state,  
then ignore the operator character while remaining in that state,  
and then reach the "or" in WAITOPERAND state which (intentionally)  
makes us treat it as data.  
  
The fix is simple enough: if we see an ISOPERATOR character while in  
WAITOPERATOR state, we have to skip it while staying in that state.  
(We don't need to worry about other punctuation characters: those will  
be consumed as though they were words, but then rejected by lexizing.)  
  
In v14 and up (since commit eb086056f) we can simplify the code a bit  
more too, because there is no longer a reason for the WAITOPERAND  
state to distinguish between quoted and unquoted operands.  
  
Per bug #18479 from Manos Emmanouilidis.  Back-patch to all supported  
branches.  
  
Discussion: https://postgr.es/m/[email protected]  

M src/backend/utils/adt/tsquery.c
M src/test/regress/expected/tsearch.out
M src/test/regress/sql/tsearch.sql

doc: Fix description WAL summarizer in glossary

commit   : d872e1b4730b793c9d72c80b65feb988269104e2    
  
author   : Michael Paquier <[email protected]>    
date     : Fri, 14 Jun 2024 09:28:11 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Fri, 14 Jun 2024 09:28:11 +0900    

Click here for diff

The WAL summarizer is an auxiliary process.  
  
Oversight in 7b1dbf0a8d1d.  
  
Author: Masahiro Ikeda  
Discussion: https://postgr.es/m/[email protected]  

M doc/src/sgml/glossary.sgml

doc: Fix description WAL writer in glossary

commit   : 3c992361cda184ff635a516832dcc54c569ea6ec    
  
author   : Michael Paquier <[email protected]>    
date     : Fri, 14 Jun 2024 09:26:32 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Fri, 14 Jun 2024 09:26:32 +0900    

Click here for diff

The WAL writer is an auxiliary process, but its description in the  
glossary did not match that.  
  
This is inexact since d3014fff4cd4.  
  
Author: Masahiro Ikeda  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 15  

M doc/src/sgml/glossary.sgml

Improve the granularity of PQsocketPoll's timeout parameter.

commit   : 105024a47238e33647d346264b4f6fe68a7287ed    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 13 Jun 2024 15:14:32 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 13 Jun 2024 15:14:32 -0400    

Click here for diff

Commit f5e4dedfa exposed libpq's internal function PQsocketPoll  
without a lot of thought about whether that was an API we really  
wanted to chisel in stone.  The main problem with it is the use of  
time_t to specify the timeout.  While we do want an absolute time  
so that a loop around PQsocketPoll doesn't have problems with  
timeout slippage, time_t has only 1-second resolution.  That's  
already problematic for libpq's own internal usage --- for example,  
pqConnectDBComplete has long had a kluge to treat "connect_timeout=1"  
as 2 seconds so that it doesn't accidentally round to nearly zero.  
And it's even less likely to be satisfactory for external callers.  
Hence, let's change this while we still can.  
  
The best idea seems to be to use an int64 count of microseconds since  
the epoch --- basically the same thing as the backend's TimestampTz,  
but let's use the standard Unix epoch (1970-01-01) since that's more  
likely for clients to be easy to calculate.  Millisecond resolution  
would be plenty for foreseeable uses, but maybe the day will come that  
we're glad we used microseconds.  
  
Also, since time(2) isn't especially helpful for computing timeouts  
defined this way, introduce a new function PQgetCurrentTimeUSec  
to get the current time in this form.  
  
Remove the hack in pqConnectDBComplete, so that "connect_timeout=1"  
now means what you'd expect.  
  
We can also remove the "#include <time.h>" that f5e4dedfa added to  
libpq-fe.h, since there's no longer a need for time_t in that header.  
It seems better for v17 not to enlarge libpq-fe.h's include footprint  
from what it's historically been, anyway.  
  
I also failed to resist the temptation to do some wordsmithing  
on PQsocketPoll's documentation.  
  
Patch by me, per complaint from Dominique Devienne.  
  
Discussion: https://postgr.es/m/[email protected]  

M doc/src/sgml/libpq.sgml
M src/bin/psql/command.c
M src/interfaces/libpq/exports.txt
M src/interfaces/libpq/fe-connect.c
M src/interfaces/libpq/fe-misc.c
M src/interfaces/libpq/libpq-fe.h
M src/interfaces/libpq/libpq-int.h
M src/tools/pgindent/typedefs.list

When replanning a plpgsql "simple expression", check it's still simple.

commit   : 6dfac24401b7143ad5c75f991c18105e1267f88e    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 13 Jun 2024 13:37:46 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 13 Jun 2024 13:37:46 -0400    

Click here for diff

The previous coding here assumed that we didn't need to recheck any  
of the querytree tests made in exec_simple_check_plan().  I think  
we supposed that those properties were fully determined by the  
syntax of the source text and hence couldn't change.  That is true  
for most of them, but at least hasTargetSRFs and hasAggs can change  
by dint of forcibly dropping an originally-referenced function and  
recreating it with new properties.  That leads to "unexpected plan  
node type" or similar failures.  
  
These tests are pretty cheap compared to the cost of replanning, so  
rather than sweat over exactly which properties need to be rechecked,  
let's just recheck them all.  Hence, factor out those tests into a new  
function exec_is_simple_query(), and rearrange callers as needed.  
  
A second problem in the same area was that if we failed during  
replanning or during exec_save_simple_expr(), we'd potentially  
leave behind now-dangling pointers to the old simple expression,  
potentially resulting in crashes later.  To fix, clear those pointers  
before replanning.  
  
The v12 code looks quite different in this area but still has the  
bug about needing to recheck query simplicity.  I chose to back-patch  
all of the plpgsql_simple.sql test script, which formerly didn't exist  
in this branch.  
  
Per bug #18497 from Nikita Kalinin.  Back-patch to all supported  
branches.  
  
Discussion: https://postgr.es/m/[email protected]  

M src/pl/plpgsql/src/expected/plpgsql_simple.out
M src/pl/plpgsql/src/pl_exec.c
M src/pl/plpgsql/src/sql/plpgsql_simple.sql

Clamp result of MultiXactMemberFreezeThreshold

commit   : c425113eebb7dbc7f0031ed97b32f267a9cac75f    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Thu, 13 Jun 2024 19:01:30 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Thu, 13 Jun 2024 19:01:30 +0300    

Click here for diff

The purpose of the function is to reduce the effective  
autovacuum_multixact_freeze_max_age if the multixact members SLRU is  
approaching wraparound, to make multixid freezing more aggressive.  
The returned value should therefore never be greater than plain  
autovacuum_multixact_freeze_max_age.  
  
Reviewed-by: Robert Haas  
Discussion: https://www.postgresql.org/message-id/[email protected]  
Backpatch-through: 12, all supported versions  

M src/backend/access/transam/multixact.c

Skip some permissions checks on Cygwin

commit   : f83908798f78c4cafda217ca875602c88ea2ae28    
  
author   : Andrew Dunstan <[email protected]>    
date     : Thu, 13 Jun 2024 07:38:48 -0400    
  
committer: Andrew Dunstan <[email protected]>    
date     : Thu, 13 Jun 2024 07:38:48 -0400    

Click here for diff

These are checks that are already skipped on other Windows systems.  
  
Backpatch to all live branches, as appropriate.  

M src/bin/initdb/t/001_initdb.pl
M src/bin/pg_basebackup/t/010_pg_basebackup.pl
M src/bin/pg_ctl/t/001_start_stop.pl
M src/bin/pg_rewind/t/002_databases.pl
M src/bin/pg_verifybackup/t/003_corruption.pl

Add postgres_inc to meson check for Python.h

commit   : 11b9b8ce44a8cc80cbef6ade2b5ae7438227da79    
  
author   : Andrew Dunstan <[email protected]>    
date     : Thu, 13 Jun 2024 07:30:10 -0400    
  
committer: Andrew Dunstan <[email protected]>    
date     : Thu, 13 Jun 2024 07:30:10 -0400    

Click here for diff

Required for Cygwin.  
  
Backpatch to release 16.  

M meson.build

Fix documentation of initdb --show option

commit   : a41106dab72cbcaa02fce8bda8965d04e85f2d3a    
  
author   : Peter Eisentraut <[email protected]>    
date     : Thu, 13 Jun 2024 11:52:35 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Thu, 13 Jun 2024 11:52:35 +0200    

Click here for diff

It wasn't in the documentation at all (even though we document all the  
other debugging-like options).  Also, change the --help output to show  
that it exits after showing, similar to other options.  

M doc/src/sgml/ref/initdb.sgml
M src/bin/initdb/initdb.c

Add missing source files to nls.mk

commit   : ad8877cb513733d8bb98d24770a094b81c27e4c5    
  
author   : Peter Eisentraut <[email protected]>    
date     : Thu, 13 Jun 2024 10:17:36 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Thu, 13 Jun 2024 10:17:36 +0200    

Click here for diff

Files in common/ and fe_utils/ that contain translatable strings need  
to be listed in the nls.mk files of the programs that use them.  (Not  
great, but that's the way it works for now.)  This usually requires  
some manual analysis which is done about once during each major  
release beta period.  This time, I wrote a hackish script that figures  
some of this out more automatically, so this update is a bit larger as  
it also includes some files that were missed in the past.  

M src/bin/initdb/nls.mk
M src/bin/pg_amcheck/nls.mk
M src/bin/pg_archivecleanup/nls.mk
M src/bin/pg_basebackup/nls.mk
M src/bin/pg_checksums/nls.mk
M src/bin/pg_combinebackup/nls.mk
M src/bin/pg_config/nls.mk
M src/bin/pg_controldata/nls.mk
M src/bin/pg_ctl/nls.mk
M src/bin/pg_dump/nls.mk
M src/bin/pg_resetwal/nls.mk
M src/bin/pg_rewind/nls.mk
M src/bin/pg_test_fsync/nls.mk
M src/bin/pg_test_timing/nls.mk
M src/bin/pg_upgrade/nls.mk
M src/bin/pg_verifybackup/nls.mk
M src/bin/pg_waldump/nls.mk
M src/bin/pg_walsummary/nls.mk
M src/bin/psql/nls.mk
M src/bin/scripts/nls.mk

libpq: Some message style normalization

commit   : 6ac5600a36c1950e1470ccb16038e6b8ca4e6eba    
  
author   : Peter Eisentraut <[email protected]>    
date     : Thu, 13 Jun 2024 07:10:35 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Thu, 13 Jun 2024 07:10:35 +0200    

Click here for diff

M src/interfaces/libpq/fe-cancel.c
M src/interfaces/libpq/fe-connect.c
M src/interfaces/libpq/fe-exec.c

Harmonize pg_bsd_indent parameter names.

commit   : 99b99285e5438ee8b0c065db58e87e6577158d22    
  
author   : Peter Geoghegan <[email protected]>    
date     : Wed, 12 Jun 2024 18:04:10 -0400    
  
committer: Peter Geoghegan <[email protected]>    
date     : Wed, 12 Jun 2024 18:04:10 -0400    

Click here for diff

Make sure that function declarations use names that exactly match the  
corresponding names from function definitions in pg_bsd_indent.  
  
This commit was written with help from clang-tidy, by mechanically  
applying the same rules as similar clean-up commits.  
  
Discussion: https://postgr.es/m/CAH2-WzkaBS8w-vCbG5M5Bx7XikC0WhNLJV_+Z_YAWW9Kef6OBQ@mail.gmail.com  

M src/tools/pg_bsd_indent/args.c
M src/tools/pg_bsd_indent/indent.c

Harmonize function parameter names for Postgres 17.

commit   : 6207f08f700ddc874765919202727fb0171b5403    
  
author   : Peter Geoghegan <[email protected]>    
date     : Wed, 12 Jun 2024 17:01:51 -0400    
  
committer: Peter Geoghegan <[email protected]>    
date     : Wed, 12 Jun 2024 17:01:51 -0400    

Click here for diff

Make sure that function declarations use names that exactly match the  
corresponding names from function definitions in a few places.  These  
inconsistencies were all introduced during Postgres 17 development.  
  
pg_bsd_indent still has a couple of similar inconsistencies, which I  
(pgeoghegan) have left untouched for now.  
  
This commit was written with help from clang-tidy, by mechanically  
applying the same rules as similar clean-up commits (the earliest such  
commit was commit 035ce1fe).  

M src/backend/access/brin/brin.c
M src/backend/access/heap/vacuumlazy.c
M src/backend/backup/basebackup_incremental.c
M src/backend/backup/basebackup_zstd.c
M src/backend/commands/tablecmds.c
M src/backend/optimizer/path/joinrels.c
M src/backend/parser/parse_expr.c
M src/backend/replication/libpqwalreceiver/libpqwalreceiver.c
M src/backend/utils/adt/jsonpath_exec.c
M src/bin/pg_combinebackup/copy_file.c
M src/bin/pg_combinebackup/reconstruct.c
M src/bin/pg_dump/pg_dumpall.c
M src/bin/pg_dump/pg_restore.c
M src/include/access/heapam.h
M src/include/common/unicode_case.h
M src/include/common/unicode_category.h
M src/include/libpq/libpq.h
M src/include/postmaster/postmaster.h
M src/include/storage/bufmgr.h
M src/include/storage/fd.h
M src/include/storage/read_stream.h
M src/include/storage/smgr.h
M src/include/utils/guc.h
M src/include/utils/jsonpath.h
M src/include/utils/pg_locale.h
M src/include/utils/resowner.h
M src/include/utils/tuplesort.h

libpq: Add missing gettext markers

commit   : a0fe90efef91fcd578a85a0f0c5bcab55285b1d7    
  
author   : Peter Eisentraut <[email protected]>    
date     : Wed, 12 Jun 2024 15:31:31 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Wed, 12 Jun 2024 15:31:31 +0200    

Click here for diff

Follow-up to 87d2801d4b: That commit restored some lost error  
messages, but they ended up in a place where xgettext wouldn't find  
them.  Rather than elevating ENCRYPTION_NEGOTIATION_FAILED() to a  
gettext trigger, it's easiest for now to put in some explicit  
libpq_gettext() calls in the couple of call sites.  

M src/interfaces/libpq/fe-connect.c

libpq: Remove a gettext marker

commit   : d112ea46813277351b577ee586c6e84e7de8ab27    
  
author   : Peter Eisentraut <[email protected]>    
date     : Wed, 12 Jun 2024 08:43:43 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Wed, 12 Jun 2024 08:43:43 +0200    

Click here for diff

This one error message is just a workaround for a missing OpenSSL  
error string.  But OpenSSL does not have gettext support, so we don't  
need to provide it in our workaround either.  That way, the  
user-facing behavior is consistent whether the user has a fixed  
OpenSSL or not.  

M src/interfaces/libpq/fe-secure-openssl.c

Fix typo in error message

commit   : f376996bb7fe621ac53279a81d475b214e492018    
  
author   : Peter Eisentraut <[email protected]>    
date     : Wed, 12 Jun 2024 04:48:39 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Wed, 12 Jun 2024 04:48:39 +0200    

Click here for diff

M src/interfaces/libpq/fe-connect.c

Fix segmentation fault in test_tidstore.

commit   : 18404ea60141a2e2eaf58a5ebbd2b99f7a0cd442    
  
author   : Masahiko Sawada <[email protected]>    
date     : Wed, 12 Jun 2024 09:56:13 +0900    
  
committer: Masahiko Sawada <[email protected]>    
date     : Wed, 12 Jun 2024 09:56:13 +0900    

Click here for diff

The do_set_block_offsets() and other functions accessing the tidstore  
did not check if the tidstore was NULL. This led to a segmentation  
fault when these functions are called without calling the  
test_create().  
  
This commit adds NULL checks in relevant functions of test_tidstore to  
raise an error instead if the tidstore is not initialized.  
  
Bug: #18483  
Reported-by: Alexander Kozhemyakin  
Reviewed-by: Michael Paquier  
Discussion: https://postgr.es/m/18483-30bfff42de238000%40postgresql.org  

M src/test/modules/test_tidstore/test_tidstore.c

Fix infer_arbiter_indexes() to not assume resultRelation is 1.

commit   : 915de706d28c433283e9dc63701e8f978488a2b9    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 11 Jun 2024 17:57:46 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 11 Jun 2024 17:57:46 -0400    

Click here for diff

infer_arbiter_indexes failed to renumber varnos in index expressions  
or predicates that it got from the catalogs.  This escaped detection  
up to now because the stored varnos in such trees will be 1, and an  
INSERT's result relation is usually the first rangetable entry,  
so that that was fine.  However, in cases such as inserting through  
an updatable view, it's not fine, leading to failure to match the  
expressions to the query with ensuing "there is no unique or exclusion  
constraint matching the ON CONFLICT specification" errors.  
  
Fix by copy-and-paste from get_relation_info().  
  
Per bug #18502 from Michael Wang.  Back-patch to all supported  
versions.  
  
Discussion: https://postgr.es/m/[email protected]  

M src/backend/optimizer/util/plancat.c
M src/test/regress/expected/insert_conflict.out
M src/test/regress/sql/insert_conflict.sql

Fix creation of partition descriptor during concurrent detach

commit   : c2fab70248d8b9f129d2333c91b7a6e279a591e3    
  
author   : Alvaro Herrera <[email protected]>    
date     : Tue, 11 Jun 2024 11:38:45 +0200    
  
committer: Alvaro Herrera <[email protected]>    
date     : Tue, 11 Jun 2024 11:38:45 +0200    

Click here for diff

When a partition is being detached in concurrent mode, it is possible  
for find_inheritance_children_extended() to return that partition in the  
list, and immediately after that receive an invalidation message that  
sets its relpartbound to NULL just before we read it.  (This can happen  
because table_open() reads invalidation messages.)  Currently we raise  
an error  
  ERROR:  missing relpartbound for relation %u  
about the situation, but that's bogus because the table is no longer a  
partition, so we shouldn't be complaining about it.  A better reaction  
is to retry the find_inheritance_children_extended call to get a new  
list, which will no longer have the partition being detached.  
  
Noticed while investigating bug #18377.  
  
Backpatch to 14, where DETACH CONCURRENTLY appeared.  
  
Discussion: https://postgr.es/m/[email protected]  

M src/backend/partitioning/partdesc.c

Fix an assert in CheckPointReplicationSlots().

commit   : d1ffcc7fa3c54de8b2a677a3e503fc808c7b419c    
  
author   : Amit Kapila <[email protected]>    
date     : Tue, 11 Jun 2024 10:51:34 +0530    
  
committer: Amit Kapila <[email protected]>    
date     : Tue, 11 Jun 2024 10:51:34 +0530    

Click here for diff

Commit e0b2eed047 assumed that the confirmed_flush LSN can't go backward.  
However, it is possible that confirmed_flush LSN can go backward  
temporarily when the client acknowledges a prior value of flush location.  
This can happen when the client (subscriber in this case) acknowledges an  
LSN it doesn't have to do anything for (say for DDLs) and thus didn't  
store persistently. After restart, the client sends the prior value of  
flush LSN which it had stored persistently and the server updates the  
confirmed_flush LSN with that value.  
  
The fix is to remove the assumption and not allow the prior value of  
confirmed_flush LSN to be flushed to the disk.  
  
Author: Vignesh C  
Reviewed-by: Amit Kapila, Shlok Kyal  
Discussion: https://postgr.es/m/CALDaNm3hgow2+oEov5jBk4iYP5eQrUCF1yZtW7+dV3J__p4KLQ@mail.gmail.com  

M src/backend/replication/slot.c

Doc: Fix ambuiguity in column lists.

commit   : 3470391e169ed46fa646ea39ade4b9b6898adb17    
  
author   : Amit Kapila <[email protected]>    
date     : Tue, 11 Jun 2024 09:39:52 +0530    
  
committer: Amit Kapila <[email protected]>    
date     : Tue, 11 Jun 2024 09:39:52 +0530    

Click here for diff

The behavior for columns added later to the table for publications with no  
specified column lists was not clear.  
  
Reported-by: Koen De Groote  
Author: Peter Smith  
Reviewed-by: Vignesh C, Laurenz Albe  
Backpatch-through: 15  
Discussion: https://postgr.es/m/[email protected]  

M doc/src/sgml/logical-replication.sgml

doc: Mention all options equivalent to pg_dump --filter patterns.

commit   : c50d4f4028e5518511b9bfc3a17860a90dc88357    
  
author   : Dean Rasheed <[email protected]>    
date     : Mon, 10 Jun 2024 14:55:41 +0100    
  
committer: Dean Rasheed <[email protected]>    
date     : Mon, 10 Jun 2024 14:55:41 +0100    

Click here for diff

In the documentation for pg_dump's new --filter option, added by  
commit a5cf808be5, each object pattern should match some other  
existing pg_dump option, but some had been omitted, so add them.  
  
Noted by Daniel Gustafsson, reviewed by Ayush Vatsa.  
  
Discussion: https://postgr.es/m/CAEZATCWtVUt51B6BjTUQoS4dcNyOBj%2B04ngL7HSH3ehBXTUt%3Dw%40mail.gmail.com  

M doc/src/sgml/ref/pg_dump.sgml

Fix comment about cross-checking the varnullingrels

commit   : 3cb19f45a3f58fb482999be5fae6ecad74f7fa27    
  
author   : Richard Guo <[email protected]>    
date     : Mon, 10 Jun 2024 13:05:20 +0900    
  
committer: Richard Guo <[email protected]>    
date     : Mon, 10 Jun 2024 13:05:20 +0900    

Click h