PostgreSQL 12.18 commit log

Stamp 12.18.

commit   : 3ba17930941ea629b2ffb5cd252f3055d4d4a9a6    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 5 Feb 2024 16:48:53 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 5 Feb 2024 16:48:53 -0500    

Click here for diff

M configure
M configure.in
M src/include/pg_config.h.win32
M src/interfaces/libpq/libpq.rc.in
M src/port/win32ver.rc

Last-minute updates for release notes.

commit   : 84e6a6e40ffc8e7e42279c6932bd1b9b7f6e24d9    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 5 Feb 2024 11:51:11 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 5 Feb 2024 11:51:11 -0500    

Click here for diff

Security: CVE-2024-0985 (not CVE-2023-5869 as claimed in prior commit msg)  

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

Translation updates

commit   : 8727cd5efb1ba6abd21de01e8c2a6839f0f853a7    
  
author   : Peter Eisentraut <[email protected]>    
date     : Mon, 5 Feb 2024 14:52:35 +0100    
  
committer: Peter Eisentraut <[email protected]>    
date     : Mon, 5 Feb 2024 14:52:35 +0100    

Click here for diff

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

M src/backend/po/de.po
M src/backend/po/es.po
M src/backend/po/fr.po
M src/backend/po/it.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/tr.po
M src/backend/po/uk.po
M src/backend/po/zh_CN.po
M src/bin/pg_upgrade/po/uk.po
M src/bin/pg_waldump/po/de.po
M src/bin/psql/po/ja.po
M src/bin/scripts/po/uk.po

Fix assertion if index is dropped during REFRESH CONCURRENTLY

commit   : add8bc9b8c31fd0c7acfd64a4e2af71ea7b6b58c    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Mon, 5 Feb 2024 11:01:30 +0200    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Mon, 5 Feb 2024 11:01:30 +0200    

Click here for diff

When assertions are disabled, the built SQL statement is invalid and  
you get a "syntax error". So this isn't a serious problem, but let's  
avoid the assertion failure.  
  
Backpatch to all supported versions.  
  
Reviewed-by: Noah Misch  

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

Run REFRESH MATERIALIZED VIEW CONCURRENTLY in right security context

commit   : 2699fc035a75d0774c1f013e9320882287f78adb    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Mon, 5 Feb 2024 11:01:23 +0200    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Mon, 5 Feb 2024 11:01:23 +0200    

Click here for diff

The internal commands in REFRESH MATERIALIZED VIEW CONCURRENTLY are  
correctly executed in SECURITY_RESTRICTED_OPERATION mode, except for  
creating the temporary "diff" table, because you cannot create  
temporary tables in SRO mode. But creating the temporary "diff" table  
is a pretty complex CTAS command that selects from another temporary  
table created earlier in the command. If you can cajole that CTAS  
command to execute code defined by the table owner, the table owner  
can run code with the privileges of the user running the REFRESH  
command.  
  
The proof-of-concept reported to the security team relied on CREATE  
RULE to convert the internally-built temp table to a view. That's not  
possible since commit b23cd185fd, and I was not able to find a  
different way to turn the SELECT on the temp table into code  
execution, so as far as I know this is only exploitable in v15 and  
below. That's a fiddly assumption though, so apply this patch to  
master and all stable versions.  
  
Thanks to Pedro Gallegos for the report.  
  
Security: CVE-2023-5869  
Reviewed-by: Noah Misch  

M src/backend/commands/matview.c

Release notes for 16.2, 15.6, 14.11, 13.14, 12.18.

commit   : 0551142a17d1f92d82c38723a89b8e89fe6b952b    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 4 Feb 2024 14:17:14 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 4 Feb 2024 14:17:14 -0500    

Click here for diff

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

Translate ENOMEM to ERRCODE_OUT_OF_MEMORY in errcode_for_file_access().

commit   : 4493bfb709ae1b83e537daf82014d9b5ad65b26d    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 2 Feb 2024 15:34:29 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 2 Feb 2024 15:34:29 -0500    

Click here for diff

Previously you got ERRCODE_INTERNAL_ERROR, which seems inappropriate,  
especially given that we're trying to avoid emitting that in reachable  
cases.  
  
Alexander Kuzmenkov  
  
Discussion: https://postgr.es/m/CALzhyqzgQph0BY8-hFRRGdHhF8CoqmmDHW9S=hMZ-HMzLxRqDQ@mail.gmail.com  

M src/backend/utils/error/elog.c

Update time zone data files to tzdata release 2024a.

commit   : b59ae79b72165b0f50651b82a16c40611c238ffa    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 1 Feb 2024 15:57:53 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 1 Feb 2024 15:57:53 -0500    

Click here for diff

DST law changes in Ittoqqortoormiit, Greenland (America/Scoresbysund),  
Kazakhstan (Asia/Almaty and Asia/Qostanay) and Palestine; as well as  
updates for the Antarctic stations Casey and Vostok.  
  
Historical corrections for Vietnam, Toronto, and Miquelon.  

M src/timezone/data/tzdata.zi

Avoid package qualification of $windows_os

commit   : 709d6fbcacd6cc2327cdb20ee0db502a34cbc884    
  
author   : Andrew Dunstan <[email protected]>    
date     : Thu, 1 Feb 2024 15:17:41 -0500    
  
committer: Andrew Dunstan <[email protected]>    
date     : Thu, 1 Feb 2024 15:17:41 -0500    

Click here for diff

Further fallout from commit 6ee26c6a4b. To keep code in sync and avoid  
issues on older releases with different package names, simply use the  
unqualified name like many other places in our code.  

M src/bin/pg_rewind/t/003_extrafiles.pl

Apply band-aid fix for an oversight in reparameterize_path_by_child.

commit   : 2e822a1d62d0f78b7d471076ea982cd0734cc875    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 1 Feb 2024 12:34:21 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 1 Feb 2024 12:34:21 -0500    

Click here for diff

The path we wish to reparameterize is not a standalone object:  
in particular, it implicitly references baserestrictinfo clauses  
in the associated RelOptInfo, and if it's a SampleScan path then  
there is also the TableSampleClause in the RTE to worry about.  
Both of those could contain lateral references to the join partner  
relation, which would need to be modified to refer to its child.  
Since we aren't doing that, affected queries can give wrong answers,  
or odd failures such as "variable not found in subplan target list",  
or executor crashes.  But we can't just summarily modify those  
expressions, because they are shared with other paths for the rel.  
We'd break things if we modify them and then end up using some  
non-partitioned-join path.  
  
In HEAD, we plan to fix this by postponing reparameterization  
until create_plan(), when we know that those other paths are  
no longer of interest, and then adjusting those expressions along  
with the ones in the path itself.  That seems like too big a change  
for stable branches however.  In the back branches, let's just detect  
whether any troublesome lateral references actually exist in those  
expressions, and fail reparameterization if so.  This will result in  
not performing a partitioned join in such cases.  Given the lack of  
field complaints, nobody's likely to miss the optimization.  
  
Report and patch by Richard Guo.  Apply to 12-16 only, since  
the intended fix for HEAD looks quite different.  We're not quite  
ready to push the HEAD fix, but with back-branch releases coming  
up soon, it seems wise to get this stopgap fix in place there.  
  
Discussion: https://postgr.es/m/CAMbWs496+N=UAjOc=rcD3P7B6oJe4rZw08e_TZRUsWbPxZW3Tw@mail.gmail.com  

M src/backend/optimizer/util/pathnode.c
M src/test/regress/expected/partition_join.out
M src/test/regress/sql/partition_join.sql

doc: remove incorrect grammar for ALTER EVENT TRIGGER

commit   : 43eb5c6a479cf7c2c18cf245ff1eed73ed84b768    
  
author   : Daniel Gustafsson <[email protected]>    
date     : Thu, 1 Feb 2024 10:45:37 +0100    
  
committer: Daniel Gustafsson <[email protected]>    
date     : Thu, 1 Feb 2024 10:45:37 +0100    

Click here for diff

The Parameters subsection had an extra TRIGGER in the grammar  
for DISABLE/ENABLE which is incorrect.  Backpatch down to all  
supported versions since it's been like this all along.  
  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: v12  

M doc/src/sgml/ref/alter_event_trigger.sgml

Fix various issues with ALTER TEXT SEARCH CONFIGURATION

commit   : 0561097822a1462391f4f44665ecf831ce523b6e    
  
author   : Michael Paquier <[email protected]>    
date     : Wed, 31 Jan 2024 13:16:50 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Wed, 31 Jan 2024 13:16:50 +0900    

Click here for diff

This commit addresses a set of issues when changing token type mappings  
in a text search configuration when using duplicated token names:  
- ADD MAPPING would fail on insertion because of a constraint failure  
after inserting the same mapping.  
- ALTER MAPPING with an "overridden" configuration failed with "tuple  
already updated by self" when the token mappings are removed.  
- DROP MAPPING failed with "tuple already updated by self", like  
previously, but in a different code path.  
  
The code is refactored so the token names (with their numbers) are  
handled as a List with unique members rather than an array with numbers,  
ensuring that no duplicates mess up with the catalog inserts, updates  
and deletes.  The list is generated by getTokenTypes(), with the same  
error handling as previously while duplicated tokens are discarded from  
the list used to work on the catalogs.  
  
Regression tests are expanded to cover much more ground for the cases  
fixed by this commit, as there was no coverage for the code touched in  
this commit.  A bit more is done regarding the fact that a token name  
not supported by a configuration's parser should result in an error even  
if IF EXISTS is used in a DROP MAPPING clause.  This is implied in the  
code but there was no coverage for that, and it was very easy to miss.  
  
These issues exist since at least their introduction in core with  
140d4ebcb46e, so backpatch all the way down.  
  
Reported-by: Alexander Lakhin  
Author: Tender Wang, Michael Paquier  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 12  

M src/backend/commands/tsearchcmds.c
M src/test/regress/expected/tsdicts.out
M src/test/regress/sql/tsdicts.sql
M src/tools/pgindent/typedefs.list

Use older name for test_primary_datadir

commit   : c944bf2f07f26aff9fcdfb8f4bf0e4973daeac54    
  
author   : Andrew Dunstan <[email protected]>    
date     : Tue, 30 Jan 2024 19:19:55 -0500    
  
committer: Andrew Dunstan <[email protected]>    
date     : Tue, 30 Jan 2024 19:19:55 -0500    

Click here for diff

Releases prior to  14 used the older naming scheme. This  fixes a bug un  
the back-patches of 6ee26c6a4b in releases 12 and 13.  

M src/bin/pg_rewind/t/003_extrafiles.pl

Fix 003_extrafiles.pl test for the Windows

commit   : e894d1d829196a482511577de743088e4e0aed76    
  
author   : Andrew Dunstan <[email protected]>    
date     : Tue, 30 Jan 2024 17:09:44 -0500    
  
committer: Andrew Dunstan <[email protected]>    
date     : Tue, 30 Jan 2024 17:09:44 -0500    

Click here for diff

File::Find converts backslashes to slashes in the newer Perl versions.  
See: https://github.com/Perl/perl5/commit/414f14df98cb1c9a20f92c5c54948b67c09f072d  
  
So, do the same conversion for Windows before comparing paths. To  
support all Perl versions, always convert them on Windows regardless of  
the Perl's version.  
  
Author: Nazir Bilal Yavuz <[email protected]>  
  
Backpatch to all live branches  

M src/bin/pg_rewind/t/003_extrafiles.pl

pgcrypto: Fix check for buffer size

commit   : c29022164f8a25d7b22763374c10a0c8311abcff    
  
author   : Daniel Gustafsson <[email protected]>    
date     : Tue, 30 Jan 2024 11:15:46 +0100    
  
committer: Daniel Gustafsson <[email protected]>    
date     : Tue, 30 Jan 2024 11:15:46 +0100    

Click here for diff

The code copying the PGP block into the temp buffer failed to  
account for the extra 2 bytes in the buffer which are needed  
for the prefix. If the block was oversized, subsequent checks  
of the prefix would have exceeded the buffer size.  Since the  
block sizes are hardcoded in the list of supported ciphers it  
can be verified that there is no live bug here. Backpatch all  
the way for consistency though, as this bug is old.  
  
Author: Mikhail Gribkov <[email protected]>  
Discussion: https://postgr.es/m/CAMEv5_uWvcMCMdRFDsJLz2Q8g16HEa9xWyfrkr+FYMMFJhawOw@mail.gmail.com  
Backpatch-through: v12  

M contrib/pgcrypto/pgp-decrypt.c

Doc: mention foreign keys can reference unique indexes

commit   : dff1756c392ec7e3ac9b0b4bb2112a594765902a    
  
author   : David Rowley <[email protected]>    
date     : Tue, 30 Jan 2024 10:17:31 +1300    
  
committer: David Rowley <[email protected]>    
date     : Tue, 30 Jan 2024 10:17:31 +1300    

Click here for diff

We seem to have only documented a foreign key can reference the columns of  
a primary key or unique constraint.  Here we adjust the documentation  
to mention columns in a non-partial unique index can be mentioned too.  
  
The header comment for transformFkeyCheckAttrs() also didn't mention  
unique indexes, so fix that too.  In passing make that header comment  
reflect reality in the various other aspects where it deviated from it.  
  
Bug: 18295  
Reported-by: Gilles PARC  
Author: Laurenz Albe, David Rowley  
Discussion: https://www.postgresql.org/message-id/18295-0ed0fac5c9f7b17b%40postgresql.org  
Backpatch-through: 12  

M doc/src/sgml/ddl.sgml
M doc/src/sgml/ref/create_table.sgml
M src/backend/commands/tablecmds.c

Fix incompatibilities with libxml2 >= 2.12.0.

commit   : b2fd1dab90240ebb9017cd2fddd731c3641ba434    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 29 Jan 2024 12:06:08 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 29 Jan 2024 12:06:08 -0500    

Click here for diff

libxml2 changed the required signature of error handler callbacks  
to make the passed xmlError struct "const".  This is causing build  
failures on buildfarm member caiman, and no doubt will start showing  
up in the field quite soon.  Add a version check to adjust the  
declaration of xml_errorHandler() according to LIBXML_VERSION.  
  
2.12.x also produces deprecation warnings for contrib/xml2/xpath.c's  
assignment to xmlLoadExtDtdDefaultValue.  I see no good reason for  
that to still be there, seeing that we disabled external DTDs (at a  
lower level) years ago for security reasons.  Let's just remove it.  
  
Back-patch to all supported branches, since they might all get built  
with newer libxml2 once it gets a bit more popular.  (The back  
branches produce another deprecation warning about xpath.c's use of  
xmlSubstituteEntitiesDefault().  We ought to consider whether to  
back-patch all or part of commit 65c5864d7 to silence that.  It's  
less urgent though, since it won't break the buildfarm.)  
  
Discussion: https://postgr.es/m/[email protected]  

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

Fix locking when fixing an incomplete split of a GIN internal page

commit   : e6511fe649c5ae6bb647258b634f3730cee3195b    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Mon, 29 Jan 2024 13:46:22 +0200    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Mon, 29 Jan 2024 13:46:22 +0200    

Click here for diff

ginFinishSplit() expects the caller to hold an exclusive lock on the  
buffer, but when finishing an earlier "leftover" incomplete split of  
an internal page, the caller held a shared lock. That caused an  
assertion failure in MarkBufferDirty(). Without assertions, it could  
lead to corruption if two backends tried to complete the split at the  
same time.  
  
On master, add a test case using the new injection point facility.  
  
Report and analysis by Fei Changhong. Backpatch the fix to all  
supported versions.  
  
Reviewed-by: Fei Changhong, Michael Paquier  
Discussion: https://www.postgresql.org/message-id/[email protected]  

M src/backend/access/gin/ginbtree.c

Detect Julian-date overflow in timestamp[tz]_pl_interval.

commit   : c3bdb25fb5f69e2b29b5d55725a134f95a9a423f    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 26 Jan 2024 13:39:37 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 26 Jan 2024 13:39:37 -0500    

Click here for diff

We perform addition of the days field of an interval via  
arithmetic on the Julian-date representation of the timestamp's date.  
This step is subject to int32 overflow, and we also should not let  
the Julian date become very negative, for fear of weird results from  
j2date.  (In the timestamptz case, allow a Julian date of -1 to pass,  
since it might convert back to zero after timezone rotation.)  
  
The additions of the months and microseconds fields could also  
overflow, of course.  However, I believe we need no additional  
checks there; the existing range checks should catch such cases.  
The difficulty here is that j2date's magic modular arithmetic could  
produce something that looks like it's in-range.  
  
Per bug #18313 from Christian Maurer.  This has been wrong for  
a long time, so back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/[email protected]  

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

Track LLVM 18 changes.

commit   : d060cb65880fe950774c6f3f9facf0f87504bfb3    
  
author   : Thomas Munro <[email protected]>    
date     : Thu, 25 Jan 2024 10:37:35 +1300    
  
committer: Thomas Munro <[email protected]>    
date     : Thu, 25 Jan 2024 10:37:35 +1300    

Click here for diff

A function was given a newly standard name from C++20 in LLVM 16.  Then  
LLVM 18 added a deprecation warning for the old name, and it is about to  
ship, so it's time to adjust that.  
  
Back-patch to all supported releases.  
  
Discussion: https://www.postgresql.org/message-id/CA+hUKGLbuVhH6mqS8z+FwAn4=5dHs0bAWmEMZ3B+iYHWKC4-ZA@mail.gmail.com  

M src/backend/jit/llvm/llvmjit_inline.cpp

Fix ALTER TABLE .. ADD COLUMN with complex inheritance trees

commit   : 2f724283719e75261d3b649d20235e4f1542be04    
  
author   : Michael Paquier <[email protected]>    
date     : Wed, 24 Jan 2024 14:20:14 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Wed, 24 Jan 2024 14:20:14 +0900    

Click here for diff

This command, when used to add a column on a parent table with a complex  
inheritance tree, tried to update multiple times the same tuple in  
pg_attribute for a child table when incrementing attinhcount, causing  
failures with "tuple already updated by self" because of a missing  
CommandCounterIncrement() between two updates.  
  
This exists for a rather long time, so backpatch all the way down.  
  
Reported-by: Alexander Lakhin  
Author: Tender Wang  
Reviewed-by: Richard Guo  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 12  

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

lwlock: Fix quadratic behavior with very long wait lists

commit   : 81038228582aa92718be2afcb7ddb67a5a19fa43    
  
author   : Andres Freund <[email protected]>    
date     : Sun, 20 Nov 2022 11:56:32 -0800    
  
committer: Michael Paquier <[email protected]>    
date     : Sun, 20 Nov 2022 11:56:32 -0800    

Click here for diff

Until now LWLockDequeueSelf() sequentially searched the list of waiters to see  
if the current proc is still is on the list of waiters, or has already been  
removed. In extreme workloads, where the wait lists are very long, this leads  
to a quadratic behavior. #backends iterating over a list #backends  
long. Additionally, the likelihood of needing to call LWLockDequeueSelf() in  
the first place also increases with the increased length of the wait queue, as  
it becomes more likely that a lock is released while waiting for the wait list  
lock, which is held for longer during lock release.  
  
Due to the exponential back-off in perform_spin_delay() this is surprisingly  
hard to detect. We should make that easier, e.g. by adding a wait event around  
the pg_usleep() - but that's a separate patch.  
  
The fix is simple - track whether a proc is currently waiting in the wait list  
or already removed but waiting to be woken up in PGPROC->lwWaiting.  
  
In some workloads with a lot of clients contending for a small number of  
lwlocks (e.g. WALWriteLock), the fix can substantially increase throughput.  
  
This has been originally fixed for 16~ with a4adc31f6902 without a  
backpatch, and we have heard complaints from users impacted by this  
quadratic behavior in older versions as well.  
  
Author: Andres Freund <[email protected]>  
Reviewed-by: Bharath Rupireddy <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  
Discussion: https://postgr.es/m/CALj2ACXktNbG=K8Xi7PSqbofTZozavhaxjatVc14iYaLu4Maag@mail.gmail.com  
Backpatch-through: 12  

M src/backend/access/transam/twophase.c
M src/backend/storage/lmgr/lwlock.c
M src/backend/storage/lmgr/proc.c
M src/include/storage/lwlock.h
M src/include/storage/proc.h

Close socket in case of errors in setting non-blocking

commit   : db0d238419decf7edfd84b24d1a151b3ac21dc6a    
  
author   : Daniel Gustafsson <[email protected]>    
date     : Wed, 17 Jan 2024 11:24:11 +0100    
  
committer: Daniel Gustafsson <[email protected]>    
date     : Wed, 17 Jan 2024 11:24:11 +0100    

Click here for diff

If configuring the newly created socket non-blocking fails we  
error out and return INVALID_SOCKET, but the socket that had  
been created wasn't closed. Fix by issuing closesocket in the  
errorpath.  
  
Backpatch to all supported branches.  
  
Author: Ranier Vilela <[email protected]>  
Discussion: https://postgr.es/m/CAEudQApmU5CrKefH85VbNYE2y8H=-qqEJbg6RAPU65+vCe+89A@mail.gmail.com  
Backpatch-through: v12  

M src/backend/port/win32/socket.c

Re-pgindent catcache.c after previous commit.

commit   : d29a4fbacfb7998df16b6fabcd33400a5ae07c43    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 13 Jan 2024 13:54:11 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 13 Jan 2024 13:54:11 -0500    

Click here for diff

Discussion: https://postgr.es/m/[email protected]  
Discussion: https://postgr.es/m/CAGjhLkOoBEC9mLsnB42d3CO1vcMx71MLSEuigeABbQ8oRdA6gw@mail.gmail.com  

M src/backend/utils/cache/catcache.c

Cope with catcache entries becoming stale during detoasting.

commit   : 3b4d85cf159c1d436bef251cb47f77671e1d99dc    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 13 Jan 2024 13:46:27 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 13 Jan 2024 13:46:27 -0500    

Click here for diff

We've long had a policy that any toasted fields in a catalog tuple  
should be pulled in-line before entering the tuple in a catalog cache.  
However, that requires access to the catalog's toast table, and we'll  
typically do AcceptInvalidationMessages while opening the toast table.  
So it's possible that the catalog tuple is outdated by the time we  
finish detoasting it.  Since no cache entry exists yet, we can't  
mark the entry stale during AcceptInvalidationMessages, and instead  
we'll press forward and build an apparently-valid cache entry.  The  
upshot is that we have a race condition whereby an out-of-date entry  
could be made in a backend's catalog cache, and persist there  
indefinitely causing indeterminate misbehavior.  
  
To fix, use the existing systable_recheck_tuple code to recheck  
whether the catalog tuple is still up-to-date after we finish  
detoasting it.  If not, loop around and restart the process of  
searching the catalog and constructing cache entries from the top.  
The case is rare enough that this shouldn't create any meaningful  
performance penalty, even in the SearchCatCacheList case where  
we need to tear down and reconstruct the whole list.  
  
Indeed, the case is so rare that AFAICT it doesn't occur during  
our regression tests, and there doesn't seem to be any easy way  
to build a test that would exercise it reliably.  To allow  
testing of the retry code paths, add logic (in USE_ASSERT_CHECKING  
builds only) that randomly pretends that the recheck failed about  
one time out of a thousand.  This is enough to ensure that we'll  
pass through the retry paths during most regression test runs.  
  
By adding an extra level of looping, this commit creates a need  
to reindent most of SearchCatCacheMiss and SearchCatCacheList.  
I'll do that separately, to allow putting those changes in  
.git-blame-ignore-revs.  
  
Patch by me; thanks to Alexander Lakhin for having built a test  
case to prove the bug is real, and to Xiaoran Wang for review.  
Back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/[email protected]  
Discussion: https://postgr.es/m/CAGjhLkOoBEC9mLsnB42d3CO1vcMx71MLSEuigeABbQ8oRdA6gw@mail.gmail.com  

M src/backend/utils/cache/catcache.c

Added literal tag for RETURNING

commit   : 35cc9f15908f554d6fddc641536b63414eae234e    
  
author   : Alvaro Herrera <[email protected]>    
date     : Fri, 12 Jan 2024 12:44:20 +0100    
  
committer: Alvaro Herrera <[email protected]>    
date     : Fri, 12 Jan 2024 12:44:20 +0100    

Click here for diff

This is an old mistake (92e38182d7c8); backpatch all the way back.  
  
Author: Atsushi Torikoshi <[email protected]>  
Reviewed-by: Ashutosh Bapat <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  

M doc/src/sgml/ref/copy.sgml

pg_regress: Disable autoruns for cmd.exe on Windows

commit   : e50a52b2b4487661a39a6f52886991d4c3c4d808    
  
author   : Michael Paquier <[email protected]>    
date     : Fri, 12 Jan 2024 14:00:02 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Fri, 12 Jan 2024 14:00:02 +0900    

Click here for diff

This is similar to 9886744a361b, to prevent the execution of other  
programs due to autorun configurations which could influence the  
postmaster startup.  
  
This was originally applied on HEAD as of 83c75ac7fb69 without a  
backpatch, but the patch has survived CI and buildfarm cycles.  I have  
checked that cmd /d exists down to Windows XP, which should make this  
change work correctly in the oldest branches still supported.  
  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 12  

M src/test/regress/pg_regress.c

pg_ctl: Disable autoruns for cmd.exe on Windows

commit   : 9e70e6564fc816c96643564ab6f906a75e0a3308    
  
author   : Michael Paquier <[email protected]>    
date     : Fri, 12 Jan 2024 13:53:14 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Fri, 12 Jan 2024 13:53:14 +0900    

Click here for diff

On Windows, cmd.exe is used to launch the postmaster process to ease its  
redirection setup.  However, cmd.exe may execute other programs at  
startup due to autorun configurations, which could influence the  
postmaster startup.  This patch adds /D flag to the launcher cmd.exe  
command line to disable autorun settings written in the registry.  
  
This was originally applied on HEAD as of 9886744a361b without a  
backpatch, but the patch has survived CI and buildfarm cycles.  I have  
checked that cmd /d exists down to Windows XP, which should make this  
change work correctly in the oldest branches still supported.  
  
Reported-by: Hayato Kuroda  
Author: Kyotaro Horiguchi  
Reviewed-by: Robert Haas, Michael Paquier  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 12  

M src/bin/pg_ctl/pg_ctl.c

Allow subquery pullup to wrap a PlaceHolderVar in another one.

commit   : 69c12c41740913cc90e20886af4218db9b9b776c    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 11 Jan 2024 15:28:13 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 11 Jan 2024 15:28:13 -0500    

Click here for diff

The code for wrapping subquery output expressions in PlaceHolderVars  
believed that if the expression already was a PlaceHolderVar, it was  
never necessary to wrap that in another one.  That's wrong if the  
expression is underneath an outer join and involves a lateral  
reference to outside that scope: failing to add an additional PHV  
risks evaluating the expression at the wrong place and hence not  
forcing it to null when the outer join should do so.  This is an  
oversight in commit 9e7e29c75, which added logic to forcibly wrap  
lateral-reference Vars in PlaceHolderVars, but didn't see that the  
adjacent case for PlaceHolderVars needed the same treatment.  
  
The test case we have for this doesn't fail before 4be058fe9, but now  
that I see the problem I wonder if it is possible to demonstrate  
related errors before that.  That's moot though, since all such  
branches are out of support.  
  
Per bug #18284 from Holger Reise.  Back-patch to all supported  
branches.  
  
Discussion: https://postgr.es/m/[email protected]  

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

Fix omission in partitioning limitation documentation

commit   : 18d51c0bb19097191182e57bc755c197ee6a4fc4    
  
author   : Magnus Hagander <[email protected]>    
date     : Thu, 11 Jan 2024 14:27:10 +0100    
  
committer: Magnus Hagander <[email protected]>    
date     : Thu, 11 Jan 2024 14:27:10 +0100    

Click here for diff

UNIQUE and PRIMARY KEY constraints can be created on ONLY the  
partitioned table.  We already had an example demonstrating that,  
but forgot to mention it in the documentation of the limits of  
partitioning.  
  
Author: Laurenz Albe  
Reviewed-By: shihao zhong, Shubham Khanna, Ashutosh Bapat  
Backpatch-through: 12  
Discussion: https://postgr.es/m/[email protected]  

M doc/src/sgml/ddl.sgml

Doc: fix character_sets view.

commit   : 469d836a90cca12e730512a445e1d78b9bc6039e    
  
author   : Tatsuo Ishii <[email protected]>    
date     : Tue, 9 Jan 2024 19:56:00 +0900    
  
committer: Tatsuo Ishii <[email protected]>    
date     : Tue, 9 Jan 2024 19:56:00 +0900    

Click here for diff

The note regarding character encoding form in "The Information Schema"  
said that LATIN1 character repertoires only use one encoding form  
LATIN1. This is not correct because LATIN1 has another encoding form  
ISO-2022-JP-2. To fix this, replace LATIN1 with LATIN2, which is not  
supported by ISO-2022-JP-2, thus it can be said that LATIN2 only uses  
one encoding form.  
  
Back-patch to supported branches.  
  
Author: Tatsuo Ishii  
Reviewed-by: Daniel Gustafsson  
Discussion: https://postgr.es/m/flat/20240102.153925.1147403616414525145.t-ishii%40sranhm.sra.co.jp  

M doc/src/sgml/information_schema.sgml

Fix indentation in ExecParallelHashIncreaseNumBatches()

commit   : a5e2853c38db7181a35486e1865e07f73782bc99    
  
author   : Alexander Korotkov <[email protected]>    
date     : Mon, 8 Jan 2024 19:43:05 +0200    
  
committer: Alexander Korotkov <[email protected]>    
date     : Mon, 8 Jan 2024 19:43:05 +0200    

Click here for diff

Backpatch-through: 12  

M src/backend/executor/nodeHash.c

Fix integer-overflow problem in intarray's g_int_decompress().

commit   : 1c7443521f856dfb5f6731ff6fc0865a67a29f14    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 7 Jan 2024 15:19:50 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 7 Jan 2024 15:19:50 -0500    

Click here for diff

An array element equal to INT_MAX gave this code indigestion,  
causing an infinite loop that surely ended in SIGSEGV.  We fixed  
some nearby problems awhile ago (cf 757c5182f) but missed this.  
  
Report and diagnosis by Alexander Lakhin (bug #18273); patch by me  
  
Discussion: https://postgr.es/m/[email protected]  

M contrib/intarray/_int_gist.c
M contrib/intarray/data/test__int.data
M contrib/intarray/expected/_int.out

Fix oversized memory allocation in Parallel Hash Join

commit   : 72d5b27763a86c1d9af79e3169aef885b79373a3    
  
author   : Alexander Korotkov <[email protected]>    
date     : Sun, 7 Jan 2024 09:03:55 +0200    
  
committer: Alexander Korotkov <[email protected]>    
date     : Sun, 7 Jan 2024 09:03:55 +0200    

Click here for diff

During the calculations of the maximum for the number of buckets, take into  
account that later we round that to the next power of 2.  
  
Reported-by: Karen Talarico  
Bug: #16925  
Discussion: https://postgr.es/m/16925-ec96d83529d0d629%40postgresql.org  
Author: Thomas Munro, Andrei Lepikhov, Alexander Korotkov  
Reviewed-by: Alena Rybakina  
Backpatch-through: 12  

M src/backend/executor/nodeHash.c

commit   : 49fa18390cfbd03956a4820910777c3d6585d5a7    
  
author   : Bruce Momjian <[email protected]>    
date     : Wed, 3 Jan 2024 20:49:04 -0500    
  
committer: Bruce Momjian <[email protected]>    
date     : Wed, 3 Jan 2024 20:49:04 -0500    

Click here for diff

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

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

Avoid masking EOF (no-password-supplied) conditions in auth.c.

commit   : c20f2aab6ad4b41770fc8a066446c703bdf5d012    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 3 Jan 2024 17:40:38 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 3 Jan 2024 17:40:38 -0500    

Click here for diff

CheckPWChallengeAuth() would return STATUS_ERROR if the user does not  
exist or has no password assigned, even if the client disconnected  
without responding to the password challenge (as libpq often will,  
for example).  We should return STATUS_EOF in that case, and the  
lower-level functions do, but this code level got it wrong since the  
refactoring done in 7ac955b34.  This breaks the intent of not logging  
anything for EOF cases (cf. comments in auth_failed()) and might  
also confuse users of ClientAuthentication_hook.  
  
Per report from Liu Lang.  Back-patch to all supported versions.  
  
Discussion: https://postgr.es/m/[email protected]  

M src/backend/libpq/auth.c

Doc: Python's control flow construct is try/except not try/catch.

commit   : 54790f4b3f048db8f18e17966ad3bfb428e5b312    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 3 Jan 2024 12:22:00 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 3 Jan 2024 12:22:00 -0500    

Click here for diff

Very ancient thinko, dating evidently to 22690719e.  
Spotted by gweatherby.  
  
Discussion: https://postgr.es/m/170423637139.1288848.11840082988774620003@wrigleys.postgresql.org  

M doc/src/sgml/plpython.sgml

In pg_dump, don't dump a stats object unless dumping underlying table.

commit   : 69d7edb06fc69da114b075be58dd4318916500e5    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 29 Dec 2023 10:57:11 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 29 Dec 2023 10:57:11 -0500    

Click here for diff

If the underlying table isn't being dumped, it's useless to dump  
an extended statistics object; it'll just cause errors at restore.  
We have always applied similar policies to, say, indexes.  
  
(When and if we get cross-table stats objects, it might be profitable  
to think a little harder about what to do with them.  But for now  
there seems no point in considering a stats object as anything but  
an appendage of its table.)  
  
Rian McGuire and Tom Lane, per report from Rian McGuire.  
Back-patch to supported branches.  
  
Discussion: https://postgr.es/m/[email protected]  

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

doc: Mention AttributeRelationId in FDW validator function description

commit   : b901961be1d5191650cb4fae49e403843fc57ccc    
  
author   : Michael Paquier <[email protected]>    
date     : Thu, 28 Dec 2023 20:09:33 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Thu, 28 Dec 2023 20:09:33 +0900    

Click here for diff

The documentation has been missing one value in the list of catalog OIDs  
that can be given to the validator function of a FDW, as of  
AttributeRelationId, when changing the attribute options of a foreign  
table.  
  
Author: Ian Lawrence Barwick  
Discussion: https://postgr.es/m/CAB8KJ=i16t2yJU_Pq2Z+hnNGWFhagp_bJmzxHZu3ZkOjZm-+rQ@mail.gmail.com  
Backpatch-through: 12  

M doc/src/sgml/fdwhandler.sgml

Doc: specify aclitem syntax more clearly.

commit   : 456b6b67511362c6aefacaddaeedc0fc6ada1475    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 27 Dec 2023 13:52:01 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 27 Dec 2023 13:52:01 -0500    

Click here for diff

The previous wording here relied solely on an example to explain  
aclitem output format.  Add an actual syntax synopsis and  
explanation of the elements to make it clearer.  
  
David Johnston and Tom Lane, per gripe from Eugen Konkov.  
  
Discussion: https://postgr.es/m/170326116972.1876499.18357820037829248593@wrigleys.postgresql.org  

M doc/src/sgml/ddl.sgml

Fix failure to verify PGC_[SU_]BACKEND GUCs in pg_file_settings view.

commit   : ea61b1cf6470fc267253962dd34fd20d16ead40d    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 26 Dec 2023 17:57:48 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 26 Dec 2023 17:57:48 -0500    

Click here for diff

set_config_option() bails out early if it detects that the option to  
be set is PGC_BACKEND or PGC_SU_BACKEND class and we're reading the  
config file in a postmaster child; we don't want to apply any new  
value in such a case.  That's fine as far as it goes, but it fails  
to consider the requirements of the pg_file_settings view: for that,  
we need to check validity of the value even though we have no  
intention to apply it.  Because we didn't, even very silly values  
for affected GUCs would be reported as valid by the view.  There  
are only half a dozen such GUCs, which perhaps explains why this  
got overlooked for so long.  
  
Fix by continuing when changeVal is false; this parallels the logic  
in some other early-exit paths.  
  
Also, the check added by commit 924bcf4f1 to prevent GUC changes in  
parallel workers seems a few bricks shy of a load: it's evidently  
assuming that ereport(elevel, ...) won't return.  Make sure we  
bail out if it does.  The lack of trouble reports suggests that  
this is only a latent bug, i.e. parallel workers don't actually  
reach here with elevel < ERROR.  (Per the code coverage report,  
we never reach here at all in the regression suite.)  But we clearly  
don't want to risk proceeding if that does happen.  
  
Per report from Rıdvan Korkmaz.  These are ancient bugs, so back-patch  
to all supported branches.  
  
Discussion: https://postgr.es/m/[email protected]  

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

Hide warnings from Python headers when using gcc-compatible compiler.

commit   : 1613e2fae1ab4d66d949a00e7378721f2c8dcfbe    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 26 Dec 2023 16:16:29 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 26 Dec 2023 16:16:29 -0500    

Click here for diff

Like commit 388e80132, use "#pragma GCC system_header" to silence  
warnings appearing within the Python headers, since newer Python  
versions no longer worry about some restrictions we still use like  
-Wdeclaration-after-statement.  
  
This patch improves on 388e80132 by inventing a separate wrapper  
header file, allowing the pragma to be tightly scoped to just  
the Python headers and not other stuff we have laying about in  
plpython.h.  I applied the same technique to plperl for the same  
reason: the original patch suppressed warnings for a good deal  
of our own code, not only the Perl headers.  
  
Like the previous commit, back-patch to supported branches.  
  
Peter Eisentraut and Tom Lane  
  
Discussion: https://postgr.es/m/[email protected]  

M src/pl/plperl/GNUmakefile
M src/pl/plperl/plperl.h
A src/pl/plperl/plperl_system.h
M src/pl/plpython/Makefile
M src/pl/plpython/plpython.h
A src/pl/plpython/plpython_system.h

Doc: Add missing pgoutput options.

commit   : aede916688c47031a26cd11f773fc6bcdf584014    
  
author   : Amit Kapila <[email protected]>    
date     : Tue, 26 Dec 2023 10:43:40 +0530    
  
committer: Amit Kapila <[email protected]>    
date     : Tue, 26 Dec 2023 10:43:40 +0530    

Click here for diff

We forgot to update the docs while adding new options in pgoutput.  
  
Author: Emre Hasegeli  
Reviewed-by: Peter Smith, Amit Kapila  
Backpatch-through: 12  
Discussion: https://postgr.es/m/CAE2gYzwdwtUbs-tPSV-QBwgTubiyGD2ZGsSnAVsDfAGGLDrGOA%40mail.gmail.com  

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

Avoid trying to fetch metapage of an SPGist partitioned index.

commit   : 1771ec9a82900665226022e77ad5f8a86d27a1be    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 21 Dec 2023 12:43:36 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 21 Dec 2023 12:43:36 -0500    

Click here for diff

This is necessary when spgcanreturn() is invoked on a partitioned  
index, and the failure might be reachable in other scenarios as  
well.  The rest of what spgGetCache() does is perfectly sensible  
for a partitioned index, so we should allow it to go through.  
  
I think the main takeaway from this is that we lack sufficient test  
coverage for non-btree partitioned indexes.  Therefore, I added  
simple test cases for brin and gin as well as spgist (hash and  
gist AMs were covered already in indexing.sql).  
  
Per bug #18256 from Alexander Lakhin.  Although the known test case  
only fails since v16 (3c569049b), I've got no faith at all that there  
aren't other ways to reach this problem; so back-patch to all  
supported branches.  
  
Discussion: https://postgr.es/m/[email protected]  

M src/backend/access/spgist/spgutils.c
M src/test/regress/expected/indexing.out
M src/test/regress/sql/indexing.sql

doc: Fix syntax in ALTER FOREIGN DATA WRAPPER example

commit   : 3cf7dfa7f3f6432788bf1df026fe79b63ee98401    
  
author   : Daniel Gustafsson <[email protected]>    
date     : Tue, 19 Dec 2023 14:13:50 +0100    
  
committer: Daniel Gustafsson <[email protected]>    
date     : Tue, 19 Dec 2023 14:13:50 +0100    

Click here for diff

The example for dropping an option was incorrectly quoting the  
option key thus making it a value turning the command into an  
unqualified ADD operation. The result of dropping became adding  
a new key/value pair instead:  
  
 d=# alter foreign data wrapper f options (drop 'b');  
 ALTER FOREIGN DATA WRAPPER  
 d=# select fdwoptions from pg_foreign_data_wrapper where fdwname='f';  
  fdwoptions  
 ------------  
  {drop=b}  
 (1 row)  
  
This has been incorrect for a long time so backpatch to all  
supported branches.  
  
Author: Tim <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  

M doc/src/sgml/ref/alter_foreign_data_wrapper.sgml

pageinspect: Fix failure with hash_bitmap_info() for partitioned indexes

commit   : f610d4f119b5761475dff65266ec29c8e9cae509    
  
author   : Michael Paquier <[email protected]>    
date     : Tue, 19 Dec 2023 18:19:21 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Tue, 19 Dec 2023 18:19:21 +0900    

Click here for diff

This function reads directly a page from a relation, relying on  
index_open() to open the index to read from.  Unfortunately, this would  
crash when using partitioned indexes, as these can be opened with  
index_open() but they have no physical pages.  
  
Alexander has fixed the module, while I have written the test.  
  
Author: Alexander Lakhin, Michael Paquier  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 12  

M contrib/pageinspect/expected/hash.out
M contrib/pageinspect/hashfuncs.c
M contrib/pageinspect/sql/hash.sql

pgstattuple: Fix failure with pgstathashindex() for partitioned indexes

commit   : bd2d3c92812f617ebc9b826484fb0d0345571d17    
  
author   : Michael Paquier <[email protected]>    
date     : Tue, 19 Dec 2023 15:20:55 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Tue, 19 Dec 2023 15:20:55 +0900    

Click here for diff

As coded, the function relied on index_open() when opening an index  
relation, allowing partitioned indexes to be processed by  
pgstathashindex().  This was leading to a "could not open file" error  
because partitioned indexes have no physical files, or to a crash with  
an assertion failure (like on HEAD).  
  
This issue is fixed by applying the same checks as the other stat  
functions for indexes, with a lookup at both RELKIND_INDEX and the index  
AM expected.  
  
Author: Alexander Lakhin  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 12  

M contrib/pgstattuple/expected/pgstattuple.out
M contrib/pgstattuple/pgstatindex.c
M contrib/pgstattuple/sql/pgstattuple.sql

Doc: add a bit to indices.sgml about what is an indexable clause.

commit   : 499342e81b0fba471889439e47e0c37fe9e62bc0    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 17 Dec 2023 16:49:44 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 17 Dec 2023 16:49:44 -0500    

Click here for diff

We didn't explain this clearly until somewhere deep in the  
"Extending SQL" chapter, but really it ought to be mentioned  
in the introductory material too.  
  
Discussion: https://postgr.es/m/[email protected]  

M doc/src/sgml/indices.sgml

Fix bugs in manipulation of large objects.

commit   : ba66f253362a1797bec9641570a02574a65b3a93    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 15 Dec 2023 13:55:05 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 15 Dec 2023 13:55:05 -0500    

Click here for diff

In v16 and up (since commit afbfc0298), large object ownership  
checking has been broken because object_ownercheck() didn't take care  
of the discrepancy between our object-address representation of large  
objects (classId == LargeObjectRelationId) and the catalog where their  
ownership info is actually stored (LargeObjectMetadataRelationId).  
This resulted in failures such as "unrecognized class ID: 2613"  
when trying to update blob properties as a non-superuser.  
  
Poking around for related bugs, I found that AlterObjectOwner_internal  
would pass the wrong classId to the PostAlterHook in the no-op code  
path where the large object already has the desired owner.  Also,  
recordExtObjInitPriv checked for the wrong classId; that bug is only  
latent because the stanza is dead code anyway, but as long as we're  
carrying it around it should be less wrong.  These bugs are quite old.  
  
In HEAD, we can reduce the scope for future bugs of this ilk by  
changing AlterObjectOwner_internal's API to let the translation happen  
inside that function, rather than requiring callers to know about it.  
  
A more bulletproof fix, perhaps, would be to start using  
LargeObjectMetadataRelationId as the dependency and object-address  
classId for blobs.  However that has substantial risk of breaking  
third-party code; even within our own code, it'd create hassles  
for pg_dump which would have to cope with a version-dependent  
representation.  For now, keep the status quo.  
  
Discussion: https://postgr.es/m/[email protected]  

M src/backend/catalog/aclchk.c
M src/backend/commands/alter.c

Prevent tuples to be marked as dead in subtransactions on standbys

commit   : 4d45ecc9284acfd341627b5e614e55ba514f443f    
  
author   : Michael Paquier <[email protected]>    
date     : Tue, 12 Dec 2023 17:05:36 +0100    
  
committer: Michael Paquier <[email protected]>    
date     : Tue, 12 Dec 2023 17:05:36 +0100    

Click here for diff

Dead tuples are ignored and are not marked as dead during recovery, as  
it can lead to MVCC issues on a standby because its xmin may not match  
with the primary.  This information is tracked by a field called  
"xactStartedInRecovery" in the transaction state data, switched on when  
starting a transaction in recovery.  
  
Unfortunately, this information was not correctly tracked when starting  
a subtransaction, because the transaction state used for the  
subtransaction did not update "xactStartedInRecovery" based on the state  
of its parent.  This would cause index scans done in subtransactions to  
return inconsistent data, depending on how the xmin of the primary  
and/or the standby evolved.  
  
This is broken since the introduction of hot standby in efc16ea52067, so  
backpatch all the way down.  
  
Author: Fei Changhong  
Reviewed-by: Kyotaro Horiguchi  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 12  

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

Fix typo in comment

commit   : 5902ba5b21da9bf16377971360bcf4232728e0bf    
  
author   : Daniel Gustafsson <[email protected]>    
date     : Tue, 12 Dec 2023 12:16:38 +0100    
  
committer: Daniel Gustafsson <[email protected]>    
date     : Tue, 12 Dec 2023 12:16:38 +0100    

Click here for diff

Commit 98e675ed7af accidentally mistyped IDENTIFY_SYSTEM as  
IDENTIFY_SERVER. Backpatch to all supported branches.  
  
Reported-by: Alexander Lakhin <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  

M src/backend/replication/libpqwalreceiver/libpqwalreceiver.c

Be more wary about OpenSSL not setting errno on error.

commit   : 271d24f31ddd691327d7e32eea7141b33b9eff58    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 11 Dec 2023 11:51:56 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 11 Dec 2023 11:51:56 -0500    

Click here for diff

OpenSSL will sometimes return SSL_ERROR_SYSCALL without having set  
errno; this is apparently a reflection of recv(2)'s habit of not  
setting errno when reporting EOF.  Ensure that we treat such cases  
the same as read EOF.  Previously, we'd frequently report them like  
"could not accept SSL connection: Success" which is confusing, or  
worse report them with an unrelated errno left over from some  
previous syscall.  
  
To fix, ensure that errno is zeroed immediately before the call,  
and report its value only when it's not zero afterwards; otherwise  
report EOF.  
  
For consistency, I've applied the same coding pattern in libpq's  
pqsecure_raw_read().  Bare recv(2) shouldn't really return -1 without  
setting errno, but in case it does we might as well cope.  
  
Per report from Andres Freund.  Back-patch to all supported versions.  
  
Discussion: https://postgr.es/m/[email protected]  

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

jit: Create void type in the right context

commit   : c922b241064ceadc95c49fac445e4ed24171b3f0    
  
author   : Daniel Gustafsson <[email protected]>    
date     : Mon, 11 Dec 2023 12:02:01 +0100    
  
committer: Daniel Gustafsson <[email protected]>    
date     : Mon, 11 Dec 2023 12:02:01 +0100    

Click here for diff

Commit 3b991f81c45 introduced a specific context for types such  
that all no longer referenced types can be dropped periodically  
rather than leaking. One void pointer type creation was however  
missed leading to an assertion failure in LLVM Debug builds.  
  
Per buildfarm members canebreak and urutu.  Fix with assistance  
from Andres. The codepath in question was refactored in version  
13 hence why this only affected version 12.  
  
Reported-by: Tom Lane <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  

M src/backend/jit/llvm/llvmjit_expr.c

Fix an undetected deadlock due to apply worker.

commit   : e81e617f3273b74c8eb46f7a7c51387509bc8d8c    
  
author   : Amit Kapila <[email protected]>    
date     : Mon, 11 Dec 2023 07:45:45 +0530    
  
committer: Amit Kapila <[email protected]>    
date     : Mon, 11 Dec 2023 07:45:45 +0530    

Click here for diff

The apply worker needs to update the state of the subscription tables to  
'READY' during the synchronization phase which requires locking the  
corresponding subscription. The apply worker also waits for the  
subscription tables to reach the 'SYNCDONE' state after holding the locks  
on the subscription and the wait is done using WaitLatch. The 'SYNCDONE'  
state is changed by tablesync workers again by locking the corresponding  
subscription. Both the state updates use AccessShareLock mode to lock the  
subscription, so they can't block each other. However, a backend can  
simultaneously try to acquire a lock on the same subscription using  
AccessExclusiveLock mode to alter the subscription. Now, the backend's  
wait on a lock can sneak in between the apply worker and table sync worker  
causing deadlock.  
  
In other words, apply_worker waits for tablesync worker which waits for  
backend, and backend waits for apply worker. This is not detected by the  
deadlock detector because apply worker uses WaitLatch.  
  
The fix is to release existing locks in apply worker before it starts to  
wait for tablesync worker to change the state.  
  
Reported-by: Tomas Vondra  
Author: Shlok Kyal  
Reviewed-by: Amit Kapila, Peter Smith  
Backpatch-through: 12  
Discussion: https://postgr.es/m/[email protected]  

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

Fix incorrect error message for IDENTIFY_SYSTEM

commit   : b608afe980a5dfe91d76148900179d52d4db5e64    
  
author   : Daniel Gustafsson <[email protected]>    
date     : Tue, 5 Dec 2023 14:30:56 +0100    
  
committer: Daniel Gustafsson <[email protected]>    
date     : Tue, 5 Dec 2023 14:30:56 +0100    

Click here for diff

Commit 5a991ef8692e accidentally reversed the order of the tuples  
and fields parameters, making the error message incorrectly refer  
to 3 tuples with 1 field when IDENTIFY_SYSTEM returns 1 tuple and  
3 or 4 fields. Fix by changing the order of the parameters.  This  
also adds a comment describing why we check for < 3 when postgres  
since 9.4 has been sending 4 fields.  
  
Backpatch all the way since the bug is almost a decade old.  
  
Author: Tomonari Katsumata <[email protected]>  
Reviewed-by: Tom Lane <[email protected]>  
Bug: #18224  
Backpatch-through: v12  

M src/backend/replication/libpqwalreceiver/libpqwalreceiver.c

doc: Remove reference to trigger file regarding promotion

commit   : fcf46f8fb76ca8086119b3f1510533332aefd604    
  
author   : Michael Paquier <[email protected]>    
date     : Mon, 4 Dec 2023 08:10:32 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Mon, 4 Dec 2023 08:10:32 +0900    

Click here for diff

The wording changed here comes from 991bfe11d28a, when the only way to  
trigger a promotion was with a trigger file.  There are more options to  
achieve this operation these days, like the SQL function pg_promote() or  
the command `pg_ctl promote`, so it is confusing to assume that only a  
trigger file is able to do the work.  
  
Note also that promote_trigger_file has been removed as of cd4329d9393f  
in 16~.  
  
Author: Shinya Kato  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 12  

M doc/src/sgml/high-availability.sgml

Check collation when creating partitioned index

commit   : 5d40b3c4f6cae974160cde49932eb1e0c2d04213    
  
author   : Peter Eisentraut <[email protected]>    
date     : Fri, 1 Dec 2023 15:48:06 +0100    
  
committer: Peter Eisentraut <[email protected]>    
date     : Fri, 1 Dec 2023 15:48:06 +0100    

Click here for diff

When creating a partitioned index, the partition key must be a subset  
of the index's columns.  But this currently doesn't check that the  
collations between the partition key and the index definition match.  
So you can construct a unique index that fails to enforce uniqueness.  
(This would most likely involve a nondeterministic collation, so it  
would have to be crafted explicitly and is not something that would  
just happen by accident.)  
  
This patch adds the required collation check.  As a result, any  
previously allowed unique index that has a collation mismatch would no  
longer be allowed to be created.  
  
Reviewed-by: Tom Lane <[email protected]>  
Discussion: https://www.postgresql.org/message-id/flat/3327cb54-f7f1-413b-8fdb-7a9dceebb938%40eisentraut.org  

M src/backend/commands/indexcmds.c

Use BIO_{get,set}_app_data instead of BIO_{get,set}_data.

commit   : 0bd682246a619fd8eb9b538f1af61afb991b06b4    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 28 Nov 2023 12:34:03 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 28 Nov 2023 12:34:03 -0500    

Click here for diff

We should have done it this way all along, but we accidentally got  
away with using the wrong BIO field up until OpenSSL 3.2.  There,  
the library's BIO routines that we rely on use the "data" field  
for their own purposes, and our conflicting use causes assorted  
weird behaviors up to and including core dumps when SSL connections  
are attempted.  Switch to using the approved field for the purpose,  
i.e. app_data.  
  
While at it, remove our configure probes for BIO_get_data as well  
as the fallback implementation.  BIO_{get,set}_app_data have been  
there since long before any OpenSSL version that we still support,  
even in the back branches.  
  
Also, update src/test/ssl/t/001_ssltests.pl to allow for a minor  
change in an error message spelling that evidently came in with 3.2.  
  
Tristan Partin and Bo Andreson.  Back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/CAN55FZ1eDDYsYaL7mv+oSLUij2h_u6hvD4Qmv-7PK7jkji0uyQ@mail.gmail.com  

M configure
M configure.in
M src/backend/libpq/be-secure-openssl.c
M src/include/pg_config.h.in
M src/include/pg_config.h.win32
M src/interfaces/libpq/fe-secure-openssl.c
M src/tools/msvc/Solution.pm

Fix assertions with RI triggers in heap_update and heap_delete.

commit   : b8a606e21b0619ac378558bdd258c54aee7cb4ed    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Tue, 28 Nov 2023 11:59:09 +0200    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Tue, 28 Nov 2023 11:59:09 +0200    

Click here for diff

If the tuple being updated is not visible to the crosscheck snapshot,  
we return TM_Updated but the assertions would not hold in that case.  
Move them to before the cross-check.  
  
Fixes bug #17893. Backpatch to all supported versions.  
  
Author: Alexander Lakhin  
Backpatch-through: 12  
Discussion: https://www.postgresql.org/message-id/17893-35847009eec517b5%40postgresql.org  

M src/backend/access/heap/heapam.c
M src/include/access/tableam.h

Fix CREATE INDEX CONCURRENTLY example

commit   : a5e95ff46f58c1aa15760ee3b2aa074f695f53d1    
  
author   : Alvaro Herrera <[email protected]>    
date     : Mon, 27 Nov 2023 19:18:03 +0100    
  
committer: Alvaro Herrera <[email protected]>    
date     : Mon, 27 Nov 2023 19:18:03 +0100    

Click here for diff

It fails to use the CONCURRENTLY keyword where it was necessary, so add  
it.  This text was added to pg11 in commit 5efd604ec0a3; backpatch to pg12.  
  
Author: Nikolay Samokhvalov <[email protected]>  
Discussion: https://postgr.es/m/CAM527d9iz6+=_c7EqSKaGzjqWvSeCeRVVvHZ1v3gDgjTtvgsbw@mail.gmail.com  

M doc/src/sgml/ddl.sgml

Fix race condition with BIO methods initialization in libpq with threads

commit   : 0217a7444a5760e5f0bb2d5e4d4b17d81ae438a0    
  
author   : Michael Paquier <[email protected]>    
date     : Mon, 27 Nov 2023 09:40:57 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Mon, 27 Nov 2023 09:40:57 +0900    

Click here for diff

The libpq code in charge of creating per-connection SSL objects was  
prone to a race condition when loading the custom BIO methods needed by  
my_SSL_set_fd().  As BIO methods are stored as a static variable, the  
initialization of a connection could fail because it could be possible  
to have one thread refer to my_bio_methods while it is being manipulated  
by a second concurrent thread.  
  
This error has been introduced by 8bb14cdd33de, that has removed  
ssl_config_mutex around the call of my_SSL_set_fd(), that itself sets  
the custom BIO methods used in libpq.  Like previously, the BIO method  
initialization is now protected by the existing ssl_config_mutex, itself  
initialized earlier for WIN32.  
  
While on it, document that my_bio_methods is protected by  
ssl_config_mutex, as this can be easy to miss.  
  
Reported-by: Willi Mann  
Author: Willi Mann, Michael Paquier  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 12  

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

Doc: list AT TIME ZONE and COLLATE in operator precedence table.

commit   : 450ad6585ac55d0cf7e32bda238db409321f4923    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 26 Nov 2023 16:40:22 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 26 Nov 2023 16:40:22 -0500    

Click here for diff

These constructs have precedence, but we forgot to list them.  
In HEAD, mention AT LOCAL as well as AT TIME ZONE.  
  
Per gripe from Shay Rojansky.  
  
Discussion: https://postgr.es/m/CADT4RqBPdbsZW7HS1jJP319TMRHs1hzUiP=iRJYR6UqgHCrgNQ@mail.gmail.com  

M doc/src/sgml/syntax.sgml

Fix timing-dependent failure in GSSAPI data transmission.

commit   : 18fad508b783654e516898d2246a8ac3c98e47e0    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 23 Nov 2023 13:30:19 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 23 Nov 2023 13:30:19 -0500    

Click here for diff

When using GSSAPI encryption in non-blocking mode, libpq sometimes  
failed with "GSSAPI caller failed to retransmit all data needing  
to be retried".  The cause is that pqPutMsgEnd rounds its transmit  
request down to an even multiple of 8K, and sometimes that can lead  
to not requesting a write of data that was requested to be written  
(but reported as not written) earlier.  That can upset pg_GSS_write's  
logic for dealing with not-yet-written data, since it's possible  
the data in question had already been incorporated into an encrypted  
packet that we weren't able to send during the previous call.  
  
We could fix this with a one-or-two-line hack to disable pqPutMsgEnd's  
round-down behavior, but that seems like making the caller work around  
a behavior that pg_GSS_write shouldn't expose in this way.  Instead,  
adjust pg_GSS_write to never report a partial write: it either  
reports a complete write, or reflects the failure of the lower-level  
pqsecure_raw_write call.  The requirement still exists for the caller  
to present at least as much data as on the previous call, but with  
the caller-visible write start point not moving there is no temptation  
for it to present less.  We lose some ability to reclaim buffer space  
early, but I doubt that that will make much difference in practice.  
  
This also gets rid of a rather dubious assumption that "any  
interesting failure condition (from pqsecure_raw_write) will recur  
on the next try".  We've not seen failure reports traceable to that,  
but I've never trusted it particularly and am glad to remove it.  
  
Make the same adjustments to the equivalent backend routine  
be_gssapi_write().  It is probable that there's no bug on the backend  
side, since we don't have a notion of nonblock mode there; but we  
should keep the logic the same to ease future maintenance.  
  
Per bug #18210 from Lars Kanis.  Back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/[email protected]  

M src/backend/libpq/be-secure-gssapi.c
M src/interfaces/libpq/fe-secure-gssapi.c
M src/interfaces/libpq/libpq-int.h

doc: FreeBSD uses camcontrol identify, not atacontrol, for cache

commit   : c15c7e4e5d17348399a6446c193cdb893edb98f3    
  
author   : Bruce Momjian <[email protected]>    
date     : Tue, 21 Nov 2023 20:09:19 -0500    
  
committer: Bruce Momjian <[email protected]>    
date     : Tue, 21 Nov 2023 20:09:19 -0500    

Click here for diff

This is for IDE drive cache control, same as SCSI (already documented  
properly).  
  
Reported-by: John Ekins  
  
Discussion: https://postgr.es/m/[email protected]  
  
Author: John Ekins  
  
Backpatch-through: 12  

M doc/src/sgml/wal.sgml

Fix query checking consistency of table amhandlers in opr_sanity.sql

commit   : deec80ef11d1f0312d1761cb4d6d529bc1de5974    
  
author   : Michael Paquier <[email protected]>    
date     : Wed, 22 Nov 2023 09:32:42 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Wed, 22 Nov 2023 09:32:42 +0900    

Click here for diff

As written, the query checked for an access method of type 's', which is  
not an AM type supported in the core code.  
  
Error introduced by 8586bf7ed888.  As this query is not checking what it  
should, backpatch all the way down.  
  
Reviewed-by: Aleksander Alekseev  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 12  

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

Lock table in DROP STATISTICS

commit   : 4f8d3c5b5adeb0bdaf7e8d58678725c58b51dcff    
  
author   : Tomas Vondra <[email protected]>    
date     : Sun, 19 Nov 2023 21:03:29 +0100    
  
committer: Tomas Vondra <[email protected]>    
date     : Sun, 19 Nov 2023 21:03:29 +0100    

Click here for diff

The DROP STATISTICS code failed to properly lock the table, leading to  
  
  ERROR:  tuple concurrently deleted  
  
when executed concurrently with ANALYZE.  
  
Fixed by modifying RemoveStatisticsById() to acquire the same lock as  
ANALYZE. This function is called only by DROP STATISTICS, as ANALYZE  
calls RemoveStatisticsDataById() directly.  
  
Reported by Justin Pryzby, fix by me. Backpatch through 12. The code was  
like this since it was introduced in 10, but older releases are EOL.  
  
Reported-by: Justin Pryzby  
Reviewed-by: Tom Lane  
Backpatch-through: 12  
  
Discussion: https://postgr.es/m/ZUuk-8CfbYeq6g_u@pryzbyj2023  

M src/backend/commands/statscmds.c

Fix typo in person's name.

commit   : 0ef893bbad9563695d49f1c6a1ec9b6634eb9409    
  
author   : Noah Misch <[email protected]>    
date     : Sat, 18 Nov 2023 17:31:18 -0800    
  
committer: Noah Misch <[email protected]>    
date     : Sat, 18 Nov 2023 17:31:18 -0800    

Click here for diff

Back-patch v16..v12 (all supported versions); master is unaffected.  

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

Guard against overflow in interval_mul() and interval_div().

commit   : f499d2b20b42c34a3941ca284ed58b95c0ce330c    
  
author   : Dean Rasheed <[email protected]>    
date     : Sat, 18 Nov 2023 14:50:00 +0000    
  
committer: Dean Rasheed <[email protected]>    
date     : Sat, 18 Nov 2023 14:50:00 +0000    

Click here for diff

Commits 146604ec43 and a898b409f6 added overflow checks to  
interval_mul(), but not to interval_div(), which contains almost  
identical code, and so is susceptible to the same kinds of  
overflows. In addition, those checks did not catch all possible  
overflow conditions.  
  
Add additional checks to the "cascade down" code in interval_mul(),  
and copy all the overflow checks over to the corresponding code in  
interval_div(), so that they both generate "interval out of range"  
errors, rather than returning bogus results.  
  
Given that these errors are relatively easy to hit, back-patch to all  
supported branches.  
  
Per bug #18200 from Alexander Lakhin, and subsequent investigation.  
  
Discussion: https://postgr.es/m/18200-5ea288c7b2d504b1%40postgresql.org  

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

llvmjit: Use explicit LLVMContextRef for inlining

commit   : 3b991f81c45720515144b928bb8d1f03577628f1    
  
author   : Daniel Gustafsson <[email protected]>    
date     : Fri, 17 Nov 2023 11:47:17 +0100    
  
committer: Daniel Gustafsson <[email protected]>    
date     : Fri, 17 Nov 2023 11:47:17 +0100    

Click here for diff

When performing inlining LLVM unfortunately "leaks" types (the  
types survive and are usable, but a new round of inlining will  
recreate new structurally equivalent types). This accumulation  
will over time amount to a memory leak which for some queries  
can be large enough to trigger the OOM process killer.  
  
To avoid accumulation of types, all IR related data is stored  
in an LLVMContextRef which is dropped and recreated in order  
to release all types.  Dropping and recreating incurs overhead,  
so it will be done only after 100 queries. This is a heuristic  
which might be revisited, but until we can get the size of the  
context from LLVM we are flying a bit blind.  
  
This issue has been reported several times, there may be more  
references to it in the archives on top of the threads linked  
below.  
  
This is a backpatch of 9dce22033d5 to all supported branches.  
  
Reported-By: Justin Pryzby <[email protected]>  
Reported-By: Kurt Roeckx <[email protected]>  
Reported-By: Jaime Casanova <[email protected]>  
Reported-By: Lauri Laanmets <[email protected]>  
Author: Andres Freund and Daniel Gustafsson  
Discussion: https://postgr.es/m/[email protected]  
Discussion: https://postgr.es/m/[email protected]  
Discussion: https://postgr.es/m/CAPH-tTxLf44s3CvUUtQpkDr1D8Hxqc2NGDzGXS1ODsfiJ6WSqA@mail.gmail.com  
Backpatch-through: v12  

M src/backend/jit/llvm/llvmjit.c
M src/backend/jit/llvm/llvmjit_deform.c
M src/backend/jit/llvm/llvmjit_expr.c
M src/backend/jit/llvm/llvmjit_inline.cpp
M src/include/jit/llvmjit.h
M src/include/jit/llvmjit_emit.h

Register llvm_shutdown using on_proc_exit, not before_shmem_exit.

commit   : c980eeddccac3f9d7030948569f8d13b6ee1e127    
  
author   : Daniel Gustafsson <[email protected]>    
date     : Fri, 17 Nov 2023 11:47:13 +0100    
  
committer: Daniel Gustafsson <[email protected]>    
date     : Fri, 17 Nov 2023 11:47:13 +0100    

Click here for diff

This seems more correct, because other before_shmem_exit calls may  
expect the infrastructure that is needed to run queries and access the  
database to be working, and also because this cleanup has nothing to  
do with shared memory.  
  
This is a back-patch of bab150045bd9.  
  
There were no known user-visible consequences to this, though, apart  
from what was previous fixed by commit 303640199d0 and back-patched  
as commit bcbc27251d35 and commit f7013683d9bb, so bab150045bd9 was  
not no back-patched at the time.  
  
Bharath Rupireddy  
  
Discussion: http://postgr.es/m/CALj2ACWk7j4F2v2fxxYfrroOF=AdFNPr1WsV+AGtHAFQOqm_pw@mail.gmail.com  
Backpatch-through: 13, 12  

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

Ensure we preprocess expressions before checking their volatility.

commit   : abd1b1325d60eefcf66942fc332f990255daccb1    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 16 Nov 2023 10:05:14 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 16 Nov 2023 10:05:14 -0500    

Click here for diff

contain_mutable_functions and contain_volatile_functions give  
reliable answers only after expression preprocessing (specifically  
eval_const_expressions).  Some places understand this, but some did  
not get the memo --- which is not entirely their fault, because the  
problem is documented only in places far away from those functions.  
Introduce wrapper functions that allow doing the right thing easily,  
and add commentary in hopes of preventing future mistakes from  
copy-and-paste of code that's only conditionally safe.  
  
Two actual bugs of this ilk are fixed here.  We failed to preprocess  
column GENERATED expressions before checking mutability, so that the  
code could fail to detect the use of a volatile function  
default-argument expression, or it could reject a polymorphic function  
that is actually immutable on the datatype of interest.  Likewise,  
column DEFAULT expressions weren't preprocessed before determining if  
it's safe to apply the attmissingval mechanism.  A false negative  
would just result in an unnecessary table rewrite, but a false  
positive could allow the attmissingval mechanism to be used in a case  
where it should not be, resulting in unexpected initial values in a  
new column.  
  
In passing, re-order the steps in ComputePartitionAttrs so that its  
checks for invalid column references are done before applying  
expression_planner, rather than after.  The previous coding would  
not complain if a partition expression contains a disallowed column  
reference that gets optimized away by constant folding, which seems  
to me to be a behavior we do not want.  
  
Per bug #18097 from Jim Keener.  Back-patch to all supported versions.  
  
Discussion: https://postgr.es/m/[email protected]  

M src/backend/catalog/heap.c
M src/backend/commands/copy.c
M src/backend/commands/indexcmds.c
M src/backend/commands/tablecmds.c
M src/backend/optimizer/util/clauses.c
M src/include/optimizer/optimizer.h
M src/test/regress/expected/fast_default.out
M src/test/regress/expected/generated.out
M src/test/regress/sql/fast_default.sql
M src/test/regress/sql/generated.sql

Fix fallback implementation for pg_atomic_test_set_flag().

commit   : c23677844c96ead2f3ee8183a2ab3dd67f7862a0    
  
author   : Nathan Bossart <[email protected]>    
date     : Wed, 15 Nov 2023 15:04:18 -0600    
  
committer: Nathan Bossart <[email protected]>    
date     : Wed, 15 Nov 2023 15:04:18 -0600    

Click here for diff

The fallback implementation of pg_atomic_test_set_flag() that uses  
atomic-exchange gives pg_atomic_exchange_u32_impl() an extra  
argument.  This issue has been present since the introduction of  
the atomics API in commit b64d92f1a5.  
  
Reviewed-by: Andres Freund  
Discussion: https://postgr.es/m/20231114035439.GA1809032%40nathanxps13  
Backpatch-through: 12  

M src/include/port/atomics/generic.h

Allow new role 'regress_dump_login_role' to log in under SSPI.

commit   : e43790342be29addaa843b80e8f58334fe7346d3    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 14 Nov 2023 00:31:39 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 14 Nov 2023 00:31:39 -0500    

Click here for diff

Semi-blind attempt to fix a70f2a57f to work on Windows,  
along the same lines as 5253519b2.  Per buildfarm.  

M src/test/modules/test_pg_dump/t/001_base.pl

Don't try to dump RLS policies or security labels for extension objects.

commit   : 891afa84c27efb2d496540cbc0b5dd1faaec4e91    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 13 Nov 2023 17:04:10 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 13 Nov 2023 17:04:10 -0500    

Click here for diff

checkExtensionMembership() set the DUMP_COMPONENT_SECLABEL and  
DUMP_COMPONENT_POLICY flags for extension member objects, even though  
we lack any infrastructure for tracking extensions' initial settings  
of these properties.  This is not OK.  The result was that a dump  
would always include commands to set these properties for extension  
objects that have them, with at least three negative consequences:  
  
1. The restoring user might not have privilege to set these properties  
on these objects.  
  
2. The properties might be incorrect/irrelevant for the version of the  
extension that's installed in the destination database.  
  
3. The dump itself might fail, in the case of RLS properties attached  
to extension tables that the dumping user lacks privilege to LOCK.  
(That's because we must get at least AccessShareLock to ensure that  
we don't fail while trying to decompile the RLS expressions.)  
  
When and if somebody cares to invent initial-state infrastructure for  
extensions' RLS policies and security labels, we could think about  
finding another way around problem #3.  But in the absence of such  
infrastructure, this whole thing is just wrong and we shouldn't do it.  
  
(Note: this applies only to ordinary dumps; binary-upgrade dumps  
still dump and restore extension member objects separately, with  
all properties.)  
  
Tom Lane and Jacob Champion.  Back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/[email protected]  

M src/bin/pg_dump/pg_dump.c
M src/test/modules/test_pg_dump/t/001_base.pl
M src/test/modules/test_pg_dump/test_pg_dump–1.0.sql

doc: correct description of libpq's PQsetnonblocking() mode

commit   : b64926fbfda6efc0ea51d91a2dabe73abb4a683d    
  
author   : Bruce Momjian <[email protected]>    
date     : Mon, 13 Nov 2023 14:03:36 -0500    
  
committer: Bruce Momjian <[email protected]>    
date     : Mon, 13 Nov 2023 14:03:36 -0500    

Click here for diff

Reported-by: Yugo NAGATA  
  
Discussion: https://postgr.es/m/[email protected]  
  
Backpatch-through: 12-16, master already done  

M doc/src/sgml/libpq.sgml

Don't release index root page pin in ginFindParents().

commit   : 5a6937ec9d41c5d61b72ce42a927a0d590e79491    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 13 Nov 2023 11:44:35 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 13 Nov 2023 11:44:35 -0500    

Click here for diff

It's clearly stated in the comments that ginFindParents() must keep  
the pin on the index's root page that's associated with the topmost  
GinBtreeStack item.  However, the code path for the case that the  
desired downlink has been pushed down to the next index level  
ignored this proviso, and would release the pin anyway if we were  
still examining the root level.  That led to an assertion failure  
or "buffer NNNN is not owned by resource owner" error later, when  
we try to release the pin again at the end of the insertion.  
  
This is quite hard to reproduce, since it can only happen if an  
index root page split occurs concurrently with our own insertion.  
Thanks to Jeff Janes for finding a test case that triggers it  
often enough to allow investigation.  
  
This has been there since the beginning of GIN, so back-patch  
to all supported branches.  
  
Discussion: https://postgr.es/m/CAMkU=1yCAKtv86dMrD__Ja-7KzjE=uMeKX8y__cx5W-OEWy2ow@mail.gmail.com  

M src/backend/access/gin/ginbtree.c

doc: Add missing semicolon in example

commit   : 1cdf3844c9d437aa366b17cf76bc33ba1732902c    
  
author   : Daniel Gustafsson <[email protected]>    
date     : Mon, 13 Nov 2023 14:13:03 +0100    
  
committer: Daniel Gustafsson <[email protected]>    
date     : Mon, 13 Nov 2023 14:13:03 +0100    

Click here for diff

One of the examples on the SELECT page was missing a semicolon from  
a listing which has the look and feel of being a psql session. This  
adds the missing semicolon and also removes the newline between the  
query and results to match the other examples nearby.  
  
Backpatch to all supported branches to avoid backpatching issues on  
this page.  
  
Reported-by: [email protected]  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: v12  

M doc/src/sgml/ref/select.sgml

Remove incorrect file reference in comment.

commit   : 7b6ba8c4315e5657fd90bad91c552fca58dc87fd    
  
author   : Etsuro Fujita <[email protected]>    
date     : Mon, 13 Nov 2023 19:05:08 +0900    
  
committer: Etsuro Fujita <[email protected]>    
date     : Mon, 13 Nov 2023 19:05:08 +0900    

Click here for diff

Commit b7eda3e0e moved XidInMVCCSnapshot() from tqual.c into snapmgr.c,  
but follow-up commit c91560def incorrectly updated this reference.  We  
could fix it, but as pointed out by Daniel Gustafsson, 1) the reader can  
easily find the file that contains the definition of that function, e.g.  
by grepping, and 2) this kind of reference is prone to going stale; so  
let's just remove it.  
  
Back-patch to all supported branches.  
  
Reviewed by Daniel Gustafsson.  
  
Discussion: https://postgr.es/m/CAPmGK145VdKkPBLWS2urwhgsfidbSexwY-9zCL6xSUJH%2BBTUUg%40mail.gmail.com  

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

Ensure we use the correct spelling of "ensure"

commit   : 2be56450758850282cb5cf667430d1ece64de955    
  
author   : David Rowley <[email protected]>    
date     : Fri, 10 Nov 2023 00:18:33 +1300    
  
committer: David Rowley <[email protected]>    
date     : Fri, 10 Nov 2023 00:18:33 +1300    

Click here for diff

We seem to have accidentally used "insure" in a few places.  Correct  
that.  
  
Author: Peter Smith  
Discussion: https://postgr.es/m/CAHut+Pv0biqrhA3pMhu40aDsj343mTsD75khKnHsLqR8P04f=Q@mail.gmail.com  
Backpatch-through: 12, oldest supported version  

M src/backend/access/heap/hio.c
M src/backend/utils/misc/guc.c
M src/include/storage/buf_internals.h

Fix corner-case 64-bit integer subtraction bug on some platforms.

commit   : b17a02be27e01d46cf9a74d173009547305d4cf8    
  
author   : Dean Rasheed <[email protected]>    
date     : Thu, 9 Nov 2023 09:57:52 +0000    
  
committer: Dean Rasheed <[email protected]>    
date     : Thu, 9 Nov 2023 09:57:52 +0000    

Click here for diff

When computing "0 - INT64_MIN", most platforms would report an  
overflow error, which is correct. However, platforms without integer  
overflow builtins or 128-bit integers would fail to spot the overflow,  
and incorrectly return INT64_MIN.  
  
Back-patch to all supported branches.  
  
Patch be me. Thanks to Jian He for initial investigation, and Laurenz  
Albe and Tom Lane for review.  
  
Discussion: https://postgr.es/m/CAEZATCUNK-AZSD0jVdgkk0N%3DNcAXBWeAEX-QU9AnJPensikmdQ%40mail.gmail.com  

M src/include/common/int.h
M src/test/regress/expected/int8.out
M src/test/regress/sql/int8.sql