PostgreSQL 15.0 (upcoming) commit log

Fix misbehavior of EvalPlanQual checks with multiple result relations.

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

Click here for diff

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

M src/backend/executor/execMain.c
M src/backend/executor/execScan.c
M src/backend/executor/nodeModifyTable.c
M src/include/executor/executor.h
M src/include/nodes/execnodes.h
M src/test/isolation/expected/eval-plan-qual.out
M src/test/isolation/specs/eval-plan-qual.spec

Avoid naming conflict between transactions.sql and namespace.sql.

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

Click here for diff

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

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

pageinspect: Fix gist_page_items() with included columns

commit   : 2dd77822178807f3da988e1d873777685d9f7504    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 19 May 2023 12:38:15 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 19 May 2023 12:38:15 +0900    

Click here for diff

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

M contrib/pageinspect/expected/gist.out
M contrib/pageinspect/gistfuncs.c
M contrib/pageinspect/sql/gist.sql
M doc/src/sgml/pageinspect.sgml
M src/backend/utils/adt/ruleutils.c
M src/include/utils/ruleutils.h

Fix handling of empty ranges and NULLs in BRIN

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

Click here for diff

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

M src/backend/access/brin/brin.c
M src/backend/access/brin/brin_tuple.c
M src/include/access/brin_tuple.h
M src/test/modules/brin/expected/summarization-and-inprogress-insertion.out
M src/test/modules/brin/specs/summarization-and-inprogress-insertion.spec

Fix handling of NULLs when merging BRIN summaries

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

Click here for diff

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

M src/backend/access/brin/brin.c

Ensure Soundex difference() function handles empty input sanely.

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

Click here for diff

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

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

Mark internal messages as no longer translatable

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

Click here for diff

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

M src/backend/executor/nodeAgg.c

Tighten usage of PSQL_WATCH_PAGER.

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

Click here for diff

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

M doc/src/sgml/ref/psql-ref.sgml
M src/bin/psql/command.c

commit   : 95f2827c80acc06fecf4b47e46d95a038e0c8664    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Wed, 10 May 2023 10:49:48 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Wed, 10 May 2023 10:49:48 -0700    

Click here for diff

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

M doc/src/sgml/storage.sgml

Fix publication syntax error message

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

Click here for diff

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

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

Fix assertion failure when updating stats_fetch_consistency in a transaction

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

Click here for diff

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

M doc/src/sgml/config.sgml
M src/backend/utils/activity/pgstat.c
M src/backend/utils/misc/guc.c
M src/include/pgstat.h
M src/test/regress/expected/stats.out
M src/test/regress/sql/stats.sql

Stamp 15.3.

commit   : 8382864eb5c9f9ebe962ac20b3392be5ae304d23    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 8 May 2023 17:13:20 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 8 May 2023 17:13:20 -0400    

Click here for diff

M configure
M configure.ac

Last-minute updates for release notes.

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

Click here for diff

Security: CVE-2023-2454, CVE-2023-2455  

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

Adjust sepgsql expected output for 681d9e462 et al.

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

Click here for diff

Security: CVE-2023-2454  

M contrib/sepgsql/expected/ddl.out

Handle RLS dependencies in inlined set-returning functions properly.

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

Click here for diff

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

M src/backend/optimizer/util/clauses.c
M src/test/regress/expected/rowsecurity.out
M src/test/regress/sql/rowsecurity.sql

Replace last PushOverrideSearchPath() call with set_config_option().

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

Click here for diff

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

M contrib/seg/Makefile
A contrib/seg/expected/security.out
A contrib/seg/sql/security.sql
M src/backend/catalog/namespace.c
M src/backend/commands/schemacmds.c
M src/test/regress/expected/namespace.out
M src/test/regress/sql/namespace.sql

Translation updates

commit   : 8229bfe91def5878b498996ab24b62950edd9e40    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 8 May 2023 14:29:57 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 8 May 2023 14:29:57 +0200    

Click here for diff

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

M src/backend/po/de.po
M src/backend/po/es.po
M src/backend/po/fr.po
M src/backend/po/ja.po
M src/backend/po/ko.po
M src/backend/po/ru.po
M src/backend/po/sv.po
M src/backend/po/uk.po
M src/bin/initdb/nls.mk
M src/bin/initdb/po/el.po
M src/bin/initdb/po/es.po
A src/bin/initdb/po/ko.po
M src/bin/initdb/po/ru.po
M src/bin/initdb/po/uk.po
M src/bin/pg_amcheck/nls.mk
M src/bin/pg_amcheck/po/el.po
A src/bin/pg_amcheck/po/ko.po
M src/bin/pg_archivecleanup/po/el.po
M src/bin/pg_archivecleanup/po/es.po
M src/bin/pg_archivecleanup/po/ko.po
M src/bin/pg_archivecleanup/po/ru.po
M src/bin/pg_basebackup/nls.mk
A src/bin/pg_basebackup/po/el.po
M src/bin/pg_basebackup/po/es.po
A src/bin/pg_basebackup/po/ko.po
M src/bin/pg_basebackup/po/ru.po
M src/bin/pg_basebackup/po/uk.po
M src/bin/pg_checksums/nls.mk
A src/bin/pg_checksums/po/el.po
M src/bin/pg_checksums/po/es.po
A src/bin/pg_checksums/po/ko.po
M src/bin/pg_checksums/po/ru.po
M src/bin/pg_config/po/es.po
M src/bin/pg_config/po/ko.po
M src/bin/pg_config/po/ru.po
M src/bin/pg_controldata/po/el.po
M src/bin/pg_controldata/po/es.po
M src/bin/pg_controldata/po/ko.po
M src/bin/pg_controldata/po/ru.po
M src/bin/pg_ctl/po/el.po
M src/bin/pg_ctl/po/es.po
M src/bin/pg_ctl/po/ko.po
M src/bin/pg_ctl/po/ru.po
M src/bin/pg_dump/po/de.po
M src/bin/pg_dump/po/el.po
M src/bin/pg_dump/po/es.po
M src/bin/pg_dump/po/fr.po
M src/bin/pg_dump/po/ja.po
M src/bin/pg_dump/po/ka.po
M src/bin/pg_dump/po/ko.po
M src/bin/pg_dump/po/ru.po
M src/bin/pg_dump/po/sv.po
M src/bin/pg_dump/po/uk.po
M src/bin/pg_resetwal/po/el.po
M src/bin/pg_resetwal/po/es.po
M src/bin/pg_resetwal/po/ko.po
M src/bin/pg_resetwal/po/ru.po
M src/bin/pg_rewind/nls.mk
M src/bin/pg_rewind/po/el.po
M src/bin/pg_rewind/po/es.po
A src/bin/pg_rewind/po/ko.po
M src/bin/pg_rewind/po/ru.po
M src/bin/pg_rewind/po/uk.po
M src/bin/pg_test_fsync/nls.mk
A src/bin/pg_test_fsync/po/el.po
M src/bin/pg_test_fsync/po/es.po
A src/bin/pg_test_fsync/po/ko.po
M src/bin/pg_test_fsync/po/ru.po
M src/bin/pg_test_timing/nls.mk
M src/bin/pg_test_timing/po/es.po
A src/bin/pg_test_timing/po/ko.po
M src/bin/pg_test_timing/po/ru.po
M src/bin/pg_upgrade/po/es.po
M src/bin/pg_upgrade/po/ka.po
M src/bin/pg_upgrade/po/ko.po
M src/bin/pg_verifybackup/po/el.po
M src/bin/pg_verifybackup/po/es.po
M src/bin/pg_verifybackup/po/ko.po
M src/bin/pg_verifybackup/po/ru.po
M src/bin/pg_waldump/nls.mk
A src/bin/pg_waldump/po/el.po
M src/bin/pg_waldump/po/es.po
A src/bin/pg_waldump/po/ko.po
M src/bin/pg_waldump/po/ru.po
M src/bin/pg_waldump/po/uk.po
M src/bin/psql/po/el.po
M src/bin/psql/po/es.po
M src/bin/psql/po/ja.po
M src/bin/psql/po/ka.po
M src/bin/psql/po/ko.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/el.po
M src/bin/scripts/po/es.po
M src/bin/scripts/po/ko.po
M src/bin/scripts/po/ru.po
M src/interfaces/ecpg/ecpglib/po/es.po
M src/interfaces/ecpg/ecpglib/po/ru.po
M src/interfaces/ecpg/preproc/po/el.po
M src/interfaces/ecpg/preproc/po/es.po
M src/interfaces/ecpg/preproc/po/ko.po
M src/interfaces/ecpg/preproc/po/ru.po
M src/interfaces/libpq/po/el.po
M src/interfaces/libpq/po/es.po
M src/interfaces/libpq/po/ja.po
M src/interfaces/libpq/po/ko.po
M src/interfaces/libpq/po/ru.po
M src/interfaces/libpq/po/uk.po
M src/pl/plperl/po/el.po
M src/pl/plperl/po/es.po
M src/pl/plperl/po/ko.po
M src/pl/plperl/po/ru.po
M src/pl/plperl/po/sv.po
M src/pl/plpgsql/src/po/el.po
M src/pl/plpgsql/src/po/es.po
M src/pl/plpgsql/src/po/ko.po
M src/pl/plpgsql/src/po/ru.po
M src/pl/plpgsql/src/po/sv.po
M src/pl/plpython/po/de.po
M src/pl/plpython/po/es.po
M src/pl/plpython/po/fr.po
M src/pl/plpython/po/ru.po
M src/pl/plpython/po/sv.po
M src/pl/tcl/po/el.po
M src/pl/tcl/po/es.po
M src/pl/tcl/po/ko.po
M src/pl/tcl/po/ru.po
M src/pl/tcl/po/sv.po

Release notes for 15.3, 14.8, 13.11, 12.15, 11.20.

commit   : b89a27ae554492501cfcd6492c9a9fc30be1dc7b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 7 May 2023 12:36:12 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 7 May 2023 12:36:12 -0400    

Click here for diff

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

Add ruleutils support for decompiling MERGE commands.

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

Click here for diff

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

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

First-draft release notes for 15.3.

commit   : 56e869a0987c93f594e73c1c3e49274de5c502d3    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 5 May 2023 12:38:54 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 5 May 2023 12:38:54 -0400    

Click here for diff

As usual, the release notes for other branches will be made by cutting  
these down, but put them up for community review first.  

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

Fix typo with wait event for SLRU buffer of commit timestamps

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

Click here for diff

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

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

Fix prove_installcheck when used with PGXS

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

Click here for diff

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

M src/Makefile.global.in

Move return statements out of PG_TRY blocks.

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

Click here for diff

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

M src/pl/plpython/plpy_exec.c

In array_position()/array_positions(), beware of empty input array.

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

Click here for diff

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

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

Tighten array dimensionality checks in Python -> SQL array conversion.

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

Click here for diff

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

M src/pl/plpython/expected/plpython_types.out
M src/pl/plpython/plpy_typeio.c
M src/pl/plpython/sql/plpython_types.sql

Doc: clarify behavior of row-limit arguments in the PLs' SPI wrappers.

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

Click here for diff

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

M doc/src/sgml/plperl.sgml
M doc/src/sgml/plpython.sgml
M doc/src/sgml/pltcl.sgml

doc: Fix typo in pg_amcheck for term "schema"

commit   : 77ea05406cb61292782eb874866247f20b47b6df    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 2 May 2023 11:40:58 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 2 May 2023 11:40:58 +0900    

Click here for diff

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

M doc/src/sgml/ref/pg_amcheck.sgml

Tighten array dimensionality checks in Perl -> SQL array conversion.

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

Click here for diff

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

M src/pl/plperl/expected/plperl_array.out
M src/pl/plperl/plperl.c
M src/pl/plperl/sql/plperl_array.sql

Handle zero-length sublist correctly in Python -> SQL array conversion.

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

Click here for diff

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

M src/pl/plpython/expected/plpython_types.out
M src/pl/plpython/plpy_typeio.c
M src/pl/plpython/sql/plpython_types.sql

Fix crashes with CREATE SCHEMA AUTHORIZATION and schema elements

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

Click here for diff

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

M src/backend/commands/schemacmds.c
M src/backend/parser/parse_utilcmd.c
M src/include/parser/parse_utilcmd.h
A src/test/regress/expected/create_schema.out
M src/test/regress/parallel_schedule
A src/test/regress/sql/create_schema.sql

Prevent underflow in KeepLogSeg().

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

Click here for diff

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

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

In hstore_plpython, avoid crashing when return value isn't a mapping.

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

Click here for diff

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

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

Re-add tracking of wait event SLRUFlushSync

commit   : 1ed1b84bdcd26abf3c4d08a9cf1aa9f7834262ab    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 26 Apr 2023 07:30:42 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 26 Apr 2023 07:30:42 +0900    

Click here for diff

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

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

Fix vacuum_cost_delay check for balance calculation.

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

Click here for diff

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

M src/backend/postmaster/autovacuum.c

Fix buffer refcount leak with FDW bulk inserts

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

Click here for diff

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

M contrib/postgres_fdw/expected/postgres_fdw.out
M contrib/postgres_fdw/sql/postgres_fdw.sql
M src/backend/executor/nodeModifyTable.c

Fix memory leakage in plpgsql DO blocks that use cast expressions.

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

Click here for diff

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

M src/pl/plpgsql/src/pl_exec.c
M src/pl/plpgsql/src/plpgsql.h

Remove duplicate lines of code

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

Click here for diff

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

M src/backend/utils/adt/multirangetypes_selfuncs.c
M src/interfaces/ecpg/preproc/variable.c

Validate ltree siglen GiST option to be int-aligned

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

Click here for diff

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

M contrib/ltree/expected/ltree.out
M contrib/ltree/ltree_gist.c
M contrib/ltree/sql/ltree.sql
M doc/src/sgml/ltree.sgml

Fix custom validators call in build_local_reloptions()

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

Click here for diff

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

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

Avoid character classification in regex escape parsing.

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

Click here for diff

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

M src/backend/regex/regc_lex.c

Use --strip-unneeded when stripping static libraries with GNU strip.

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

Click here for diff

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

M config/programs.m4
M configure

Fix list_copy_head() with empty Lists

commit   : 63a03aea6bc89060010255e8e61c83f95e1daec8    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Fri, 21 Apr 2023 10:02:25 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Fri, 21 Apr 2023 10:02:25 +1200    

Click here for diff

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

M src/backend/nodes/list.c

Doc: clarify NULLS NOT DISTINCT use in unique indexes

commit   : 94d73f9abdf13e6dd93d96d0e4b197479c8756de    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Thu, 20 Apr 2023 23:52:36 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Thu, 20 Apr 2023 23:52:36 +1200    

Click here for diff

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

M doc/src/sgml/indices.sgml

Update time zone data files to tzdata release 2023c.

commit   : 62b22caa5531da8f6498f09f15ac0f09c95b1459    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 18 Apr 2023 14:46:39 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 18 Apr 2023 14:46:39 -0400    

Click here for diff

DST law changes in Egypt, Greenland, Morocco, and Palestine.  
  
When observing Moscow time, Europe/Kirov and Europe/Volgograd now  
use the abbreviations MSK/MSD instead of numeric abbreviations,  
for consistency with other timezones observing Moscow time.  
  
Also, America/Yellowknife is no longer distinct from America/Edmonton;  
this affects some pre-1948 timestamps in that area.  

M src/timezone/data/tzdata.zi
M src/timezone/known_abbrevs.txt

ecpg: Fix handling of strings in ORACLE compat code with SQLDA

commit   : 8c746be44002e8f95dcf8e98f58a47ac851563ee    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 18 Apr 2023 11:20:47 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 18 Apr 2023 11:20:47 +0900    

Click here for diff

When compiled with -C ORACLE, ecpg_get_data() had a one-off issue where  
it would incorrectly store the null terminator byte to str[-1] when  
varcharsize is 0, which is something that can happen when using SQLDA.  
This would eat 1 byte from the previous field stored, corrupting the  
results generated.  
  
All the callers of ecpg_get_data() estimate and allocate enough storage  
for the data received, and the fix of this commit relies on this  
assumption.  Note that this maps to the case where no padding or  
truncation is required.  
  
This issue has been introduced by 3b7ab43 with the Oracle compatibility  
option, so backpatch down to v11.  
  
Author: Kyotaro Horiguchi  
Discussion: https://postgr.es/m/20230410.173500.440060475837236886.horikyota.ntt@gmail.com  
Backpatch-through: 11  

M src/interfaces/ecpg/ecpglib/data.c
M src/interfaces/ecpg/test/compat_oracle/char_array.pgc
M src/interfaces/ecpg/test/expected/compat_oracle-char_array.c
M src/interfaces/ecpg/test/expected/compat_oracle-char_array.stderr
M src/interfaces/ecpg/test/expected/compat_oracle-char_array.stdout

Avoid trying to write an empty WAL record in log_newpage_range().

commit   : 2207df7c34bfcecec33da2a47068e94d7882ffdb    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 17 Apr 2023 14:22:06 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 17 Apr 2023 14:22:06 -0400    

Click here for diff

If the last few pages in the specified range are empty (all zero),  
then log_newpage_range() could try to emit an empty WAL record  
containing no FPIs.  This at least upsets an Assert in  
ReserveXLogInsertLocation, and might perhaps have bad real-world  
consequences in non-assert builds.  
  
This has been broken since log_newpage_range() was introduced,  
but the case was hard if not impossible to hit before commit 3d6a98457  
decided it was okay to leave VM and FSM pages intentionally zero.  
Nonetheless, it seems prudent to back-patch.  log_newpage_range()  
was added in v12 but later back-patched, so this affects all  
supported branches.  
  
Matthias van de Meent, per report from Justin Pryzby  
  
Discussion: https://postgr.es/m/ZD1daibg4RF50IOj@telsasoft.com  

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

Fix assignment to array of domain over composite, redux.

commit   : c53ed26ea46e425c1a78bd0e72b74a541eb08a93    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 15 Apr 2023 12:01:39 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 15 Apr 2023 12:01:39 -0400    

Click here for diff

Commit 3e310d837 taught isAssignmentIndirectionExpr() to look through  
CoerceToDomain nodes.  That's not sufficient, because since commit  
04fe805a1 it's been possible for the planner to simplify  
CoerceToDomain to RelabelType when the domain has no constraints  
to enforce.  So we need to look through RelabelType too.  
  
Per bug #17897 from Alexander Lakhin.  Although 3e310d837 was  
back-patched to v11, it seems sufficient to apply this change  
to v12 and later, since 04fe805a1 came in in v12.  
  
Dmitry Dolgov  
  
Discussion: https://postgr.es/m/17897-4216c546c3874044@postgresql.org  

M src/backend/executor/execExpr.c
M src/test/regress/expected/domain.out
M src/test/regress/sql/domain.sql

doc: PQinitOpenSSL and PQinitSSL are obsolete in OpenSSL 1.1.0+

commit   : de575c78e14c909ce6962021552e0263ac237935    
  
author   : Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Fri, 14 Apr 2023 10:15:50 +0200    
  
committer: Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Fri, 14 Apr 2023 10:15:50 +0200    

Click here for diff

Starting with OpenSSL 1.1.0 there is no need to call PQinitOpenSSL  
or PQinitSSL to avoid duplicate initialization of OpenSSL.  Add a  
note to the documentation to explain this.  
  
Backpatch to all supported versions as older OpenSSL versions are  
equally likely to be used for all branches.  
  
Reported-by: Sebastien Flaesch <sebastien.flaesch@4js.com>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/DBAP191MB12895BFFEC4B5FE0460D0F2FB0459@DBAP191MB1289.EURP191.PROD.OUTLOOK.COM  
Backpatch-through: 11, all supported versions  

M doc/src/sgml/libpq.sgml

Fix incorrect partition pruning logic for boolean partitioned tables

commit   : 0c09160e113f3b7daf9fc5370357955ab039428d    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Fri, 14 Apr 2023 16:21:07 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Fri, 14 Apr 2023 16:21:07 +1200    

Click here for diff

The partition pruning logic assumed that "b IS NOT true" was exactly the  
same as "b IS FALSE".  This is not the case when considering NULL values.  
Fix this so we correctly include any partition which could hold NULL  
values for the NOT case.  
  
Additionally, this fixes a bug in the partition pruning code which handles  
partitioned tables partitioned like ((NOT boolcol)).  This is a seemingly  
unlikely schema design, and it was untested and also broken.  
  
Here we add tests for the ((NOT boolcol)) case and insert some actual data  
into those tables and verify we do get the correct rows back when running  
queries.  I've also adjusted the existing boolpart tests to include some  
data and verify we get the correct results too.  
  
Both the bugs being fixed here could lead to incorrect query results with  
fewer rows being returned than expected.  No additional rows could have  
been returned accidentally.  
  
In passing, remove needless ternary expression.  It's more simple just to  
pass !is_not_clause to makeBoolConst().  It makes sense to do this so the  
code is consistent with the bug fix in the "else if" condition just below.  
  
David Kimura did submit a patch to fix the first of the issues here, but  
that's not what's being committed here.  
  
Reported-by: David Kimura  
Reviewed-by: Richard Guo, David Kimura  
Discussion: https://postgr.es/m/CAHnPFjQ5qxs6J_p+g8=ww7GQvfn71_JE+Tygj0S7RdRci1uwPw@mail.gmail.com  
Backpatch-through: 11, all supported versions  

M src/backend/partitioning/partprune.c
M src/test/regress/expected/partition_prune.out
M src/test/regress/sql/partition_prune.sql

basebackup_to_shell: Check for a NULL return from OpenPipeStream.

commit   : fa83e9e23ca2542d040466d820c3bf8eef930331    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Wed, 12 Apr 2023 11:37:13 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Wed, 12 Apr 2023 11:37:13 -0400    

Click here for diff

Per complaint from Peter Eisentraut.  
  
Discussion: http://postgr.es/m/4f1707cc-2432-da35-64a2-5c2a8d92a388@enterprisedb.com  

M contrib/basebackup_to_shell/basebackup_to_shell.c

Document BaseBackupSync and BaseBackupWrite wait events.

commit   : 749320cdc3fd747b9238d4e67a7521973c03fa27    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Wed, 12 Apr 2023 11:18:40 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Wed, 12 Apr 2023 11:18:40 -0400    

Click here for diff

Commit 3500ccc39b0dadd1068a03938e4b8ff562587ccc should have done  
this, but I overlooked it.  
  
Per complaint from Thomas Munro.  
  
Discussion: http://postgr.es/m/CA+hUKGJixAHc860Ej9Qzd_z96Z6aoajAgJ18bYfV3Lfn6t9=+Q@mail.gmail.com  

M doc/src/sgml/monitoring.sgml

Fix parallel-safety marking when moving initplans to another node.

commit   : f4badbcf4540d3f15de0e36fabca3ab05b20b922    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 12 Apr 2023 10:46:30 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 12 Apr 2023 10:46:30 -0400    

Click here for diff

Our policy since commit ab77a5a45 has been that a plan node having  
any initplans is automatically not parallel-safe.  (This could be  
relaxed, but not today.)  clean_up_removed_plan_level neglected  
this, and could attach initplans to a parallel-safe child plan  
node without clearing the plan's parallel-safe flag.  That could  
lead to "subplan was not initialized" errors at runtime, in case  
an initplan referenced another one and only the referencing one  
got transmitted to parallel workers.  
  
The fix in clean_up_removed_plan_level is trivial enough.  
materialize_finished_plan also moves initplans from one node  
to another, but it's okay because it already copies the source  
node's parallel_safe flag.  The other place that does this kind  
of thing is standard_planner's hack to inject a top-level Gather  
when debug_parallel_query is active.  But that's actually dead  
code given that we're correctly enforcing the "initplans aren't  
parallel safe" rule, so just replace it with an Assert that  
there are no initplans.  
  
Also improve some related comments.  
  
Normally we'd add a regression test case for this sort of bug.  
The mistake itself is already reached by existing tests, but there  
is accidentally no visible problem.  The only known test case that  
creates an actual failure seems too indirect and fragile to justify  
keeping it as a regression test (not least because it fails to fail  
in v11, though the bug is clearly present there too).  
  
Per report from Justin Pryzby.  Back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/ZDVt6MaNWkRDO1LQ@telsasoft.com  

M src/backend/optimizer/plan/planner.c
M src/backend/optimizer/plan/setrefs.c
M src/backend/optimizer/plan/subselect.c
M src/backend/optimizer/util/pathnode.c

Fix detection of unseekable files for fseek() and ftello() with MSVC

commit   : 5c32549460fcabfb34ce47f96499bf753aaabeea    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 12 Apr 2023 09:09:53 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 12 Apr 2023 09:09:53 +0900    

Click here for diff

Calling fseek() or ftello() on a handle to a non-seeking device such as  
a pipe or a communications device is not supported.  Unfortunately,  
MSVC's flavor of these routines, _fseeki64() and _ftelli64(), do not  
return an error when given a pipe as handle.  Some of the logic of  
pg_dump and restore relies on these routines to check if a handle is  
seekable, causing failures when passing the contents of pg_dump to  
pg_restore through a pipe, for example.  
  
This commit introduces wrappers for fseeko() and ftello() on MSVC so as  
any callers are able to properly detect the cases of non-seekable  
handles.  This relies mainly on GetFileType(), sharing a bit of code  
with the MSVC port for fstat().  The code in charge of getting a file  
type is refactored into a new file called win32common.c, shared by  
win32stat.c and the new win32fseek.c.  It includes the MSVC ports for  
fseeko() and ftello().  
  
Like 765f5df, this is backpatched down to 14, where the fstat()  
implementation for MSVC is able to understand about files larger than  
4GB in size.  Using a TAP test for that is proving to be tricky as  
IPC::Run handles the pipes by itself, still I have been able to check  
the fix manually.  
  
Reported-by: Daniel Watzinger  
Author: Juan José Santamaría Flecha, Michael Paquier  
Discussion: https://postgr.es/m/CAC+AXB26a4EmxM2suXxPpJaGrqAdxracd7hskLg-zxtPB50h7A@mail.gmail.com  
Backpatch-through: 14  

M configure
M configure.ac
M src/include/port/win32_port.h
A src/port/win32common.c
A src/port/win32fseek.c
M src/port/win32stat.c
M src/tools/msvc/Mkvcbuild.pm

Doc: add missed entries in BRIN extensibility tables.

commit   : 8b07ee0beb9f67716a13bae193207ac19129bd0c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Apr 2023 15:49:48 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Apr 2023 15:49:48 -0400    

Click here for diff

The tables in "71.3. Extensibility" listing the support functions  
for bloom and minmax-multi opclasses should include the associated  
options function.  While this isn't quite as required as the rest,  
you need it for full functionality of the opclass.  
  
Back-patch to v14 where these functions were added.  

M doc/src/sgml/brin.sgml

Doc: adjust examples of EXTRACT() output to match current reality.

commit   : 707691ea620eaa7d8c7fc1e5177a54e944f39b59    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Apr 2023 13:09:18 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Apr 2023 13:09:18 -0400    

Click here for diff

EXTRACT(EPOCH), EXTRACT(SECOND), and some related cases print more  
trailing zeroes than they used to.  This behavior change happened  
with commit a2da77cdb (Change return type of EXTRACT to numeric),  
and it was intentional according to the commit log:  
  
    - Return values when extracting fields with possibly fractional  
      values, such as second and epoch, now have the full scale that the  
      value has internally (so, for example, '1.000000' instead of just  
      '1').  
  
It's been like that for two releases now, so while I suggested  
changing this back, it's probably better to adjust the documentation  
examples.  
  
Per bug #17866 from Евгений Жужнев.  Back-patch to v14 where the  
change came in.  
  
Discussion: https://postgr.es/m/17866-18eb70095b1594e2@postgresql.org  

M doc/src/sgml/func.sgml

For Kerberos testing, disable DNS lookups

commit   : ced712f1a1d60d5e24d207d97efbc4dddc051079    
  
author   : Stephen Frost <sfrost@snowman.net>    
date     : Fri, 7 Apr 2023 19:36:25 -0400    
  
committer: Stephen Frost <sfrost@snowman.net>    
date     : Fri, 7 Apr 2023 19:36:25 -0400    

Click here for diff

Similar to 8dff2f224, this disables DNS lookups by the Kerberos library  
to look up the KDC and the realm while the Kerberos tests are running.  
In some environments, these lookups can take a long time and end up  
timing out and causing tests to fail.  Further, since this isn't really  
our domain, we shouldn't be sending out these DNS requests during our  
tests.  

M src/test/kerberos/t/001_auth.pl

For Kerberos testing, disable reverse DNS lookup

commit   : 0787432f33fbbda4f628f4499468a3f7d0bc11ad    
  
author   : Stephen Frost <sfrost@snowman.net>    
date     : Fri, 7 Apr 2023 19:36:25 -0400    
  
committer: Stephen Frost <sfrost@snowman.net>    
date     : Fri, 7 Apr 2023 19:36:25 -0400    

Click here for diff

In our Kerberos test suite, there isn't much need to worry about the  
normal canonicalization that Kerberos provides by looking up the reverse  
DNS for the IP address connected to, and in some cases it can actively  
cause problems (eg: a captive portal wifi where the normally not  
resolvable localhost address used ends up being resolved anyway, and  
not to the domain we are using for testing, causing the entire  
regression test to fail with errors about not being able to get a TGT  
for the remote realm for cross-realm trust).  
  
Therefore, disable it by adding rdns = false into the krb5.conf that's  
generated for the test.  
  
Reviewed-By: Heikki Linnakangas  
Discussion: https://postgr.es/m/Y/QD2zDkDYQA1GQt@tamriel.snowman.net  

M src/test/kerberos/t/001_auth.pl

Stabilize just-added regression test cases.

commit   : d6ac2348b8a1f031013066619dfb2ce9872251ff    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 6 Apr 2023 18:13:49 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 6 Apr 2023 18:13:49 -0400    

Click here for diff

The tests added by commits 029dea882 et al turn out to produce  
different output under -DRANDOMIZE_ALLOCATED_MEMORY.  This is  
not a bug exactly: that flag causes coerce_type() to invoke  
the input function twice when coercing an unknown-type literal  
to a specific type.  So you get tsqueryin's bleat about an empty  
tsquery twice.  Revise the test query to avoid that.  
  
Discussion: https://postgr.es/m/20230406213813.uep7plg6lvcywujo@awork3.anarazel.de  

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

Fix ts_headline() edge cases for empty query and empty search text.

commit   : f976a77787ebfd0595a3aa19ac6bb587cc6391e2    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 6 Apr 2023 15:52:37 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 6 Apr 2023 15:52:37 -0400    

Click here for diff

tsquery's GETQUERY() macro is only safe to apply to a tsquery  
that is known non-empty; otherwise it gives a pointer to garbage.  
Before commit 5a617d75d, ts_headline() avoided this pitfall, but  
only in a very indirect, nonobvious way.  (hlCover could not reach  
its TS_execute call, because if the query contains no lexemes  
then hlFirstIndex would surely return -1.)  After that commit,  
it fell into the trap, resulting in weird errors such as  
"unrecognized operator" and/or valgrind complaints.  In HEAD,  
fix this by not calling TS_execute_locations() at all for an  
empty query.  In the back branches, add a defensive check to  
hlCover() --- that's not fixing any live bug, but I judge the  
code a bit too fragile as-is.  
  
Also, both mark_hl_fragments() and mark_hl_words() were careless  
about the possibility of empty search text: in the cases where  
no match has been found, they'd end up telling mark_fragment() to  
mark from word indexes 0 to 0 inclusive, even when there is no  
word 0.  This is harmless since we over-allocated the prs->words  
array, but it does annoy valgrind.  Fix so that the end index is -1  
and thus mark_fragment() will do nothing in such cases.  
  
Bottom line is that this fixes a live bug in HEAD, but in the  
back branches it's only getting rid of a valgrind nitpick.  
Back-patch anyway.  
  
Per report from Alexander Lakhin.  
  
Discussion: https://postgr.es/m/c27f642d-020b-01ff-ae61-086af287c4fd@gmail.com  

M src/backend/tsearch/wparser_def.c
M src/test/regress/expected/tsearch.out
M src/test/regress/sql/tsearch.sql

Fix another issue with ENABLE/DISABLE TRIGGER on partitioned tables.

commit   : 2624de79efe8d6866ddaf82ab780c96ad554b004    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 5 Apr 2023 12:56:30 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 5 Apr 2023 12:56:30 -0400    

Click here for diff

In v13 and v14, the ENABLE/DISABLE TRIGGER USER variant malfunctioned  
on cloned triggers, failing to find the clones because it thought they  
were system triggers.  Other variants of ENABLE/DISABLE TRIGGER would  
improperly apply a superuserness check.  Fix by adjusting the is-it-  
a-system-trigger check to match reality in those branches.  (As far  
as I can find, this is the only place that got it wrong.)  
  
There's no such bug in v15/HEAD, because we revised the catalog  
representation of system triggers to be what this code was expecting.  
However, add the test case to these branches anyway, because this area  
is visibly pretty fragile.  Also remove an obsoleted comment.  
  
The recent v15/HEAD commit 6949b921d fixed a nearby bug.  I now see  
that my commit message for that was inaccurate: the behavior of  
recursing to clone triggers is older than v15, but it didn't apply  
to the case in v13/v14 because in those branches parent partitioned  
tables have no pg_trigger entries for foreign-key triggers.  But add  
the test case from that commit to v13/v14, just to show what is  
happening there.  
  
Per bug #17886 from DzmitryH.  
  
Discussion: https://postgr.es/m/17886-5406d5d828aa4aa3@postgresql.org  

M src/backend/commands/trigger.c
M src/test/regress/expected/triggers.out
M src/test/regress/sql/triggers.sql

doc: Update error messages in RLS examples

commit   : f5d60b1ea2156ecd42c6ccd4284f715763abf8f8    
  
author   : John Naylor <john.naylor@postgresql.org>    
date     : Wed, 5 Apr 2023 14:16:19 +0700    
  
committer: John Naylor <john.naylor@postgresql.org>    
date     : Wed, 5 Apr 2023 14:16:19 +0700    

Click here for diff

Since 8b9e9644d, the messages for failed permissions checks report  
"table" where appropriate, rather than "relation".  
  
Backpatch to all supported branches  

M doc/src/sgml/ddl.sgml

doc: Add more details about pg_stat_get_xact_blocks_{fetched,hit}

commit   : b135a94db7743ffbceabf62c87be2b8f32a91465    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 5 Apr 2023 07:59:49 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 5 Apr 2023 07:59:49 +0900    

Click here for diff

The explanation describing the dependency to system read() calls for  
these two functions has been removed in ddfc2d9.  And after more  
discussion about d69c404, we have concluded that adding more details  
makes them easier to understand.  
  
While on it, use the term "block read requests" (maybe found in cache)  
rather than "buffers fetched" and "buffer hits".  
  
Per discussion with Melanie Plageman, Kyotaro Horiguchi, Bertrand  
Drouvot and myself.  
  
Discussion: https://postgr.es/m/CAAKRu_ZmdiScT4q83OAbfmR5AH-L5zWya3SXjaxiJvhCob-e2A@mail.gmail.com  
Backpatch-through: 11  

M doc/src/sgml/monitoring.sgml

Reject system columns as elements of foreign keys.

commit   : 6e369817367cc3a9d0db368383a4430733883142    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 31 Mar 2023 11:18:49 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 31 Mar 2023 11:18:49 -0400    

Click here for diff

Up through v11 it was sensible to use the "oid" system column as  
a foreign key column, but since that was removed there's no visible  
usefulness in making any of the remaining system columns a foreign  
key.  Moreover, since the TupleTableSlot rewrites in v12, such cases  
actively fail because of implicit assumptions that only user columns  
appear in foreign keys.  The lack of complaints about that seems  
like good evidence that no one is trying to do it.  Hence, rather  
than trying to repair those assumptions (of which there are at least  
two, maybe more), let's just forbid the case up front.  
  
Per this patch, a system column in either the referenced or  
referencing side of a foreign key will draw this error; however,  
putting one in the referenced side would have failed later anyway,  
since we don't allow unique indexes to be made on system columns.  
  
Per bug #17877 from Alexander Lakhin.  Back-patch to v12; the  
case still appears to work in v11, so we shouldn't break it there.  
  
Discussion: https://postgr.es/m/17877-4bcc658e33df6de1@postgresql.org  

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

Ensure acquire_inherited_sample_rows sets its output parameters.

commit   : 6f7ca625b9d3f6298a3e1ecd0187d123c25316a4    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 31 Mar 2023 10:08:40 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 31 Mar 2023 10:08:40 -0400    

Click here for diff

The totalrows/totaldeadrows outputs were left uninitialized in cases  
where we find no analyzable child tables of a partitioned table.  This  
could lead to setting the partitioned table's pg_class.reltuples value  
to garbage.  It's not clear that that would have any very bad effects  
in practice, but fix it anyway because it's making valgrind unhappy.  
  
Reported and diagnosed by Alexander Lakhin (bug #17880).  
  
Discussion: https://postgr.es/m/17880-9282037c923d856e@postgresql.org  

M src/backend/commands/analyze.c

Fix List memory issue in transformColumnDefinition

commit   : df567fbf6e41aa6b574ead3803c304af55645501    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Fri, 31 Mar 2023 12:13:34 +1300    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Fri, 31 Mar 2023 12:13:34 +1300    

Click here for diff

When calling generateSerialExtraStmts(), we would pass in the  
constraint->options.  In some cases, generateSerialExtraStmts() would  
modify the referenced List to remove elements from it, but doing so is  
invalid without assigning the list back to all variables that point to it.  
In the particular reported problem case, the List became empty, in which  
cases it became NIL, but the passed in constraint->options didn't get to  
find out about that and was left pointing to free'd memory.  
  
To fix this, just perform a list_copy() inside generateSerialExtraStmts().  
We could just do a list_copy() just before we perform the delete from the  
list, however, that seems less robust.  Let's make sure the generated  
CreateSeqStmt gets a completely different copy of the list to be safe.  
  
Bug: #17879  
Reported-by: Fei Changhong  
Diagnosed-by: Fei Changhong  
Discussion: https://postgr.es/m/17879-b7dfb5debee58ff5@postgresql.org  
Backpatch-through: 11, all supported versions  

M src/backend/parser/parse_utilcmd.c

Fix dereference of dangling pointer in GiST index buffering build.

commit   : 2dc77adc768e7b5732b58c7ce1d0c0beb09cc79c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 29 Mar 2023 11:31:30 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 29 Mar 2023 11:31:30 -0400    

Click here for diff

gistBuildCallback tried to fetch the size of an index tuple that  
might have already been freed by gistProcessEmptyingQueue.  
While this seems to usually be harmless in production builds,  
in principle it could result in a SIGSEGV, or more likely a bogus  
value for indtuplesSize leading to poor page-split decisions later  
in the build.  
  
The memory management here is confusing and could stand to be  
refactored, but for the moment it seems to be enough to fetch  
the tuple size sooner.  AFAICT the indtuples[Size] totals aren't  
used in between these places; even if they were, the updated  
values shouldn't be any worse to use.  So just move the  
incrementing of the totals up.  
  
It's not very clear why our valgrind-using buildfarm animals  
haven't noticed this problem, because the relevant code path  
does seem to be exercised according to the code coverage report.  
I think the reason that we didn't fix this bug after the first  
report is that I'd wanted to try to understand that better.  
However, now that it's been re-discovered let's just be pragmatic  
and fix it already.  
  
Original report by Alexander Lakhin (bug #16329),  
later rediscovered by Egor Chindyaskin (bug #17874).  
  
Patch by Alexander Lakhin (commentary by Pavel Borisov and me).  
Back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/16329-7a6aa9b6fa1118a1@postgresql.org  
Discussion: https://postgr.es/m/17874-63ca6c7ce42d2103@postgresql.org  

M src/backend/access/gist/gistbuild.c

amcheck: In verify_heapam, allows tuples with xmin 0.

commit   : 453f53821fa549d3e46c87a076fc7849fab9a948    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Tue, 28 Mar 2023 16:16:53 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Tue, 28 Mar 2023 16:16:53 -0400    

Click here for diff

Commit e88754a1965c0f40a723e6e46d670cacda9e19bd caused that case  
to be reported as corruption, but Peter Geoghegan pointed out that  
it can legitimately happen in the case of a speculative insertion  
that aborts, so we'd better not flag it as corruption after all.  
  
Back-patch to v14, like the commit that introduced the issue.  
  
Discussion: http://postgr.es/m/CAH2-WzmEabzcPTxSY-NXKH6Qt3FkAPYHGQSe2PtvGgj17ZQkCw@mail.gmail.com  

M contrib/amcheck/verify_heapam.c

Fix corner-case planner failure for MERGE.

commit   : bf5c4b3d9da67ab0dd8a5a560804f88370c42866    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 28 Mar 2023 11:36:50 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 28 Mar 2023 11:36:50 -0400    

Click here for diff

MERGE planning could fail with "variable not found in subplan target  
list" if the target table is partitioned and all its partitions are  
excluded at plan time, or in the case where it has no partitions but  
used to have some.  This happened because distribute_row_identity_vars  
thought it didn't need to make the target table's reltarget list  
fully valid; but if we generate a join plan then that is required  
because the dummy Result node's tlist will be made from the reltarget.  
  
The same logic appears in distribute_row_identity_vars in v14,  
but AFAICS the problem is unreachable in that branch for lack of  
MERGE.  In other updating statements, the target table is always  
inner-joined to any other tables, so if the target is known dummy  
then the whole plan reduces to dummy, so no join nodes are created.  
So I'll refrain from back-patching this code change to v14 for now.  
  
Per report from Alvaro Herrera.  
  
Discussion: https://postgr.es/m/20230328112248.6as34mlx5sr4kltg@alvherre.pgsql  

M src/backend/optimizer/util/appendinfo.c
M src/test/regress/expected/merge.out
M src/test/regress/sql/merge.sql

doc: Fix XML_CATALOG_FILES env var for Apple Silicon machines

commit   : 50792b15537147a5e62e672568bd14e1e9292db2    
  
author   : Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Mon, 27 Mar 2023 21:35:19 +0200    
  
committer: Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Mon, 27 Mar 2023 21:35:19 +0200    

Click here for diff

Homebrew changed the prefix for Apple Silicon based machines, so  
our advice for XML_CATALOG_FILES needs to mention both.  More info  
on the Homebrew change can be found at:  
  
https://github.com/Homebrew/brew/issues/9177  
  
This is backpatch of commits 4c8d65408 and 5a91c7975, the latter  
which contained a small fix based on a report from Dagfinn Ilmari  
Mannsåker.  
  
Author: Julien Rouhaud <julien.rouhaud@free.fr>  
Discussion: https://postgr.es/m/20230327082441.h7pa2vqiobbyo7rd@jrouhaud  

M doc/src/sgml/docguide.sgml

Reject attempts to alter composite types used in indexes.

commit   : d90d59e2503879cc2742a3a0eee01d2af2cca02d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 27 Mar 2023 15:04:02 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 27 Mar 2023 15:04:02 -0400    

Click here for diff

find_composite_type_dependencies() ignored indexes, which is a poor  
decision because an expression index could have a stored column of  
a composite (or other container) type even when the underlying table  
does not.  Teach it to detect such cases and error out.  We have to  
work a bit harder than for other relations because the pg_depend entry  
won't identify the specific index column of concern, but it's not much  
new code.  
  
This does not address bug #17872's original complaint that dropping  
a column in such a type might lead to violations of the uniqueness  
property that a unique index is supposed to ensure.  That seems of  
much less concern to me because it won't lead to crashes.  
  
Per bug #17872 from Alexander Lakhin.  Back-patch to all supported  
branches.  
  
Discussion: https://postgr.es/m/17872-d0fbb799dc3fd85d@postgresql.org  

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

Fix oversights in array manipulation.

commit   : 7c4873438fd4c89da40beb943a373c61ae509e93    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 26 Mar 2023 13:41:06 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 26 Mar 2023 13:41:06 -0400    

Click here for diff

The nested-arrays code path in ExecEvalArrayExpr() used palloc to  
allocate the result array, whereas every other array-creating function  
has used palloc0 since 18c0b4ecc.  This mostly works, but unused bits  
past the end of the nulls bitmap may end up undefined.  That causes  
valgrind complaints with -DWRITE_READ_PARSE_PLAN_TREES, and could  
cause planner misbehavior as cited in 18c0b4ecc.  There seems no very  
good reason why we should strive to avoid palloc0 in just this one case,  
so fix it the easy way with s/palloc/palloc0/.  
  
While looking at that I noted that we also failed to check for overflow  
of "nbytes" and "nitems" while summing the sizes of the sub-arrays,  
potentially allowing a crash due to undersized output allocation.  
For "nbytes", follow the policy used by other array-munging code of  
checking for overflow after each addition.  (As elsewhere, the last  
addition of the array's overhead space doesn't need an extra check,  
since palloc itself will catch a value between 1Gb and 2Gb.)  
For "nitems", there's no very good reason to sum the inputs at all,  
since we can perfectly well use ArrayGetNItems' result instead of  
ignoring it.  
  
Per discussion of this bug, also remove redundant zeroing of the  
nulls bitmap in array_set_element and array_set_slice.  
  
Patch by Alexander Lakhin and myself, per bug #17858 from Alexander  
Lakhin; thanks also to Richard Guo.  These bugs are a dozen years old,  
so back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/17858-8fd287fd3663d051@postgresql.org  

M src/backend/executor/execExprInterp.c
M src/backend/utils/adt/arrayfuncs.c

amcheck: Fix verify_heapam for tuples where xmin or xmax is 0.

commit   : 701ec555796884f6bd5d3ce67d927f52707ef9e6    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Thu, 23 Mar 2023 15:29:28 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Thu, 23 Mar 2023 15:29:28 -0400    

Click here for diff

In such cases, get_xid_status() doesn't set its output parameter (the  
third argument), so we shouldn't fall through to code which will test  
the value of that parameter. There are five existing calls to  
get_xid_status(), three of which seem to already handle this case  
properly.  This commit tries to fix the other two.  
  
If we're checking xmin and find that it is invalid (i.e. 0) just  
report that as corruption, similar to what's already done in the  
three cases that seem correct. If we're checking xmax and find  
that's invalid, that's fine: it just means that the tuple hasn't  
been updated or deleted.  
  
Thanks to Andres Freund and valgrind for finding this problem, and  
also to Andres for having a look at the patch.  This bug seems to go  
all the way back to where verify_heapam was first introduced, but  
wasn't detected until recently, possibly because of the new test cases  
added for update chain verification.  Back-patch to v14, where this  
code showed up.  
  
Discussion: http://postgr.es/m/CA+TgmoZAYzQZqyUparXy_ks3OEOfLD9-bEXt8N-2tS1qghX9gQ@mail.gmail.com  

M contrib/amcheck/verify_heapam.c

Ignore generated columns during apply of update/delete.

commit   : b6bf90edcd2f9a754a90a3c852d9e445d17a6555    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Thu, 23 Mar 2023 11:46:16 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Thu, 23 Mar 2023 11:46:16 +0530    

Click here for diff

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

M src/backend/executor/execReplication.c
M src/test/subscription/t/100_bugs.pl

Fix memory leak and inefficiency in CREATE DATABASE ... STRATEGY WAL_LOG

commit   : 560bb56c6eba5da7917e67783d46f0d5ca30e89a    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Wed, 22 Mar 2023 09:26:23 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Wed, 22 Mar 2023 09:26:23 -0700    

Click here for diff

RelationCopyStorageUsingBuffer() did not free the strategies used to access  
the source / target relation. They memory was released at the end of the  
transaction, but when using a template database with a lot of relations, the  
temporary leak can become big prohibitively big.  
  
RelationCopyStorageUsingBuffer() acquired the buffer for the target relation  
with RBM_NORMAL, therefore requiring a read of a block guaranteed to be  
zero. Use RBM_ZERO_AND_LOCK instead.  
  
Reviewed-by: Robert Haas <robertmhaas@gmail.com>  
Discussion: https://postgr.es/m/20230321070113.o2vqqxogjykwgfrr@awork3.anarazel.de  
Backpatch: 15-, where STRATEGY WAL_LOG was introduced  

M src/backend/storage/buffer/bufmgr.c

doc: Add description of some missing monitoring functions

commit   : a70e6e430628fe5ee802f47f4b043d33a0d41dda    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 22 Mar 2023 18:32:02 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 22 Mar 2023 18:32:02 +0900    

Click here for diff

This commit adds some documentation about two monitoring functions:  
- pg_stat_get_xact_blocks_fetched()  
- pg_stat_get_xact_blocks_hit()  
  
The description of these functions has been removed in ddfc2d9, later  
simplified by 5f2b089, assuming that all the functions whose  
descriptions were removed are used in system views.  Unfortunately, some  
of them were are not used in any system views, so they lacked  
documentation.  
  
This gap exists in the docs for a long time, so backpatch all the way  
down.  
  
Reported-by: Michael Paquier  
Author: Bertrand Drouvot  
Reviewed-by: Kyotaro Horiguchi  
Discussion: https://postgr.es/m/ZBeeH5UoNkTPrwHO@paquier.xyz  
Backpatch-through: 11  

M doc/src/sgml/monitoring.sgml

Ignore dropped columns during apply of update/delete.

commit   : 3c12407f4cf735e17a8af54ab4306cd199601619    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Tue, 21 Mar 2023 09:40:41 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Tue, 21 Mar 2023 09:40:41 +0530    

Click here for diff

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

M src/backend/executor/execReplication.c
M src/test/subscription/t/100_bugs.pl

Fix race in parallel hash join batch cleanup, take II.

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

Click here for diff

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

M src/backend/executor/nodeHash.c
M src/backend/executor/nodeHashjoin.c
M src/include/executor/hashjoin.h

Fix netmask handling in inet_minmax_multi_ops

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

Click here for diff

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

M src/backend/access/brin/brin_minmax_multi.c
M src/test/regress/expected/brin_multi.out
M src/test/regress/sql/brin_multi.sql

Fix memory leak in Memoize cache key evaluation

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

Click here for diff

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

M src/backend/executor/nodeMemoize.c

Doc: fix documentation example for bytea hex output format.

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

Click here for diff

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

M doc/src/sgml/datatype.sgml

Fix t_isspace(), etc., when datlocprovider=i and datctype=C.

commit   : 8b87e92919cd0e8e8ffbae543d996063149c3ccc    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Fri, 17 Mar 2023 11:47:35 -0700    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Fri, 17 Mar 2023 11:47:35 -0700    

Click here for diff

Check whether the datctype is C to determine whether t_isspace() and  
related functions use isspace() or iswspace().  
  
Previously, t_isspace() checked whether the database default collation  
was C; which is incorrect when the default collation uses the ICU  
provider.  
  
Discussion: https://postgr.es/m/79e4354d9eccfdb00483146a6b9f6295202e7890.camel@j-davis.com  
Reviewed-by: Peter Eisentraut  
Backpatch-through: 15  

M src/backend/tsearch/ts_locale.c
M src/backend/tsearch/wparser_def.c
M src/backend/utils/adt/pg_locale.c
M src/backend/utils/init/postinit.c
M src/include/utils/pg_locale.h

Fix pg_dump for hash partitioning on enum columns.

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

Click here for diff

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

M doc/src/sgml/ref/pg_dump.sgml
M doc/src/sgml/ref/pg_dumpall.sgml
M src/bin/pg_dump/common.c
M src/bin/pg_dump/pg_backup_archiver.c
M src/bin/pg_dump/pg_dump.c
M src/bin/pg_dump/pg_dump.h
A src/bin/pg_dump/t/004_pg_dump_parallel.pl

tests: Prevent syslog activity by slapd, take 2

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

Click here for diff

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

M src/test/ldap/t/001_auth.pl

Fix incorrect logic for determining safe WindowAgg run conditions

commit   : 371e3daaa53d09f1f265865dc9bf0dbff57c46ab    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Fri, 17 Mar 2023 15:51:00 +1300    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Fri, 17 Mar 2023 15:51:00 +1300    

Click here for diff

The logic added in 9d9c02ccd to determine when a qual can be used as a  
WindowClause run condition failed to correctly check for subqueries in the  
qual.  This was being done correctly for normal subquery qual pushdowns,  
it's just that 9d9c02ccd failed to follow the lead on that.  
  
This also fixes various other cases where transforming the qual into a  
WindowClause run condition in the subquery should have been disallowed.  
  
Bug: #17826  
Reported-by: Anban Company  
Discussion: https://postgr.es/m/17826-7d8750952f19a5f5@postgresql.org  
Backpatch-through: 15, where 9d9c02ccd was introduced.  

M src/backend/optimizer/path/allpaths.c
M src/test/regress/expected/window.out
M src/test/regress/sql/window.sql

tests: Minimize syslog activity by slapd

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

Click here for diff

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

M src/test/ldap/t/001_auth.pl

Small tidyup for commit d41a178b, part II.

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

Click here for diff

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

M src/backend/postmaster/postmaster.c

Work around spurious compiler warning in inet operators

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

Click here for diff

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

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

Small tidyup for commit d41a178b.

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

Click here for diff

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

M src/backend/postmaster/postmaster.c

Doc: mention CREATE+ATTACH PARTITION with CREATE TABLE...PARTITION OF.

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

Click here for diff

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

M doc/src/sgml/ddl.sgml
M doc/src/sgml/ref/create_table.sgml

Support PlaceHolderVars in MERGE actions.

commit   : 3908d6ae115801cc61486b286ab71d91c2cdbb99    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 15 Mar 2023 11:59:18 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 15 Mar 2023 11:59:18 -0400    

Click here for diff

preprocess_targetlist thought PHVs couldn't appear here.  
It was mistaken, as per report from Önder Kalacı.  
  
Surveying other pull_var_clause calls, I noted no similar errors,  
but I did notice that qual_is_pushdown_safe's assertion about  
!contain_window_function was pointless, because the following  
pull_var_clause call would complain about them anyway.  In HEAD  
only, remove the redundant Assert and improve the commentary.  
  
Discussion: https://postgr.es/m/CACawEhUuum-gC_2S3sXLTcsk7bUSPSHOD+g1ZpfKaDK-KKPPWA@mail.gmail.com  

M src/backend/optimizer/prep/preptlist.c
M src/test/regress/expected/merge.out
M src/test/regress/sql/merge.sql

Improve WIN32 port of fstat() to detect more file types

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

Click here for diff

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

M src/port/win32stat.c

Fix fractional vacuum_cost_delay.

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

Click here for diff

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

M src/backend/commands/vacuum.c

Fix waitpid() emulation on Windows.

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

Click here for diff

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

M src/backend/postmaster/postmaster.c

Fix corner case bug in numeric to_char() some more.

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

Click here for diff

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

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

Remove unnecessary code in dependency_is_compatible_expression().

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

Click here for diff

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

M src/backend/statistics/dependencies.c

Fix JSON error reporting for many cases of erroneous string values.

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

Click here for diff

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

M src/backend/utils/adt/jsonfuncs.c
M src/common/jsonapi.c
M src/test/regress/expected/json_encoding.out
M src/test/regress/expected/json_encoding_1.out

Fix failure to detect some cases of improperly-nested aggregates.

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

Click here for diff

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

M src/backend/parser/parse_agg.c
M src/test/regress/expected/aggregates.out
M src/test/regress/sql/aggregates.sql

Fix MERGE command tag for actions blocked by BEFORE ROW triggers.

commit   : da6257eee35db5d281a115838abaf285b46b52f3    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Mon, 13 Mar 2023 11:11:10 +0000    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Mon, 13 Mar 2023 11:11:10 +0000    

Click here for diff

This ensures that the row count in the command tag for a MERGE is  
correctly computed in the case where UPDATEs or DELETEs are skipped  
due to a BEFORE ROW trigger returning NULL (the INSERT case was  
already handled correctly by ExecMergeNotMatched() calling  
ExecInsert()).  
  
Back-patch to v15, where MERGE was introduced.  
  
Discussion: https://postgr.es/m/CAEZATCU8XEmR0JWKDtyb7iZ%3DqCffxS9uyJt0iOZ4TV4RT%2Bow1w%40mail.gmail.com  

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

Fix concurrent update issues with MERGE.

commit   : 7d9a75713ab91071a2110e25e7c86cbf2a6fdc4b    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Mon, 13 Mar 2023 10:23:42 +0000    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Mon, 13 Mar 2023 10:23:42 +0000    

Click here for diff

If MERGE attempts an UPDATE or DELETE on a table with BEFORE ROW  
triggers, or a cross-partition UPDATE (with or without triggers), and  
a concurrent UPDATE or DELETE happens, the merge code would fail.  
  
In some cases this would lead to a crash, while in others it would  
cause the wrong merge action to be executed, or no action at all. The  
immediate cause of the crash was the trigger code calling  
ExecGetUpdateNewTuple() as part of the EPQ mechanism, which fails  
because during a merge ri_projectNew is NULL, since merge has its own  
per-action projection information, which ExecGetUpdateNewTuple() knows  
nothing about.  
  
Fix by arranging for the trigger code to exit early, returning the  
TM_Result and TM_FailureData information, if a concurrent modification  
is detected, allowing the merge code to do the necessary EPQ handling  
in its own way. Similarly, prevent the cross-partition update code  
from doing any EPQ processing for a merge, allowing the merge code to  
work out what it needs to do.  
  
This leads to a number of simplifications in nodeModifyTable.c. Most  
notably, the ModifyTableContext->GetUpdateNewTuple() callback is no  
longer needed, and mergeGetUpdateNewTuple() can be deleted, since  
there is no longer any requirement for get-update-new-tuple during a  
merge. Similarly, ModifyTableContext->cpUpdateRetrySlot is no longer  
needed. Thus ExecGetUpdateNewTuple() and the retry_slot handling of  
ExecCrossPartitionUpdate() can be restored to how they were in v14,  
before the merge code was added, and ExecMergeMatched() no longer  
needs any special-case handling for cross-partition updates.  
  
While at it, tidy up ExecUpdateEpilogue() a bit, making it handle  
recheckIndexes locally, rather than passing it in as a parameter,  
ensuring that it is freed properly. This dates back to when it was  
split off from ExecUpdate() to support merge.  
  
Per bug #17809 from Alexander Lakhin, and follow-up investigation of  
bug #17792, also from Alexander Lakhin.  
  
Back-patch to v15, where MERGE was introduced, taking care to preserve  
backwards-compatibility of the trigger API in v15 for any extensions  
that might use it.  
  
Discussion:  
  https://postgr.es/m/17809-9e6650bef133f0fe%40postgresql.org  
  https://postgr.es/m/17792-0f89452029662c36%40postgresql.org  

M src/backend/commands/trigger.c
M src/backend/executor/nodeModifyTable.c
M src/include/commands/trigger.h
M src/test/isolation/expected/merge-delete.out
M src/test/isolation/expected/merge-match-recheck.out
M src/test/isolation/specs/merge-delete.spec
M src/test/isolation/specs/merge-match-recheck.spec

Fix inconsistent error handling for GSS encryption in PQconnectPoll()

commit   : 4493256c5c0b0dace8cec76d5c3962f50ea28144    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 13 Mar 2023 16:36:28 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 13 Mar 2023 16:36:28 +0900    

Click here for diff

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

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

Mark unsafe_tests module as not runnable with installcheck

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

Click here for diff

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

M src/test/modules/unsafe_tests/Makefile
M src/test/modules/unsafe_tests/README

amcheck: Fix FullTransactionIdFromXidAndCtx() for xids before epoch 0

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

Click here for diff

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

M contrib/amcheck/verify_heapam.c
M src/bin/pg_amcheck/t/004_verify_heapam.pl

amcheck: Fix ordering bug in update_cached_xid_range()

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

Click here for diff

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

M contrib/amcheck/verify_heapam.c

Fix misbehavior in contrib/pg_trgm with an unsatisfiable regex.

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

Click here for diff

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

M contrib/pg_trgm/expected/pg_word_trgm.out
M contrib/pg_trgm/sql/pg_word_trgm.sql
M contrib/pg_trgm/trgm_regexp.c

Ensure COPY TO on an RLS-enabled table copies no more than it should.

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

Click here for diff

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

M src/backend/commands/copy.c
M src/backend/commands/copyto.c
M src/test/regress/expected/rowsecurity.out
M src/test/regress/sql/rowsecurity.sql

Fix race in SERIALIZABLE READ ONLY.

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

Click here for diff

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

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

Fix corruption due to vacuum_defer_cleanup_age underflowing 64bit xids

commit   : 391f08fd68047881345a69e5a7fff173d8f9c897    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Tue, 7 Mar 2023 21:36:48 -0800    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Tue, 7 Mar 2023 21:36:48 -0800    

Click here for diff

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

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

Fix more bugs caused by adding columns to the end of a view.

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

Click here for diff

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

M src/backend/parser/parse_relation.c
M src/backend/rewrite/rewriteHandler.c
M src/test/regress/expected/alter_table.out
M src/test/regress/sql/alter_table.sql

doc: Update pg_size_pretty documentation about petabytes support

commit   : ae4860183213518c2578d0fabb365ac3a8214f45    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 7 Mar 2023 19:30:14 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 7 Mar 2023 19:30:14 +0100    

Click here for diff

Missing documentation update for ca2e4472ba.  
  
Discussion: https://www.postgresql.org/message-id/CAApHDvrCwMgSD_93LZr4CLMas8Hc61fXAQ-Cd4%3D%2ByoRfHnYbJA%40mail.gmail.com  

M doc/src/sgml/func.sgml

Fix some more cases of missed GENERATED-column updates.

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

Click here for diff

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

M src/backend/executor/execUtils.c
M src/backend/executor/nodeModifyTable.c
M src/test/isolation/expected/eval-plan-qual.out
M src/test/isolation/specs/eval-plan-qual.spec
M src/test/regress/expected/generated.out
M src/test/regress/sql/generated.sql

In basebackup.c, perform end-of-file test after checksum validation.

commit   : 349803b18fee2476c7c9c84039d04c900ce8d499    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Thu, 2 Feb 2023 12:04:16 -0500    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Thu, 2 Feb 2023 12:04:16 -0500    

Click here for diff

We read blocks of data from files that we're backing up in chunks,  
some multiple of BLCKSZ for each read. If checksum verification fails,  
we then try rereading just the one block for which validation failed.  
If that block happened to be the first block of the chunk, and if  
the file was concurrently truncated to remove that block, then we'd  
reach a call to bbsink_archive_contents() with a buffer length of 0.  
That causes an assertion failure.  
  
As far as I can see, there are no particularly bad consequences if  
this happens in a non-assert build, and it's pretty unlikely to happen  
in the first place because it requires a series of somewhat unlikely  
things to happen in very quick succession. However, assertion failures  
are bad, so rearrange the code to avoid that possibility.  
  
Patch by me, reviewed by Michael Paquier.  
  
Discussion: http://postgr.es/m/CA+TgmoZ_fFAoU6mrHt9QBs+dcYhN6yXenGTTMRebZNhtwPwHyg@mail.gmail.com  

M src/backend/backup/basebackup.c

Fix assert failures in parallel SERIALIZABLE READ ONLY.

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

Click here for diff

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

M src/backend/storage/lmgr/predicate.c
M src/test/isolation/expected/serializable-parallel-2.out
A src/test/isolation/expected/serializable-parallel-3.out
M src/test/isolation/isolation_schedule
M src/test/isolation/specs/serializable-parallel-2.spec
A src/test/isolation/specs/serializable-parallel-3.spec

Avoid failure when altering state of partitioned foreign-key triggers.

commit   : f61e60102f08305f3cb9e55a7958b8036a02fe39    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 4 Mar 2023 13:32:35 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 4 Mar 2023 13:32:35 -0500    

Click here for diff

Beginning in v15, if you apply ALTER TABLE ENABLE/DISABLE TRIGGER to  
a partitioned table, it also affects the partitions' cloned versions  
of the affected trigger(s).  The initial implementation of this  
located the clones by name, but that fails on foreign-key triggers  
which have names incorporating their own OIDs.  We can fix that, and  
also make the behavior more bulletproof in the face of user-initiated  
trigger renames, by identifying the cloned triggers by tgparentid.  
  
Following the lead of earlier commits in this area, I took care not  
to break ABI in the v15 branch, even though I rather doubt there  
are any external callers of EnableDisableTrigger.  
  
While here, update the documentation, which was not touched when  
the semantics were changed.  
  
Per bug #17817 from Alan Hodgson.  Back-patch to v15; older versions  
do not have this behavior.  
  
Discussion: https://postgr.es/m/17817-31dfb7c2100d9f3d@postgresql.org  

M doc/src/sgml/ref/alter_table.sgml
M src/backend/commands/tablecmds.c
M src/backend/commands/trigger.c
M src/include/commands/trigger.h
M src/test/regress/expected/triggers.out
M src/test/regress/sql/triggers.sql

pageinspect: Fix crash with gist_page_items()

commit   : 9d41ecfcd9a7cb4ec6b20add4a55603ebba03f0d    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 2 Mar 2023 14:03:08 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 2 Mar 2023 14:03:08 +0900    

Click here for diff

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

M contrib/pageinspect/expected/brin.out
M contrib/pageinspect/expected/gist.out
M contrib/pageinspect/gistfuncs.c
M contrib/pageinspect/sql/brin.sql
M contrib/pageinspect/sql/gist.sql

Avoid fetching one past the end of translate()'s "to" parameter.

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

Click here for diff

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

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

doc: Fix description of pg_get_wal_stats_till_end_of_wal() in pg_walinspect

commit   : b5784e6a5ecd81468462a91486266adc87d03110    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 1 Mar 2023 08:38:55 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 1 Mar 2023 08:38:55 +0900    

Click here for diff

end_lsn was mentioned as an input parameter, but that should not be the  
case.  Error introduced in 58597ed.  
  
Author: Nathan Bossart  
Discussion: https://postgr.es/m/20230228195740.GA1397484@nathanxps13  
Backpatch-through: 15  

M doc/src/sgml/pgwalinspect.sgml

Drop test view when done with it.

commit   : b15db7f6905acb0c40e651bef54d86ffe4b30d39    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 27 Feb 2023 20:27:48 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 27 Feb 2023 20:27:48 -0500    

Click here for diff

The view just added by commit 53fe7e6cb decompiles differently  
in v15 than HEAD (presumably as a consequence of 47bb9db75).  
That causes failures in cross-version upgrade testing.  
  
We could teach AdjustUpgrade.pm to compensate for that, but it  
seems less painful to just drop the view after we're done with it.  
  
Per buildfarm.  

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

Harden postgres_fdw tests against unexpected cache flushes.

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

Click here for diff

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

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

Don't force SQL_ASCII/no-locale for installcheck in vcregress.pl

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

Click here for diff

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

M src/tools/msvc/vcregress.pl

Doc: Miscellaneous doc updates for MERGE.

commit   : a6864751cd11ae99c16da48d603fafa55ce8e57e    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Sun, 26 Feb 2023 09:04:04 +0000    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Sun, 26 Feb 2023 09:04:04 +0000    

Click here for diff

Update a few places in the documentation that should mention MERGE  
among the list of applicable commands. In a couple of places, a  
slightly more detailed description of what happens for MERGE seems  
appropriate.  
  
Reviewed by Alvaro Herrera.  
  
Discussion: http://postgr.es/m/CAEZATCWqHLcxab89ATMQZNGFG_mxDPM%2BjzkSbXKD3JYPfRGvtw%40mail.gmail.com  

M doc/src/sgml/arch-dev.sgml
M doc/src/sgml/ddl.sgml
M doc/src/sgml/high-availability.sgml
M doc/src/sgml/perform.sgml
M doc/src/sgml/plpgsql.sgml
M doc/src/sgml/protocol.sgml
M doc/src/sgml/queries.sgml
M doc/src/sgml/ref/create_publication.sgml
M doc/src/sgml/ref/explain.sgml
M doc/src/sgml/ref/prepare.sgml
M doc/src/sgml/ref/set_transaction.sgml
M doc/src/sgml/xfunc.sgml

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

Click here for diff

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

M src/backend/executor/execExpr.c
M src/backend/executor/nodeSubplan.c
M src/include/nodes/primnodes.h
M src/test/regress/expected/inherit.out
M src/test/regress/sql/inherit.sql

Fix mishandling of OLD/NEW references in subqueries in rule actions.

commit   : 8e5b4e0013a8a24644243cdb9516ac52287a81c8    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Sat, 25 Feb 2023 14:43:57 +0000    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Sat, 25 Feb 2023 14:43:57 +0000    

Click here for diff

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

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

Don't repeatedly register cache callbacks in pgoutput plugin.

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

Click here for diff

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

M src/backend/replication/pgoutput/pgoutput.c

Fix multi-row DEFAULT handling for INSERT ... SELECT rules.

commit   : 940b5474365fa87ef4aad7abeee070e8e49cc9d5    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Thu, 23 Feb 2023 10:54:51 +0000    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Thu, 23 Feb 2023 10:54:51 +0000    

Click here for diff

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

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

Fix snapshot handling in logicalmsg_decode

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

Click here for diff

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

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

Add missing support for the latest SPI status codes.

commit   : 576b25bfd0e9a1d5bbc54931e888135bc6da8a2f    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Wed, 22 Feb 2023 13:24:51 +0000    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Wed, 22 Feb 2023 13:24:51 +0000    

Click here for diff

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

M doc/src/sgml/spi.sgml
M src/backend/executor/spi.c
M src/pl/tcl/pltcl.c

Fix Assert failure for MERGE into a partitioned table with RLS.

commit   : d8c3b65db58db0a074dc9f7e27846e22e9dc579f    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Wed, 22 Feb 2023 10:54:57 +0000    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Wed, 22 Feb 2023 10:54:57 +0000    

Click here for diff

In ExecInitPartitionInfo(), the Assert when building the WITH CHECK  
OPTION list for the new partition assumed that the command would be an  
INSERT or UPDATE, but it can also be a MERGE. This can be triggered by  
a MERGE into a partitioned table with RLS checks to enforce.  
  
Fix, and back-patch to v15, where MERGE was introduced.  
  
Discussion: https://postgr.es/m/CAEZATCWWFtQmW67F3XTyMU5Am10Oxa_b8oe0x%2BNu5Mo%2BCdRErg%40mail.gmail.com  

M src/backend/executor/execPartition.c
M src/test/regress/expected/merge.out
M src/test/regress/sql/merge.sql

Fix MERGE command tag for cross-partition updates.

commit   : 018af1cc1c8075346e6a5fe3bb77b7e31399be70    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Wed, 22 Feb 2023 09:41:28 +0000    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Wed, 22 Feb 2023 09:41:28 +0000    

Click here for diff

This ensures that the row count in the command tag for a MERGE is  
correctly computed. Previously, if MERGE updated a partitioned table,  
the row count would be incorrect if any row was moved to a different  
partition, since such updates were counted twice.  
  
Back-patch to v15, where MERGE was introduced.  
  
Discussion: https://postgr.es/m/CAEZATCWRMG7XX2QEsVL1LswmNo2d_YG8tKTLkpD3=Lp644S7rg@mail.gmail.com  

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

Fix corruption of templates after CREATE DATABASE .. STRATEGY WAL_LOG

commit   : fa5dd460c1805a00a6fcc909b7e1f826663bcce3    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 22 Feb 2023 10:14:56 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 22 Feb 2023 10:14:56 +0900    

Click here for diff

WAL_LOG does a scan of the template's pg_class to determine the set of  
relations that need to be copied from a template database to the new  
one.  However, as coded in 9c08aea, this copy strategy would load the  
pages of pg_class without considering it as a permanent relation,  
causing the loaded pages to never be flushed when they should.  Any  
modification of the template's pg_class, mostly through DDLs, would then  
be missed, causing corruptions.  
  
STRATEGY = WAL_LOG is the default over FILE_COPY since it has been  
introduced, so any changes done to pg_class on a database template would  
be gone.  Updates of database templates should be a rare thing, so the  
impact of this bug should be hopefully limited.  The pre-14 default  
strategy FILE_COPY is safe, and can be used as a workaround.  
  
Ryo Matsumura has found and analyzed the issue, and Nathan has written a  
test able to reproduce the failure (with few tweaks from me).  
  
Backpatch down to 15, where STRATEGY = WAL_LOG has been introduced.  
  
Author: Nathan Bossart, Ryo Matsumura  
Reviewed-by: Dilip Kumar, Michael Paquier  
Discussion: https://postgr.es/m/TYCPR01MB6868677E499C9AD5123084B5E8A39@TYCPR01MB6868.jpnprd01.prod.outlook.com  
Backpatch-through: 15  

M src/backend/commands/dbcommands.c
A src/test/recovery/t/034_create_database.pl

Fix erroneous Valgrind markings in AllocSetRealloc.

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

Click here for diff

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

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

Fix handling of escape sequences in postgres_fdw.application_name

commit   : 5bace41abc317ae8ecf3397e9e92f3b0e5444c69    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 21 Feb 2023 20:02:09 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 21 Feb 2023 20:02:09 +0900    

Click here for diff

postgres_fdw.application_name relies on MyProcPort to define the data  
that should be added to escape sequences %u (user name) or %d (database  
name).  However this code could be run in processes that lack a  
MyProcPort, like an autovacuum process, causing crashes.  
  
The code generating the application name is made more flexible with this  
commit, so as it now generates no data for %u and %d if MyProcPort is  
missing, and a simple "unknown" if MyProcPort exists, but the expected  
fields are not set.  
  
Reported-by: Alexander Lakhin  
Author: Kyotaro Horiguchi, Michael Paquier  
Reviewed-by: Hayato Kuroda, Masahiko Sawada  
Discussion: https://postgr.es/m/17789-8b31c5a4672b74d9@postgresql.org  
Backpatch-through: 15  

M contrib/postgres_fdw/option.c

pgbench: Prepare commands in pipelines in advance

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

Click here for diff

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

M src/bin/pgbench/pgbench.c
M src/bin/pgbench/t/001_pgbench_with_server.pl

Fix parsing of ISO-8601 interval fields with exponential notation.

commit   : ded5ede2779fec65ed0a4022296efa71e9c64aac    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 20 Feb 2023 16:55:59 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 20 Feb 2023 16:55:59 -0500    

Click here for diff

Historically we've accepted interval input like 'P.1e10D'.  This  
is probably an accident of having used strtod() to do the parsing,  
rather than something anyone intended, but it's been that way for  
a long time.  Commit e39f99046 broke this by trying to parse the  
integer and fractional parts separately, without accounting for  
the possibility of an exponent.  In principle that coding allowed  
for precise conversions of field values wider than 15 decimal  
digits, but that does not seem like a goal worth sweating bullets  
for.  So, rather than trying to manage an exponent on top of the  
existing complexity, let's just revert to the previous coding that  
used strtod() by itself.  We can still improve on the old code to  
the extent of allowing the value to range up to 1.0e15 rather than  
only INT_MAX.  (Allowing more than that risks creating problems  
due to precision loss: the converted fractional part might have  
absolute value more than 1.  Perhaps that could be dealt with in  
some way, but it really does not seem worth additional effort.)  
  
Per bug #17795 from Alexander Lakhin.  Back-patch to v15 where  
the faulty code came in.  
  
Discussion: https://postgr.es/m/17795-748d6db3ed95d313@postgresql.org  

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

Prevent join removal from removing the query's result relation.

commit   : e6d8639cf25ccfffe12695768a4f7a60130c426f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 20 Feb 2023 15:18:22 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 20 Feb 2023 15:18:22 -0500    

Click here for diff

This was not something that required consideration before MERGE  
was invented; but MERGE builds a join tree that left-joins to the  
result relation, meaning that remove_useless_joins will consider  
removing it.  That should generally be stopped by the query's use  
of output variables from the result relation.  However, if the  
result relation is inherited (e.g. a partitioned table) then  
we don't add any row identity variables to the query until  
expand_inherited_rtentry, which happens after join removal.  
  
This was exposed as of commit 3c569049b, which made it possible  
to deduce that a partitioned table could contain at most one row  
matching a join key, enabling removal of the not-yet-expanded  
result relation.  Ooops.  
  
To fix, let's just teach join_is_removable that the query result  
rel is never removable.  It's a cheap enough test in any case,  
and it'll save some cycles that we'd otherwise expend in proving  
that it's not removable, even in the cases we got right.  
  
Back-patch to v15 where MERGE was added.  Although I think the  
case cannot be reached in v15, this seems like cheap insurance.  
  
Per investigation of a report from Alexander Lakhin.  
  
Discussion: https://postgr.es/m/36bee393-b351-16ac-93b2-d46d83637e45@gmail.com  

M src/backend/optimizer/plan/analyzejoins.c
M src/test/regress/expected/merge.out
M src/test/regress/sql/merge.sql

Limit memory usage of pg_walinspect functions.

commit   : da32a99df1f519622eee0d5c3ea61226468272a7    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Mon, 20 Feb 2023 11:29:31 -0800    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Mon, 20 Feb 2023 11:29:31 -0800    

Click here for diff

GetWALRecordsInfo() and pg_get_wal_fpi_info() can leak memory across  
WAL record iterations. Fix this by using a temporary memory context  
that's reset for each WAL record iteraion.  
  
Also use a temporary context for loops in GetXLogSummaryStats(). The  
number of iterations is a small constant, so the previous behavior was  
not a leak, but fix for clarity (but no need to backport).  
  
Backport GetWALRecordsInfo() change to version  
15. pg_get_wal_fpi_info() didn't exist in version 15.  
  
Reported-by: Peter Geoghegan  
Author: Bharath Rupireddy  
Discussion: https://www.postgresql.org/message-id/CAH2-WznLEJjn7ghmKOABOEZYuJvkTk%3DGKU3m0%2B-XBAH%2BerPiJQ%40mail.gmail.com  
Backpatch-through: 15  

M contrib/pg_walinspect/pg_walinspect.c

Fix handling of multi-column BRIN indexes

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

Click here for diff

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

M src/backend/access/brin/brin.c

Print the correct aliases for DML target tables in ruleutils.

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

Click here for diff

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

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

Don't rely on uninitialized value in MERGE / DELETE

commit   : 5d8ec1b9f625be800c8db93408e7c0553356fcd3    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 15 Feb 2023 20:37:44 +0100    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 15 Feb 2023 20:37:44 +0100    

Click here for diff

On MERGE / WHEN MATCHED DELETE it's not possible to get cross-partition  
updates, so we don't initialize cpUpdateRetrySlot; however, the code was  
not careful to ignore the value in that case.  Make it do so.  
  
Backpatch to 15.  
  
Reported-by: Alexander Lakhin <exclusion@gmail.com>  
Reviewed-by: Dean Rasheed <dean.a.rasheed@gmail.com>  
Discussion: https://postgr.es/m/17792-0f89452029662c36@postgresql.org  

M src/backend/executor/nodeModifyTable.c

Fix handling of SCRAM-SHA-256's channel binding with RSA-PSS certificates

commit   : 5fd61055eacf3d0c45be20b90402a87c9848db43    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 15 Feb 2023 10:12:31 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 15 Feb 2023 10:12:31 +0900    

Click here for diff

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

M configure
M configure.ac
M src/backend/libpq/be-secure-openssl.c
M src/include/libpq/libpq-be.h
M src/include/pg_config.h.in
M src/interfaces/libpq/fe-secure-openssl.c
M src/interfaces/libpq/libpq-int.h
M src/test/ssl/README
A src/test/ssl/conf/server-rsapss.config
A src/test/ssl/ssl/server-rsapss.crt
A src/test/ssl/ssl/server-rsapss.key
M src/test/ssl/sslfiles.mk
M src/test/ssl/t/002_scram.pl
M src/tools/msvc/Solution.pm

Disable WindowAgg inverse transitions when subplans are present

commit   : a9fa6d79aded60564737c502115d531499deacf4    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Mon, 13 Feb 2023 17:10:31 +1300    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Mon, 13 Feb 2023 17:10:31 +1300    

Click here for diff

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

M src/backend/executor/nodeWindowAgg.c

Avoid dereferencing an undefined pointer in DecodeInterval().

commit   : 0ef65d0f55e5cec81fe98aba7c907dfc1b93923f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 12 Feb 2023 12:50:55 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 12 Feb 2023 12:50:55 -0500    

Click here for diff

Commit e39f99046 moved some code up closer to the start of  
DecodeInterval(), without noticing that it had been implicitly  
relying on previous checks to reject the case of empty input.  
Given empty input, we'd now dereference a pointer that hadn't been  
set, possibly leading to a core dump.  (But if we fail to provoke  
a SIGSEGV, nothing bad happens, and the expected syntax error is  
thrown a bit later.)  
  
Per bug #17788 from Alexander Lakhin.  Back-patch to v15 where  
the fault was introduced.  
  
Discussion: https://postgr.es/m/17788-dabac9f98f7eafd5@postgresql.org  

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

Un-revert "Disable STARTUP_PROGRESS_TIMEOUT in standby mode."

commit   : ecb01e6ebb5a67f3fc00840695682a8b1ba40461    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 10 Feb 2023 16:27:05 -0500    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 10 Feb 2023 16:27:05 -0500    

Click here for diff

This reverts commit 1eadfbdd7eb0679ba8d45787aa8b2f06e76de20a  
and thus reinstates commit 98e7234242a652497c99d4d0d6f2bf9a75d4e921.  
  
It's a better time to commit this now that the release is over.  
  
Discussion: http://postgr.es/m/3509384.1675878203@sss.pgh.pa.us  

M src/backend/access/transam/xlogrecovery.c
M src/backend/postmaster/startup.c
M src/include/postmaster/startup.h

Stop recommending auto-download of DTD files, and indeed disable it.

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

Click here for diff

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

M doc/src/sgml/Makefile
M doc/src/sgml/docguide.sgml
M doc/src/sgml/images/Makefile

commit   : dbe8a1726cfd5a09cf1ef99e76f5f89e2efada71    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 8 Feb 2023 16:56:50 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 8 Feb 2023 16:56:50 +0900    

Click here for diff

No GUCs that use NO_SHOW_ALL are reported in pg_show_all_settings(),  
hence trying to check combinations of flags related to it is pointless.  
  
These queries have been introduced by d10e41d, so backpatch down to 15  
to keep all the branches consistent.  Equivalent checks based on  
NO_SHOW_ALL could be added in check_GUC_init() when a GUC is initially  
loaded, but this can be done only on HEAD.  
  
Author: Nitin Jadhav  
Discussion: https://postgr.es/m/CAMm1aWaYe0muu3ABo7iSAgK+OWDS9yNe8GGRYnCyeEpScYKa+g@mail.gmail.com  
Backpatch-through: 15  

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

Stamp 15.2.

commit   : 78ec02d612a9b69039ec2610740f738968fe144d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 6 Feb 2023 16:39:04 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 6 Feb 2023 16:39:04 -0500    

Click here for diff

M configure
M configure.ac

Last-minute updates for release notes.

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

Click here for diff

Security: CVE-2022-41862  

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

Revert "Disable STARTUP_PROGRESS_TIMEOUT in standby mode."

commit   : 1eadfbdd7eb0679ba8d45787aa8b2f06e76de20a    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Mon, 6 Feb 2023 11:16:03 -0500    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Mon, 6 Feb 2023 11:16:03 -0500    

Click here for diff

This reverts commit 98e7234242a652497c99d4d0d6f2bf9a75d4e921. I  
forgot that we're about to wrap a release, and this fix isn't  
critical enough to justify committing it right before we wrap  
a release.  
  
Discussion: http://postgr.es/m/2676424.1675700113@sss.pgh.pa.us  

M src/backend/access/transam/xlogrecovery.c
M src/backend/postmaster/startup.c
M src/include/postmaster/startup.h

Disable STARTUP_PROGRESS_TIMEOUT in standby mode.

commit   : 98e7234242a652497c99d4d0d6f2bf9a75d4e921    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Mon, 6 Feb 2023 10:51:08 -0500    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Mon, 6 Feb 2023 10:51:08 -0500    

Click here for diff

In standby mode, we don't actually report progress of recovery,  
but up until now, startup_progress_timeout_handler() nevertheless  
got called every log_startup_progress_interval seconds. That's  
an unnecessary expense, so avoid it.  
  
Report by Thomas Munro. Patch by Bharath Rupireddy, reviewed by  
Simon Riggs, Thomas Munro, and me. Back-patch to v15, where  
the problem was introduced.  
  
Discussion: https://www.postgresql.org/message-id/CA%2BhUKGKCHSffAj8zZJKJvNX7ygnQFxVD6wm1d-2j3fVw%2BMafPQ%40mail.gmail.com  

M src/backend/access/transam/xlogrecovery.c
M src/backend/postmaster/startup.c
M src/include/postmaster/startup.h

Translation updates

commit   : ec16eac8dabcd80559dcc6aeec48c0b57fb8b2bd    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 6 Feb 2023 12:15:49 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 6 Feb 2023 12:15:49 +0100    

Click here for diff

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

M src/backend/po/de.po
M src/backend/po/fr.po
M src/backend/po/ja.po
M src/backend/po/ru.po
M src/backend/po/sv.po
M src/bin/pg_dump/po/ru.po
M src/bin/pg_upgrade/po/ru.po
M src/bin/psql/po/de.po
M src/bin/psql/po/fr.po
M src/bin/psql/po/ja.po
M src/bin/psql/po/ru.po
M src/bin/psql/po/sv.po
M src/interfaces/libpq/po/ja.po
M src/interfaces/libpq/po/ru.po

Properly NULL-terminate GSS receive buffer on error packet reception

commit   : 715c345dd9a5594758be9a7aa41e898ead96e2a6    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 6 Feb 2023 11:20:20 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 6 Feb 2023 11:20:20 +0900    

Click here for diff

pqsecure_open_gss() includes a code path handling error messages with  
v2-style protocol messages coming from the server.  The client-side  
buffer holding the error message does not force a NULL-termination, with  
the data of the server getting copied to the errorMessage of the  
connection.  Hence, it would be possible for a server to send an  
unterminated string and copy arbitrary bytes in the buffer receiving the  
error message in the client, opening the door to a crash or even data  
exposure.  
  
As at this stage of the authentication process the exchange has not been  
completed yet, this could be abused by an attacker without Kerberos  
credentials.  Clients that have a valid kerberos cache are vulnerable as  
libpq opportunistically requests for it except if gssencmode is  
disabled.  
  
Author: Jacob Champion  
Backpatch-through: 12  
Security: CVE-2022-41862  

M src/interfaces/libpq/fe-secure-gssapi.c

Release notes for 15.2, 14.7, 13.10, 12.14, 11.19.

commit   : 80d43843e70aaa168d17f9a0c2ecc8c88a46b430    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 5 Feb 2023 16:22:32 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 5 Feb 2023 16:22:32 -0500    

Click here for diff

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

First-draft release notes for 15.2.

commit   : f282b026787da69d88a35404cf62f1cc21cfbb7c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 3 Feb 2023 14:30:49 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 3 Feb 2023 14:30:49 -0500    

Click here for diff

As usual, the release notes for other branches will be made by cutting  
these down, but put them up for community review first.  

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

Make int64_div_fast_to_numeric() more robust.

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

Click here for diff

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

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

doc: Fix XML formatting that psql cannot handle

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

Click here for diff

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

M doc/src/sgml/ref/fetch.sgml
M doc/src/sgml/ref/move.sgml

ci: Use windows VMs instead of windows containers

commit   : 8488babc7f497949f89f77c1b18e41e0962e5398    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Thu, 2 Feb 2023 21:31:48 -0800    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Thu, 2 Feb 2023 21:31:48 -0800    

Click here for diff

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

M .cirrus.yml

ci: Upgrade macOS version from 12 to 13.

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

Click here for diff

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

M .cirrus.yml

Doc: Abstract AF_UNIX sockets don't work on Windows.

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

Click here for diff

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

M doc/src/sgml/config.sgml

Update time zone data files to tzdata release 2022g.

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

Click here for diff

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

M src/timezone/data/tzdata.zi

Doc: clarify use of NULL to drop comments and security labels.

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

Click here for diff

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

M doc/src/sgml/ref/comment.sgml
M doc/src/sgml/ref/security_label.sgml

Remove recovery test 011_crash_recovery.pl

commit   : c5b2975ec183e8776f82bad33ec957ce58ec709a    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 31 Jan 2023 12:47:08 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 31 Jan 2023 12:47:08 +0900    

Click here for diff

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

D src/test/recovery/t/011_crash_recovery.pl

Ensure that MERGE recomputes GENERATED expressions properly.

commit   : 4785af9e6318856d45e51fbc328d52f6c5340e13    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Mon, 30 Jan 2023 10:07:32 +0000    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Mon, 30 Jan 2023 10:07:32 +0000    

Click here for diff

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

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

Fix rare sharedtuplestore.c corruption.

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

Click here for diff

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

M src/backend/utils/sort/sharedtuplestore.c

doc: Fix network_ops -> inet_ops in SpGiST operator class list

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

Click here for diff

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

M doc/src/sgml/spgist.sgml

Fix the Drop Database hang.

commit   : 267135d01d79c63dfba7fe69dd3b40c125c49a6f    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Tue, 24 Jan 2023 09:12:04 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Tue, 24 Jan 2023 09:12:04 +0530    

Click here for diff

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

M src/backend/replication/logical/tablesync.c
M src/test/subscription/t/004_sync.pl

Fix error handling in libpqrcv_connect()

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

Click here for diff

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

M src/backend/replication/libpqwalreceiver/libpqwalreceiver.c
M src/test/regress/expected/subscription.out
M src/test/regress/sql/subscription.sql

Use OFFSET 0 instead of ORDER BY to stop subquery pullup

commit   : 5dc582da6b9a281321e687ae2b52f96b929d8d0e    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Tue, 24 Jan 2023 13:49:39 +1300    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Tue, 24 Jan 2023 13:49:39 +1300    

Click here for diff

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

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

Fix LATERAL join test in test memoize.sql

commit   : 73f77ab508d1514ca604c47b6f56c5dee4dd9025    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Tue, 24 Jan 2023 12:29:57 +1300    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Tue, 24 Jan 2023 12:29:57 +1300    

Click here for diff

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

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

Fix and clarify function comment on LogicalTapeSetCreate.

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

Click here for diff

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

M src/backend/utils/sort/logtape.c

Allow REPLICA IDENTITY to be set on an index that's not (yet) valid.

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

Click here for diff

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

M src/backend/catalog/index.c
M src/backend/commands/tablecmds.c
M src/test/regress/expected/replica_identity.out
M src/test/regress/sql/replica_identity.sql

Reject CancelRequestPacket having unexpected length.

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

Click here for diff

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

M src/backend/postmaster/postmaster.c

Make our back branches build under -fkeep-inline-functions.

commit   : 9a40a031197a302a638d6464c9db081b7839175f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 20 Jan 2023 11:58:12 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 20 Jan 2023 11:58:12 -0500    

Click here for diff

Add "#ifndef FRONTEND" where necessary to make pg_waldump build  
on compilers that don't elide unused static-inline functions.  
  
This back-patches relevant parts of commit 3e9ca5260, fixing build  
breakage from dc7420c2c and back-patching of f10f0ae42.  
  
Per recently-resurrected buildfarm member castoroides.  We aren't  
expecting castoroides to build anything newer than v11, but we  
might as well clean up the intermediate branches while at it.  

M src/include/utils/rel.h
M src/include/utils/snapmgr.h

Avoid harmless warning from pg_dump --if-exists mode.

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

Click here for diff

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

M src/bin/pg_dump/pg_backup_archiver.c

Log the correct ending timestamp in recovery_target_xid mode.

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

Click here for diff

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

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

Add missing assign hook for GUC checkpoint_completion_target

commit   : 49e3a5e7149d3f676318f2222aaab30613f8dc59    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 19 Jan 2023 13:13:27 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 19 Jan 2023 13:13:27 +0900    

Click here for diff

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

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

Fix failure with perlcritic in psql's create_help.pl

commit   : 1391916736cf218c7f234471ef3c98f740ed2a5e    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 19 Jan 2023 10:02:07 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 19 Jan 2023 10:02:07 +0900    

Click here for diff

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

M src/bin/psql/create_help.pl

AdjustUpgrade.pm should zap test_ext_cine, too.

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

Click here for diff

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

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

Create common infrastructure for cross-version upgrade testing.

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

Click here for diff

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

M src/bin/pg_upgrade/TESTING
M src/bin/pg_upgrade/t/002_pg_upgrade.pl
D src/bin/pg_upgrade/upgrade_adapt.sql
A src/test/perl/PostgreSQL/Test/AdjustUpgrade.pm

Fix some BufFileRead() error reporting

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

Click here for diff

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

M src/backend/backup/backup_manifest.c
M src/backend/replication/logical/worker.c

Remove arbitrary FUNC_MAX_ARGS limit in int2vectorin and oidvectorin.

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

Click here for diff

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

M src/backend/utils/adt/int.c
M src/backend/utils/adt/oid.c

Make new GENERATED-expressions code more bulletproof.

commit   : a8f7687a0b8645697b48cc40fd1a73d455d0c1fc    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 15 Jan 2023 14:06:46 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 15 Jan 2023 14:06:46 -0500    

Click here for diff

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

M src/backend/executor/execUtils.c
M src/backend/executor/nodeModifyTable.c
M src/include/executor/nodeModifyTable.h
M src/test/subscription/t/011_generated.pl

Doc: fix typo in backup.sgml.

commit   : 40015cf8ec7a0384a0320c11a31fdeebba4b8e15    
  
author   : Tatsuo Ishii <ishii@postgresql.org>    
date     : Sat, 14 Jan 2023 18:12:19 +0900    
  
committer: Tatsuo Ishii <ishii@postgresql.org>    
date     : Sat, 14 Jan 2023 18:12:19 +0900    

Click here for diff

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

M doc/src/sgml/backup.sgml

doc: Simplify description of functions for pg_walinspect

commit   : 93595ffd5964247198699339fd8af19c1e4b6a33    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 13 Jan 2023 09:30:12 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 13 Jan 2023 09:30:12 +0900    

Click here for diff

As introduced in 2258e76, the docs were hard to parse:  
- The examples used listed a lot of long records, bloating the output.  
These are switched to show less records with the expanded format,  
similarly to pageinspect.  
- The function descriptions listed all the OUT parameters, producing  
long lines.  This is updated so as only the input parameters are  
documented, clarifying the whole.  
- Remove one example on pg_get_wal_stats() when per_record is set to  
true, which is not really necessary once we know the output produced,  
and the behavior of the parameter is documented.  
  
While on it, fix a few grammar mistakes and simplify a couple of  
sentences.  
  
Author: Bharath Rupireddy  
Discussion: https://postgr.es/m/CALj2ACVGcUpziGgQrcT-1G3dHWQQfWjYBu1YQ2ypv9y86dgogg@mail.gmail.com  
Backpatch-through: 15  

M doc/src/sgml/pgwalinspect.sgml

Fix WaitEventSetWait() buffer overrun.

commit   : 8a98523a542f0fb6fa19c071922776dac7d45d36    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Fri, 13 Jan 2023 10:40:52 +1300    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Fri, 13 Jan 2023 10:40:52 +1300    

Click here for diff

The WAIT_USE_EPOLL and WAIT_USE_KQUEUE implementations of  
WaitEventSetWaitBlock() confused the size of their internal buffer with  
the size of the caller's output buffer, and could ask the kernel for too  
many events.  In fact the set of events retrieved from the kernel needs  
to be able to fit in both buffers, so take the smaller of the two.  
  
The WAIT_USE_POLL and WAIT_USE WIN32 implementations didn't have this  
confusion.  
  
This probably didn't come up before because we always used the same  
number in both places, but commit 7389aad6 calculates a dynamic size at  
construction time, while using MAXLISTEN for its output event buffer on  
the stack.  That seems like a reasonable thing to want to do, so  
consider this to be a pre-existing bug worth fixing.  
  
As discovered by valgrind on skink.  
  
Back-patch to all supported releases for epoll, and to release 13 for  
the kqueue part, which copied the incorrect epoll code.  
  
Reviewed-by: Andres Freund <andres@anarazel.de>  
Discussion: https://postgr.es/m/901504.1673504836%40sss.pgh.pa.us  

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

Fix jsonpath existense checking of missing variables

commit   : 4dc3f94fae3de3f19b5c7dd507beac0216b0cde9    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Thu, 12 Jan 2023 18:16:34 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Thu, 12 Jan 2023 18:16:34 +0300    

Click here for diff

The current jsonpath code assumes that the referenced variable always exists.  
It could only throw an error at the value valuation time.  At the same time  
existence checking assumes variable is present without valuation, and error  
suppression doesn't work for missing variables.  
  
This commit makes existense checking trigger an error for missing variables.  
This makes the overall behavior consistent.  
  
Backpatch to 12 where jsonpath was introduced.  
  
Reported-by: David G. Johnston  
Discussion: https://postgr.es/m/CAKFQuwbeytffJkVnEqDyLZ%3DrQsznoTh1OgDoOF3VmOMkxcTMjA%40mail.gmail.com  
Author: Alexander Korotkov, David G. Johnston  
Backpatch-through: 12  

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

Acquire spinlock when updating 2PC slot data during logical decoding creation

commit   : 6f25e48774fe9302ca08dae07420df95998d792a    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 12 Jan 2023 13:41:22 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 12 Jan 2023 13:41:22 +0900    

Click here for diff

The creation of a logical decoding context in CreateDecodingContext()  
updates some data of its slot for two-phase transactions if enabled by  
the caller, but the code forgot to acquire a spinlock when updating  
these fields like any other code paths.  This could lead to the read of  
inconsistent data.  
  
Oversight in a8fd13c.  
  
Author: Sawada Masahiko  
Discussion: https://postgr.es/m/CAD21AoAD8_fp47191LKuecjDd3DYhoQ4TaucFco1_TEr_jQ-Zw@mail.gmail.com  
Backpatch-through: 15  

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

Fix MERGE's test for unreachable WHEN clauses.

commit   : 38255f2d0059a101c3fb791d6523a9e66e55aa66    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Tue, 10 Jan 2023 14:16:27 +0000    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Tue, 10 Jan 2023 14:16:27 +0000    

Click here for diff

The former code would only detect an unreachable WHEN clause if it had  
an AND condition. Fix, so that unreachable unconditional WHEN clauses  
are also detected.  
  
Back-patch to v15, where MERGE was added.  
  
Discussion: https://postgr.es/m/CAEZATCVQ=7E2z4cSBB49jjeGGsB6WeoYQY32NDeSvcHiLUZ=ow@mail.gmail.com  

M src/backend/parser/parse_merge.c
M src/test/regress/expected/merge.out
M src/test/regress/sql/merge.sql

Remove the streaming files for incomplete xacts after restart.

commit   : 18b81258ab60cdd172329fe80dd2314d587bd551    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Sat, 7 Jan 2023 12:04:33 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Sat, 7 Jan 2023 12:04:33 +0530    

Click here for diff

After restart, we try to stream the changes for large transactions that  
were not sent before server crash and restart. However, we forget to send  
the abort message for such transactions. This leads to spurious streaming  
files on the subscriber which won't be cleaned till the apply worker or  
the subscriber server restarts.  
  
Reported-by: Dilip Kumar  
Author: Hou Zhijie  
Reviewed-by: Dilip Kumar and Amit Kapila  
Backpatch-through: 14  
Discussion: https://postgr.es/m/OS0PR01MB5716A773F46768A1B75BE24394FB9@OS0PR01MB5716.jpnprd01.prod.outlook.com  

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

Fix tab completion of ALTER FUNCTION/PROCEDURE/ROUTINE ... SET SCHEMA.

commit   : 2daf4664ce5402e4bd5bda24bf52716137336ad2    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Fri, 6 Jan 2023 11:16:53 +0000    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Fri, 6 Jan 2023 11:16:53 +0000    

Click here for diff

The ALTER DATABASE|FUNCTION|PROCEDURE|ROLE|ROUTINE|USER ... SET <name>  
case in psql tab completion failed to exclude <name> = "SCHEMA", which  
caused ALTER FUNCTION|PROCEDURE|ROUTINE ... SET SCHEMA to complete  
with "FROM CURRENT" and "TO", which won't work.  
  
Fix that, so that those cases now complete with the list of schemas,  
like other ALTER ... SET SCHEMA commands.  
  
Noticed while testing the recent patch to improve tab completion for  
ALTER FUNCTION/PROCEDURE/ROUTINE, but this is not directly related to  
that patch. Rather, this is a long-standing bug, so back-patch to all  
supported branches.  
  
Discussion: https://postgr.es/m/CALDaNm0s7GQmkLP_mx5Cvk=UzYMnjhPmXBxU8DsHEunFbC5sTg@mail.gmail.com  

M src/bin/psql/tab-complete.c

Fix pg_truncate() on Windows.

commit   : f60acde869985b35146c6f7f941dd571fc88b3c4    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Fri, 6 Jan 2023 16:38:46 +1300    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Fri, 6 Jan 2023 16:38:46 +1300    

Click here for diff

Commit 57faaf376 added pg_truncate(const char *path, off_t length), but  
"length" was ignored under WIN32 and the file was unconditionally  
truncated to 0.  
  
There was no live bug, since the only caller passes 0.  
  
Fix, and back-patch to 14 where the function arrived.  
  
Author: Justin Pryzby <pryzby@telsasoft.com>  
Discussion: https://postgr.es/m/20230106031652.GR3109%40telsasoft.com  

M src/backend/storage/file/fd.c

Fix calculation of which GENERATED columns need to be updated.

commit   : 3706cc97aa36bb65fd82dbfc79ca809033bcad1f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 5 Jan 2023 14:12:17 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 5 Jan 2023 14:12:17 -0500    

Click here for diff

We were identifying the updatable generated columns of inheritance  
children by transposing the calculation made for their parent.  
However, there's nothing that says a traditional-inheritance child  
can't have generated columns that aren't there in its parent, or that  
have different dependencies than are in the parent's expression.  
(At present it seems that we don't enforce that for partitioning  
either, which is likely wrong to some degree or other; but the case  
clearly needs to be handled with traditional inheritance.)  
  
Hence, drop the very-klugy-anyway "extraUpdatedCols" RTE field  
in favor of identifying which generated columns depend on updated  
columns during executor startup.  In HEAD we can remove  
extraUpdatedCols altogether; in back branches, it's still there but  
always empty.  Another difference between the HEAD and back-branch  
versions of this patch is that in HEAD we can add the new bitmap field  
to ResultRelInfo, but that would cause an ABI break in back branches.  
Like 4b3e37993, add a List field at the end of struct EState instead.  
  
Back-patch to v13.  The bogus calculation is also being made in v12,  
but it doesn't have the same visible effect because we don't use it  
to decide which generated columns to recalculate; as a consequence of  
which the patch doesn't apply easily.  I think that there might still  
be a demonstrable bug associated with trigger firing conditions, but  
that's such a weird corner-case usage that I'm content to leave it  
unfixed in v12.  
  
Amit Langote and Tom Lane  
  
Discussion: https://postgr.es/m/CA+HiwqFshLKNvQUd1DgwJ-7tsTp=dwv7KZqXC4j2wYBV1aCDUA@mail.gmail.com  
Discussion: https://postgr.es/m/2793383.1672944799@sss.pgh.pa.us  

M contrib/postgres_fdw/postgres_fdw.c
M src/backend/executor/execUtils.c
M src/backend/executor/nodeModifyTable.c
M src/backend/optimizer/util/inherit.c
M src/backend/optimizer/util/plancat.c
M src/backend/replication/logical/worker.c
M src/backend/rewrite/rewriteHandler.c
M src/include/nodes/execnodes.h
M src/include/nodes/parsenodes.h
M src/include/optimizer/inherit.h
M src/include/optimizer/plancat.h
M src/include/rewrite/rewriteHandler.h
M src/test/regress/expected/generated.out
M src/test/regress/sql/generated.sql

Improve documentation of the CREATEROLE attibute.

commit   : aa26980ca0813200c25b06e3ad0f54d449cce8b2    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Tue, 3 Jan 2023 14:50:40 -0500    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Tue, 3 Jan 2023 14:50:40 -0500    

Click here for diff

In user-manag.sgml, document precisely what privileges are conveyed  
by CREATEROLE. Make particular note of the fact that it allows  
changing passwords and granting access to high-privilege roles.  
Also remove the suggestion of using a user with CREATEROLE and  
CREATEDB instead of a superuser, as there is no real security  
advantage to this approach.  
  
Elsewhere in the documentation, adjust text that suggests that  
<literal>CREATEROLE</literal> only allows for role creation, and  
refer to the documentation in user-manag.sgml as appropriate.  
  
Patch by me, reviewed by Álvaro Herrera  
  
Discussion: http://postgr.es/m/CA+TgmoZBsPL8nPhvYecx7iGo5qpDRqa9k_AcaW1SbOjugAY1Ag@mail.gmail.com  

M doc/src/sgml/ref/alter_role.sgml
M doc/src/sgml/ref/create_role.sgml
M doc/src/sgml/ref/createuser.sgml
M doc/src/sgml/user-manag.sgml

Fix typos in comments, code and documentation

commit   : c772dfe07a9d4e499117f58d47a7c50d56666459    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 3 Jan 2023 16:26:27 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 3 Jan 2023 16:26:27 +0900    

Click here for diff

While on it, newlines are removed from the end of two elog() strings.  
The others are simple grammar mistakes.  One comment in pg_upgrade  
referred incorrectly to sequences since a7e5457.  
  
Author: Justin Pryzby  
Discussion: https://postgr.es/m/20221230231257.GI1153@telsasoft.com  
Backpatch-through: 11  

M .cirrus.yml
M doc/src/sgml/parallel.sgml
M doc/src/sgml/ref/alter_table.sgml
M doc/src/sgml/ref/create_subscription.sgml
M doc/src/sgml/sources.sgml
M src/backend/access/common/bufmask.c
M src/backend/access/spgist/spgutils.c
M src/backend/jit/llvm/llvmjit.c
M src/backend/optimizer/util/tlist.c
M src/backend/utils/adt/ruleutils.c
M src/bin/pg_upgrade/info.c
M src/test/regress/expected/copy.out
M src/test/regress/expected/expressions.out
M src/test/regress/sql/copy.sql
M src/test/regress/sql/expressions.sql
M src/test/ssl/t/SSL/Server.pm

perl: Hide warnings inside perl.h when using gcc compatible compiler

commit   : c6e75e4c2703d8eb7cb14cbf94a3d3dc36fdabbd    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Thu, 29 Dec 2022 12:47:29 -0800    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Thu, 29 Dec 2022 12:47:29 -0800    

Click here for diff

New versions of perl trigger warnings within perl.h with our compiler  
flags. At least -Wdeclaration-after-statement, -Wshadow=compatible-local are  
known to be problematic.  
  
To avoid these warnings, conditionally use #pragma GCC system_header before  
including plperl.h.  
  
Alternatively, we could add the include paths for problematic headers with  
-isystem, but that is a larger hammer and is harder to search for.  
  
A more granular alternative would be to use #pragma GCC diagnostic  
push/ignored/pop, but gcc warns about unknown warnings being ignored, so every  
to-be-ignored-temporarily compiler warning would require its own pg_config.h  
symbol and #ifdef.  
  
As the warnings are voluminous, it makes sense to backpatch this change. But  
don't do so yet, we first want gather buildfarm coverage - it's e.g. possible  
that some compiler claiming to be gcc compatible has issues with the pragma.  
  
Author: Andres Freund <andres@anarazel.de>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: Discussion: https://postgr.es/m/20221228182455.hfdwd22zztvkojy2@awork3.anarazel.de  

M src/include/c.h
M src/pl/plperl/plperl.h

Avoid reference to nonexistent array element in ExecInitAgg().

commit   : fbed54fb3890894055072381bb13850baf524ba5    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 2 Jan 2023 16:17:00 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 2 Jan 2023 16:17:00 -0500    

Click here for diff

When considering an empty grouping set, we fetched  
phasedata->eqfunctions[-1].  Because the eqfunctions array is  
palloc'd, that would always be an aset pointer in released versions,  
and thus the code accidentally failed to malfunction (since it would  
do nothing unless it found a null pointer).  Nonetheless this seems  
like trouble waiting to happen, so add a check for length == 0.  
  
It's depressing that our valgrind testing did not catch this.  
Maybe we should reconsider the choice to not mark that word NOACCESS?  
  
Richard Guo  
  
Discussion: https://postgr.es/m/CAMbWs4-vZuuPOZsKOYnSAaPYGKhmacxhki+vpOKk0O7rymccXQ@mail.gmail.com  

M src/backend/executor/nodeAgg.c

commit   : 1fbcb1360bc19b89369209203ea7cc19b8cde224    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 2 Jan 2023 15:00:37 -0500    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 2 Jan 2023 15:00:37 -0500    

Click here for diff

Backpatch-through: 11  

M COPYRIGHT
M doc/src/sgml/legal.sgml

ci: Change macOS builds from Intel to ARM.

commit   : dc513bc6544dd7f49a1c2d3bf06c77dbc2b5c9c3    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Sun, 1 Jan 2023 10:43:23 +1300    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Sun, 1 Jan 2023 10:43:23 +1300    

Click here for diff

Cirrus is about to shut down its macOS-on-Intel support, so it's time to  
move our CI testing over to ARM instances.  The Homebrew package manager  
changed its default installation prefix for the new architecture, so a  
couple of tests need tweaks to find binaries.  
  
Back-patch to 15, where in-tree CI began.  
  
Author: Justin Pryzby <pryzby@telsasoft.com>  
Discussion: https://postgr.es/m/20221122225744.GF11463%40telsasoft.com  

M .cirrus.yml
M src/test/kerberos/t/001_auth.pl
M src/test/ldap/t/001_auth.pl

Fix assert in BRIN build_distances

commit   : c4f64cfab9fefd7974c9097be72691c33c7afcea    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Fri, 30 Dec 2022 19:44:48 +0100    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Fri, 30 Dec 2022 19:44:48 +0100    

Click here for diff

When brin_minmax_multi_union merges summaries, we may end up with just a  
single range after merge_overlapping_ranges. The summaries may contain  
just one range each, and they may overlap (or be exactly the same).  
  
With a single range there's no distance to calculate, but we happen to  
call build_distances anyway - which is fine, we don't calculate the  
distance in this case, except that with asserts this failed due to a  
check there are at least two ranges.  
  
The assert is unnecessarily strict, so relax it a bit and bail out if  
there's just a single range. The relaxed assert would be enough, but  
this way we don't allocate unnecessary memory for distance.  
  
Backpatch to 14, where minmax-multi opclasses were introduced.  
  
Reported-by: Jaime Casanova  
Backpatch-through: 14  
Discussion: https://postgr.es/m/YzVA55qS0hgz8P3r@ahch-to  

M src/backend/access/brin/brin_minmax_multi.c

Rework <warning> box about column list combining in logical replication

commit   : d8209d09170f0029663da4335979b4f49d48b6be    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 23 Dec 2022 17:49:51 +0100    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 23 Dec 2022 17:49:51 +0100    

Click here for diff

After some copy-edit I made in commit 3a06a79cd137, we have a <sect2>  
that only contains a warning box.  This doesn't look good.  Rework by  
moving the sect2 title to be the warning's title, and put the 'id' to it  
as well, so that the external reference continues to work.  
  
Backpatch to 15.  
  
In branch master, I also take the opportunity to add titles to a couple  
of other warning boxes elsewhere in the documentation.  
  
Discussion: https://postgr.es/m/20221219164713.ccnlvtkyj6lmshqq@alvherre.pgsql  

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

Fix end LSN determination in recently added test

commit   : 5436cb373c6289eca8fc2b4aabb75f002a0394cf    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 23 Dec 2022 17:27:05 +0100    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 23 Dec 2022 17:27:05 +0100    

Click here for diff

The test added in commit e44dae07f931 has a thinko: it wants to read  
info about a few WAL records, but it obtains the LSN of the final record  
to read by asking for the WAL insert position; however,  
pg_get_wal_records_info only accepts to read up to the flush position  
(cf. IsFutureLSN()).  In normal conditions there is no difference, since  
the last record written by the preceding loop is known flushed and it's  
the one the test wants; but it's possible to have some other process  
insert another WAL record that isn't flushed, and that causes the whole  
test to explode.  
  
Fix by having pg_get_wal_records_info() read only up to the flushed  
position.  Backpatch to 15, which is where pg_walinspect appeared.  
  
Author: Karina Litskevich <litskevichkarina@gmail.com>  
Discussion: https://postgr.es/m/a5559c95-52c3-5eea-cd63-9b4f1c70ff96@gmail.com  

M src/test/modules/brin/t/02_wal_consistency.pl

Fix event trigger example

commit   : 2655ecde2c3313e1f9bc158faee884417252bc38    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 23 Dec 2022 13:21:41 +0100    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 23 Dec 2022 13:21:41 +0100    

Click here for diff

Commit 2f9661311b changed command tags from strings to numbers, but  
forgot to adjust the code in the event trigger example, which  
consequently failed to compile.  
  
While fixing that, improve the indentation to adhere to pgindent style.  
  
Backpatch to v13, where the change was introduced.  
  
Author: Laurenz Albe  
Discussion: https://postgr.es/m/81e36ac17dc80489e74dc5b6914afa6ccdb1a99d.camel@cybertec.at  

M doc/src/sgml/event-trigger.sgml

Fix some incorrectness in upgrade_adapt.sql on query for WITH OIDS

commit   : 9c48a0f00011c45d9a7b8903ffbecd286cf46de0    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 23 Dec 2022 11:27:11 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 23 Dec 2022 11:27:11 +0900    

Click here for diff

The query used to disable WITH OIDS in all the relations making use of  
it was checking for materialized views, but this is not a supported  
operation.  On the contrary, this needs to be done on foreign tables.  
  
While on it, use quote_ident() in the ALTER TABLE strings built on the  
relation name.  
  
Author: Anton A. Melnikov, Michael Paquier  
Discussion: https://postgr.es/m/49f389ba-95ce-8a9b-09ae-f60650c0e7c7@inbox.ru  
Backpatch-through: 12  

M src/bin/pg_upgrade/upgrade_adapt.sql

Fix come incorrect elog() messages in aclchk.c

commit   : e3897a3a4c559e20ba2c4f311be6ace8006f9005    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 23 Dec 2022 10:04:30 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 23 Dec 2022 10:04:30 +0900    

Click here for diff

Three error strings used with cache lookup failures were referring to  
incorrect object types for ACL checks:  
- Schemas  
- Types  
- Foreign Servers  
There errors should never be triggered, but if they do incorrect  
information would be reported.  
  
Author: Justin Pryzby  
Discussion: https://postgr.es/m/20221222153041.GN1153@telsasoft.com  
Backpatch-through: 11  

M src/backend/catalog/aclchk.c

Add some recursion and looping defenses in prepjointree.c.

commit   : 1a3daa5bb2e0ec10dd6cee38d120a52bed9213e0    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 22 Dec 2022 10:35:02 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 22 Dec 2022 10:35:02 -0500    

Click here for diff

Andrey Lepikhov demonstrated a case where we spend an unreasonable  
amount of time in pull_up_subqueries().  Not only is that recursing  
with no explicit check for stack overrun, but the code seems not  
interruptable by control-C.  Let's stick a CHECK_FOR_INTERRUPTS  
there, along with sprinkling some stack depth checks.  
  
An actual fix for the excessive time consumption seems a bit  
risky to back-patch; but this isn't, so let's do so.  
  
Discussion: https://postgr.es/m/703c09a2-08f3-d2ec-b33d-dbecd62428b8@postgrespro.ru  

M src/backend/optimizer/prep/prepjointree.c

Fix contrib/seg to be more wary of long input numbers.

commit   : b87037b373cf5605e6755e50c62348337a0d32c8    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 21 Dec 2022 17:51:50 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 21 Dec 2022 17:51:50 -0500    

Click here for diff

seg stores the number of significant digits in an input number  
in a "char" field.  If char is signed, and the input is more than  
127 digits long, the count can read out as negative causing  
seg_out() to print garbage (or, if you're really unlucky,  
even crash).  
  
To fix, clamp the digit count to be not more than FLT_DIG.  
(In theory this loses some information about what the original  
input was, but it doesn't seem like useful information; it would  
not survive dump/restore in any case.)  
  
Also, in case there are stored values of the seg type containing  
bad data, add a clamp in seg_out's restore() subroutine.  
  
Per bug #17725 from Robins Tharakan.  It's been like this  
forever, so back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/17725-0a09313b67fbe86e@postgresql.org  

M contrib/seg/expected/seg.out
M contrib/seg/seg.c
M contrib/seg/segparse.y
M contrib/seg/sql/seg.sql

Fix inability to reference CYCLE column from inside its CTE.

commit   : ae98debf77d4aba7caa305fa4957577528699470    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 16 Dec 2022 13:07:42 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 16 Dec 2022 13:07:42 -0500    

Click here for diff

Such references failed with "cache lookup failed for type 0"  
because we didn't resolve the type of the CYCLE column until after  
analyzing the CTE's query.  We can just move that processing  
to before the recursive parse_sub_analyze call, though.  
  
While here, invent a couple of local variables to make this  
code less egregiously wider-than-80-columns.  
  
Per bug #17723 from Vik Fearing.  Back-patch to v14 where  
the CYCLE feature was added.  
  
Discussion: https://postgr.es/m/17723-2c4985ff111e7bba@postgresql.org  

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

Re-adjust drop-index-concurrently-1 isolation test

commit   : 1a9b43c688da9bbb13f0cb07d4b4c03abf1518b5    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Fri, 16 Dec 2022 11:40:22 +1300    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Fri, 16 Dec 2022 11:40:22 +1300    

Click here for diff

It seems that drop-index-concurrently-1 has started to forget what it was  
originally meant to be testing.  d2d8a229b, which added incremental sorts  
changed the expected plan to be an Index Scan plan instead of a Seq Scan  
plan.  This occurred as the primary key index of the table in question  
provided presorted input and, because that index happened to be the  
cheapest input path due to enable_seqscan being disabled, the incremental  
sort changes just added a Sort on top of that.  It seems based on the name  
of the PREPAREd statement that the intention here is that the query  
produces a seqscan plan.  
  
The reason this test has become broken seems to be due to how the test was  
originally coded.  The test was trying to force a seqscan plan by  
performing some casting to make it so the test_dc index couldn't be used  
to perform the required filtering.  Trying to coax the planner into using  
a plan which has costed in a disable_cost seems like it's always going to  
be flakey as small changes in costs are drowned out by the large  
disable_cost combined with add_path's STD_FUZZ_FACTOR.  Here we get rid of  
the casts that we're using to try to trick the planner into a seqscan and  
instead toggle enable_seqscan as and when required to get the desired  
plan.  
  
Additionally, rename a few things in the test and add some additional  
wording to the comments to try and make it more clear in the future what  
we expect this test to be doing.  
  
Discussion: https://postgr.es/m/CAApHDvrbDhObhLV+=U_K_-t+2Av2av1aL9d+2j_3AO-XndaviA@mail.gmail.com  
Backpatch-through: 13, where d2d8a229b changed the expected test output  

M src/test/isolation/expected/drop-index-concurrently-1.out
M src/test/isolation/expected/drop-index-concurrently-1_2.out
M src/test/isolation/specs/drop-index-concurrently-1.spec

Rethink handling of [Prevent|Is]InTransactionBlock in pipeline mode.

commit   : 18431ee6f511be0c4cf4d7463899ce318c7632eb    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 13 Dec 2022 14:23:59 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 13 Dec 2022 14:23:59 -0500    

Click here for diff

Commits f92944137 et al. made IsInTransactionBlock() set the  
XACT_FLAGS_NEEDIMMEDIATECOMMIT flag before returning "false",  
on the grounds that that kept its API promises equivalent to those of  
PreventInTransactionBlock().  This turns out to be a bad idea though,  
because it allows an ANALYZE in a pipelined series of commands to  
cause an immediate commit, which is unexpected.  
  
Furthermore, if we return "false" then we have another issue,  
which is that ANALYZE will decide it's allowed to do internal  
commit-and-start-transaction sequences, thus possibly unexpectedly  
committing the effects of previous commands in the pipeline.  
  
To fix the latter situation, invent another transaction state flag  
XACT_FLAGS_PIPELINING, which explicitly records the fact that we  
have executed some extended-protocol command and not yet seen a  
commit for it.  Then, require that flag to not be set before allowing  
InTransactionBlock() to return "false".  
  
Having done that, we can remove its setting of NEEDIMMEDIATECOMMIT  
without fear of causing problems.  This means that the API guarantees  
of IsInTransactionBlock now diverge from PreventInTransactionBlock,  
which is mildly annoying, but it seems OK given the very limited usage  
of IsInTransactionBlock.  (In any case, a caller preferring the old  
behavior could always set NEEDIMMEDIATECOMMIT for itself.)  
  
For consistency also require XACT_FLAGS_PIPELINING to not be set  
in PreventInTransactionBlock.  This too is meant to prevent commands  
such as CREATE DATABASE from silently committing previous commands  
in a pipeline.  
  
Per report from Peter Eisentraut.  As before, back-patch to all  
supported branches (which sadly no longer includes v10).  
  
Discussion: https://postgr.es/m/65a899dd-aebc-f667-1d0a-abb89ff3abf8@enterprisedb.com  

M doc/src/sgml/libpq.sgml
M doc/src/sgml/protocol.sgml
M src/backend/access/transam/xact.c
M src/backend/tcop/postgres.c
M src/include/access/xact.h

Fix jsonb subscripting to cope with toasted subscript values.

commit   : d79b76b10ed55ceb25377c0623f2a159ad6117b4    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 12 Dec 2022 16:17:49 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 12 Dec 2022 16:17:49 -0500    

Click here for diff

jsonb_get_element() was incautious enough to use VARDATA() and  
VARSIZE() directly on an arbitrary text Datum.  That of course  
fails if the Datum is short-header, compressed, or out-of-line.  
The typical result would be failing to match any element of a  
jsonb object, though matching the wrong one seems possible as well.  
  
setPathObject() was slightly brighter, in that it used VARDATA_ANY  
and VARSIZE_ANY_EXHDR, but that only kept it out of trouble for  
short-header Datums.  push_path() had the same issue.  This could  
result in faulty subscripted insertions, though keys long enough to  
cause a problem are likely rare in the wild.  
  
Having seen these, I looked around for unsafe usages in the rest  
of the adt/json* files.  There are a couple of places where it's not  
immediately obvious that the Datum can't be compressed or out-of-line,  
so I added pg_detoast_datum_packed() to cope if it is.  Also, remove  
some other usages of VARDATA/VARSIZE on Datums we just extracted from  
a text array.  Those aren't actively broken, but they will become so  
if we ever start allowing short-header array elements, which does not  
seem like a terribly unreasonable thing to do.  In any case they are  
not great coding examples, and they could also do with comments  
pointing out that we're assuming we don't need pg_detoast_datum_packed.  
  
Per report from exe-dealer@yandex.ru.  Patch by me, but thanks to  
David Johnston for initial investigation.  Back-patch to v14 where  
jsonb subscripting was introduced.  
  
Discussion: https://postgr.es/m/205321670615953@mail.yandex.ru  

M src/backend/utils/adt/jsonb_gin.c
M src/backend/utils/adt/jsonb_op.c
M src/backend/utils/adt/jsonfuncs.c
M src/test/regress/expected/jsonb.out
M src/test/regress/sql/jsonb.sql

Fix failure to advance content pointer in sendFileWithContent.

commit   : 8b5ba2f3f40a9c82623a19b551bc5790a84275a2    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Mon, 12 Dec 2022 10:17:02 -0500    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Mon, 12 Dec 2022 10:17:02 -0500    

Click here for diff

If sendFileWithContent were used to send a file larger than the  
bbsink buffer size, this would result in corruption. The only  
files that are sent via sendFileWithContent are the backup label  
file, the tablespace map file, and .done files for WAL segments  
included in the backup. Of these, it seems that only the  
tablespace_map file can become large enough to cause a problem,  
and then only if you have a lot of tablespaces. If you do have  
that situation, you might end up with a corrupted  
tablespace_map file, which would be bad.  
  
My commit bef47ff85df18bf4a3a9b13bd2a54820e27f3614 introduced  
this problem.  
  
Report and patch by Antonin Houska.  
  
Discussion: http://postgr.es/m/15764.1670528645@antos  

M src/backend/backup/basebackup.c

Add subquery pullup handling for WindowClause runCondition

commit   : 04788ee4c5efcfbf026b968a064fcdd74fcba154    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Sat, 10 Dec 2022 19:27:53 +1300    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Sat, 10 Dec 2022 19:27:53 +1300    

Click here for diff

9d9c02ccd added code to allow WindowAgg to take some shortcuts when a  
monotonic WindowFunc reached some value that it could never come back  
from due to the function's monotonic nature.  That commit added a  
runCondition field to WindowClause to store the condition which, when it  
becomes false we can start taking shortcuts in nodeWindowAgg.c.  
  
Here we fix an issue where subquery pullups didn't properly update the  
runCondition to update the Vars to properly reference the new query level.  
  
Here we also add a missing call to preprocess_expression() for the  
WindowClause's runCondtion.  The WindowFuncs in the targetlist will have  
had this process done, so we must also do it for the WindowFuncs in the  
runCondition so that they can be correctly found in the targetlist  
during setrefs.c  
  
Bug: #17709  
Reported-by: Alexey Makhmutov  
Author: Richard Guo, David Rowley  
Discussion: https://postgr.es/m/17709-4f557160e3e8ee9a@postgresql.org  
Backpatch-through: 15, where 9d9c02ccd was introduced  

M src/backend/optimizer/plan/planner.c
M src/backend/optimizer/prep/prepjointree.c

Update MERGE docs to mention that ONLY is supported.

commit   : ee1c6728d8a9c377287577e34444442fa3ed16eb    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Fri, 9 Dec 2022 10:03:04 +0000    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Fri, 9 Dec 2022 10:03:04 +0000    

Click here for diff

Commit 7103ebb7aa added support for MERGE, which included support for  
inheritance hierarchies, but didn't document the fact that ONLY could  
be specified before the source and/or target tables to exclude tables  
inheriting from the tables specified.  
  
Update merge.sgml to mention this, and while at it, add some  
regression tests to cover it.  
  
Dean Rasheed, reviewed by Nathan Bossart.  
  
Backpatch to 15, where MERGE was added.  
  
Discussion: https://postgr.es/m/CAEZATCU0XM-bJCvpJuVRU3UYNRqEBS6g4-zH%3Dj9Ye0caX8F6uQ%40mail.gmail.com  

M doc/src/sgml/ref/merge.sgml
M src/test/regress/expected/merge.out
M src/test/regress/sql/merge.sql

Remove new structure member from ResultRelInfo.

commit   : a0bf7a0eccbf73c7ce4efd7b09c3c9544a57c5a4    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Thu, 8 Dec 2022 16:15:01 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Thu, 8 Dec 2022 16:15:01 +0900    

Click here for diff

In commit ffbb7e65a, I added a ModifyTableState member to ResultRelInfo  
to save the owning ModifyTableState for use by nodeModifyTable.c when  
performing batch inserts, but as pointed out by Tom Lane, that changed  
the array stride of es_result_relations, and that would break any  
previously-compiled extension code that accesses that array.  Fix by  
removing that member from ResultRelInfo and instead adding a List member  
at the end of EState to save such ModifyTableStates.  
  
Per report from Tom Lane.  Back-patch to v14, like the previous commit;  
I chose to apply the patch to HEAD as well, to make back-patching easy.  
  
Discussion: http://postgr.es/m/4065383.1669395453%40sss.pgh.pa.us  

M src/backend/executor/execMain.c
M src/backend/executor/execPartition.c
M src/backend/executor/execUtils.c
M src/backend/executor/nodeModifyTable.c
M src/include/nodes/execnodes.h

Fix FK comment think-o

commit   : 6bcd1d9f30c00fda59cd5210fc368bc086db15f6    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 7 Dec 2022 17:06:50 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 7 Dec 2022 17:06:50 +0100    

Click here for diff

from commit d6f96ed94e7  
  
Author: Paul Jungwirth <pj@illuminatedcomputing.com>  
Reviewed-by: Ian Lawrence Barwick <barwick@gmail.com>  
Discussion: https://www.postgresql.org/message-id/flat/6a7c7338-1aa2-4689-d171-0b0b294fdd84%40illuminatedcomputing.com  

M src/backend/commands/tablecmds.c

Fix 32-bit build dangling pointer issue in WindowAgg

commit   : 2a535620cec565e2ef195f99ca186ab71a1cacbb    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Wed, 7 Dec 2022 00:10:21 +1300    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Wed, 7 Dec 2022 00:10:21 +1300    

Click here for diff

9d9c02ccd added window "run conditions", which allows the evaluation of  
monotonic window functions to be skipped when the run condition is no  
longer true.  Prior to this commit, once the run condition was no longer  
true and we stopped evaluating the window functions, we simply just left  
the ecxt_aggvalues[] and ecxt_aggnulls[] arrays alone to store whatever  
value was stored there the last time the window function was evaluated.  
Leaving a stale value in there isn't really a problem on 64-bit builds as  
all of the window functions which we recognize as monotonic all return  
int8, which is passed by value on 64-bit builds.  However, on 32-bit  
builds, this was a problem as the value stored in the ecxt_values[]  
element would be a by-ref value and it would be pointing to some memory  
which would get reset once the tuple context is destroyed.  Since the  
WindowAgg node will output these values in the resulting tupleslot, this  
could be problematic for the top-level WindowAgg node which must look at  
these values to filter out the rows that don't meet its filter condition.  
  
Here we fix this by just zeroing the ecxt_aggvalues[] and setting the  
ecxt_aggnulls[] array to true when the run condition first becomes false.  
This results in the WindowAgg's output having NULLs for the WindowFunc's  
columns rather than the stale or pointer pointing to possibly freed  
memory.  These tuples with the NULLs can only make it as far as the  
top-level WindowAgg node before they're filtered out.  To ensure that  
these tuples *are* always filtered out, we now insist that OpExprs making  
up the run condition are strict OpExprs.  Currently, all the window  
functions which the planner recognizes as monotonic return INT8 and the  
operator which is used for the run condition must be a member of a btree  
opclass.  In reality, these restrictions exclude nothing that's built-in  
to Postgres and are unlikely to exclude anyone's custom operators due to  
the requirement that the operator is part of a btree opclass.  It would be  
unusual if those were not strict.  
  
Reported-by: Sergey Shinderuk, using valgrind  
Reviewed-by: Richard Guo, Sergey Shinderuk  
Discussion: https://postgr.es/m/29184c50-429a-ebd7-f1fb-0589c6723a35@postgrespro.ru  
Backpatch-through: 15, where 9d9c02ccd was added  

M src/backend/executor/nodeWindowAgg.c
M src/backend/optimizer/path/allpaths.c

Fix Memoize to work with partitionwise joining.

commit   : c959f84c2b770bc136ade3cfd11f6063a51d2708    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 5 Dec 2022 12:36:41 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 5 Dec 2022 12:36:41 -0500    

Click here for diff

A couple of places weren't up to speed for this.  By sheer good  
luck, we didn't fail but just selected a non-memoized join plan,  
at least in the test case we have.  Nonetheless, it's a bug,  
and I'm not quite sure that it couldn't have worse consequences  
in other examples.  So back-patch to v14 where Memoize came in.  
  
Richard Guo  
  
Discussion: https://postgr.es/m/CAMbWs48GkNom272sfp0-WeD6_0HSR19BJ4H1c9ZKSfbVnJsvRg@mail.gmail.com  

M src/backend/optimizer/path/joinpath.c
M src/backend/optimizer/util/pathnode.c
M src/include/nodes/pathnodes.h
M src/test/regress/expected/memoize.out
M src/test/regress/sql/memoize.sql

doc: Add missing <varlistentry> markups for developer GUCs

commit   : 74a600a1506113cce67aa2d5b869ad69459a8ccd    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 5 Dec 2022 11:23:27 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 5 Dec 2022 11:23:27 +0900    

Click here for diff

Missing such markups makes it impossible to create links back to these  
GUCs, and all the other parameters have one already.  
  
Author: Ian Lawrence Barwick  
Discussion: https://postgr.es/m/CAB8KJ=jx=6dFB_EN3j0UkuvG3cPu5OmQiM-ZKRAz+fKvS+u8Ng@mail.gmail.com  
Backpatch-through: 11  

M doc/src/sgml/config.sgml

Fix broken MemoizePath support in reparameterize_path().

commit   : 834d97c32b712c170594378d27385638c5b87c60    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 4 Dec 2022 13:48:12 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 4 Dec 2022 13:48:12 -0500    

Click here for diff

It neglected to recurse to the subpath, meaning you'd get back  
a path identical to the input.  This could produce wrong query  
results if the omission meant that the subpath fails to enforce  
some join clause it should be enforcing.  We don't have a test  
case for this at the moment, but the code is obviously broken  
and the fix is equally obvious.  Back-patch to v14 where  
Memoize was introduced.  
  
Richard Guo  
  
Discussion: https://postgr.es/m/CAMbWs4_R=ORpz=Lkn2q3ebPC5EuWyfZF+tmfCPVLBVK5W39mHA@mail.gmail.com  

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

Fix generate_partitionwise_join_paths() to tolerate failure.

commit   : bf8fd64ff5e65f8964d1b52c50019f0198ec5f5e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 4 Dec 2022 13:17:18 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 4 Dec 2022 13:17:18 -0500    

Click here for diff

We might fail to generate a partitionwise join, because  
reparameterize_path_by_child() does not support all path types.  
This should not be a hard failure condition: we should just fall back  
to a non-partitioned join.  However, generate_partitionwise_join_paths  
did not consider this possibility and would emit the (misleading)  
error "could not devise a query plan for the given query" if we'd  
failed to make any paths for a child join.  Fix it to give up on  
partitionwise joining if so.  (The accepted technique for giving up  
appears to be to set rel->nparts = 0, which I find pretty bizarre,  
but there you have it.)  
  
I have not added a test case because there'd be little point:  
any omissions of this sort that we identify would soon get fixed  
by extending reparameterize_path_by_child(), so the test would stop  
proving anything.  However, right now there is a known test case based  
on failure to cover MaterialPath, and with that I've found that this  
is broken in all supported versions.  Hence, patch all the way back.  
  
Original report and patch by me; thanks to Richard Guo for  
identifying a test case that works against committed versions.  
  
Discussion: https://postgr.es/m/1854233.1669949723@sss.pgh.pa.us  

M src/backend/optimizer/path/allpaths.c

Fix DEFAULT handling for multi-row INSERT rules.

commit   : c67204db61fa9c4429b30ce031ef833748c8c69a    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Sat, 3 Dec 2022 12:14:36 +0000    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Sat, 3 Dec 2022 12:14:36 +0000    

Click here for diff

When updating a relation with a rule whose action performed an INSERT  
from a multi-row VALUES list, the rewriter might skip processing the  
VALUES list, and therefore fail to replace any DEFAULTs in it. This  
would lead to an "unrecognized node type" error.  
  
The reason was that RewriteQuery() assumed that a query doing an  
INSERT from a multi-row VALUES list would necessarily only have one  
item in its fromlist, pointing to the VALUES RTE to read from. That  
assumption is correct for the original query, but not for product  
queries produced for rule actions. In such cases, there may be  
multiple items in the fromlist, possibly including multiple VALUES  
RTEs.  
  
What is required instead is for RewriteQuery() to skip any RTEs from  
the product query's originating query, which might include one or more  
already-processed VALUES RTEs. What's left should then include at most  
one VALUES RTE (from the rule action) to be processed.  
  
Patch by me. Thanks to Tom Lane for reviewing.  
  
Back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/CAEZATCV39OOW7LAR_Xq4i%2BLc1Byux%3DeK3Q%3DHD_pF1o9LBt%3DphA%40mail.gmail.com  

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

Prevent pgstats from getting confused when relkind of a relation changes

commit   : c6a60471a1a5e21bf901ad24cac27874a1886306    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Fri, 2 Dec 2022 17:50:26 -0800    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Fri, 2 Dec 2022 17:50:26 -0800    

Click here for diff

When the relkind of a relache entry changes, because a table is converted into  
a view, pgstats can get confused in 15+, leading to crashes or assertion  
failures.  
  
For HEAD, Tom fixed this in b23cd185fd5, by removing support for converting a  
table to a view, removing the source of the inconsistency. This commit just  
adds an assertion that a relcache entry's relkind does not change, just in  
case we end up with another case of that in the future. As there's no cases of  
changing relkind anymore, we can't add a test that that's handled correctly.  
  
For 15, fix the problem by not maintaining the association with the old pgstat  
entry when the relkind changes during a relcache invalidation processing. In  
that case the pgstat entry needs to be unlinked first, to avoid  
PgStat_TableStatus->relation getting out of sync. Also add a test reproducing  
the issues.  
  
No known problem exists in 11-14, so just add the test there.  
  
Reported-by: vignesh C <vignesh21@gmail.com>  
Author: Andres Freund <andres@anarazel.de>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/CALDaNm2yXz+zOtv7y5zBd5WKT8O0Ld3YxikuU3dcyCvxF7gypA@mail.gmail.com  
Discussion: https://postgr.es/m/CALDaNm3oZA-8Wbps2Jd1g5_Gjrr-x3YWrJPek-mF5Asrrvz2Dg@mail.gmail.com  
Backpatch: 15-  

M src/backend/utils/cache/relcache.c
M src/test/regress/expected/create_view.out
M src/test/regress/sql/create_view.sql

Fix psql's \sf and \ef for new-style SQL functions.

commit   : 97299cf99df086af847a641161e8b925fdf840b9    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 2 Dec 2022 14:24:44 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 2 Dec 2022 14:24:44 -0500    

Click here for diff

Some options of these commands need to be able to identify the start  
of the function body within the output of pg_get_functiondef().  
It used to be that that always began with "AS", but since the  
introduction of new-style SQL functions, it might also start with  
"BEGIN" or "RETURN".  Fix that on the psql side, and add some  
regression tests.  
  
Noted by me awhile ago, but I didn't do anything about it.  
Thanks to David Johnston for a nag.  
  
Discussion: https://postgr.es/m/AM9PR01MB8268D5CDABDF044EE9F42173FE8C9@AM9PR01MB8268.eurprd01.prod.exchangelabs.com  

M src/backend/utils/adt/ruleutils.c
M src/bin/psql/command.c
M src/test/regress/expected/psql.out
M src/test/regress/sql/psql.sql

Fix incorrect output from pgoutput when using column lists.

commit   : ebf87c019c042a33cf9d2810c1fe360ddc7f8e93    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Fri, 2 Dec 2022 10:34:16 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Fri, 2 Dec 2022 10:34:16 +0530    

Click here for diff

For Updates and Deletes, we were not honoring the columns list for old  
tuple values while sending tuple data via pgoutput. This results in  
pgoutput emitting more columns than expected.  
  
This is not a problem for built-in logical replication as we simply ignore  
additional columns based on the relation information sent previously which  
didn't have those columns. However, some other users of pgoutput plugin  
may expect the columns as per the column list. Also, sending extra columns  
unnecessarily consumes network bandwidth defeating the purpose of the  
column list feature.  
  
Reported-by: Gunnar Morling  
Author: Hou Zhijie  
Reviewed-by: Amit Kapila  
Backpatch-through: 15  
Discussion: https://postgr.es/m/CADGJaX9kiRZ-OH0EpWF5Fkyh1ZZYofoNRCrhapBfdk02tj5EKg@mail.gmail.com  

M src/backend/replication/logical/proto.c
M src/backend/replication/pgoutput/pgoutput.c
M src/include/replication/logicalproto.h
M src/test/subscription/t/031_column_list.pl

Fix memory leak for hashing with nondeterministic collations.

commit   : 9377b4f30a14e1c79183b3138fa88fc99d4a872a    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Thu, 1 Dec 2022 11:26:32 -0800    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Thu, 1 Dec 2022 11:26:32 -0800    

Click here for diff

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

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

Doc: add example of round(v, s) with negative s.

commit   : e10799aa252c2232a3d4f73f4875532423f3f7b4    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 1 Dec 2022 12:26:12 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 1 Dec 2022 12:26:12 -0500    

Click here for diff

This has always worked, but you'd be unlikely to guess it  
from the documentation.  Add an example showing it.  
  
Lack of docs noted by David Johnston.  Back-patch to v13;  
the documentation layout we used before that was not very  
amenable to squeezing in multiple examples.  
  
Discussion: https://postgr.es/m/CAKFQuwZ4Vy1Xty0G5Ok+ot=NDrU3C6hzF1JwUk-FEkwe3V9_RA@mail.gmail.com  

M doc/src/sgml/func.sgml

Doc: word-smith the discussion of secure schema usage patterns.

commit   : afa4a4f764cca2d0232d9f12d0a268c3804afce7    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 1 Dec 2022 12:10:25 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 1 Dec 2022 12:10:25 -0500    

Click here for diff

Rearrange the discussion of user-private schemas so that details  
applying only to upgraded-from-pre-v15 databases are in a follow-on  
paragraph, not in the main description of how to set up this pattern.  
This seems a little clearer even today, and it'll get more so as  
pre-v15 systems fade into the sunset.  
  
Wording contributions from Robert Haas, Tom Lane, Noah Misch.  
  
Discussion: https://postgr.es/m/CA+TgmoYUHsfp90inEMAP0yNr7Y_L6EphPH1YOon1JKtBztXHyQ@mail.gmail.com  

M doc/src/sgml/ddl.sgml

Fix under-parenthesized display of AT TIME ZONE constructs.

commit   : a711b36e5b88e786f541b6c5671f28e997e68415    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 1 Dec 2022 11:38:06 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 1 Dec 2022 11:38:06 -0500    

Click here for diff

In commit 40c24bfef, I forgot to use get_rule_expr_paren() for the  
arguments of AT TIME ZONE, resulting in possibly not printing parens  
for expressions that need it.  But get_rule_expr_paren() wouldn't have  
gotten it right anyway, because isSimpleNode() hadn't been taught that  
COERCE_SQL_SYNTAX parent nodes don't guarantee sufficient parentheses.  
Improve all that.  Also use this methodology for F_IS_NORMALIZED, so  
that we don't print useless parens for that.  
  
In passing, remove a comment that was obsoleted later.  
  
Per report from Duncan Sands.  Back-patch to v14 where this code  
came in.  (Before that, we didn't try to print AT TIME ZONE that way,  
so there was no bug just ugliness.)  
  
Discussion: https://postgr.es/m/f41566aa-a057-6628-4b7c-b48770ecb84a@deepbluecap.com  

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

revert: add transaction processing chapter with internals info

commit   : f79cca5bfd2250c56e93f32a21bd3cd39be07724    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Thu, 1 Dec 2022 10:45:08 -0500    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Thu, 1 Dec 2022 10:45:08 -0500    

Click here for diff

This doc patch (master hash 66bc9d2d3e) was decided to be too  
significant for backpatching, so reverted in all but master.  Also fix  
SGML file header comment in master.  
  
Reported-by:  	Peter Eisentraut  
  
Discussion: https://postgr.es/m/c6304b19-6ff7-f3af-0148-cf7aa7e2fbfd@enterprisedb.com  
  
Backpatch-through: 11  

M doc/src/sgml/config.sgml
M doc/src/sgml/datatype.sgml
M doc/src/sgml/filelist.sgml
M doc/src/sgml/func.sgml
M doc/src/sgml/glossary.sgml
M doc/src/sgml/monitoring.sgml
M doc/src/sgml/pgrowlocks.sgml
M doc/src/sgml/postgres.sgml
M doc/src/sgml/ref/release_savepoint.sgml
M doc/src/sgml/ref/rollback.sgml
M doc/src/sgml/ref/rollback_to.sgml
M doc/src/sgml/system-views.sgml
M doc/src/sgml/wal.sgml
D doc/src/sgml/xact.sgml

Reject missing database name in pg_regress and cohorts.

commit   : f2f9e11d35226ff8d4cbb737b7c31d072e212178    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 30 Nov 2022 13:01:41 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 30 Nov 2022 13:01:41 -0500    

Click here for diff

Writing "pg_regress --dbname= ..." led to a crash, because  
we weren't expecting there to be no database name supplied.  
It doesn't seem like a great idea to run regression tests  
in whatever is the user's default database; so rather than  
supporting this case let's explicitly reject it.  
  
Per report from Xing Guo.  Back-patch to all supported  
branches.  
  
Discussion: https://postgr.es/m/CACpMh+A8cRvtvtOWVAZsCM1DU81GK4DL26R83y6ugZ1osV=ifA@mail.gmail.com  

M src/test/regress/pg_regress.c

doc: add transaction processing chapter with internals info

commit   : 8592b56faf86be1a8684544ad3a93e2fe8f5aa1b    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 29 Nov 2022 20:49:52 -0500    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 29 Nov 2022 20:49:52 -0500    

Click here for diff

This also adds references to this new chapter at relevant sections of  
our documentation.  Previously much of these internal details were  
exposed to users, but not explained.  This also updates RELEASE  
SAVEPOINT.  
  
Discussion: https://postgr.es/m/CANbhV-E_iy9fmrErxrCh8TZTyenpfo72Hf_XD2HLDppva4dUNA@mail.gmail.com  
  
Author: Simon Riggs, Laurenz Albe  
  
Reviewed-by: Bruce Momjian  
  
Backpatch-through: 11  

M doc/src/sgml/config.sgml
M doc/src/sgml/datatype.sgml
M doc/src/sgml/filelist.sgml
M doc/src/sgml/func.sgml
M doc/src/sgml/glossary.sgml
M doc/src/sgml/monitoring.sgml
M doc/src/sgml/pgrowlocks.sgml
M doc/src/sgml/postgres.sgml
M doc/src/sgml/ref/release_savepoint.sgml
M doc/src/sgml/ref/rollback.sgml
M doc/src/sgml/ref/rollback_to.sgml
M doc/src/sgml/system-views.sgml
M doc/src/sgml/wal.sgml
A doc/src/sgml/xact.sgml

Fix comment in fe-auth-scram.c

commit   : 15571ccd190b242b944422a663a8269f8f688d4f    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 30 Nov 2022 08:38:27 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 30 Nov 2022 08:38:27 +0900    

Click here for diff

The frontend-side routine in charge of building a SCRAM verifier  
mentioned that the restrictions applying to SASLprep on the password  
with the encoding are described at the top of fe-auth-scram.c, but this  
information is in auth-scram.c.  
  
This is wrong since 8f8b9be, so backpatch all the way down as this is an  
important documentation bit.  
  
Spotted while reviewing a different patch.  
  
Backpatch-through: 11  

M src/interfaces/libpq/fe-auth-scram.c

Improve heuristics for compressing the KnownAssignedXids array.

commit   : 55fa993d7eacb3f3ef99015649d44606201767e5    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 29 Nov 2022 15:43:17 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 29 Nov 2022 15:43:17 -0500    

Click here for diff

Previously, we'd compress only when the active range of array entries  
reached Max(4 * PROCARRAY_MAXPROCS, 2 * pArray->numKnownAssignedXids).  
If max_connections is large, the first term could result in not  
compressing for a long time, resulting in much wastage of cycles in  
hot-standby backends scanning the array to take snapshots.  Get rid  
of that term, and just bound it to 2 * pArray->numKnownAssignedXids.  
  
That however creates the opposite risk, that we might spend too much  
effort compressing.  Hence, consider compressing only once every 128  
commit records.  (This frequency was chosen by benchmarking.  While  
we only tried one benchmark scenario, the results seem stable over  
a fairly wide range of frequencies.)  
  
Also, force compression when processing RecoveryInfo WAL records  
(which should be infrequent); the old code could perform compression  
then, but would do so only after the same array-range check as for  
the transaction-commit path.  
  
Also, opportunistically run compression if the startup process is about  
to wait for WAL, though not oftener than once a second.  This should  
prevent cases where we waste lots of time by leaving the array  
not-compressed for long intervals due to low WAL traffic.  
  
Lastly, add a simple check to keep us from uselessly compressing  
when the array storage is already compact.  
  
Back-patch, as the performance problem is worse in pre-v14 branches  
than in HEAD.  
  
Simon Riggs and Michail Nikolaev, with help from Tom Lane and  
Andres Freund.  
  
Discussion: https://postgr.es/m/CALdSSPgahNUD_=pB_j=1zSnDBaiOtqVfzo8Ejt5J_k7qZiU1Tw@mail.gmail.com  

M src/backend/access/transam/xlogrecovery.c
M src/backend/storage/ipc/procarray.c
M src/include/storage/procarray.h

Prevent clobbering of utility statements in SQL function caches.

commit   : 5dfc2b753b0f40ea036bcf621f827b800a422aac    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 29 Nov 2022 11:46:33 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 29 Nov 2022 11:46:33 -0500    

Click here for diff

This is an oversight in commit 7c337b6b5: I apparently didn't think  
about the possibility of a SQL function being executed multiple  
times within a query.  In that case, functions.c's primitive caching  
mechanism allows the same utility parse tree to be presented for  
execution more than once.  We have to tell ProcessUtility to make  
a working copy of the parse tree, or bad things happen.  
  
Normally I'd add a regression test, but I think the reported crasher  
is dependent on some rather random implementation choices that are  
nowhere near functions.c, so its usefulness as a long-lived test  
feels questionable.  In any case, this fix is clearly correct given  
the design choices of 7c337b6b5.  
  
Per bug #17702 from Xin Wen.  Thanks to Daniel Gustafsson for  
analysis.  Back-patch to v14 where the faulty commit came in  
(before that, the responsibility for copying scribble-able  
utility parse trees lay elsewhere).  
  
Discussion: https://postgr.es/m/17702-ad24fdcdd1e9047a@postgresql.org  

M src/backend/executor/functions.c

Remove bogus Assert and dead code in remove_useless_results_recurse().

commit   : 556c0b913be150b92ee9fb250d2d5acc6d28f4c2    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 29 Nov 2022 10:52:44 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 29 Nov 2022 10:52:44 -0500    

Click here for diff

The JOIN_SEMI case Assert'ed that there are no PlaceHolderVars that  
need to be evaluated at the semijoin's RHS, which is wrong because  
there could be some in the semijoin's qual condition.  However, there  
could not be any references further up than that, and within the qual  
there is not any way that such a PHV could have gone to null yet, so  
we don't really need the PHV and there is no need to avoid making the  
RHS-removal optimization.  The upshot is that there's no actual bug  
in production code, and we ought to just remove this misguided Assert.  
  
While we're here, also drop the JOIN_RIGHT case, which is dead code  
because reduce_outer_joins() already got rid of JOIN_RIGHT.  
  
Per bug #17700 from Xin Wen.  Uselessness of the JOIN_RIGHT case  
pointed out by Richard Guo.  Back-patch to v12 where this code  
was added.  
  
Discussion: https://postgr.es/m/17700-2b5c10d917c30687@postgresql.org  

M src/backend/optimizer/prep/prepjointree.c
M src/test/regress/expected/join.out
M src/test/regress/sql/join.sql

Fix binary mismatch for MSVC plperl vs gcc built perl libs

commit   : b5d8fd4182f24ee489aa6bb72308f8712cd8810d    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Sun, 27 Nov 2022 09:03:22 -0500    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Sun, 27 Nov 2022 09:03:22 -0500    

Click here for diff

When loading plperl built against Strawberry perl or the msys2 ucrt perl  
that have been built with gcc, a binary mismatch has been encountered  
which looks like this:  
  
loadable library and perl binaries are mismatched (got handshake key 0000000012800080, needed 0000000012900080)  
  
To cure this we bring the handshake keys into sync by adding  
NO_THREAD_SAFE_LOCALE to the defines used to build plperl.  
  
Discussion: https://postgr.es/m/20211005004334.tgjmro4kuachwiuc@alap3.anarazel.de  
Discussion: https://postgr.es/m/c2da86a0-2906-744c-923d-16da6047875e@dunslane.net  
  
Backpatch to all live branches.  

M src/tools/msvc/Mkvcbuild.pm

Remove temporary portlock directory during make [dist]clean.

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

Click here for diff

Another oversight in 9b4eafcaf.  

M GNUmakefile.in

Add portlock directory to .gitignore

commit   : fec24b75230e59ebf90ea5acadb577a1e2b2e923    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Sat, 26 Nov 2022 07:44:23 -0500    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Sat, 26 Nov 2022 07:44:23 -0500    

Click here for diff

Commit 9b4eafcaf4 added creattion of a directory to reserve TAP test  
ports at the top of the build tree. In a non-vpath build this means at  
the top of the source tree, so it needs to be added to .gitignore.  
  
As suggested by Michael Paquier  
  
Backpatch to all live branches.  

M .gitignore

Allow building with MSVC and Strawberry perl

commit   : fed54fc9a5819d43ab60518306925c38f5e2bc43    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 25 Nov 2022 15:28:38 -0500    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 25 Nov 2022 15:28:38 -0500    

Click here for diff

Strawberry uses __builtin_expect which Visual C doesn't have. For this  
case define it as a noop. Solution taken from vim sources.  
  
Backpatch to all live branches  

M src/pl/plperl/plperl.h

Fix rule-detection code for MERGE.

commit   : 04d61bfe64c9098aa737d0bea428b46a46b358bb    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Fri, 25 Nov 2022 13:29:51 +0000    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Fri, 25 Nov 2022 13:29:51 +0000    

Click here for diff

Use the relation's rd_rules structure to test whether it has rules,  
rather than the relhasrules flag, which might be out of date.  
  
Reviewed by Tom Lane.  
  
Backpatch to 15, where MERGE was added.  
  
Discussion: https://postgr.es/m/CAEZATCVkBVZABfw71sYvkcPf6tarcOFST5Bc6AOi-LFT9YdccQ%40mail.gmail.com  

M src/backend/parser/parse_merge.c

Fix handling of pending inserts in nodeModifyTable.c.

commit   : fc02019c09feab1f371fb5881f2f050ce6e30ea9    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Fri, 25 Nov 2022 17:45:01 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Fri, 25 Nov 2022 17:45:01 +0900    

Click here for diff

Commit b663a4136, which allowed FDWs to INSERT rows in bulk, added to  
nodeModifyTable.c code to flush pending inserts to the foreign-table  
result relation(s) before completing processing of the ModifyTable node,  
but the code failed to take into account the case where the INSERT query  
has modifying CTEs, leading to incorrect results.  
  
Also, that commit failed to flush pending inserts before firing BEFORE  
ROW triggers so that rows are visible to such triggers.  
  
In that commit we scanned through EState's  
es_tuple_routing_result_relations or es_opened_result_relations list to  
find the foreign-table result relations to which pending inserts are  
flushed, but that would be inefficient in some cases.  So to fix, 1) add  
a List member to EState to record the insert-pending result relations,  
and 2) modify nodeModifyTable.c so that it adds the foreign-table result  
relation to the list in ExecInsert() if appropriate, and flushes pending  
inserts properly using the list where needed.  
  
While here, fix a copy-and-pasteo in a comment in ExecBatchInsert(),  
which was added by that commit.  
  
Back-patch to v14 where that commit appeared.  
  
Discussion: https://postgr.es/m/CAPmGK16qutyCmyJJzgQOhfBq%3DNoGDqTB6O0QBZTihrbqre%2BoxA%40mail.gmail.com  

M contrib/postgres_fdw/expected/postgres_fdw.out
M contrib/postgres_fdw/sql/postgres_fdw.sql
M src/backend/executor/execMain.c
M src/backend/executor/execPartition.c
M src/backend/executor/execUtils.c
M src/backend/executor/nodeModifyTable.c
M src/include/nodes/execnodes.h

Fix uninitialized access to InitialRunningXacts during decoding.

commit   : 898ef41bf6f400264616444fbaea669e0685f98f    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Fri, 25 Nov 2022 09:38:03 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Fri, 25 Nov 2022 09:38:03 +0530    

Click here for diff

In commit 272248a0c, we introduced an InitialRunningXacts array to  
remember transactions and subtransactions that were running when the  
xl_running_xacts record that we decoded was written. This array was  
allocated in the snapshot builder memory context after we restore  
serialized snapshot but we forgot to reset the array while freeing the  
builder memory context. So, the next time when we start decoding in the  
same session where we don't restore any serialized snapshot, we ended up  
using the uninitialized array and that can lead to unpredictable behavior.  
  
This problem doesn't exist in HEAD as instead of using  
InitialRunningXacts, we added the list of transaction IDs and  
sub-transaction IDs, that have modified catalogs and are running during  
snapshot serialization, to the serialized snapshot (see commit 7f13ac8123).  
  
Reported-by: Maxim Orlov  
Author: Masahiko Sawada  
Reviewed-by: Amit Kapila, Maxim Orlov  
Backpatch-through: 11  
Discussion: https://postgr.es/m/CACG=ezZoz_KG+Ryh9MrU_g5e0HiVoHocEvqFF=NRrhrwKmEQJQ@mail.gmail.com  

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

Make multixact error message more explicit

commit   : f63f29733e2f4fe58f52557699242b80e23e19ee    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 24 Nov 2022 10:45:10 +0100    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 24 Nov 2022 10:45:10 +0100    

Click here for diff

There are recent reports involving a very old error message that we have  
no history of hitting -- perhaps a recently introduced bug.  Improve the  
error message in an attempt to improve our chances of investigating the  
bug.  
  
Per reports from Dimos Stamatakis and Bob Krier.  
  
Backpatch to 11.  
  
Discussion: https://postgr.es/m/CO2PR0801MB2310579F65529380A4E5EDC0E20A9@CO2PR0801MB2310.namprd08.prod.outlook.com  
Discussion: https://postgr.es/m/17518-04e368df5ad7f2ee@postgresql.org  

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

Fix perl warning from commit 9b4eafcaf4

commit   : 2c0d0ee761551582c9cd3727d444b7408aa82db7    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Wed, 23 Nov 2022 07:03:06 -0500    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Wed, 23 Nov 2022 07:03:06 -0500    

Click here for diff

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

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

YA attempt at taming worst-case behavior of get_actual_variable_range.

commit   : 2debceed2947029b7368d091be4442eccc798e4f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 22 Nov 2022 14:40:20 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 22 Nov 2022 14:40:20 -0500    

Click here for diff

We've made multiple attempts at preventing get_actual_variable_range  
from taking an unreasonable amount of time (3ca930fc3, fccebe421).  
But there's still an issue for the very first planning attempt after  
deletion of a large number of extremal-valued tuples.  While that  
planning attempt will set "killed" bits on the tuples it visits and  
thereby reduce effort for next time, there's still a lot of work it  
has to do to visit the heap and then set those bits.  It's (usually?)  
not worth it to do that much work at plan time to have a slightly  
better estimate, especially in a context like this where the table  
contents are known to be mutating rapidly.  
  
Therefore, let's bound the amount of work to be done by giving up  
after we've visited 100 heap pages.  Giving up just means we'll  
fall back on the extremal value recorded in pg_statistic, so it  
shouldn't mean that planner estimates suddenly become worthless.  
  
Note that this means we'll still gradually whittle down the problem  
by setting a few more index "killed" bits in each planning attempt;  
so eventually we'll reach a good state (barring further deletions),  
even in the absence of VACUUM.  
  
Simon Riggs, per a complaint from Jakub Wartak (with cosmetic  
adjustments by me).  Back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/CAKZiRmznOwi0oaV=4PHOCM4ygcH4MgSvt8=5cu_vNCfc8FSUug@mail.gmail.com  

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

Prevent port collisions between concurrent TAP tests

commit   : 153e21567750d37b031123d3bbf14f9e2434f4b2    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Tue, 22 Nov 2022 10:30:42 -0500    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Tue, 22 Nov 2022 10:30:42 -0500    

Click here for diff

Currently there is a race condition where if concurrent TAP tests both  
test that they can open a port they will assume that it is free and use  
it, causing one of them to fail. To prevent this we record a reservation  
using an exclusive lock, and any TAP test that discovers a reservation  
checks to see if the reserving process is still alive, and looks for  
another free port if it is.  
  
Ports are reserved in a directory set by the environment setting  
PG_TEST_PORT_DIR, or if that doesn't exist a subdirectory of the top  
build directory as set by Makefile.global, or its own  
tmp_check directory.  
  
The prove_check recipe in Makefile.global.in is extended to export  
top_builddir to the TAP tests. This was already exported by the  
prove_installcheck recipes.  
  
Per complaint from Andres Freund  
  
Backpatched from 9b4eafcaf4 to all live branches  
  
Discussion: https://postgr.es/m/20221002164931.d57hlutrcz4d2zi7@awork3.anarazel.de  

M src/Makefile.global.in
M src/test/perl/PostgreSQL/Test/Cluster.pm

Remove useless MERGE test

commit   : 1118a8d2c4f5b6dccf1845c73403d036df679648    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 22 Nov 2022 11:26:47 +0100    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 22 Nov 2022 11:26:47 +0100    

Click here for diff

This was trying to exercise an ERROR we don't actually have.  
  
Backpatch to 15.  
  
Reported by Teja Mupparti <Tejeswar.Mupparti@microsoft.com>  
Discussion: https://postgr.es/m/SN6PR2101MB1040BDAF740EA4389484E92BF0079@SN6PR2101MB1040.namprd21.prod.outlook.com  

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

Ignore invalidated slots while computing oldest catalog Xmin

commit   : 1ad033df16df8d9f9e9f597ca31915266dfbdfb9    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 22 Nov 2022 10:56:07 +0100    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 22 Nov 2022 10:56:07 +0100    

Click here for diff

Once a logical slot has acquired a catalog_xmin, it doesn't let go of  
it, even when invalidated by exceeding the max_slot_wal_keep_size, which  
means that dead catalog tuples are not removed by vacuum anymore since  
the point is invalidated, until the slot is dropped.  This could be  
catastrophic if catalog churn is high.  
  
Change the computation of Xmin to ignore invalidated slots,  
to prevent dead rows from accumulating.  
  
Backpatch to 13, where slot invalidation appeared.  
  
Author: Sirisha Chamarthi <sirichamarthi22@gmail.com>  
Reviewed-by: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>  
Discussion: https://postgr.es/m/CAKrAKeUEDeqquN9vwzNeG-CN8wuVsfRYbeOUV9qKO_RHok=j+g@mail.gmail.com  

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

commit   : 4f997ad06255a2e2cb23c9ba1c30bf42ceb8fbb5    
  
author   : Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Mon, 21 Nov 2022 23:25:48 +0100    
  
committer: Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Mon, 21 Nov 2022 23:25:48 +0100    

Click here for diff

The Hunspell project moved from Sourceforge to Github sometime  
in 2016, so update our links to match the new URL.  Backpatch  
the doc changes to all supported versions.  
  
Discussion: https://postgr.es/m/DC9A662A-360D-4125-A453-5A6CB9C6C4B4@yesql.se  
Backpatch-through: v11  

M doc/src/sgml/textsearch.sgml

Add comments and a missing CHECK_FOR_INTERRUPTS in ts_headline.

commit   : 0353db996e37c6b923863ee648f4d2f153bf619d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 21 Nov 2022 17:07:07 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 21 Nov 2022 17:07:07 -0500    

Click here for diff

I just spent an annoying amount of time reverse-engineering the  
100%-undocumented API between ts_headline and the text search  
parser's prsheadline function.  Add some commentary about that  
while it's fresh in mind.  Also remove some unused macros in  
wparser_def.c.  
  
While at it, I noticed that when commit 78e73e875 added a  
CHECK_FOR_INTERRUPTS call in TS_execute_recurse, it missed  
doing so in the parallel function TS_phrase_execute, which  
surely needs one just as much.  
  
Back-patch because of the missing CHECK_FOR_INTERRUPTS.  
Might as well back-patch the rest of this too.  

M src/backend/tsearch/ts_parse.c
M src/backend/tsearch/wparser_def.c
M src/backend/utils/adt/tsvector_op.c
M src/include/tsearch/ts_public.h

Mark pageinspect's disk-accessing functions as parallel restricted.

commit   : b8988cf1d0a74f2e394278e0d88c2c133ee252fb    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 21 Nov 2022 15:37:10 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 21 Nov 2022 15:37:10 -0500    

Click here for diff

These functions have been marked parallel safe, but the buildfarm's  
response to commit e2933a6e1 exposed the flaw in that thinking:  
if you try to use them on a temporary table, and they run inside  
a parallel worker, they'll fail with "cannot access temporary tables  
during a parallel operation".  
  
Fix that by marking them parallel restricted instead.  Maybe someday  
we'll have a better answer and can reverse this decision.  
  
Back-patch to v15.  To go back further, we'd have to devise variant  
versions of pre-1.10 pageinspect versions.  Given the lack of field  
complaints, it doesn't seem worth the trouble.  We'll just deem  
this case unsupported pre-v15.  (If anyone does complain, it might  
be good enough to update the markings manually in their DBs.)  
  
Discussion: https://postgr.es/m/E1ox94a-000EHu-VH@gemulon.postgresql.org  

M contrib/pageinspect/Makefile
A contrib/pageinspect/pageinspect–1.10–1.11.sql
M contrib/pageinspect/pageinspect.control

Prevent instability in contrib/pageinspect's regression test.

commit   : ff9d27ee2b8bbf15ef974732671df9df662f0cf9    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 21 Nov 2022 10:50:50 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 21 Nov 2022 10:50:50 -0500    

Click here for diff

pageinspect has occasionally failed on slow buildfarm members,  
with symptoms indicating that the expected effects of VACUUM  
FREEZE didn't happen.  This is presumably because a background  
transaction such as auto-analyze was holding back global xmin.  
  
We can work around that by using a temp table in the test.  
Since commit a7212be8b, that will use an up-to-date cutoff xmin  
regardless of other processes.  And pageinspect itself shouldn't  
really care whether the table is temp.  
  
Back-patch to v14.  There would be no point in older branches  
without back-patching a7212be8b, which seems like more trouble  
than the problem is worth.  
  
Discussion: https://postgr.es/m/2892135.1668976646@sss.pgh.pa.us  

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

commit   : a0d35ebcc570265405a293e509dccbdf0fd5ee45    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Wed, 16 Nov 2022 20:00:59 -0800    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Wed, 16 Nov 2022 20:00:59 -0800    

Click here for diff

ProcSleep() used a PGPROC* variable to point to PROC_QUEUE->links.next,  
because that does "the right thing" with SHMQueueInsertBefore(). While that  
largely works, it's certainly not correct and unnecessary - we can just use  
SHM_QUEUE* to point to the insertion point.  
  
Noticed when testing a 32bit of postgres with undefined behavior  
sanitizer. UBSan noticed that sometimes the supposed PGPROC wasn't  
sufficiently aligned (required since 46d6e5f5679, ensured indirectly, via  
ShmemAllocRaw() guaranteeing cacheline alignment).  
  
For now fix this by using a SHM_QUEUE* for the insertion point. Subsequently  
we should replace all the use of PROC_QUEUE and SHM_QUEUE with ilist.h, but  
that's a larger change that we don't want to backpatch.  
  
Backpatch to all supported versions - it's useful to be able to run postgres  
under UBSan.  
  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/20221117014230.op5kmgypdv2dtqsf@awork3.anarazel.de  
Backpatch: 11-  

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

Disable debug_discard_caches in test_oat_hooks test.

commit   : ad0867314daa8181031071f316f4c85e87755718    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 19 Nov 2022 13:42:53 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 19 Nov 2022 13:42:53 -0500    

Click here for diff

The test output varies when debug_discard_caches is enabled,  
because that causes extra executions of recomputeNamespacePath.  
Maybe putting a hook in that was a bad idea, but as a stopgap,  
just turn off debug_discard_caches in this test.  
  
Per buildfarm (now that we have debug_discard_caches coverage  
again).  Back-patch to v15 where this module was added.  
  
Discussion: https://postgr.es/m/2267406.1668804934@sss.pgh.pa.us  

M src/test/modules/test_oat_hooks/expected/test_oat_hooks.out
M src/test/modules/test_oat_hooks/sql/test_oat_hooks.sql

Doc: sync src/tutorial/basics.source with SGML documentation.

commit   : 8e3f104440eeaa407479f0a9287acea483a5108b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 19 Nov 2022 13:09:14 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 19 Nov 2022 13:09:14 -0500    

Click here for diff

basics.source is supposed to be pretty closely in step with  
the examples in chapter 2 of the tutorial, but I forgot to  
update it in commit f05a5e000.  Fix that, and adjust a couple  
of other discrepancies that had crept in over time.  
  
(I notice that advanced.source is nowhere near being in sync  
with chapter 3, but I lack the ambition to do something  
about that right now.)  

M src/tutorial/basics.source

Fix version comparison in Version.pm

commit   : df4e93bea4f9370c14f01d27e6d36cbe7afaac72    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 18 Nov 2022 08:38:26 -0500    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 18 Nov 2022 08:38:26 -0500    

Click here for diff

Version strings with unequal numbers of parts were being compared  
incorrectly. We cure this by treating a missing part in the shorter  
version as 0.  
  
per complaint from Jehan-Guillaume de Rorthais, but the fix is mine, not  
his.  
  
Discussion: https://postgr.es/m/20220628225325.53d97b8d@karst  
  
Backpatch to release 14 where this code was introduced.  

M src/test/perl/PostgreSQL/Version.pm

Fix MERGE tuple count with DO NOTHING

commit   : 3d45edcef0e141f2a17a21d0411efa889f843b00    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 17 Nov 2022 18:56:11 +0100    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 17 Nov 2022 18:56:11 +0100    

Click here for diff

Reporting tuples for which nothing is done is useless and goes against  
the documented behavior, so don't do it.  
  
Backpatch to 15.  
  
Reported by: Luca Ferrari  
Discussion: https://postgr.es/m/CAKoxK+42MmACUh6s8XzASQKizbzrtOGA6G1UjzCP75NcXHsiNw@mail.gmail.com  

M src/backend/executor/nodeModifyTable.c

Account for IPC::Run::result() Windows behavior change.

commit   : 41afaa1ed4d40330a7f51f7b398064657b87831b    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Thu, 17 Nov 2022 07:35:06 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Thu, 17 Nov 2022 07:35:06 -0800    

Click here for diff

This restores compatibility with the not-yet-released successor of  
version 20220807.0.  Back-patch to 9.4, which introduced this code.  
  
Reviewed by Andrew Dunstan.  
  
Discussion: https://postgr.es/m/20221117061805.GA4020280@rfd.leadboat.com  

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

Fix outdated comment in ExecDelete

commit   : cefe182533f38406e032b573dcf506c8da2b0faf    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 17 Nov 2022 12:52:20 +0100    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 17 Nov 2022 12:52:20 +0100    

Click here for diff

This commend references a struct that disappeared before MERGE was  
merged ... and ExecDelete is not called by the committed MERGE anyway.  
Revert to the original wording.  
  
Backpatch to 15  

M src/backend/executor/nodeModifyTable.c

doc: Fix wording of MERGE actions in README

commit   : 1eaa48e998e20766d70ed80cf538f3871d1c562c    
  
author   : Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Thu, 17 Nov 2022 10:07:06 +0100    
  
committer: Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Thu, 17 Nov 2022 10:07:06 +0100    

Click here for diff

UPDATE was listed twice and DELETE was omitted, replace one UPDATE  
with DELETE instead.  
  
Backpatch through v15 where MERGE was added.  
  
Author: Myo Wai Thant <myo.waithant@fujitsu.com>  
Reviewed-by: Richard Guo <guofenglinux@gmail.com>  
Discussion: https://postgr.es/m/OSAPR01MB43247E46931E9E9CFC4AA0F29A079@OSAPR01MB4324.jpnprd01.prod.outlook.com  
Backpatch-through: 15  

M src/backend/executor/README

Fix cleanup lock acquisition in SPLIT_ALLOCATE_PAGE replay.

commit   : e49e191815b6a7fc801e03cf798fb83d3b7f2501    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Mon, 14 Nov 2022 10:32:47 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Mon, 14 Nov 2022 10:32:47 +0530    

Click here for diff

During XLOG_HASH_SPLIT_ALLOCATE_PAGE replay, we were checking for a  
cleanup lock on the new bucket page after acquiring an exclusive lock on  
it and raising a PANIC error on failure. However, it is quite possible  
that checkpointer can acquire the pin on the same page before acquiring a  
lock on it, and then the replay will lead to an error. So instead, directly  
acquire the cleanup lock on the new bucket page during  
XLOG_HASH_SPLIT_ALLOCATE_PAGE replay operation.  
  
Reported-by: Andres Freund  
Author: Robert Haas  
Reviewed-By: Amit Kapila, Andres Freund, Vignesh C  
Backpatch-through: 11  
Discussion: https://postgr.es/m/20220810022617.fvjkjiauaykwrbse@awork3.anarazel.de  

M src/backend/access/hash/hash_xlog.c
M src/backend/access/hash/hashpage.c

Doc: remove pg_prepared_statements.result_types from v15 docs.

commit   : f754e7600a9284b6de8eb78b6b64aa9b46dc80db    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 13 Nov 2022 10:42:03 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 13 Nov 2022 10:42:03 -0500    

Click here for diff

This column is new in v16, but it was listed in the v15 docs too  
via a back-patching fumble.  
  
Per report from Peter Gigowski; diagnosis by Julien Rouhaud.  
  
Discussion: https://postgr.es/m/CAM7cJ6XY_PAmx0kGn6U307EKZ+qXDFEBH27WP87-_ygetnBuxQ@mail.gmail.com  

M doc/src/sgml/system-views.sgml

Use installed postgresql.conf.sample for GUC sanity TAP test

commit   : 0086ee356fd9fd0ced2f21e6b31031cb28b4a64a    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Sun, 13 Nov 2022 09:07:53 -0500    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Sun, 13 Nov 2022 09:07:53 -0500    

Click here for diff

The current code looks for the sample file in the source directory, but  
it seems better to test against the installed sample file.  
  
Backpatch to release 15 where the test was introduced.  
  
Discussion: https://postgr.es/m/73eea68e-3b6f-5f63-6024-25ed26b52016@dunslane.net  
  
Reviewed by Tom Lane, Alvaro Herrera, Michael Paquier.  

M src/test/modules/test_misc/t/003_check_guc.pl

Make PostgreSQL::Test::Cluster::config_data more flexible

commit   : 7a387f513d6c583b1c3fe5e4e0ea2b8cb92c85da    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Sun, 13 Nov 2022 08:45:14 -0500    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Sun, 13 Nov 2022 08:45:14 -0500    

Click here for diff

Currently this only allows for one argument, which must be present, and  
always returns a single string. With this change the following now all  
work:  
  
  $all_config = $node->config_data;  
  %config_map = ($node->config_data);  
  $incdir = $node->config_data('--include-dir');  
  ($incdir, $sharedir) = $node->config_data(  
      qw(--include-dir --share-dir));  
  
Backpatch to release 15 where this was introduced.  
  
Discussion: https://postgr.es/m/73eea68e-3b6f-5f63-6024-25ed26b52016@dunslane.net  
  
Reviewed by Tom Lane, Alvaro Herrera, Michael Paquier.  

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

If wait_for_catchup fails under has_wal_read_bug, skip balance of test.

commit   : e5f94d42eb38f39af81f934d70c3969913f2862e    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sat, 12 Nov 2022 11:19:50 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sat, 12 Nov 2022 11:19:50 -0800    

Click here for diff

Test files should now ignore has_wal_read_bug() so long as  
wait_for_catchup() is their only known way of reaching the bug.  That's  
at least five files today, a number expected to grow over time.  This  
commit removes skip logic from three.  By doing so, systems having the  
bug regain the ability to catch other kinds of defects via those three  
tests.  The other two, 002_databases.pl and 031_recovery_conflict.pl,  
have been unprotected.  Back-patch to v15, where done_testing() first  
became our standard.  
  
Discussion: https://postgr.es/m/20221030031639.GA3082137@rfd.leadboat.com  

M contrib/bloom/t/001_wal.pl
M src/test/perl/PostgreSQL/Test/Cluster.pm
M src/test/recovery/t/027_stream_regress.pl
M src/test/recovery/t/032_relfilenode_reuse.pl

Fix theoretical torn page hazard.

commit   : 7bf713dd2d0739fbcd4103971ed69c17ebe677ea    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Thu, 10 Nov 2022 14:46:30 -0800    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Thu, 10 Nov 2022 14:46:30 -0800    

Click here for diff

The original report was concerned with a possible inconsistency  
between the heap and the visibility map, which I was unable to  
confirm. The concern has been retracted.  
  
However, there did seem to be a torn page hazard when using  
checksums. By not setting the heap page LSN during redo, the  
protections of minRecoveryPoint were bypassed. Fixed, along with a  
misleading comment.  
  
It may have been impossible to hit this problem in practice, because  
it would require a page tear between the checksum and the flags, so I  
am marking this as a theoretical risk. But, as discussed, it did  
violate expectations about the page LSN, so it may have other  
consequences.  
  
Backpatch to all supported versions.  
  
Reported-by: Konstantin Knizhnik  
Reviewed-by: Konstantin Knizhnik  
Discussion: https://postgr.es/m/fed17dac-8cb8-4f5b-d462-1bb4908c029e@garret.ru  
Backpatch-through: 11  

M src/backend/access/heap/heapam.c

Fix alter_table.sql test case to test what it claims to.

commit   : 9c1a4fc891646110fe9b306fe4103f052504d6d9    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 10 Nov 2022 17:24:26 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 10 Nov 2022 17:24:26 -0500    

Click here for diff

The stanza "SET STORAGE may need to add a TOAST table" does not  
test what it's supposed to, and hasn't done so since we added  
the ability to store constant column default values as metadata.  
We need to use a non-constant default to get the expected table  
rewrite to actually happen.  
  
Fix that, and add the missing checks that would have exposed the  
problem to begin with.  
  
Noted while reviewing a patch that made changes in this test case.  
Back-patch to v11 where the problem came in.  

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

Re-allow building on Microsoft Visual Studio 2013.

commit   : 576506303c2a1b38383dc905db5f6e11b13ce872    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 10 Nov 2022 10:23:49 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 10 Nov 2022 10:23:49 -0500    

Click here for diff

In commit 450ee7012 I supposed that all platforms we now care about have  
snprintf(), since that's required by C99.  Turns out that Microsoft did  
not get around to adding that until VS2015.  We've dropped support for  
VS2013 as of HEAD (cf 6203583b7), but not in the back branches, so add  
a hack for this in the back branches only.  
  
There's no easy shortcut to an exact emulation of standard snprintf  
in VS2013, but fortunately we don't need one: this code was just fine  
with using sprintf before 450ee7012, so we can make it do so again  
on that platform (and any others where the problem might crop up).  
  
Per bug #17681 from Daisuke Higuchi.  Back-patch to v12, like the  
previous patch.  
  
Discussion: https://postgr.es/m/17681-485ba2ec13e7f392@postgresql.org  

M src/port/snprintf.c

Fix comments atop ReorderBufferAddInvalidations.

commit   : daadb42e92ed903642bce314e9c7a0325ee6b1b2    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Thu, 10 Nov 2022 17:08:27 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Thu, 10 Nov 2022 17:08:27 +0530    

Click here for diff

The comments atop seem to indicate that we always accumulate invalidation  
messages in a top-level transaction which is neither required nor matches  
with the code.  
  
Author: Amit Kapila  
Reviewd by: Masahiko Sawada  
Backpatch-through: 14, where it was introduced in commit c55040ccd0  
Discussion: https://postgr.es/m/CAA4eK1LxGgnUroPz8STb6OfjVU1yaHoSA+T63URwmGCLdMJ0LA@mail.gmail.com  

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

Fix comment of SimpleLruInit() in slru.c

commit   : 5962c8cbe5a6f02aa638279822cc59bd364e2081    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 10 Nov 2022 16:33:52 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 10 Nov 2022 16:33:52 +0900    

Click here for diff

sync_handler was not mentioned in the comment block of the function.  
  
Oversight in dee663f.  
  
Author: Aleksander Alekseev  
Discussion: https://postgr.es/m/CAJ7c6TPUd9BwNY47TtMxaijLHSbyHNdhu=kvbGnvO_bi+oC6_Q@mail.gmail.com  
Backpatch-through: 14  

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

Apply a better fix to mdunlinkfork().

commit   : 7b6610508d68f0c6191c01e824d90051295a39fc    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 9 Nov 2022 14:15:38 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 9 Nov 2022 14:15:38 -0500    

Click here for diff

Replace the stopgap fix I made in 0e758ae89 with a cleaner one.  
  
The real problem with 4ab5dae94 is that it contorted this function's  
logic substantially, by introducing a third code path that required  
different behavior in the function's main loop.  That seems quite  
unnecessary on closer inspection: the new IsBinaryUpgrade case can  
just share the behavior of the other immediate-unlink cases.  Hence,  
revert 4ab5dae94 and most of 0e758ae89 (keeping the latter's  
save/restore errno fix), and add IsBinaryUpgrade to the set of  
conditions tested to choose immediate unlink.  
  
Also fix some additional places with sloppy handling of errno,  
to ensure we have an invariant that we always continue processing  
after any non-ENOENT failure of do_truncate.  I doubt that that's  
fixing any bug of field importance, so I don't feel it necessary to  
back-patch; but we might as well get it right while we're here.  
  
Also improve the comments, which had drifted a bit from what the  
code actually does, and neglected to mention some important  
considerations.  
  
Back-patch to v15, not because this is fixing any bug but because  
it doesn't seem like a good idea for v15's mdunlinkfork logic to be  
significantly different from both v14 and v16.  
  
Discussion: https://postgr.es/m/3797575.1667924888@sss.pgh.pa.us  

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

Doc: add comments about PreventInTransactionBlock/IsInTransactionBlock.

commit   : e70cd16f2223d76d4f00453eb2cc067d992ed4f3    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 9 Nov 2022 11:08:52 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 9 Nov 2022 11:08:52 -0500    

Click here for diff

Add a little to the header comments for these functions to make it  
clearer what guarantees about commit behavior are provided to callers.  
(See commit f92944137 for context.)  
  
Although this is only a comment change, it's really documentation  
aimed at authors of extensions, so it seems appropriate to back-patch.  
  
Yugo Nagata and Tom Lane, per further discussion of bug #17434.  
  
Discussion: https://postgr.es/m/17434-d9f7a064ce2a88a3@postgresql.org  

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

Doc: improve tutorial section about grouped aggregates.

commit   : 362ba3e932c0f343a199b74f94ca7b22f4f8448d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 8 Nov 2022 18:25:03 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 8 Nov 2022 18:25:03 -0500    

Click here for diff

Commit fede15417 introduced FILTER by jamming it into the existing  
example introducing HAVING, which seems pedagogically poor to me;  
and it added no information about what the keyword actually does.  
Not to mention that the claimed output didn't match the sample  
data being used in this running example.  
  
Revert that and instead make an independent example using FILTER.  
To help drive home the point that it's a per-aggregate filter,  
we need to use two aggregates not just one; for consistency  
expand all the examples in this segment to do that.  
  
Also adjust the example using WHERE ... LIKE so that it'd produce  
nonempty output with this sample data, and show that output.  
  
Back-patch, as the previous patch was.  (Sadly, v10 is now out  
of scope.)  
  
Discussion: https://postgr.es/m/166794307526.652.9073408178177444190@wrigleys.postgresql.org  

M doc/src/sgml/query.sgml

Stamp 15.1.

commit   : c5dc80c1bc216f0e21a2f79f5e0415c2d4cfb35d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 7 Nov 2022 16:36:53 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 7 Nov 2022 16:36:53 -0500    

Click here for diff

M configure
M configure.ac

Translation updates

commit   : 0bc9872b1106fa5cdd488bc0ddafb270b2e7540a    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 7 Nov 2022 19:21:03 +0100    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 7 Nov 2022 19:21:03 +0100    

Click here for diff

Source-Git-URL: ssh://git@git.postgresql.org/pgtranslation/messages.git  
Source-Git-Hash: 0a578288026cfaae6b3d120b3ecf719aaa94dfdc  

M src/backend/po/es.po
M src/bin/pg_amcheck/nls.mk
A src/bin/pg_amcheck/po/it.po
M src/bin/pg_archivecleanup/nls.mk
A src/bin/pg_archivecleanup/po/it.po
M src/bin/pg_checksums/nls.mk
A src/bin/pg_checksums/po/it.po
M src/bin/pg_test_fsync/nls.mk
A src/bin/pg_test_fsync/po/it.po
M src/bin/pg_test_timing/nls.mk
A src/bin/pg_test_timing/po/it.po
M src/bin/pg_upgrade/nls.mk
A src/bin/pg_upgrade/po/it.po
M src/bin/pg_verifybackup/nls.mk
A src/bin/pg_verifybackup/po/it.po
M src/bin/pg_waldump/nls.mk
M src/bin/pg_waldump/po/es.po
A src/bin/pg_waldump/po/it.po

Last-minute updates for release notes.

commit   : b7f9c762a8e10a64866309b64b785a4496bcd194    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 7 Nov 2022 13:02:24 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 7 Nov 2022 13:02:24 -0500    

Click here for diff

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

Fix failure to remove non-first segments of temporary tables.

commit   : 5fe0ab42015ae8b084d959ac79cd7ee26de57b62    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 7 Nov 2022 11:36:45 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 7 Nov 2022 11:36:45 -0500    

Click here for diff

Commit 4ab5dae94 broke mdunlinkfork's logic for removing additional  
segments of a multi-gigabyte table, because it neglected to advance  
"segno" after unlinking the first segment, in the code path where it  
chooses to unlink that one immediately.  Then the main remove loop  
gets ENOENT at segment zero and figures it's done, so we never remove  
whatever additional segments might exist.  
  
The main problem here is with large temporary tables, but WAL replay  
of a drop of a large regular table would also fail to remove extra  
segments.  The third case where this path is taken is for non-main  
forks; but I doubt it matters for those since they probably never  
exceed 1GB.  
  
The simplest fix is just to increment segno after that unlink().  
(Probably this logic could do with a more thorough rethink, but not  
with mere hours to go before 15.1 wraps.)  
  
While here, also fix an incautious assumption that  
register_forget_request cannot change errno.  I don't think that  
that has any really bad consequences, as we'd end up trying to unlink  
the zero'th segment either way, but it greatly complicates reasoning  
about what could happen here.  Also make a couple of other cosmetic  
fixes.  
  
Per bug #17679 from Balazs Szilfai.  Back-patch into v15, as the  
faulty patch was.  
  
Discussion: https://postgr.es/m/17679-1095d04450cf6a6e@postgresql.org  

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

Translation updates

commit   : 7134af1149247d956d32c994fa00a844f2bdc796    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 7 Nov 2022 14:04:05 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 7 Nov 2022 14:04:05 +0100    

Click here for diff

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

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

Release notes for 15.1, 14.6, 13.9, 12.13, 11.18, 10.23.

commit   : ca3f0d44ac6a6794a89e59b1ff80613b12c792ba    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 6 Nov 2022 11:07:28 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 6 Nov 2022 11:07:28 -0500    

Click here for diff

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

First-draft release notes for 15.1.

commit   : bc62182f0afe6b01fec45b8d26df03fc9de4599a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 4 Nov 2022 12:46:02 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 4 Nov 2022 12:46:02 -0400    

Click here for diff

As usual, the release notes for other branches will be made by cutting  
these down, but put them up for community review first.  
  
Also as usual for a .1 release, there are some entries here that  
are not really relevant for v15 because they already appeared in 15.0.  
Those'll be removed later.  

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

Fix CREATE DATABASE so we can pg_upgrade DBs with OIDs above 2^31.

commit   : 2c6d43650d16d91a3e731d236315beffd98db729    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 4 Nov 2022 10:39:52 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 4 Nov 2022 10:39:52 -0400    

Click here for diff

Commit aa0105141 repeated one of the oldest mistakes in our book:  
thinking that OID is the same as int32.  It isn't of course, and  
unsurprisingly the first person who came along with a database  
OID above 2 billion broke it.  Repair.  
  
Per bug #17677 from Sergey Pankov.  Back-patch to v15.  
  
Discussion: https://postgr.es/m/17677-a99fa067d7ed71c9@postgresql.org  

M src/backend/commands/dbcommands.c
M src/backend/commands/define.c
M src/backend/parser/gram.y
M src/include/commands/defrem.h

Correct error message for row-level triggers with transition tables on partitioned tables.

commit   : 81173264440d7d3bd6479313b1d4611a2bfe8031    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Fri, 4 Nov 2022 19:15:01 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Fri, 4 Nov 2022 19:15:01 +0900    

Click here for diff

"Triggers on partitioned tables cannot have transition tables." is  
incorrect as we allow statement-level triggers on partitioned tables to  
have transition tables.  
  
This has been wrong since commit 86f575948; back-patch to v11 where that  
commit came in.  
  
Reviewed by Tom Lane.  
  
Discussion: https://postgr.es/m/CAPmGK17gk4vXLzz2iG%2BG4LWRWCoVyam70nZ3OuGm1hMJwDrhcg%40mail.gmail.com  

M src/backend/commands/trigger.c
M src/test/regress/expected/triggers.out

docs: Improve pg_settings_get_flags docs.

commit   : 387e059f8e9c506aba17d63e7220cad2f488f238    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 3 Nov 2022 19:53:35 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 3 Nov 2022 19:53:35 -0400    

Click here for diff

In the docs, the GUC flags that pg_settings_get_flags() reported were  
listed using <simplelist>. But the list was treated as separate lines  
in the existing function table and didn't look good. For better view,  
this commit separates the list from the table entry for  
pg_settings_get_flags() and adds the table for it at the bottom of  
the existing function table.  
  
Author: Fujii Masao  
Reviewed-by: Alvaro Herrera, Michael Paquier  
Discussion: https://postgr.es/m/f093edf9-6e5a-b119-ee50-6a2c97c79ee8@oss.nttdata.com  
  
Back-patch of f2d0c7f18 into v15.  
Discussion: https://postgr.es/m/20221103123320.GQ16921@telsasoft.com  

M doc/src/sgml/func.sgml

Create FKs properly when attaching table as partition

commit   : c301e1c0c09cfedce9eb469744384a6d15e50745    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 3 Nov 2022 20:40:21 +0100    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 3 Nov 2022 20:40:21 +0100    

Click here for diff

Commit f56f8f8da6af added some code in CloneFkReferencing that's way too  
lax about a Constraint node it manufactures, not initializing enough  
struct members -- initially_valid in particular was forgotten.  This  
causes some FKs in partitions added by ALTER TABLE ATTACH PARTITION to  
be marked as not validated.  Set initially_valid true, which fixes the  
bug.  
  
While at it, make the struct initialization more complete.  Very similar  
code was added in two other places by the same commit; make them all  
follow the same pattern for consistency, though no bugs are apparent  
there.  
  
This bug has never been reported: I only happened to notice while  
working on commit 614a406b4ff1.  The test case that was added there with  
the improper result is repaired.  
  
Backpatch to 12.  
  
Discussion: https://postgr.es/m/20221005105523.bhuhkdx4olajboof@alvherre.pgsql  

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

Avoid crash after function syntax error in a replication worker.

commit   : f2dc7f9e35a288d21dfdd74e56f8809862d02dd6    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 3 Nov 2022 12:01:57 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 3 Nov 2022 12:01:57 -0400    

Click here for diff

If a syntax error occurred in a SQL-language or PL/pgSQL-language  
CREATE FUNCTION or DO command executed in a logical replication worker,  
we'd suffer a null pointer dereference or assertion failure.  That  
seems like a rather contrived case, but nonetheless worth fixing.  
  
The cause is that function_parse_error_transpose assumes it must be  
executing within the context of a Portal, but logical/worker.c  
doesn't create a Portal since it's not running the standard executor.  
We can just back off the hard Assert check and make it fail gracefully  
if there's not an ActivePortal.  (I have a feeling that the aggressive  
check here was my fault originally, probably because I wasn't sure if  
the case would always hold and wanted to find out.  Well, now we know.)  
  
The hazard seems to exist in all branches that have logical replication,  
so back-patch to v10.  
  
Maxim Orlov, Anton Melnikov, Masahiko Sawada, Tom Lane  
  
Discussion: https://postgr.es/m/b570c367-ba38-95f3-f62d-5f59b9808226@inbox.ru  
Discussion: https://postgr.es/m/adf0452f-8c6b-7def-d35e-ab516c80088e@inbox.ru  

M src/backend/catalog/pg_proc.c

Add casts to simplehash.h to silence C++ warnings.

commit   : 725cd4d2e4819056993ce32336ea130473eb02a1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 3 Nov 2022 10:47:31 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 3 Nov 2022 10:47:31 -0400    

Click here for diff

Casting the result of palloc etc. to the intended type is more per  
project style anyway.  
  
(The fact that cpluspluscheck doesn't notice these problems is  
because it doesn't expand any macros, which seems like a troubling  
shortcoming.  Don't have a good idea about improving that.)  
  
Back-patch to v13, which is as far as the patch applies cleanly;  
doesn't seem worth working harder.  
  
David Geier  
  
Discussion: https://postgr.es/m/aa5d88a3-71f4-3455-11cf-82de0372c941@gmail.com  

M src/include/lib/simplehash.h

Allow use of __sync_lock_test_and_set for spinlocks on any machine.

commit   : a5737e765d85c170a035ee5eedf5d4cd8e9d5128    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 2 Nov 2022 17:37:26 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 2 Nov 2022 17:37:26 -0400    

Click here for diff

If we have no special-case code in s_lock.h for the current platform,  
but the compiler has __sync_lock_test_and_set, use that instead of  
failing.  It's unlikely that anybody's __sync_lock_test_and_set  
would be so awful as to be worse than our semaphore-based fallback,  
but if it is, they can (continue to) use --disable-spinlocks.  
  
This allows removal of the RISC-V special case installed by commit  
c32fcac56, which generated exactly the same code but only on that  
platform.  Usefully, the RISC-V buildfarm animals should now test  
at least the int variant of this patch.  
  
I've manually tested both variants on ARM by dint of removing the  
ARM-specific stanza.  We don't want to drop that, because it already  
has some special knowledge and is likely to grow more over time.  
Likewise, this is not meant to preclude installing special cases  
for other arches if that proves worthwhile.  
  
Per discussion of a request to install the same code for loongarch64.  
Like the previous patch, we might as well back-patch to supported  
branches.  
  
Discussion: https://postgr.es/m/761ac43d44b84d679ba803c2bd947cc0@HSMAILSVR04.hs.handsome.com.cn  

M src/include/storage/s_lock.h

Defend against unsupported partition relkind in logical replication worker.

commit   : 414d29a826f3a63fabae5e9ac2eb5b17f03787d8    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 2 Nov 2022 12:29:39 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 2 Nov 2022 12:29:39 -0400    

Click here for diff

Since partitions can be foreign tables not only plain tables, but  
logical replication only supports plain tables, we'd better check the  
relkind of a partition after we find it.  (There was some discussion  
of checking this when adding a partitioned table to a subscription;  
but that would be inadequate since the troublesome partition could be  
added later.)  Without this, the situation leads to a segfault or  
assertion failure.  
  
In passing, add a separate variable for the target Relation of  
a cross-partition UPDATE; reusing partrel seemed mighty confusing  
and error-prone.  
  
Shi Yu and Tom Lane, per report from Ilya Gladyshev.  Back-patch  
to v13 where logical replication into partitioned tables became  
a thing.  
  
Discussion: https://postgr.es/m/6b93e3748ba43298694f376ca8797279d7945e29.camel@gmail.com  

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

pg_dump: fix failure to dump comments on constraints in some cases.

commit   : 0eede9625659d47a9b3fb1292f71c8b16667326b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 2 Nov 2022 11:30:04 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 2 Nov 2022 11:30:04 -0400    

Click here for diff

Thinko in commit 5209c0ba0: I checked the wrong object's  
DUMP_COMPONENT_COMMENT bit in two places.  
  
Per bug #17675 from Franz-Josef Färber.  
  
Discussion: https://postgr.es/m/17675-c69c001e06390867@postgresql.org  

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

Fix copy-and-pasteo in comment.

commit   : d5e1748f02fb54cff276e7714be474f4e9a9de72    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Wed, 2 Nov 2022 18:15:01 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Wed, 2 Nov 2022 18:15:01 +0900    

Click here for diff

M src/backend/executor/nodeModifyTable.c

commit   : 468a9f37fb69065760054c83d2ee9aa01910a495    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 2 Nov 2022 11:56:28 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 2 Nov 2022 11:56:28 +0900    

Click here for diff

pg_ident_file_mappings.line_number was described as a line number in  
pg_ident.conf for a "rule" number, but this should refer to a "map".  
The same inconsistent term was used in the main paragraph describing the  
view.  
  
Extracted from a patch by the same author.  Issue introduced by  
a2c8499 where this view has been added.  
  
Author: Julien Rouhaud  
Discussion: https://postgr.es/m/20221026031948.cbrnzgy5e7glsq2d@jrouhaud  
Backpatch-through: 15  

M doc/src/sgml/system-views.sgml

Fix outdated comment in tuplesort.h

commit   : 23f44276123031d21cffeb699d9863149e1c734f    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Wed, 2 Nov 2022 15:29:49 +1300    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Wed, 2 Nov 2022 15:29:49 +1300    

Click here for diff

This was outdated by 77bae396d.  
  
Backpatch-through: 15, where 77bae396d was added  

M src/include/utils/tuplesort.h

Update time zone data files to tzdata release 2022f.

commit   : c3d16eb3d5f1ee843017a059fe3e272061bb9875    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 1 Nov 2022 17:08:28 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 1 Nov 2022 17:08:28 -0400    

Click here for diff

DST law changes in Chile, Fiji, Iran, Jordan, Mexico, Palestine,  
and Syria.  Historical corrections for Chile, Crimea, Iran, and  
Mexico.  
  
Also, the Europe/Kiev zone has been renamed to Europe/Kyiv  
(retaining the old name as a link).  
  
The following zones have been merged into nearby, more-populous zones  
whose clocks have agreed since 1970: Antarctica/Vostok, Asia/Brunei,  
Asia/Kuala_Lumpur, Atlantic/Reykjavik, Europe/Amsterdam,  
Europe/Copenhagen, Europe/Luxembourg, Europe/Monaco, Europe/Oslo,  
Europe/Stockholm, Indian/Christmas, Indian/Cocos, Indian/Kerguelen,  
Indian/Mahe, Indian/Reunion, Pacific/Chuuk, Pacific/Funafuti,  
Pacific/Majuro, Pacific/Pohnpei, Pacific/Wake and Pacific/Wallis.  
(This indirectly affects zones that were already links to one of  
these: Arctic/Longyearbyen, Atlantic/Jan_Mayen, Iceland,  
Pacific/Ponape, Pacific/Truk, and Pacific/Yap.)  America/Nipigon,  
America/Rainy_River, America/Thunder_Bay, Europe/Uzhgorod, and  
Europe/Zaporozhye were also merged into nearby zones after discovering  
that their claimed post-1970 differences from those zones seem to have  
been errors.  
  
While the IANA crew have been working on merging zones that have no  
post-1970 differences for some time, this batch of changes affects  
some zones that are significantly more populous than those merged  
in the past, notably parts of Europe.  The loss of pre-1970 timezone  
history for those zones may be troublesome for applications  
expecting consistency of timestamptz display.  As an example, the  
stored value '1944-06-01 12:00 UTC' would previously display as  
'1944-06-01 13:00:00+01' if the Europe/Stockholm zone is selected,  
but now it will read out as '1944-06-01 14:00:00+02'.  
  
There exists a "packrat" option that will build the timezone data  
files with this old data preserved, but the problem is that it also  
resurrects a bunch of other, far less well-attested data; so much so  
that actually more zones' contents change from 2022a with that option  
than without it.  I have chosen not to do that here, for that reason  
and because it appears that no major OS distributions are using the  
"packrat" option, so that doing so would cause Postgres' behavior  
to diverge significantly depending on whether it was built with  
--with-system-tzdata.  However, for anyone for whom these changes pose  
significant problems, there is a solution: build a set of timezone  
files with the "packrat" option and use those with Postgres.  

M src/timezone/data/tzdata.zi

Fix planner failure with extended statistics on partitioned tables.

commit   : 1f1865e9083625239769c26f68b9c2861b8d4b1c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 1 Nov 2022 14:34:44 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 1 Nov 2022 14:34:44 -0400    

Click here for diff

Some cases would result in "cache lookup failed for statistics object",  
due to trying to fetch inherited statistics when only non-inherited  
ones are available or vice versa.  
  
Richard Guo and Justin Pryzby  
  
Discussion: https://postgr.es/m/20221030170520.GM16921@telsasoft.com  

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

pg_stat_statements: fetch stmt location/length before it disappears.

commit   : 8b0a5cf3fe48a929b26e6e305f0765cf383d2ade    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 1 Nov 2022 12:48:01 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 1 Nov 2022 12:48:01 -0400    

Click here for diff

When executing a utility statement, we must fetch everything  
we need out of the PlannedStmt data structure before calling  
standard_ProcessUtility.  In certain cases (possibly only ROLLBACK  
in extended query protocol), that data structure will get freed  
during command execution.  The situation is probably often harmless  
in production builds, but in debug builds we intentionally overwrite  
the freed memory with garbage, leading to picking up garbage values  
of statement location and length, typically causing an assertion  
failure later in pg_stat_statements.  In non-debug builds, if  
something did go wrong it would likely lead to storing garbage  
for the query string.  
  
Report and fix by zhaoqigui (with cosmetic adjustments by me).  
It's an old problem, so back-patch to all supported versions.  
  
Discussion: https://postgr.es/m/17663-a344fd0675f92128@postgresql.org  
Discussion: https://postgr.es/m/1667307420050.56657@hundsun.com  

M contrib/pg_stat_statements/pg_stat_statements.c

Remove incorrect name from release notes

commit   : d2354b6eecccb78fe697a270bd97298cbc63f477    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 1 Nov 2022 14:17:36 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 1 Nov 2022 14:17:36 +0100    

Click here for diff

This name was incorrect in the underlying commit message.  (The  
correct name is already listed.)  
  
Reported-by: Mark Wong  

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

Under has_wal_read_bug, skip recovery/t/032_relfilenode_reuse.pl.

commit   : 3395cc1dbae5f5713373e59510425138da8cecb4    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sat, 29 Oct 2022 10:42:16 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sat, 29 Oct 2022 10:42:16 -0700    

Click here for diff

Per buildfarm member kittiwake.  Back-patch to v15, where this test  
first appeared.  
  
Discussion: https://postgr.es/m/20220116210241.GC756210@rfd.leadboat.com  

M src/test/recovery/t/032_relfilenode_reuse.pl

Fix ordering issue with WAL operations in GIN fast insert path

commit   : ca4070f2b4b1ed62e3d333a51a2f412b1c841ba4    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 26 Oct 2022 09:41:13 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 26 Oct 2022 09:41:13 +0900    

Click here for diff

Contrary to what is documented in src/backend/access/transam/README,  
ginHeapTupleFastInsert() had a few ordering issues with the way it does  
its WAL operations when inserting items in its fast path.  
  
First, when using a separate list, XLogBeginInsert() was being always  
called before START_CRIT_SECTION(), and in this case a second thing was  
wrong when merging lists, as an exclusive lock was taken on the tail  
page *before* calling XLogBeginInsert().  Finally, when inserting items  
into a tail page, the order of XLogBeginInsert() and  
START_CRIT_SECTION() was reversed.  This commit addresses all these  
issues by moving the calls of XLogBeginInsert() after all the pages  
logged are locked and pinned, within a critical section.  
  
This has been applied first only on HEAD as of 56b6625, but as per  
discussion with Tom Lane and Álvaro Herrera, a backpatch is preferred to  
keep all the branches consistent and to respect the transam's README  
where we can.  
  
Author:  Matthias van de Meent, Zhang Mingli  
Discussion: https://postgr.es/m/CAEze2WhL8uLMqynnnCu1LAPwxD5RKEo0nHV+eXGg_N6ELU88HQ@mail.gmail.com  
Backpatch-through: 10  

M src/backend/access/gin/ginfast.c

doc: Fix type of cursor_position in jsonlog table

commit   : f975df7203607c51f2f6284b54e7394a33f575ed    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 25 Oct 2022 09:29:54 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 25 Oct 2022 09:29:54 +0900    

Click here for diff

This entry was listed as a "string", but it is a "number.  The other  
fields are correctly described, on a second look.  
  
Reported-by: Nuko Yokohama  
Author: Tatsuo Ishii  
Discussion: https://postgr.es/m/CAF3Gu1awoVoDP5d0_eN=cR=QkGVwH+OtFvwJkkc5cB_ZMWjyeA@mail.gmail.com  
Backpatch-through: 15  

M doc/src/sgml/config.sgml

Update some comments that should've covered MERGE

commit   : fb2a83b2b750a32ddfd107a75a3bc173f4f0a81f    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 24 Oct 2022 12:52:43 +0200    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 24 Oct 2022 12:52:43 +0200    

Click here for diff

Oversight in 7103ebb7aae8.  Backpatch to 15.  
  
Author: Richard Guo <guofenglinux@gmail.com>  
Discussion: https://postgr.es/m/CAMbWs48gnDjZXq3-b56dVpQCNUJ5hD9kdtWN4QFwKCEapspNsA@mail.gmail.com  

M src/backend/optimizer/path/indxpath.c
M src/backend/optimizer/plan/planmain.c
M src/backend/optimizer/plan/planner.c
M src/backend/optimizer/util/appendinfo.c
M src/backend/optimizer/util/inherit.c
M src/backend/optimizer/util/pathnode.c
M src/backend/optimizer/util/relnode.c
M src/backend/parser/parse_clause.c
M src/backend/parser/parse_expr.c
M src/backend/parser/parse_merge.c
M src/include/nodes/parsenodes.h
M src/include/nodes/pathnodes.h
M src/include/nodes/plannodes.h
M src/include/nodes/primnodes.h

psql: Fix exit status when query is canceled

commit   : 4a6de748d3429cfa081942c46411d62341867bfd    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 22 Oct 2022 09:41:38 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 22 Oct 2022 09:41:38 +0200    

Click here for diff

Because of a small thinko in 7844c9918a43b494adde3575891d217a37062378,  
psql -c would exit successfully when a query is canceled.  Fix this so  
that it exits with a nonzero status, just like for all other errors.  

M src/bin/psql/common.c

pg_basebackup: Fix cross-platform tablespace relocation.

commit   : 5c013e620c911d728f653785843eb3c272c43538    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 21 Oct 2022 08:21:55 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 21 Oct 2022 08:21:55 -0400    

Click here for diff

Specifically, when pg_basebackup is invoked with -Tx=y, don't error  
out if x could plausibly be an absolute path either on Windows or on  
non-Windows systems. We don't know whether the remote system is  
running the same OS as the local system, so it's not appropriate to  
assume that our local rule about absolute pathnames is the same as  
the rule on the remote system.  
  
Patch by me, reviewed by Tom Lane, Andrew Dunstan, and  
Davinder Singh.  
  
Discussion: http://postgr.es/m/CA+TgmoY+jC3YiskomvYKDPK3FbrmsDU7_8+wMHt02HOdJeRb0g@mail.gmail.com  

M src/bin/pg_basebackup/pg_basebackup.c
M src/include/port.h

Add CHECK_FOR_INTERRUPTS while restoring changes during decoding.

commit   : 10eaa975018f7ea88f5d0af5af40b2d3749b3ca8    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Fri, 21 Oct 2022 12:43:28 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Fri, 21 Oct 2022 12:43:28 +0530    

Click here for diff

Previously in commit 42681dffaf, we added CFI during decoding changes but  
missed another similar case that can happen while restoring changes  
spilled to disk back into memory in a loop.  
  
Reported-by: Robert Haas  
Author: Amit Kapila  
Backpatch-through: 10  
Discussion: https://postgr.es/m/CA+TgmoaLObg0QbstbC8ykDwOdD1bDkr4AbPpB=0DPgA2JW0mFg@mail.gmail.com  

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

Fix executing invalidation messages generated by subtransactions during decoding.

commit   : 343afa9671060c3d6482d1252207a64cc5ddd23d    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Fri, 21 Oct 2022 10:03:35 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Fri, 21 Oct 2022 10:03:35 +0530    

Click here for diff

This problem has been introduced by commit 272248a0c1 where we started  
assigning the subtransactions to the top-level transaction when we mark  
both the top-level transaction and its subtransactions as containing  
catalog changes. After we assign subtransactions to the top-level  
transaction, we were not allowed to execute any invalidations associated  
with it when we decide to skip the transaction.  
  
The reason to assign the subtransactions to the top-level transaction was  
to avoid the assertion failure in AssertTXNLsnOrder() as they have the  
same LSN when we sometimes start accumulating transaction changes for  
partial transactions after the restart. Now that with commit 64ff0fe4e8,  
we skip this assertion check until we reach the LSN at which we start  
decoding the contents of the transaction, so, there is no reason for such  
an assignment anymore.  
  
The assignment change was introduced in 15 and prior versions but this bug  
doesn't exist in branches prior to 14 since we don't add invalidation  
messages to subtransactions. We decided to backpatch through 11 for  
consistency but not for 10 since its final release is near.  
  
Reported-by: Kuroda Hayato  
Author: Masahiko Sawada  
Reviewed-by: Amit Kapila  
Backpatch-through: 11  
Discussion: https://postgr.es/m/TYAPR01MB58660803BCAA7849C8584AA4F57E9%40TYAPR01MB5866.jpnprd01.prod.outlook.com  
Discussion: https://postgr.es/m/a89b46b6-0239-2fd5-71a9-b19b1f7a7145%40enterprisedb.com  

M contrib/test_decoding/expected/catalog_change_snapshot.out
M contrib/test_decoding/specs/catalog_change_snapshot.spec
M src/backend/replication/logical/snapbuild.c

Doc: fix outdated wording about parallel seq scans

commit   : 536a3b87037b7eac1e9e2780738a0056d89634f6    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Fri, 21 Oct 2022 09:29:56 +1300    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Fri, 21 Oct 2022 09:29:56 +1300    

Click here for diff

56788d215 adjusted the parallel seq scan code so that instead of handing  
out a single block at a time to parallel workers, it now hands out ranges  
of blocks.  
  
Here we update the documentation which still claimed that workers received  
just 1 block at a time.  
  
Reported-by: Zhang Mingli  
Discussion: https://postgr.es/m/17c99615-2c3b-4e4e-9d0b-424a66a7bccd@Spark  
Backpatch-through: 14, where 56788d215 was added.  

M doc/src/sgml/parallel.sgml

Fix assertion failures while processing NEW_CID record in logical decoding.

commit   : 64ff0fe4e8c47fc390bb645d48ba38675494a2b4    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Thu, 20 Oct 2022 09:43:59 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Thu, 20 Oct 2022 09:43:59 +0530    

Click here for diff

When the logical decoding restarts from NEW_CID, since there is no  
association between the top transaction and its subtransaction, both are  
created as top transactions and have the same LSN. This caused the  
assertion failure in AssertTXNLsnOrder().  
  
This patch skips the assertion check until we reach the LSN at which we  
start decoding the contents of the transaction, specifically  
start_decoding_at LSN in SnapBuild. This is okay because we don't  
guarantee to make the association between top transaction and  
subtransaction until we try to decode the actual contents of transaction.  
The ordering of the records prior to the start_decoding_at LSN should have  
been checked before the restart.  
  
The other assertion failure is due to the reason that we forgot to track  
that we have considered top-level transaction id in the list of catalog  
changing transactions that were committed when one of its subtransactions  
is marked as containing catalog change.  
  
Reported-by: Tomas Vondra, Osumi Takamichi  
Author: Masahiko Sawada, Kuroda Hayato  
Reviewed-by: Amit Kapila, Dilip Kumar, Kuroda Hayato, Kyotaro Horiguchi, Masahiko Sawada  
Backpatch-through: 10  
Discussion: https://postgr.es/m/a89b46b6-0239-2fd5-71a9-b19b1f7a7145%40enterprisedb.com  
Discussion: https://postgr.es/m/TYCPR01MB83733C6CEAE47D0280814D5AED7A9%40TYCPR01MB8373.jpnprd01.prod.outlook.com  

M contrib/test_decoding/expected/catalog_change_snapshot.out
M contrib/test_decoding/specs/catalog_change_snapshot.spec
M src/backend/replication/logical/reorderbuffer.c
M src/backend/replication/logical/snapbuild.c

Track LLVM 15 changes.

commit   : af64846e1cca9628fd3d816d3de3ae414c4891b4    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Wed, 19 Oct 2022 22:18:54 +1300    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Wed, 19 Oct 2022 22:18:54 +1300    

Click here for diff

Per https://llvm.org/docs/OpaquePointers.html, support for non-opaque  
pointers still exists and we can request that on our context.  We have  
until LLVM 16 to move to opaque pointers, a much larger change.  
  
Back-patch to 11, where LLVM support arrived.  
  
Author: Thomas Munro <thomas.munro@gmail.com>  
Author: Andres Freund <andres@anarazel.de>  
Discussion: https://postgr.es/m/CAMHz58Sf_xncdyqsekoVsNeKcruKootLtVH6cYXVhhUR1oKPCg%40mail.gmail.com  

M configure
M configure.ac
M src/backend/jit/llvm/llvmjit.c

Rework shutdown callback of archiver modules

commit   : 5d2a47a2924240606ce1c57c98490fa41752ad41    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 19 Oct 2022 14:07:01 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 19 Oct 2022 14:07:01 +0900    

Click here for diff

As currently designed, with a callback registered in a ERROR_CLEANUP  
block, the shutdown callback would get called twice when updating  
archive_library on SIGHUP, which is something that we want to avoid to  
ease the life of extension writers.  
  
Anyway, an ERROR in the archiver process is treated as a FATAL, stopping  
it immediately, hence there is no need for a ERROR_CLEANUP block.  
Instead of that, the shutdown callback is not called upon  
before_shmem_exit(), giving to the modules the opportunity to do any  
cleanup actions before the server shuts down its subsystems.  
  
While on it, this commit adds some testing coverage for the shutdown  
callback.  Neither shell_archive nor basic_archive have been using it,  
and one is added to shell_archive, whose trigger is checked in a TAP  
test through a shutdown sequence.  
  
Author: Nathan Bossart, Bharath Rupireddy  
Reviewed-by: Kyotaro Horiguchi, Michael Paquier  
Discussion: https://postgr.es/m/20221015221328.GB1821022@nathanxps13  
Backpatch-through: 15  

M doc/src/sgml/config.sgml
M src/backend/postmaster/pgarch.c
M src/backend/postmaster/shell_archive.c
M src/test/recovery/t/020_archive_status.pl

Improve errhint for ALTER SUBSCRIPTION ADD/DROP PUBLICATION

commit   : 25fb9579bbb97c65d6b007c3de803c81abb4b240    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 18 Oct 2022 11:46:58 +0200    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 18 Oct 2022 11:46:58 +0200    

Click here for diff

The original hint says to use SET PUBLICATION when really ADD/DROP  
PUBLICATION is called for, so this is arguably a bug fix.  
  
Also, a very similar message elsewhere was using an inconsistent  
SQLSTATE.  
  
While at it, unwrap some strings.  
  
Backpatch to 15.  
  
Author: Hou zj <houzj.fnst@fujitsu.com>  
Discussion: https://postgr.es/m/OS0PR01MB57160AD0E7386547BA978EB394299@OS0PR01MB5716.jpnprd01.prod.outlook.com  

M src/backend/commands/subscriptioncmds.c

Rename SetSingleFuncCall() to InitMaterializedSRF()

commit   : f2f7e509e6a96329805ecaf30fb64ba4c7f4b0d2    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 18 Oct 2022 10:22:40 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 18 Oct 2022 10:22:40 +0900    

Click here for diff

Per discussion, the existing routine name able to initialize a SRF  
function with materialize mode is unpopular, so rename it.  Equally, the  
flags of this function are renamed, as of:  
- SRF_SINGLE_USE_EXPECTED -> MAT_SRF_USE_EXPECTED_DESC  
- SRF_SINGLE_BLESS -> MAT_SRF_BLESS  
The previous function and flags introduced in 9e98583 are kept around  
for compatibility purposes, so as any extension code already compiled  
with v15 continues to work as-is.  The declarations introduced here for  
compatibility will be removed from HEAD in a follow-up commit.  
  
The new names have been suggested by Andres Freund and Melanie  
Plageman.  
  
Discussion: https://postgr.es/m/20221013194820.ciktb2sbbpw7cljm@awork3.anarazel.de  
Backpatch-through: 15  

M contrib/amcheck/verify_heapam.c
M contrib/dblink/dblink.c
M contrib/pageinspect/brinfuncs.c
M contrib/pageinspect/gistfuncs.c
M contrib/pg_stat_statements/pg_stat_statements.c
M contrib/pg_walinspect/pg_walinspect.c
M contrib/pgrowlocks/pgrowlocks.c
M contrib/postgres_fdw/connection.c
M contrib/xml2/xpath.c
M src/backend/access/transam/rmgr.c
M src/backend/access/transam/xlogprefetcher.c
M src/backend/commands/event_trigger.c
M src/backend/commands/extension.c
M src/backend/commands/prepare.c
M src/backend/foreign/foreign.c
M src/backend/replication/logical/launcher.c
M src/backend/replication/logical/logicalfuncs.c
M src/backend/replication/logical/origin.c
M src/backend/replication/slotfuncs.c
M src/backend/replication/walsender.c
M src/backend/storage/ipc/shmem.c
M src/backend/utils/adt/datetime.c
M src/backend/utils/adt/genfile.c
M src/backend/utils/adt/hbafuncs.c
M src/backend/utils/adt/jsonfuncs.c
M src/backend/utils/adt/mcxtfuncs.c
M src/backend/utils/adt/misc.c
M src/backend/utils/adt/pgstatfuncs.c
M src/backend/utils/adt/varlena.c
M src/backend/utils/fmgr/README
M src/backend/utils/fmgr/funcapi.c
M src/backend/utils/misc/guc.c
M src/backend/utils/misc/pg_config.c
M src/backend/utils/mmgr/portalmem.c
M src/include/funcapi.h

doc: move the mention of aggregate JSON functions up in section

commit   : ef325ee04dd407b7f3cef35e0e5722cbb5a9576d    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 17 Oct 2022 15:21:29 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 17 Oct 2022 15:21:29 -0400    

Click here for diff

It was previously easily overlooked at the end of several tables.  
  
Reported-by: Alex Denman  
  
Discussion: https://postgr.es/m/166335888474.659.16897487975376230364@wrigleys.postgresql.org  
  
Backpatch-through: 10  

M doc/src/sgml/func.sgml

doc: warn pg_stat_reset() can cause vacuum/analyze problems

commit   : 189db21e2ac41a719b8e70ac35b3d0b05b352f14    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 17 Oct 2022 15:07:03 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 17 Oct 2022 15:07:03 -0400    

Click here for diff

The fix is to run ANALYZE.  
  
Discussion: https://postgr.es/m/YzRr+ys98UzVQJvK@momjian.us,  
   https://postgr.es/m/flat/CAKJS1f8DTbCHf9gedU0He6ARsd58E6qOhEHM1caomqj_r9MOiQ%40mail.gmail.com,  
   https://postgr.es/m/CAKJS1f80o98hcfSk8j%3DfdN09S7Sjz%2BvuzhEwbyQqvHJb_sZw0g%40mail.gmail.com  
  
Backpatch-through: 10  

M doc/src/sgml/monitoring.sgml

Reject non-ON-SELECT rules that are named "_RETURN".

commit   : 4a41a069e7ac78e0a8b700fac181f59a234f8606    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 17 Oct 2022 12:14:39 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 17 Oct 2022 12:14:39 -0400    

Click here for diff

DefineQueryRewrite() has long required that ON SELECT rules be named  
"_RETURN".  But we overlooked the converse case: we should forbid  
non-ON-SELECT rules that are named "_RETURN".  In particular this  
prevents using CREATE OR REPLACE RULE to overwrite a view's _RETURN  
rule with some other kind of rule, thereby breaking the view.  
  
Per bug #17646 from Kui Liu.  Back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/17646-70c93cfa40365776@postgresql.org  

M src/backend/rewrite/rewriteDefine.c

Guard against table-AM-less relations in planner.

commit   : 2e3326929b0ba9f421f2ab1270c57b294c208a99    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 17 Oct 2022 11:35:23 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 17 Oct 2022 11:35:23 -0400    

Click here for diff

The executor will dump core if it's asked to execute a seqscan on  
a relation having no table AM, such as a view.  While that shouldn't  
really happen, it's possible to get there via catalog corruption,  
such as a missing ON SELECT rule.  It seems worth installing a defense  
against that.  There are multiple plausible places for such a defense,  
but I picked the planner's get_relation_info().  
  
Per discussion of bug #17646 from Kui Liu.  Back-patch to v12 where  
the tableam APIs were introduced; in older versions you won't get a  
SIGSEGV, so it seems less pressing.  
  
Discussion: https://postgr.es/m/17646-70c93cfa40365776@postgresql.org  

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

commit   : 9ebcb5ffdf3a1f49388c38ba5273370f49bf7d19    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 17 Oct 2022 11:40:19 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 17 Oct 2022 11:40:19 +0900    

Click here for diff

The file name used for its temporary destination, before renaming it to  
the real deal, has been using a microseconds in a timestamp aimed to be  
originally in milli-seconds.  This is harmless as this is aimed at being  
a safeguard against name collisions (note MyProcPid in the name), but  
let's be correct with the maths.  
  
While on it, add a note in the module's makefile to document why  
installcheck is not supported.  
  
Author: Nathan Bossart  
Reviewed-by: Bharath Rupireddy  
Discussion: https://postgr.es/m/20221014044106.GA1673343@nathanxps13  
Backpatch-through: 15  

M contrib/basic_archive/Makefile
M contrib/basic_archive/basic_archive.c

Fix EXPLAIN of SEARCH BREADTH FIRST with a constant initial value.

commit   : d4abb0bc5abb5dcb351956aed70f317a6bc494ba    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 16 Oct 2022 19:18:08 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 16 Oct 2022 19:18:08 -0400    

Click here for diff

If the non-recursive term of a SEARCH BREADTH FIRST recursive  
query has only constants in its target list, the planner will  
fold the starting RowExpr added by rewrite into a simple Const  
of type RECORD.  The executor doesn't have any problem with  
that --- but EXPLAIN VERBOSE will encounter the Const as the  
ultimate source of truth about what the field names of the  
SET column are, and it didn't know what to do with that.  
Fortunately, we can pull the identifying typmod out of the  
Const, in much the same way that record_out would.  
  
For reasons that remain a bit obscure to me, this only fails  
with SEARCH BREADTH FIRST, not SEARCH DEPTH FIRST or CYCLE.  
But I added regression test cases for both of those options  
too, just to make sure we don't break it in future.  
  
Per bug #17644 from Matthijs van der Vleuten.  Back-patch  
to v14 where these constructs were added.  
  
Discussion: https://postgr.es/m/17644-3bd1f3036d6d7a16@postgresql.org  

M src/backend/utils/adt/ruleutils.c
M src/backend/utils/fmgr/funcapi.c
M src/test/regress/expected/with.out
M src/test/regress/sql/with.sql

Rename parser token REF to REF_P to avoid a symbol conflict.

commit   : 24c4c2617138b1b14def8bd39dfe228c862ea129    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 16 Oct 2022 15:27:04 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 16 Oct 2022 15:27:04 -0400    

Click here for diff

In the latest version of Apple's macOS SDK, <sys/socket.h>  
fails to compile if "REF" is #define'd as something.  
Apple may or may not agree that this is a bug, and even if  
they do accept the bug report I filed, they probably won't  
fix it very quickly.  In the meantime, our back branches will all  
fail to compile gram.y.  v15 and HEAD currently escape the problem  
thanks to the refactoring done in 98e93a1fc, but that's purely  
accidental.  Moreover, since that patch removed a widely-visible  
inclusion of <netdb.h>, back-patching it seems too likely to break  
third-party code.  
  
Instead, change the token's code name to REF_P, following our usual  
convention for naming parser tokens that are likely to have symbol  
conflicts.  The effects of that should be localized to the grammar  
and immediately surrounding files, so it seems like a safer answer.  
  
Per project policy that we want to keep recently-out-of-support  
branches buildable on modern systems, back-patch all the way to 9.2.  
  
Discussion: https://postgr.es/m/1803927.1665938411@sss.pgh.pa.us  

M src/backend/parser/gram.y
M src/include/parser/kwlist.h

Use libc's snprintf, not sprintf, for special cases in snprintf.c.

commit   : bd4b2926ecc25b4435f816ce4ec542d9a01cdb09    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 16 Oct 2022 11:47:44 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 16 Oct 2022 11:47:44 -0400    

Click here for diff

snprintf.c has always fallen back on libc's *printf implementation  
when printing pointers (%p) and floats.  When this code originated,  
we were still supporting some platforms that lacked native snprintf,  
so we used sprintf for that.  That's not actually unsafe in our usage,  
but nonetheless builds on macOS are starting to complain about sprintf  
being unconditionally deprecated; and I wouldn't be surprised if other  
platforms follow suit.  There seems little reason to believe that any  
platform supporting C99 wouldn't have standards-compliant snprintf,  
so let's just use that instead to suppress such warnings.  
  
Back-patch to v12, which is where we started to require C99.  It's  
also where we started to use our snprintf.c everywhere, so this  
wouldn't be enough to suppress the warning in older branches anyway  
--- that is, in older branches these aren't necessarily all our  
usages of libc's sprintf.  It is enough in v12+ because any  
deprecation annotation attached to libc's sprintf won't apply to  
pg_sprintf.  (Whether all our usages of pg_sprintf are adequately  
safe is not a matter I intend to address here, but perhaps it could  
do with some review.)  
  
Per report from Andres Freund and local testing.  
  
Discussion: https://postgr.es/m/20221015211955.q4cwbsfkyk3c4ty3@awork3.anarazel.de  

M src/port/snprintf.c

Disallow MERGE cleanly for foreign partitions

commit   : 16d11d68437a6a37af1fea08d4a29ef463f0d62c    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Sat, 15 Oct 2022 19:24:26 +0200    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Sat, 15 Oct 2022 19:24:26 +0200    

Click here for diff

While directly targetting a foreign table with MERGE was already  
expressly forbidden, we failed to catch the case of a partitioned table  
that has a foreign table as a partition; and the result if you try is an  
incomprehensible error.  Fix that by adding a specific check.  
  
Backpatch to 15.  
  
Reported-by: Tatsuhiro Nakamori <bt22nakamorit@oss.nttdata.com>  
Discussion: https://postgr.es/m/bt22nakamorit@oss.nttdata.com  

M contrib/postgres_fdw/expected/postgres_fdw.out
M contrib/postgres_fdw/sql/postgres_fdw.sql
M src/backend/optimizer/plan/createplan.c

libpq: Reset singlerow flag correctly in pipeline mode

commit   : 27ca0bce5f41cecc3b219cc9d675239a79d7562a    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 14 Oct 2022 19:06:26 +0200    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 14 Oct 2022 19:06:26 +0200    

Click here for diff

When a query whose results were requested in single-row mode is the last  
in the queue by the time those results are being read, the single-row  
flag was not being reset, because we were returning early from  
pqPipelineProcessQueue.  Move that stanza up so that the flag is always  
reset at the end of sending that query's results.  
  
Add a test for the situation.  
  
Backpatch to 14.  
  
Author: Denis Laxalde <denis.laxalde@dalibo.com>  
Discussion: https://postgr.es/m/01af18c5-dacc-a8c8-07ee-aecc7650c3e8@dalibo.com  

M src/interfaces/libpq/fe-exec.c
M src/test/modules/libpq_pipeline/libpq_pipeline.c
M src/test/modules/libpq_pipeline/traces/singlerow.trace

Fix typo in CREATE PUBLICATION reference page

commit   : f7eec7fe38676f0be78640f0d4d77c3e4ffcc6d6    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 13 Oct 2022 13:36:14 +0200    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 13 Oct 2022 13:36:14 +0200    

Click here for diff

While at it, simplify wording a bit.  
  
Author: Takamichi Osumi <osumi.takamichi@fujitsu.com>  
Reviewed-by: Peter Smith <smithpb2250@gmail.com>  
Discussion: https://postgr.es/m/TYCPR01MB8373F93F5D094A2BE648990DED259@TYCPR01MB8373.jpnprd01.prod.outlook.com  

M doc/src/sgml/ref/create_publication.sgml

doc: Fix description of replication command CREATE_REPLICATION_SLOT

commit   : 91416f45f8bb8c4466e577efd79822be11645794    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 13 Oct 2022 08:53:44 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 13 Oct 2022 08:53:44 +0900    

Click here for diff

The output plugin name is a mandatory option when creating a logical  
slot, but the grammar documented was not described as such.  While on  
it, fix two comments in repl_gram.y to show that TEMPORARY is an  
optional grammar choice.  
  
Author: Ayaki Tachikake  
Discussion: https://postgr.es/m/OSAPR01MB2852607B2329FFA27834105AF1229@OSAPR01MB2852.jpnprd01.prod.outlook.com  
Backpatch-through: 15  

M doc/src/sgml/protocol.sgml
M src/backend/replication/repl_gram.y

commit   : 42d203ccfa8741ca8086e33f98aaa6c169063ef7    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 12 Oct 2022 10:51:11 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 12 Oct 2022 10:51:11 -0400    

Click here for diff

Add  
    After=network-online.target  
    Wants=network-online.target  
to the suggested unit file for starting a Postgres server.  
This delays startup until the network interfaces have been  
configured; without that, any attempt to bind to a specific  
IP address will fail.  
  
If listen_addresses is set to "localhost" or "*", it might be  
possible to get away with the less restrictive "network.target",  
but I don't think we need to get into such detail here.  
  
Per suggestion from Pablo Federico.  
  
Discussion: https://postgr.es/m/166552157407.591805.10036014441784710940@wrigleys.postgresql.org  

M doc/src/sgml/runtime.sgml

Harden pmsignal.c against clobbered shared memory.

commit   : e7b4ff327c4d5cc8ff3eaebff9c79c28232cabdd    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 11 Oct 2022 18:54:31 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 11 Oct 2022 18:54:31 -0400    

Click here for diff

The postmaster is not supposed to do anything that depends  
fundamentally on shared memory contents, because that creates  
the risk that a backend crash that trashes shared memory will  
take the postmaster down with it, preventing automatic recovery.  
In commit 969d7cd43 I lost sight of this principle and coded  
AssignPostmasterChildSlot() in such a way that it could fail  
or even crash if the shared PMSignalState structure became  
corrupted.  Remarkably, we've not seen field reports of such  
crashes; but I managed to induce one while testing the recent  
changes around palloc chunk headers.  
  
To fix, make a semi-duplicative state array inside the postmaster  
so that we need consult only local state while choosing a "child  
slot" for a new backend.  Ensure that other postmaster-executed  
routines in pmsignal.c don't have critical dependencies on the  
shared state, either.  Corruption of PMSignalState might now  
lead ReleasePostmasterChildSlot() to conclude that backend X  
failed, when actually backend Y was the one that trashed things.  
But that doesn't matter, because we'll force a cluster-wide reset  
regardless.  
  
Back-patch to all supported branches, since this is an old bug.  
  
Discussion: https://postgr.es/m/3436789.1665187055@sss.pgh.pa.us  

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

Yet further fixes for multi-row VALUES lists for updatable views.

commit   : 07ce6769824c4081208122ae3c1b38812e4715ed    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 11 Oct 2022 18:24:14 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 11 Oct 2022 18:24:14 -0400    

Click here for diff

DEFAULT markers appearing in an INSERT on an updatable view  
could be mis-processed if they were in a multi-row VALUES clause.  
This would lead to strange errors such as "cache lookup failed  
for type NNNN", or in older branches even to crashes.  
  
The cause is that commit 41531e42d tried to re-use rewriteValuesRTE()  
to remove any SetToDefault nodes (that hadn't previously been replaced  
by the view's own default values) appearing in "product" queries,  
that is DO ALSO queries.  That's fundamentally wrong because the  
DO ALSO queries might not even be INSERTs; and even if they are,  
their targetlists don't necessarily match the view's column list,  
so that almost all the logic in rewriteValuesRTE() is inapplicable.  
  
What we want is a narrow focus on replacing any such nodes with NULL  
constants.  (That is, in this context we are interpreting the defaults  
as being strictly those of the view itself; and we already replaced  
any that aren't NULL.)  We could add still more !force_nulls tests  
to further lobotomize rewriteValuesRTE(); but it seems cleaner to  
split out this case to a new function, restoring rewriteValuesRTE()  
to the charter it had before.  
  
Per bug #17633 from jiye_sw.  Patch by me, but thanks to  
Richard Guo and Japin Li for initial investigation.  
Back-patch to all supported branches, as the previous fix was.  
  
Discussion: https://postgr.es/m/17633-98cc85e1fa91e905@postgresql.org  

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

Doc: update release date for v15.

commit   : 2a7ce2e2ce474504a707ec03e128fde66cfb8b48    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Oct 2022 16:57:37 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Oct 2022 16:57:37 -0400    

Click here for diff

Drat, forgot this ...  

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

Stamp 15.0.

commit   : 957d1993c13d8477a3db5e319ece845fb3e0e5a7    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Oct 2022 16:28:16 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Oct 2022 16:28:16 -0400    

Click here for diff

M configure
M configure.ac

Translation updates

commit   : 77d500abb8a112df81486b1a717d3dd09479070e    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 10 Oct 2022 12:03:38 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 10 Oct 2022 12:03:38 +0200    

Click here for diff

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

M src/backend/po/de.po
M src/backend/po/ja.po
M src/backend/po/ru.po
M src/backend/po/sv.po
M src/bin/initdb/nls.mk
M src/bin/initdb/po/fr.po
A src/bin/initdb/po/pt_BR.po
M src/bin/initdb/po/ru.po
M src/bin/pg_archivecleanup/nls.mk
A src/bin/pg_archivecleanup/po/pt_BR.po
M src/bin/pg_basebackup/po/fr.po
M src/bin/pg_basebackup/po/ru.po
M src/bin/pg_basebackup/po/sv.po
M src/bin/pg_checksums/nls.mk
A src/bin/pg_checksums/po/pt_BR.po
M src/bin/pg_config/po/pt_BR.po
M src/bin/pg_controldata/nls.mk
A src/bin/pg_controldata/po/pt_BR.po
M src/bin/pg_ctl/nls.mk
A src/bin/pg_ctl/po/pt_BR.po
M src/bin/pg_dump/po/fr.po
M src/bin/pg_resetwal/nls.mk
A src/bin/pg_resetwal/po/pt_BR.po
M src/bin/pg_rewind/po/fr.po
M src/bin/pg_rewind/po/ru.po
M src/bin/pg_rewind/po/sv.po
M src/bin/pg_test_fsync/nls.mk
A src/bin/pg_test_fsync/po/pt_BR.po
M src/bin/pg_test_timing/nls.mk
A src/bin/pg_test_timing/po/pt_BR.po
M src/bin/pg_upgrade/po/ru.po
M src/bin/pg_waldump/po/fr.po
M src/bin/pg_waldump/po/ru.po
M src/bin/pg_waldump/po/sv.po
M src/bin/psql/po/ru.po
M src/bin/scripts/nls.mk
A src/bin/scripts/po/pt_BR.po
M src/bin/scripts/po/ru.po
M src/interfaces/ecpg/ecpglib/po/pt_BR.po
M src/interfaces/ecpg/preproc/po/pt_BR.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/interfaces/libpq/po/sv.po
M src/pl/plperl/po/pt_BR.po
M src/pl/plpgsql/src/po/pt_BR.po
M src/pl/plpgsql/src/po/ru.po
M src/pl/plpython/po/pt_BR.po
M src/pl/tcl/nls.mk
A src/pl/tcl/po/pt_BR.po

Update list of acknowledgments in release notes

commit   : 48c81b57e942075f40702787f14acb2451871b4f    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 10 Oct 2022 08:15:29 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 10 Oct 2022 08:15:29 +0200    

Click here for diff

current through c3b5992b91c4b0d2c4f4eab0fb856f34854c129d  

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

pgstat: Prevent stats reset from corrupting slotname by removing slotname

commit   : c3b5992b91c4b0d2c4f4eab0fb856f34854c129d    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Sat, 8 Oct 2022 09:33:23 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Sat, 8 Oct 2022 09:33:23 -0700    

Click here for diff

Previously PgStat_StatReplSlotEntry contained the slotname, which was mainly  
used when writing out the stats during shutdown, to identify the slot in the  
serialized data (at runtime the index in ReplicationSlotCtl->replication_slots  
is used, but that can change during a restart). Unfortunately the slotname was  
overwritten when the slot's stats were reset.  
  
That turned out to only cause "real" problems if the slot was active during  
the reset, triggering an assertion failure at the next  
pgstat_report_replslot(). In other paths the stats were re-initialized during  
pgstat_acquire_replslot().  
  
Fix this by removing slotname from PgStat_StatReplSlotEntry. Instead we can  
get the slot's name from the slot itself. Besides fixing a bug, this also is  
architecturally cleaner (a name is not really statistics). This is safe  
because stats, for a slot removed while shut down, will not be restored at  
startup.  
  
In 15 the slotname is not removed, but renamed, to avoid changing the stats  
format. In master, bump PGSTAT_FILE_FORMAT_ID.  
  
This commit does not contain a test for the fix. I think this can only be  
tested by a tap test starting pg_recvlogical in the background and checking  
pg_recvlogical's output. That type of test is notoriously hard to be reliable,  
so committing it shortly before the release is wrapped seems like a bad idea.  
  
Reported-by: Jaime Casanova <jcasanov@systemguards.com.ec>  
Author: Andres Freund <andres@anarazel.de>  
Reviewed-by: Masahiko Sawada <sawada.mshk@gmail.com>  
Reviewed-by: Kyotaro Horiguchi <horikyota.ntt@gmail.com>  
Discussion: https://postgr.es/m/YxfagaTXUNa9ggLb@ahch-to  
Backpatch: 15-, where the bug was introduced in 5891c7a8ed8f  

M src/backend/replication/slot.c
M src/backend/utils/activity/pgstat.c
M src/backend/utils/activity/pgstat_replslot.c
M src/include/pgstat.h
M src/include/replication/slot.h
M src/include/utils/pgstat_internal.h

Fix self-referencing foreign keys with partitioned tables

commit   : 6083132abdd46462a0eca15412bb35fa3495eab2    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 7 Oct 2022 19:37:48 +0200    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 7 Oct 2022 19:37:48 +0200    

Click here for diff

There are a number of bugs in this area.  Two of them are fixed here,  
namely:  
1. get_relation_idx_constraint_oid does not restrict the type of  
   constraint that's returned, so with sufficient bad luck it can  
   return the OID of a foreign key constraint.  This has the effect that  
   a primary key in a partition can end up as a child of a foreign key,  
   which makes no sense (it needs to be the child of the equivalent  
   primary key.)  
   Change the API contract so that only index-backed constraints are  
   returned, mimicking get_constraint_index().  
  
2. Both CloneFkReferenced and CloneFkReferencing clone a  
   self-referencing foreign key, so the partition ends up with  
   a duplicate foreign key.  Change the former function to ignore such  
   constraints.  
  
Add some tests to verify that things are better now.  (However, these  
new tests show some additional misbehavior that will be fixed later --  
namely that there's a constraint marked NOT VALID.)  
  
Backpatch to 12, where these constraints are possible at all.  
  
Author: Jehan-Guillaume de Rorthais <jgdr@dalibo.com>  
Discussion: https://postgr.es/m/20220603154232.1715b14c@karst  

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

relnotes: fix author names

commit   : be5cf460817b54c31dcf84f8e9b947c902327ae9    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 5 Oct 2022 16:17:30 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 5 Oct 2022 16:17:30 -0400    

Click here for diff

Reported-by: Elena Indrupskaya  
  
Discussion: https://postgr.es/m/0af43b49-1646-93d0-ccf1-bb3c635c8c6f@postgrespro.ru  
  
Author: Elena Indrupskaya  
  
Backpatch-through: 15 only  

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

doc: clarify description for log_startup_progress_interval

commit   : d2d67949f5ca95cf4bd66d849e947f3bbe065e0d    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 5 Oct 2022 15:53:40 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 5 Oct 2022 15:53:40 -0400    

Click here for diff

Reported-by: Elena Indrupskaya  
  
Discussion: https://postgr.es/m/0af43b49-1646-93d0-ccf1-bb3c635c8c6f@postgrespro.ru  
  
Author: Elena Indrupskaya  
  
Backpatch-through: 15  

M doc/src/sgml/config.sgml

Stamp 15rc2.

commit   : 2a40d040c924b1707cd03a9c66c80fcc4795c2d1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 3 Oct 2022 17:03:12 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 3 Oct 2022 17:03:12 -0400    

Click here for diff

M configure
M configure.ac

Fix psql's behavior with \g for a multiple-command string.

commit   : 595580aa1243df5f199516ff11a27ba9680e6904    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 3 Oct 2022 15:07:10 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 3 Oct 2022 15:07:10 -0400    

Click here for diff

The pre-v15 behavior was to discard all but the last result,  
but with the new behavior of printing all results by default,  
we will send each such result to the \g file.  However,  
we're still opening and closing the \g file for each result,  
so you lose all but the last result anyway.  Move the output-file  
state up to ExecQueryAndProcessResults so that we open/close the  
\g file only once per command string.  
  
To support this without changing other behavior, we must  
adjust PrintQueryResult to have separate FILE * arguments  
for query and status output (since status output has never  
gone to the \g file).  That in turn makes it a good idea  
to push the responsibility for fflush'ing output down to  
PrintQueryTuples and PrintQueryStatus.  
  
Also fix an infinite loop if COPY IN/OUT is attempted in \watch.  
We used to reject that, but that error exit path got broken  
somewhere along the line in v15.  There seems no real reason  
to reject it anyway as the code now stands, so just remove  
the error exit and make sure that COPY OUT data goes to the  
right place.  
  
Also remove PrintQueryResult's unused is_watch parameter,  
and make some other cosmetic cleanups (adjust obsolete  
comments, break some overly-long lines).  
  
Daniel Vérité and Tom Lane  
  
Discussion: https://postgr.es/m/4333844c-2244-4d6e-a49a-1d483fbe304f@manitou-mail.org  

M src/bin/psql/common.c

Doc: update v15 release notes.

commit   : b1c73e1cf1ffdfedeed4f2cd7f34247dcad308bf    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 3 Oct 2022 11:06:33 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 3 Oct 2022 11:06:33 -0400    

Click here for diff

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

Revert "Optimize order of GROUP BY keys".

commit   : 443df6e2db932a7cd6d85ddfb67e11a43345130d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 3 Oct 2022 10:56:16 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 3 Oct 2022 10:56:16 -0400    

Click here for diff

This reverts commit db0d67db2401eb6238ccc04c6407a4fd4f985832 and  
several follow-on fixes.  The idea of making a cost-based choice  
of the order of the sorting columns is not fundamentally unsound,  
but it requires cost information and data statistics that we don't  
really have.  For example, relying on procost to distinguish the  
relative costs of different sort comparators is pretty pointless  
so long as most such comparator functions are labeled with cost 1.0.  
Moreover, estimating the number of comparisons done by Quicksort  
requires more than just an estimate of the number of distinct values  
in the input: you also need some idea of the sizes of the larger  
groups, if you want an estimate that's good to better than a factor of  
three or so.  That's data that's often unknown or not very reliable.  
Worse, to arrive at estimates of the number of calls made to the  
lower-order-column comparison functions, the code needs to make  
estimates of the numbers of distinct values of multiple columns,  
which are necessarily even less trustworthy than per-column stats.  
Even if all the inputs are perfectly reliable, the cost algorithm  
as-implemented cannot offer useful information about how to order  
sorting columns beyond the point at which the average group size  
is estimated to drop to 1.  
  
Close inspection of the code added by db0d67db2 shows that there  
are also multiple small bugs.  These could have been fixed, but  
there's not much point if we don't trust the estimates to be  
accurate in-principle.  
  
Finally, the changes in cost_sort's behavior made for very large  
changes (often a factor of 2 or so) in the cost estimates for all  
sorting operations, not only those for multi-column GROUP BY.  
That naturally changes plan choices in many situations, and there's  
precious little evidence to show that the changes are for the better.  
Given the above doubts about whether the new estimates are really  
trustworthy, it's hard to summon much confidence that these changes  
are better on the average.  
  
Since we're hard up against the release deadline for v15, let's  
revert these changes for now.  We can always try again later.  
  
Note: in v15, I left T_PathKeyInfo in place in nodes.h even though  
it's unreferenced.  Removing it would be an ABI break, and it seems  
a bit late in the release cycle for that.  
  
Discussion: https://postgr.es/m/TYAPR01MB586665EB5FB2C3807E893941F5579@TYAPR01MB5866.jpnprd01.prod.outlook.com  

M contrib/postgres_fdw/expected/postgres_fdw.out
M doc/src/sgml/config.sgml
M src/backend/optimizer/path/costsize.c
M src/backend/optimizer/path/equivclass.c
M src/backend/optimizer/path/pathkeys.c
M src/backend/optimizer/plan/planner.c
M src/backend/optimizer/util/pathnode.c
M src/backend/utils/adt/selfuncs.c
M src/backend/utils/misc/guc.c
M src/backend/utils/misc/postgresql.conf.sample
M src/include/nodes/pathnodes.h
M src/include/optimizer/cost.h
M src/include/optimizer/paths.h
M src/include/utils/selfuncs.h
M src/test/regress/expected/aggregates.out
M src/test/regress/expected/incremental_sort.out
M src/test/regress/expected/join.out
M src/test/regress/expected/merge.out
M src/test/regress/expected/partition_aggregate.out
M src/test/regress/expected/partition_join.out
M src/test/regress/expected/sysviews.out
M src/test/regress/expected/union.out
M src/test/regress/sql/aggregates.sql
M src/test/regress/sql/incremental_sort.sql

ci: macos: Reduce test concurrency

commit   : b507a7a19b5d9a8ed2500c5a7159353e02846901    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Sat, 1 Oct 2022 16:55:16 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Sat, 1 Oct 2022 16:55:16 -0700    

Click here for diff

Test performance regresses noticably when using all cores. This is more  
pronounced with meson than with autoconf, presumably because meson will  
schedule the "full number" of tests more consistently.  8 seems to work  
OK.  
  
Discussion: https://postgr.es/m/20220927040208.l3shfcidovpzqxfh@awork3.anarazel.de  
Backpatch: 15-, where CI was introduced  

M .cirrus.yml

doc: Fix some grammar and typos

commit   : 64b431d15c49ce39a12dcaec78a60b884be1efba    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sat, 1 Oct 2022 15:28:11 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sat, 1 Oct 2022 15:28:11 +0900    

Click here for diff

This fixes some areas related to logical replication and custom RMGRs.  
  
Author: Ekaterina Kiryanova  
Discussion: https://postgr.es/m/fa4773f1-1396-384a-bcd7-85b5e013f399@postgrespro.ru  
Backpatch-through: 15  

M doc/src/sgml/custom-rmgr.sgml
M doc/src/sgml/func.sgml
M doc/src/sgml/logical-replication.sgml
M src/backend/access/transam/rmgr.c

Avoid improbable PANIC during heap_update, redux.

commit   : 2267085c168899b43dadc4ca52fb516773068228    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 30 Sep 2022 19:36:46 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 30 Sep 2022 19:36:46 -0400    

Click here for diff

Commit 34f581c39 intended to ensure that RelationGetBufferForTuple  
would acquire a visibility-map page pin in case the otherBuffer's  
all-visible bit had become set since we last had lock on that page.  
But I missed a case: when we're extending the relation, VM concerns  
were dealt with only in the relatively-less-likely case that we  
fail to conditionally lock the otherBuffer.  I think I'd believed  
that we couldn't need to worry about it if the conditional lock  
succeeds, which is true for the target buffer; but the otherBuffer  
was unlocked for awhile so its bit might be set anyway.  So we need  
to do the GetVisibilityMapPins dance, and then also recheck the  
page's free space, in both cases.  
  
Per report from Jaime Casanova.  Back-patch to v12 as the previous  
patch was (although there's still no evidence that the bug is  
reachable pre-v14).  
  
Discussion: https://postgr.es/m/E1lWLjP-00006Y-Ml@gemulon.postgresql.org  

M src/backend/access/heap/hio.c

Fix tab-completion after commit 790bf615ddba

commit   : d8e6ae9f38984ca16dc0e18924cc26568bb75960    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 30 Sep 2022 12:53:31 +0200    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 30 Sep 2022 12:53:31 +0200    

Click here for diff

I (Álvaro) broke tab-completion for GRANT .. ALL TABLES IN SCHEMA while  
removing ALL from the publication syntax for schemas in the  
aforementioned commit.  I also missed to update a bunch of  
tab-completion rules for ALTER/CREATE PUBLICATION that match each  
individual piece of ALL TABLES IN SCHEMA.  Repair those bugs.  
  
While fixing up that commit, update a couple of outdated comments  
related to the same change.  
  
Backpatch to 15.  
  
Author: Shi yu <shiy.fnst@fujitsu.com>  
Reviewed-by: Peter Smith <smithpb2250@gmail.com>  
Discussion: https://postgr.es/m/OSZPR01MB6310FCE8609185A56344EED2FD559@OSZPR01MB6310.jpnprd01.prod.outlook.com  

M src/backend/replication/logical/tablesync.c
M src/bin/psql/tab-complete.c
M src/test/subscription/t/031_column_list.pl

doc: Fix PQsslAttribute docs for compression

commit   : a613474411e690947fbf869ef519da13a35d993d    
  
author   : Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Fri, 30 Sep 2022 12:03:48 +0200    
  
committer: Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Fri, 30 Sep 2022 12:03:48 +0200    

Click here for diff

The compression parameter to PQsslAttribute has never returned the  
compression method used, it has always returned "on" or "off since  
it was added in commit 91fa7b4719ac. Backpatch through v10.  
  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/B9EC60EC-F665-47E8-A221-398C76E382C9@yesql.se  
Backpatch-through: v10  

M doc/src/sgml/libpq.sgml

Fix bogus behavior of PQsslAttribute(conn, "library").

commit   : cae4688ce81b8449aa6e1e7bfa384d53520a81fb    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 29 Sep 2022 17:28:09 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 29 Sep 2022 17:28:09 -0400    

Click here for diff

Commit ebc8b7d44 intended to change the behavior of  
PQsslAttribute(NULL, "library"), but accidentally also changed  
what happens with a non-NULL conn pointer.  Undo that so that  
only the intended behavior change happens.  Clarify some  
associated documentation.  
  
Per bug #17625 from Heath Lord.  Back-patch to v15.  
  
Discussion: https://postgr.es/m/17625-fc47c78b7d71b534@postgresql.org  

M doc/src/sgml/libpq.sgml
M src/interfaces/libpq/fe-secure-openssl.c

Update comment in ExecInsert() regarding batch insertion.

commit   : d460faf00285fd99d3c80e890c8f6fe798233b48    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Thu, 29 Sep 2022 16:55:01 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Thu, 29 Sep 2022 16:55:01 +0900    

Click here for diff

Remove the stale text that is a leftover from an earlier version of the  
patch to add support for batch insertion, and adjust the wording in the  
remaining text.  
  
Back-patch to v14 where batch insertion came in.  
  
Review and wording adjustment by Tom Lane.  
  
Discussion: https://postgr.es/m/CAPmGK14goatHPHQv2Aeu_UTKqZ%2BBO%2BP%2Bzd3HKv5D%2BdyyfWKDSw%40mail.gmail.com  

M src/backend/executor/nodeModifyTable.c

Restrict Datum sort optimization to byval types only

commit   : f7ae8a2e186ca27f4ea64fddc21bfabaf0618507    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Thu, 29 Sep 2022 11:43:40 +1300    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Thu, 29 Sep 2022 11:43:40 +1300    

Click here for diff

91e9e89dc modified nodeSort.c so that it used datum sorts when the  
targetlist of the outer node contained only a single column.  That commit  
failed to recognise that the Datum returned by tuplesort_getdatum() must  
be pfree'd when the type is a byref type.  Ronan Dunklau did originally  
propose the patch with that restriction, but that, probably through my own  
fault, got lost during further development work.  
  
Due to the timing of this report (PG15 RC1 is almost out the door), let's  
just restrict the datum sort optimization to apply for byval types only.  
We might want to look harder into making this work for byref types in  
PG16.  
  
Reported-by: Önder Kalacı  
Diagnosis-by: Tom Lane  
Discussion: https://postgr.es/m/CACawEhVxe0ufR26UcqtU7GYGRuubq3p6ZWPGXL4cxy_uexpAAQ@mail.gmail.com  
Backpatch-through: 15, where 91e9e89dc was introduced.  

M src/backend/executor/nodeSort.c

doc: clarify internal behavior of RECURSIVE CTE queries

commit   : 517fab6a405628a7e4d2aad4cb19ab652adea720    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 28 Sep 2022 13:14:38 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 28 Sep 2022 13:14:38 -0400    

Click here for diff

Reported-by: Tom Lane  
  
Discussion: https://postgr.es/m/3976627.1662651004@sss.pgh.pa.us  
  
Backpatch-through: 10  

M doc/src/sgml/queries.sgml

revert "warn of SECURITY DEFINER schemas for non-sql_body funcs"

commit   : 9bb5412885d12fd8598e0aacc29c3d9afdce857d    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 28 Sep 2022 13:05:20 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 28 Sep 2022 13:05:20 -0400    

Click here for diff

doc revert of commit 1703726488.  Change was applied to irrelevant  
branches, and was not detailed enough to be helpful in relevant  
branches.  
  
Reported-by: Peter Eisentraut, Noah Misch  
  
Discussion: https://postgr.es/m/a2dc9de4-24fc-3222-87d3-0def8057d7d8@enterprisedb.com  
  
Backpatch-through: 10  

M doc/src/sgml/ref/create_function.sgml

Change some errdetail() to errdetail_internal()

commit   : 1eeac95dc4a639c51ff6cc6e2ac6ae52dab32b32    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 28 Sep 2022 17:14:53 +0200    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 28 Sep 2022 17:14:53 +0200    

Click here for diff

This prevents marking the argument string for translation for gettext,  
and it also prevents the given string (which is already translated) from  
being translated at runtime.  
  
Also, mark the strings used as arguments to check_rolespec_name for  
translation.  
  
Backpatch all the way back as appropriate.  None of this is caught by  
any tests (necessarily so), so I verified it manually.  

M src/backend/catalog/dependency.c
M src/backend/commands/publicationcmds.c
M src/backend/commands/user.c
M src/backend/utils/adt/acl.c
M src/backend/utils/adt/jsonfuncs.c
M src/common/jsonapi.c

Remove publicationcmds.c's expr_allowed_in_node as a function

commit   : a60b11327bbd4ae9f661563644a15b0c324f3d9d    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 28 Sep 2022 13:47:25 +0200    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 28 Sep 2022 13:47:25 +0200    

Click here for diff

Its API is quite strange, and since there's only one caller, there's no  
reason for it to be a separate function in the first place.  Inline it  
instead.  
  
Discussion: https://postgr.es/m/20220927124249.4zdzzlz6had7k3x2@alvherre.pgsql  

M src/backend/commands/publicationcmds.c

commit   : f5441b912493e14fc2ca904971aeb000ceddca4e    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 27 Sep 2022 14:11:31 +0200    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 27 Sep 2022 14:11:31 +0200    

Click here for diff

While at it, remove an unused queryString parameter from  
CheckPubRelationColumnList() and make other minor stylistic changes.  
  
Backpatch to 15.  
  
Reported by Kyotaro Horiguchi <horikyota.ntt@gmail.com>  
Co-authored-by: Hou zj <houzj.fnst@fujitsu.com>  
Discussion: https://postgr.es/m/20220926.160426.454497059203258582.horikyota.ntt@gmail.com  

M src/backend/commands/publicationcmds.c
M src/test/regress/expected/publication.out

Fix pg_stat_statements for MERGE

commit   : 72abf03b6491a8df880e1fea45798797bcc86c47    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 27 Sep 2022 10:44:42 +0200    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 27 Sep 2022 10:44:42 +0200    

Click here for diff

We weren't jumbling the merge action list, so wildly different commands  
would be considered to use the same query ID.  Add that, mention it in  
the docs, and some test lines.  
  
Backpatch to 15.  
  
Author: Tatsu <bt22nakamorit@oss.nttdata.com>  
Reviewed-by: Julien Rouhaud <rjuju123@gmail.com>  
Discussion: https://postgr.es/m/d87e391694db75a038abc3b2597828e8@oss.nttdata.com  

M contrib/pg_stat_statements/expected/pg_stat_statements.out
M contrib/pg_stat_statements/sql/pg_stat_statements.sql
M doc/src/sgml/pgstatstatements.sgml
M src/backend/nodes/nodeFuncs.c
M src/backend/utils/misc/queryjumble.c

ci: Add hint about downloadable logs to README

commit   : d1f95fa2476bcf427a3e3677f67ceee26552e23e    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 26 Sep 2022 20:02:26 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Mon, 26 Sep 2022 20:02:26 -0700    

Click here for diff

I (Andres) chose to backpatch this to 15, as it seems better to keep the  
README the same.  
  
Author: James Coleman <jtc331@gmail.com>  
Discussion: https://postgr.es/m/CAAaqYe_7BXDjpk0Ks_eqf1r6LZpC_rfB7kjhb_T3+eC4t6yiGQ@mail.gmail.com  
Backpatch: 15-, where CI came in  

M src/tools/ci/README

Doc: last minute adjustment to the release notes

commit   : bb76510a07f3705a28d93e065ebe4261d6ddf54d    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Tue, 27 Sep 2022 10:57:07 +1300    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Tue, 27 Sep 2022 10:57:07 +1300    

Click here for diff

The change made in 9d9c02ccd also affects the dense_rank() function.  
Mention this in the release notes.  
  
Author: Jonathan S. Katz  
Discussion: https://postgr.es/m/5c6d3f50-e9b5-f62d-d58a-7b22eb91d8b8@postgresql.org  

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

Stamp 15rc1.

commit   : 6abbd212b2828717fb3b10ed2925edf8f212e38d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 26 Sep 2022 16:36:49 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 26 Sep 2022 16:36:49 -0400    

Click here for diff

M configure
M configure.ac

Doc: more tweaking of v15 release notes.

commit   : 780add2c32a7577f1eab81ae3d8802cd02c4f8fe    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 26 Sep 2022 14:32:51 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 26 Sep 2022 14:32:51 -0400    

Click here for diff

Per suggestions from Justin Pryzby.  
  
Discussion: https://postgr.es/m/20220925215009.GC21938@telsasoft.com  

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

Doc: further adjust notes about pg_upgrade_output.d.

commit   : 796aa20a11b4060e07b0864081e6977eb66b64bd    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 26 Sep 2022 14:19:21 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 26 Sep 2022 14:19:21 -0400    

Click here for diff

I'd misunderstood how it worked in 5f1048881.  
  
Discussion: https://postgr.es/m/20220925215009.GC21938@telsasoft.com  

M doc/src/sgml/ref/pgupgrade.sgml

Translation updates

commit   : 0570eba3dcf8c819a6b100b14e25290eaedb4b5a    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 26 Sep 2022 13:16:06 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 26 Sep 2022 13:16:06 +0200    

Click here for diff

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

M src/backend/nls.mk
M src/backend/po/de.po
M src/backend/po/es.po
D src/backend/po/id.po
D src/backend/po/it.po
M src/backend/po/ja.po
D src/backend/po/pl.po
D src/backend/po/pt_BR.po
M src/backend/po/ru.po
M src/backend/po/sv.po
D src/backend/po/tr.po
M src/backend/po/uk.po
M src/bin/initdb/nls.mk
D src/bin/initdb/po/cs.po
M src/bin/initdb/po/de.po
M src/bin/initdb/po/es.po
D src/bin/initdb/po/he.po
D src/bin/initdb/po/it.po
M src/bin/initdb/po/ja.po
M src/bin/initdb/po/ka.po
D src/bin/initdb/po/ko.po
D src/bin/initdb/po/pl.po
D src/bin/initdb/po/pt_BR.po
M src/bin/initdb/po/ru.po
M src/bin/initdb/po/sv.po
D src/bin/initdb/po/tr.po
M src/bin/initdb/po/uk.po
D src/bin/initdb/po/vi.po
M src/bin/pg_amcheck/po/es.po
M src/bin/pg_amcheck/po/ru.po
M src/bin/pg_amcheck/po/uk.po
M src/bin/pg_archivecleanup/nls.mk
M src/bin/pg_archivecleanup/po/es.po
D src/bin/pg_archivecleanup/po/pl.po
M src/bin/pg_archivecleanup/po/ru.po
M src/bin/pg_archivecleanup/po/uk.po
D src/bin/pg_archivecleanup/po/vi.po
M src/bin/pg_basebackup/nls.mk
D src/bin/pg_basebackup/po/cs.po
M src/bin/pg_basebackup/po/de.po
M src/bin/pg_basebackup/po/es.po
D src/bin/pg_basebackup/po/he.po
D src/bin/pg_basebackup/po/it.po
M src/bin/pg_basebackup/po/ja.po
M src/bin/pg_basebackup/po/ka.po
D src/bin/pg_basebackup/po/ko.po
D src/bin/pg_basebackup/po/pl.po
D src/bin/pg_basebackup/po/pt_BR.po
M src/bin/pg_basebackup/po/ru.po
M src/bin/pg_basebackup/po/sv.po
D src/bin/pg_basebackup/po/tr.po
M src/bin/pg_basebackup/po/uk.po
D src/bin/pg_basebackup/po/vi.po
D src/bin/pg_basebackup/po/zh_CN.po
M src/bin/pg_checksums/nls.mk
D src/bin/pg_checksums/po/cs.po
D src/bin/pg_checksums/po/el.po
M src/bin/pg_checksums/po/es.po
D src/bin/pg_checksums/po/ko.po
M src/bin/pg_checksums/po/ru.po
D src/bin/pg_checksums/po/tr.po
M src/bin/pg_checksums/po/uk.po
D src/bin/pg_checksums/po/zh_CN.po
M src/bin/pg_config/nls.mk
M src/bin/pg_config/po/es.po
D src/bin/pg_config/po/nb.po
D src/bin/pg_config/po/ro.po
M src/bin/pg_config/po/ru.po
D src/bin/pg_config/po/ta.po
M src/bin/pg_config/po/uk.po
D src/bin/pg_config/po/zh_TW.po
M src/bin/pg_controldata/nls.mk
M src/bin/pg_controldata/po/es.po
D src/bin/pg_controldata/po/pl.po
D src/bin/pg_controldata/po/pt_BR.po
M src/bin/pg_controldata/po/ru.po
M src/bin/pg_controldata/po/uk.po
D src/bin/pg_controldata/po/vi.po
M src/bin/pg_ctl/nls.mk
M src/bin/pg_ctl/po/es.po
D src/bin/pg_ctl/po/he.po
D src/bin/pg_ctl/po/pl.po
D src/bin/pg_ctl/po/pt_BR.po
M src/bin/pg_ctl/po/ru.po
M src/bin/pg_ctl/po/uk.po
M src/bin/pg_dump/nls.mk
M src/bin/pg_dump/po/es.po
D src/bin/pg_dump/po/he.po
D src/bin/pg_dump/po/it.po
M src/bin/pg_dump/po/ka.po
D src/bin/pg_dump/po/pl.po
D src/bin/pg_dump/po/pt_BR.po
M src/bin/pg_dump/po/ru.po
M src/bin/pg_dump/po/uk.po
M src/bin/pg_resetwal/nls.mk
M src/bin/pg_resetwal/po/es.po
D src/bin/pg_resetwal/po/it.po
D src/bin/pg_resetwal/po/pl.po
D src/bin/pg_resetwal/po/pt_BR.po
M src/bin/pg_resetwal/po/ru.po
D src/bin/pg_resetwal/po/tr.po
M src/bin/pg_resetwal/po/uk.po
M src/bin/pg_rewind/nls.mk
D src/bin/pg_rewind/po/cs.po
M src/bin/pg_rewind/po/de.po
M src/bin/pg_rewind/po/es.po
D src/bin/pg_rewind/po/it.po
M src/bin/pg_rewind/po/ja.po
M src/bin/pg_rewind/po/ka.po
D src/bin/pg_rewind/po/ko.po
D src/bin/pg_rewind/po/pl.po
D src/bin/pg_rewind/po/pt_BR.po
M src/bin/pg_rewind/po/ru.po
M src/bin/pg_rewind/po/sv.po
D src/bin/pg_rewind/po/tr.po
M src/bin/pg_rewind/po/uk.po
M src/bin/pg_test_fsync/nls.mk
D src/bin/pg_test_fsync/po/cs.po
D src/bin/pg_test_fsync/po/el.po
M src/bin/pg_test_fsync/po/es.po
D src/bin/pg_test_fsync/po/ko.po
D src/bin/pg_test_fsync/po/pl.po
M src/bin/pg_test_fsync/po/ru.po
D src/bin/pg_test_fsync/po/tr.po
M src/bin/pg_test_fsync/po/uk.po
D src/bin/pg_test_fsync/po/vi.po
D src/bin/pg_test_fsync/po/zh_CN.po
M src/bin/pg_test_timing/nls.mk
D src/bin/pg_test_timing/po/cs.po
M src/bin/pg_test_timing/po/es.po
D src/bin/pg_test_timing/po/ko.po
D src/bin/pg_test_timing/po/pl.po
D src/bin/pg_test_timing/po/tr.po
M src/bin/pg_test_timing/po/uk.po
D src/bin/pg_test_timing/po/vi.po
M src/bin/pg_upgrade/nls.mk
M src/bin/pg_upgrade/po/es.po
M src/bin/pg_upgrade/po/ka.po
M src/bin/pg_upgrade/po/ru.po
D src/bin/pg_upgrade/po/tr.po
M src/bin/pg_upgrade/po/uk.po
M src/bin/pg_verifybackup/po/es.po
M src/bin/pg_verifybackup/po/ru.po
M src/bin/pg_verifybackup/po/uk.po
M src/bin/pg_waldump/nls.mk
D src/bin/pg_waldump/po/cs.po
M src/bin/pg_waldump/po/de.po
D src/bin/pg_waldump/po/el.po
M src/bin/pg_waldump/po/es.po
M src/bin/pg_waldump/po/fr.po
M src/bin/pg_waldump/po/ja.po
M src/bin/pg_waldump/po/ka.po
D src/bin/pg_waldump/po/ko.po
M src/bin/pg_waldump/po/ru.po
M src/bin/pg_waldump/po/sv.po
D src/bin/pg_waldump/po/tr.po
M src/bin/pg_waldump/po/uk.po
D src/bin/pg_waldump/po/vi.po
D src/bin/pg_waldump/po/zh_CN.po
M src/bin/psql/nls.mk
M src/bin/psql/po/es.po
D src/bin/psql/po/he.po
D src/bin/psql/po/it.po
D src/bin/psql/po/pl.po
D src/bin/psql/po/pt_BR.po
M src/bin/psql/po/ru.po
D src/bin/psql/po/tr.po
M src/bin/psql/po/uk.po
D src/bin/psql/po/zh_TW.po
M src/bin/scripts/nls.mk
M src/bin/scripts/po/es.po
D src/bin/scripts/po/he.po
D src/bin/scripts/po/it.po
D src/bin/scripts/po/pl.po
D src/bin/scripts/po/pt_BR.po
M src/bin/scripts/po/ru.po
M src/bin/scripts/po/uk.po
M src/interfaces/ecpg/ecpglib/po/es.po
M src/interfaces/ecpg/ecpglib/po/ru.po
M src/interfaces/ecpg/ecpglib/po/uk.po
M src/interfaces/ecpg/preproc/po/es.po
M src/interfaces/ecpg/preproc/po/ru.po
M src/interfaces/ecpg/preproc/po/uk.po
M src/interfaces/libpq/nls.mk
M src/interfaces/libpq/po/de.po
M src/interfaces/libpq/po/es.po
D src/interfaces/libpq/po/he.po
D src/interfaces/libpq/po/it.po
M src/interfaces/libpq/po/ja.po
M src/interfaces/libpq/po/ka.po
D src/interfaces/libpq/po/pl.po
D src/interfaces/libpq/po/pt_BR.po
M src/interfaces/libpq/po/ru.po
M src/interfaces/libpq/po/sv.po
D src/interfaces/libpq/po/tr.po
M src/interfaces/libpq/po/uk.po
D src/interfaces/libpq/po/zh_TW.po
M src/pl/plperl/nls.mk
M src/pl/plperl/po/es.po
D src/pl/plperl/po/ro.po
M src/pl/plperl/po/ru.po
M src/pl/plperl/po/uk.po
D src/pl/plperl/po/zh_TW.po
M src/pl/plpgsql/src/nls.mk
M src/pl/plpgsql/src/po/es.po
D src/pl/plpgsql/src/po/ro.po
M src/pl/plpgsql/src/po/ru.po
M src/pl/plpgsql/src/po/uk.po
D src/pl/plpgsql/src/po/zh_TW.po
M src/pl/plpython/po/es.po
M src/pl/plpython/po/ka.po
M src/pl/plpython/po/ru.po
M src/pl/plpython/po/uk.po
M src/pl/tcl/nls.mk
M src/pl/tcl/po/es.po
D src/pl/tcl/po/pt_BR.po
D src/pl/tcl/po/ro.po
M src/pl/tcl/po/ru.po
M src/pl/tcl/po/uk.po
D src/pl/tcl/po/zh_TW.po

Update list of acknowledgments in release notes

commit   : 5483649cd6875c219beb10465b515ba096dc7f34    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 26 Sep 2022 12:57:12 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 26 Sep 2022 12:57:12 +0200    

Click here for diff

current through 15113bfb467a84688744b57b74a14550878d0224  

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

Doc: Remove the use of a duplicate word.

commit   : 15113bfb467a84688744b57b74a14550878d0224    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Mon, 26 Sep 2022 09:26:47 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Mon, 26 Sep 2022 09:26:47 +0530    

Click here for diff

This has been removed in HEAD by commit a234177906, so doing just backpatch  
to 15 where it was introduced in commit 860ea46ba7.  
  
Author: Zhang Mingli  
Discussion: https://postgr.es/m/OS0PR01MB57162559C01FE2848C12E8F7944D9@OS0PR01MB5716.jpnprd01.prod.outlook.com  

M doc/src/sgml/runtime.sgml

Fix tupdesc lifespan bug with AfterTriggersTableData.storeslot.

commit   : c82766c0298a6c73b1e768b9239288d96879286e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 25 Sep 2022 17:10:58 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 25 Sep 2022 17:10:58 -0400    

Click here for diff

Commit 25936fd46 adjusted things so that the "storeslot" we use  
for remapping trigger tuples would have adequate lifespan, but it  
neglected to consider the lifespan of the tuple descriptor that  
the slot depends on.  It turns out that in at least some cases, the  
tupdesc we are passing is a refcounted tupdesc, and the refcount for  
the slot's reference can get assigned to a resource owner having  
different lifespan than the slot does.  That leads to an error like  
"tupdesc reference 0x7fdef236a1b8 is not owned by resource owner  
SubTransaction".  Worse, because of a second oversight in the same  
commit, we'd try to free the same tupdesc refcount again while  
cleaning up after that error, leading to recursive errors and an  
"ERRORDATA_STACK_SIZE exceeded" PANIC.  
  
To fix the initial problem, let's just make a non-refcounted copy  
of the tupdesc we're supposed to use.  That seems likely to guard  
against additional problems, since there's no strong reason for  
this code to assume that what it's given is a refcounted tupdesc;  
in which case there's an independent hazard of the tupdesc having  
shorter lifespan than the slot does.  (I didn't bother trying to  
free said copy, since it should go away anyway when the (sub)  
transaction context is cleaned up.)  
  
The other issue can be fixed by making the code added to  
AfterTriggerFreeQuery work like the rest of that function, ie be  
sure that it doesn't try to free the same slot twice in the event  
of recursive error cleanup.  
  
While here, also clean up minor stylistic issues in the test case  
added by 25936fd46: don't use "create or replace function", as any  
name collision within the tests is likely to have ill effects  
that that won't mask; and don't use function names as generic as  
trigger_function1, especially if you're not going to drop them  
at the end of the test stanza.  
  
Per bug #17607 from Thomas Mc Kay.  Back-patch to v12, as the  
previous fix was.  
  
Discussion: https://postgr.es/m/17607-bd8ccc81226f7f80@postgresql.org  

M src/backend/commands/trigger.c
M src/test/regress/expected/triggers.out
M src/test/regress/sql/triggers.sql

Avoid loss of code coverage with unlogged-index test cases.

commit   : 7a84c35fe6dcec62c95d023ad057e5717d9304a1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 25 Sep 2022 13:10:10 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 25 Sep 2022 13:10:10 -0400    

Click here for diff

Commit 4fb5c794e intended to add coverage of some ambuildempty  
methods that were not getting reached, without removing any  
test coverage.  However, by changing a temp table to unlogged  
it managed to negate the intent of 4c51a2d1e, which means that  
we didn't have reliable test coverage of ginvacuum.c anymore.  
As things stand, much of that file might or might not get reached  
depending on timing, which seems pretty undesirable.  
  
Although this is only clearly broken for the GIN test, it seems  
best to revert 4fb5c794e altogether and instead add bespoke test  
cases covering unlogged indexes for these four AMs.  We don't  
need to do very much with them, so the extra tests are cheap.  
(Note that btree, hash, and bloom already have similar test cases,  
so they need no additional work.)  
  
We can also undo dec8ad367.  Since the testing deficiency that that  
hacked around was later fixed by 2f2e24d90, let's intentionally leave  
an unlogged table behind to improve test coverage in the modules that  
use the regression database for other test purposes.  (The case I used  
also leaves an unlogged sequence behind.)  
  
Per report from Alex Kozhemyakin.  Back-patch to v15 where the  
faulty test came in.  
  
Discussion: https://postgr.es/m/b00c8ee096ee46cd25c183125562a1a7@postgrespro.ru  

M src/test/regress/expected/brin.out
M src/test/regress/expected/gin.out
M src/test/regress/expected/gist.out
M src/test/regress/expected/spgist.out
M src/test/regress/sql/brin.sql
M src/test/regress/sql/gin.sql
M src/test/regress/sql/gist.sql
M src/test/regress/sql/spgist.sql

Add missing source files to pg_waldump/nls.mk

commit   : 7a41e34e68a9be767279d17e051555b9cb9477c9    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Sun, 25 Sep 2022 17:48:03 +0200    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Sun, 25 Sep 2022 17:48:03 +0200    

Click here for diff

M src/bin/pg_waldump/nls.mk

Message style improvements

commit   : 517484b5820e9e20057ff066b5df7d09cbb5f464    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 24 Sep 2022 18:38:35 -0400    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 24 Sep 2022 18:38:35 -0400    

Click here for diff

M src/backend/access/transam/xlogprefetcher.c
M src/backend/access/transam/xlogreader.c
M src/backend/backup/basebackup.c
M src/backend/backup/basebackup_server.c
M src/backend/catalog/pg_publication.c
M src/backend/commands/dbcommands.c
M src/backend/commands/publicationcmds.c
M src/backend/commands/subscriptioncmds.c
M src/backend/commands/trigger.c
M src/backend/executor/nodeModifyTable.c
M src/backend/postmaster/pgarch.c
M src/backend/replication/logical/tablesync.c
M src/backend/replication/logical/worker.c
M src/backend/replication/walsender.c
M src/backend/utils/activity/pgstat.c
M src/backend/utils/activity/pgstat_xact.c
M src/bin/pg_basebackup/pg_basebackup.c
M src/bin/pg_basebackup/pg_receivewal.c
M src/bin/pg_basebackup/streamutil.c
M src/bin/pg_basebackup/t/010_pg_basebackup.pl
M src/bin/pg_basebackup/t/020_pg_receivewal.pl
M src/bin/scripts/t/020_createdb.pl
M src/common/compression.c
M src/test/recovery/t/006_logical_decoding.pl
M src/test/regress/expected/foreign_key.out
M src/test/regress/expected/publication.out
M src/test/regress/expected/triggers.out
M src/test/subscription/t/027_nosuperuser.pl
M src/test/subscription/t/029_on_error.pl

Improve terminology

commit   : 8d985560fc1de6197323d4397d2a2bf762657463    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 23 Sep 2022 21:16:08 -0400    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 23 Sep 2022 21:16:08 -0400    

Click here for diff

Use "prepared transaction" instead of "two-phrase transaction".  This  
is in line with c5d67881d343a507269bde124a49df19e0296157.  

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

Doc: make an editorial pass over the v15 release notes.

commit   : 2b14b5b5d9d5cf2f039a90a670abaf7b2f37bbe6    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 23 Sep 2022 18:22:33 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 23 Sep 2022 18:22:33 -0400    

Click here for diff

Rearrange, reword, clarify, fix markup, etc etc.  
  
Also include commit bd8ac900d.  

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

Doc: minor cleanups.

commit   : cea5aa988ea84182f61b1b84d7dafe06e4d90a9b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 23 Sep 2022 18:20:11 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 23 Sep 2022 18:20:11 -0400    

Click here for diff

Improve a couple of things I noticed while working on v15  
release notes.  

M doc/src/sgml/config.sgml
M doc/src/sgml/ref/pgupgrade.sgml

pgstat: Fix transactional stats dropping for indexes

commit   : 43e496e242984320efcf42c51c1e2b379aa03344    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Fri, 23 Sep 2022 13:00:55 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Fri, 23 Sep 2022 13:00:55 -0700    

Click here for diff

Because index creation does not go through heap_create_with_catalog() we  
didn't call pgstat_create_relation(), leading to index stats of a newly  
created realtion not getting dropped during rollback. To fix, move the  
pgstat_create_relation() to heap_create(), which indexes do use.  
  
Similarly, because dropping an index does not go through  
heap_drop_with_catalog(), we didn't drop index stats when the transaction  
dropping an index committed. Here there's no convenient common path for  
indexes and relations, so index_drop() now calls pgstat_drop_relation().  
  
Add tests for transactional index stats handling.  
  
Author: "Drouvot, Bertrand" <bdrouvot@amazon.com>  
Reviewed-by: Andres Freund <andres@anarazel.de>  
Reviewed-by: Kyotaro Horiguchi <horikyota.ntt@gmail.com>  
Discussion: https://postgr.es/m/51bbf286-2b4a-8998-bd12-eaae4b765d99@amazon.com  
Backpatch: 15-, like 8b1dccd37c71, which introduced the bug  

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

Doc: update v15 release notes through today.

commit   : e956325c8bc8c7257b04c322bf996fff2d81b514    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 23 Sep 2022 13:59:29 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 23 Sep 2022 13:59:29 -0400    

Click here for diff

Account for commits since 2022-06-11.  

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

Remove PQsendQuery support in pipeline mode

commit   : bd8ac900df4d2824f50ce4b1674754685aeaed56    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 23 Sep 2022 18:21:22 +0200    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 23 Sep 2022 18:21:22 +0200    

Click here for diff

The extended query protocol implementation I added in commit  
acb7e4eb6b1c has bugs when used in pipeline mode.  Rather than spend  
more time trying to fix it, remove that code and make the function rely  
on simple query protocol only, meaning it can no longer be used in  
pipeline mode.  
  
Users can easily change their applications to use PQsendQueryParams  
instead.  We leave PQsendQuery in place for Postgres 14, just in case  
somebody is using it and has not hit the mentioned bugs; but we should  
recommend that it not be used.  
  
Backpatch to 15.  
  
Per bug report from Gabriele Varrazzo.  
Discussion: https://postgr.es/m/CA+mi_8ZGSQNmW6-mk_iSR4JZB_LJ4ww3suOF+1vGNs3MrLsv4g@mail.gmail.com  

M doc/src/sgml/libpq.sgml
M src/interfaces/libpq/fe-exec.c
M src/interfaces/libpq/fe-protocol3.c
M src/test/modules/libpq_pipeline/libpq_pipeline.c

Stop using PQsendQuery in libpq_pipeline

commit   : 27e04412c9c3c3c3b2d182821c759f95693c0039    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 23 Sep 2022 18:11:48 +0200    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 23 Sep 2022 18:11:48 +0200    

Click here for diff

The "emulation" I wrote for PQsendQuery in pipeline mode to use extended  
query protocol, in commit acb7e4eb6b1c, is problematic.  Due to numerous  
bugs we'll soon remove it.  As a first step and for all branches back to  
14, stop using PQsendQuery in libpq_pipeline.  Also remove a few test  
lines that will no longer be relevant.  
  
Backpatch to 14.  
  
Discussion: https://postgr.es/m/CA+mi_8ZGSQNmW6-mk_iSR4JZB_LJ4ww3suOF+1vGNs3MrLsv4g@mail.gmail.com  

M src/test/modules/libpq_pipeline/libpq_pipeline.c
M src/test/modules/libpq_pipeline/traces/pipeline_abort.trace
M src/test/modules/libpq_pipeline/traces/pipeline_idle.trace

Doc: add list of major features to the v15 release notes.

commit   : a2ab0ad88cf87e0dcd9fc4c7fcfac132a4e88d2a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 23 Sep 2022 11:24:12 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 23 Sep 2022 11:24:12 -0400    

Click here for diff

Jonathan Katz (word-smithed a bit by me)  
  
Discussion: https://postgr.es/m/a6661e2c-72e0-b4bd-9301-9225bdddda4c@postgresql.org  

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

Allow publications with schema and table of the same schema.

commit   : b7256753ec251fd6a1f6bd205dbe62ccbb3261c4    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Fri, 23 Sep 2022 08:08:24 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Fri, 23 Sep 2022 08:08:24 +0530    

Click here for diff

We previously thought that allowing such cases can confuse users when they  
specify DROP TABLES IN SCHEMA but that doesn't seem to be the case based  
on discussion. This helps to uplift the restriction during  
ALTER TABLE ... SET SCHEMA which used to ensure that we couldn't end up  
with a publication having both a schema and the same schema's table.  
  
To allow this, we need to forbid having any schema on a publication if  
column lists on a table are specified (and vice versa). This is because  
otherwise we still need a restriction during ALTER TABLE ... SET SCHEMA to  
forbid cases where it could lead to a publication having both a schema and  
the same schema's table with column list.  
  
Based on suggestions by Peter Eisentraut.  
  
Author: Hou Zhijie and Vignesh C  
Reviewed-By: Peter Smith, Amit Kapila  
Backpatch-through: 15, where it was introduced  
Discussion: https://postgr.es/m/2729c9e2-9aac-8cda-f2f4-34f2bcc18f4e@enterprisedb.com  

M doc/src/sgml/logical-replication.sgml
M doc/src/sgml/ref/alter_publication.sgml
M doc/src/sgml/ref/create_publication.sgml
M src/backend/catalog/pg_publication.c
M src/backend/commands/publicationcmds.c
M src/backend/commands/tablecmds.c
M src/backend/replication/pgoutput/pgoutput.c
M src/bin/pg_dump/t/002_pg_dump.pl
M src/test/regress/expected/alter_table.out
M src/test/regress/expected/publication.out
M src/test/regress/sql/alter_table.sql
M src/test/regress/sql/publication.sql
M src/test/subscription/t/028_row_filter.pl

Fix race condition where heap_delete() fails to pin VM page.

commit   : dd6070bc81733c3174f2e257d43908f98b0255fb    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Thu, 22 Sep 2022 10:58:49 -0700    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Thu, 22 Sep 2022 10:58:49 -0700    

Click here for diff

Similar to 5f12bc94dc, the code must re-check PageIsAllVisible() after  
buffer lock is re-acquired. Backpatching to the same version, 12.  
  
Discussion: https://postgr.es/m/CAEP4nAw9jYQDKd_5Y+-s2E4YiUJq1vqiikFjYGpLShtp-K3gag@mail.gmail.com  
Reported-by: Robins Tharakan  
Reviewed-by: Robins Tharakan  
Backpatch-through: 12  

M src/backend/access/heap/heapam.c

Remove ALL keyword from TABLES IN SCHEMA for publication

commit   : f256236fb1b00e9d05f889a53e93feeecbd50991    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 22 Sep 2022 19:02:25 +0200    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 22 Sep 2022 19:02:25 +0200    

Click here for diff

This may be a bit too subtle, but removing that word from there makes  
this clause no longer a perfect parallel of the GRANT variant "ALL  
TABLES IN SCHEMA": indeed, for publications what we record is the schema  
itself, not the tables therein, which means that any tables added to the  
schema in the future are also published.  This is completely different  
to what GRANT does, which is affect only the tables that exist when the  
command is executed.  
  
There isn't resounding support for this change, but there are a few  
positive votes and no opposition.  Because the time to 15 RC1 is very  
short, let's get this out now.  
  
Backpatch to 15.  
  
Discussion: https://postgr.es/m/2729c9e2-9aac-8cda-f2f4-34f2bcc18f4e  

M doc/src/sgml/logical-replication.sgml
M doc/src/sgml/ref/alter_publication.sgml
M doc/src/sgml/ref/create_publication.sgml
M doc/src/sgml/ref/create_subscription.sgml
M doc/src/sgml/system-views.sgml
M src/backend/catalog/pg_publication.c
M src/backend/commands/publicationcmds.c
M src/backend/parser/gram.y
M src/backend/replication/pgoutput/pgoutput.c
M src/bin/pg_dump/pg_dump.c
M src/bin/pg_dump/t/002_pg_dump.pl
M src/bin/psql/tab-complete.c
M src/test/regress/expected/alter_table.out
M src/test/regress/expected/object_address.out
M src/test/regress/expected/publication.out
M src/test/regress/sql/alter_table.sql
M src/test/regress/sql/object_address.sql
M src/test/regress/sql/publication.sql
M src/test/subscription/t/025_rep_changes_for_schema.pl
M src/test/subscription/t/028_row_filter.pl
M src/test/subscription/t/031_column_list.pl

Restore archive_command documentation

commit   : 5f56933ea5d5b0b1a0bbe4c7b8f5110f8fe256ed    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 17 Sep 2022 11:34:20 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 17 Sep 2022 11:34:20 +0200    

Click here for diff

Commit 5ef1eefd76f404ddc59b885d50340e602b70f05f, which added  
archive_library, purged most mentions of archive_command from the  
documentation.  This is inappropriate, since archive_command is still  
a feature in use and users will want to see information about it.  
  
This restores all the removed mentions and rephrases things so that  
archive_command and archive_library are presented as alternatives of  
each other.  
  
Reviewed-by: Nathan Bossart <nathandbossart@gmail.com>  
Discussion: https://www.postgresql.org/message-id/9366d634-a917-85a9-4991-b2a4859edaf9@enterprisedb.com  

M doc/src/sgml/backup.sgml
M doc/src/sgml/config.sgml
M doc/src/sgml/high-availability.sgml
M doc/src/sgml/ref/pg_receivewal.sgml
M doc/src/sgml/wal.sgml

Use min/max bounds defined by Zstd for compression level

commit   : ade925e1693a595ef1c278583fa699ca6fc1ff45    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 22 Sep 2022 20:03:30 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 22 Sep 2022 20:03:30 +0900    

Click here for diff

The bounds hardcoded in compression.c since ffd5365 (minimum at 1 and  
maximum at 22) do not match the reality of what zstd is able to  
handle, these values being available via ZSTD_maxCLevel() and  
ZSTD_minCLevel() at run-time.  The maximum of 22 is actually correct  
in recent versions, but the minimum was not as the library can go down  
to -131720 by design.  This commit changes the code to use the run-time  
values in the code instead of some hardcoded ones.  
  
Zstd seems to assume that these bounds could change in the future, and  
Postgres will be able to adapt automatically to such changes thanks to  
what's being done in this commit.  
  
Reported-by: Justin Prysby  
Discussion: https://postgr.es/m/20220922033716.GL31833@telsasoft.com  
Backpatch-through: 15  

M doc/src/sgml/protocol.sgml
M src/common/compression.c

Fix thinko in comment.

commit   : 901ef14afe981065a0c5c61b1759d36482869d98    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Thu, 22 Sep 2022 15:55:01 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Thu, 22 Sep 2022 15:55:01 +0900    

Click here for diff

This comment has been wrong since its introduction in commit 0d5f05cde;  
backpatch to v12 where that came in.  
  
Discussion: https://postgr.es/m/CAPmGK14VGf-xQjGQN4o1QyAbXAaxugU5%3DqfcmTDh1iufUDnV_w%40mail.gmail.com  

M src/backend/commands/copyfrom.c

Clear ps display of startup process at the end of recovery

commit   : 848c323c1295dd724587d9c91275414db15e2772    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 22 Sep 2022 14:25:12 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 22 Sep 2022 14:25:12 +0900    

Click here for diff

If the ps display is not cleared at this point, the process could  
continue displaying "recovering NNN" even if handling end-of-recovery  
steps.  df9274a has tackled that by providing some information with the  
end-of-recovery checkpoint but 7ff23c6 has nullified the effect of the  
first commit.  
  
Per a suggestion from Justin, just clear the ps display when we are done  
with recovery, so as no incorrect information is displayed.  This may  
get extended in the future, but for now restore the pre-7ff23c6  
behavior.  
  
Author: Justin Prysby  
Discussion: https://postgr.es/m/20220913223954.GU31833@telsasoft.com  
Backpatch-through: 15  

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

docs: Fix snapshot name in SET TRANSACTION docs.

commit   : 4230279f357602bd99c038e0aec8087a7076522b    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Thu, 22 Sep 2022 12:54:26 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Thu, 22 Sep 2022 12:54:26 +0900    

Click here for diff

Commit 6c2003f8a1 changed the snapshot names mentioned in  
SET TRANSACTION docs, however, there was one place that  
the commit missed updating the name.  
  
Back-patch to all supported versions.  
  
Author: Japin Li  
Reviewed-by: Fujii Masao  
Discussion: https://postgr.es/m/MEYP282MB1669BD4280044501165F8B07B64F9@MEYP282MB1669.AUSP282.PROD.OUTLOOK.COM  

M doc/src/sgml/ref/set_transaction.sgml

psql: Improve tab-completion for MERGE.

commit   : f80919df950ab05cbe79c7ab34fb359aa79641d4    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Thu, 22 Sep 2022 09:25:29 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Thu, 22 Sep 2022 09:25:29 +0900    

Click here for diff

Commit 7103ebb7aa added the tab-completion for MERGE accidentally  
in the middle of that for LOCK TABLE. This commit fixes this issue.  
  
This also adds some tab-completion for MERGE.  
  
Back-patch to v15 where MERGE was introduced.  
  
Author: Kotaro Kawamoto, Fujii Masao  
Reviewed-by: Shinya Kato, Álvaro Herrera  
Discussion: https://postgr.es/m/9f1ad2a87a58cd5e7d64f3993130958d@oss.nttdata.com  

M src/bin/psql/tab-complete.c

ci: windows: set error mode to not include SEM_NOGPFAULTERRORBOX

commit   : 0c400445dbe316d67d19f79fdd096f0b77458b86    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Wed, 21 Sep 2022 17:15:54 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Wed, 21 Sep 2022 17:15:54 -0700    

Click here for diff

Cirrus defaults to SetErrorMode(SEM_NOGPFAULTERRORBOX | ...). That prevents  
crash reporting from working unless binaries do SetErrorMode()  
themselves. Furthermore, it appears that either python or, more likely, the C  
runtime has a bug where SEM_NOGPFAULTERRORBOX can very occasionally *trigger*  
a crash on process exit - which is hard to debug, given that it explicitly  
prevents crash dumps from working...  
  
Discussion: https://postgr.es/m/20220909235836.lz3igxtkcjb5w7zb%40awork3.anarazel.de  
Backpatch: 15-, where CI was added  

M .cirrus.yml

ci: Increase requested memory size.

commit   : 08ddb3c0852d87394b44eea45709b9d9b8154f68    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Thu, 22 Sep 2022 11:35:46 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Thu, 22 Sep 2022 11:35:46 +1200    

Click here for diff

CI builds recently started failing with:  
  
"Memory size for 4.0 vCPU instance should be between 3840MiB and  
26624MiB, while 2048MiB is requested."  
  
Ok then, let's ask for 4G instead of 2G.  
  
This may be due to a change in the type of instance used to work around  
an outage, per:  
  
https://twitter.com/cirrus_labs/status/1572657320093712384  

M .cirrus.yml

Improve ICU option handling in CREATE DATABASE

commit   : 865b52af61049719e0a289419a0eceded6ea7bae    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 21 Sep 2022 10:28:40 -0400    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 21 Sep 2022 10:28:40 -0400    

Click here for diff

We check that the ICU locale is only specified if the ICU locale  
provider is selected.  But we did that too early.  We need to wait  
until we load the settings of the template database, since that could  
also set what the locale provider is.  
  
Reported-by: Marina Polyakova <m.polyakova@postgrespro.ru>  
Discussion: https://www.postgresql.org/message-id/9ba4cd1ea6ed6b7b15c0ff15e6f540cd@postgrespro.ru  

M src/backend/commands/dbcommands.c
M src/bin/scripts/t/020_createdb.pl

Tighten pg_get_object_address argument checking

commit   : ab7032b3a8fec281db71acfc37c5c92fc65b08ae    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 21 Sep 2022 09:34:22 -0400    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 21 Sep 2022 09:34:22 -0400    

Click here for diff

For publication schemas (OBJECT_PUBLICATION_NAMESPACE) and user  
mappings (OBJECT_USER_MAPPING), pg_get_object_address() checked the  
array length of the second argument, but not of the first argument.  
If the first argument was too long, it would just silently ignore  
everything but the first argument.  Fix that by checking the length of  
the first argument as well.  
  
Reviewed-by: Amit Kapila <amit.kapila16@gmail.com>  
Discussion: https://www.postgresql.org/message-id/flat/caaef70b-a874-1088-92ef-5ac38269c33b%40enterprisedb.com  

M src/backend/catalog/objectaddress.c
M src/test/regress/expected/object_address.out
M src/test/regress/sql/object_address.sql

Improve some GUC description strings

commit   : 1d3955266a5d9e71dc002634926210ccab8b15dc    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 21 Sep 2022 12:29:38 +0200    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 21 Sep 2022 12:29:38 +0200    

Click here for diff

It is not our usual style to use "we" in messages.  Also, remove some  
noise words.  Backpatch to 15.  
  
Noted by Kyotaro Horiguchi.  
  
Discussion: https://postgr.es/m/20220914.111507.13049297635620898.horikyota.ntt@gmail.com  

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

Disable -Wdeprecated-non-prototype in the back branches.

commit   : f9a56e726334e4776ac0e5b2ead282793c1d9857    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 20 Sep 2022 18:59:53 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 20 Sep 2022 18:59:53 -0400    

Click here for diff

There doesn't seem to be any good ABI-preserving way to silence  
clang 15's -Wdeprecated-non-prototype warnings about our tree-walk  
APIs.  While we've fixed it properly in HEAD, the only way to not  
see hundreds of these in the back branches is to disable the  
warnings.  We're not going to do anything about them, so we might  
as well disable them.  
  
I noticed that we also get some of these warnings about fmgr.c's  
support for V0 function call convention, in branches before v10  
where we removed that.  That's another area we aren't going to  
change, so turning off the warning seems fine for that too.  
  
Per project policy, this is a candidate for back-patching into  
out-of-support branches: it suppresses annoying compiler warnings  
but changes no behavior.  Hence, back-patch all the way to 9.2.