PostgreSQL 16.2 commit log

commit   : b78fa8547d02fc72ace679fb4d5289dccdbfc781    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 5 Feb 2024 16:41:37 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 5 Feb 2024 16:41:37 -0500    

commit   : da21a3a7d5d37e34f2adef07b1f2f6231d61c3cc    
  
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    

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

commit   : 246d16eb8738298c929b6c2ca21f1192d896c89a    
  
author   : Peter Eisentraut <[email protected]>    
date     : Mon, 5 Feb 2024 14:45:29 +0100    
  
committer: Peter Eisentraut <[email protected]>    
date     : Mon, 5 Feb 2024 14:45:29 +0100    

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

commit   : fb3836855ca12024f3d7432a4a04217073b1688c    
  
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    

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  

commit   : d6a61cb3bef3c8fbc35c2a6182e75a8c1d351e41    
  
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    

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  

commit   : 272aecfc2f496c90ddcba8e69b0f9b5cf2978ec6    
  
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    

commit   : cd307c38f043e40fd2419d5a035b1a078a32c6b4    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Sat, 3 Feb 2024 00:18:21 +0200    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Sat, 3 Feb 2024 00:18:21 +0200    

Backpatch-through: v16  

commit   : a15378100fae00d3954337a52f15bc38fd7ab5a8    
  
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    

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  

commit   : 87dcc5e45fad3021514f01360d3a2abd4e6480ee    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 2 Feb 2024 12:52:29 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 2 Feb 2024 12:52:29 -0500    

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

commit   : 48a6bf5c4ea8e04cc9bb33a8120a21743da515ed    
  
author   : Noah Misch <[email protected]>    
date     : Thu, 1 Feb 2024 13:44:19 -0800    
  
committer: Noah Misch <[email protected]>    
date     : Thu, 1 Feb 2024 13:44:19 -0800    

An OS crash could leave PG_VERSION empty or missing.  The same symptom  
appeared in a backup by block device snapshot, taken after the next  
checkpoint and before the OS flushes the PG_VERSION blocks.  Device  
snapshots are not a documented backup method, however.  Back-patch to  
v15, where commit 9c08aea6a3090a396be334cc58c511edab05776a introduced  
STRATEGY=WAL_LOG and made it the default.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 6d423e9ff95ac2e62655faa97633155d08dfdd64    
  
author   : Noah Misch <[email protected]>    
date     : Thu, 1 Feb 2024 13:44:19 -0800    
  
committer: Noah Misch <[email protected]>    
date     : Thu, 1 Feb 2024 13:44:19 -0800    

Restoring a base backup taken in the middle of CreateDirAndVersionFile()  
or write_relmap_file() would lose the function's effects.  The symptom  
was absence of the database directory, PG_VERSION file, or  
pg_filenode.map.  If missing the directory, recovery would fail.  Either  
missing file would not fail recovery but would render the new database  
unusable.  Fix CreateDirAndVersionFile() with the transam/README "action  
first and then write a WAL entry" strategy.  That has a side benefit of  
moving filesystem mutations out of a critical section, reducing the ways  
to PANIC.  Fix the write_relmap_file() call with a lock acquisition, so  
it interacts with checkpoints like non-CREATE DATABASE calls do.  
Back-patch to v15, where commit 9c08aea6a3090a396be334cc58c511edab05776a  
introduced STRATEGY=WAL_LOG and made it the default.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : b4fb76fb5283dcd76de0e5b9ef8c4588ef8ee619    
  
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    

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.  

commit   : 90bad72cbbb3293c4aa11cd8e1a5939c200e7115    
  
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    

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.  

commit   : 62f12020314792cafc7d5e631a3c98cfd33b5fb9    
  
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    

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  

commit   : 88be3f076c4cc26d31586d433cb41185eebb3c11    
  
author   : Bruce Momjian <[email protected]>    
date     : Thu, 1 Feb 2024 06:11:53 -0500    
  
committer: Bruce Momjian <[email protected]>    
date     : Thu, 1 Feb 2024 06:11:53 -0500    

Role option management was changed in Postgres 16.  This patch improves  
the docs around these changes, including CREATE ROLE's INHERIT option,  
inheritance handling, and grant's ability to change role options.  
  
Discussion: https://postgr.es/m/[email protected]  
  
Co-authored-by: David G. Johnston  
  
Backpatch-through: 16  

commit   : 7743046b7557c8eba39449e5f82a9e4d832b2464    
  
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    

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  

commit   : 0df4f75eeafa6d7c7ec9a42744f7acea3eff6383    
  
author   : Daniel Gustafsson <[email protected]>    
date     : Thu, 1 Feb 2024 09:36:34 +0100    
  
committer: Daniel Gustafsson <[email protected]>    
date     : Thu, 1 Feb 2024 09:36:34 +0100    

The openssl command for displaying the DN of a client certificate was  
using --subject and not the single-dash option -subject. While recent  
versions of openssl handles double dash options,  earlier does not so  
fix by using just -subject  (which is per the openssl documentation).  
  
Backpatch to v14 where this was introduced.  
  
Reported-by: [email protected]  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: v14  

commit   : 781bc121de897c235ae731ad9f58dfd4075a1008    
  
author   : Michael Paquier <[email protected]>    
date     : Thu, 1 Feb 2024 17:13:09 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Thu, 1 Feb 2024 17:13:09 +0900    

This impacts the statistics retrieved in transactions for the following  
views when updating the value of stats_fetch_consistency, leading to  
behaviors contrary to what is documented since 605994651b6a as an update  
of this parameter should discard all statistics snapshot data:  
- pg_stat_archiver  
- pg_stat_bgwriter  
- pg_stat_checkpointer  
- pg_stat_io  
- pg_stat_slru  
- pg_stat_wal  
  
For example, updating stats_fetch_consistency from "snapshot" to "cache"  
in a transaction did not re-fetch any fresh data, using data cached from  
the time when "snapshot" was in use.  
  
Author: Shinya Kato  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 15  

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

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  

commit   : 52a9af3b8b9f6ac28c41d2d5d1f743a57e4424e9    
  
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    

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  

commit   : 5d726c72cd0f6b13842896058151bac5f68b4100    
  
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    

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  

commit   : 1c8336e3e2f35e3968f73afc3a78ff34aaa523e2    
  
author   : David Rowley <[email protected]>    
date     : Tue, 30 Jan 2024 10:15:51 +1300    
  
committer: David Rowley <[email protected]>    
date     : Tue, 30 Jan 2024 10:15:51 +1300    

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  

commit   : 1b924a86e696c25775e873ccd4cac1f24ec6502f    
  
author   : Nathan Bossart <[email protected]>    
date     : Mon, 29 Jan 2024 12:09:03 -0600    
  
committer: Nathan Bossart <[email protected]>    
date     : Mon, 29 Jan 2024 12:09:03 -0600    

This function requires simd.h, which is a rather large dependency  
for a widely-used header file like pg_wchar.h.  Furthermore, there  
is a report of a third-party tool that is struggling to use  
pg_wchar.h due to its dependence on simd.h (presumably because  
simd.h uses several intrinsics).  Moving the function to the much  
less popular ascii.h resolves these issues for now.  
  
This commit is back-patched for the benefit of the aforementioned  
third-party tool.  The simd.h dependency was only added in v16,  
but we've opted to back-patch to v15 so that is_valid_ascii() lives  
in the same file for all versions where it exists.  This could  
break existing third-party code that uses the function, but we  
couldn't find any examples of such code.  It should be possible to  
fix any code that this commit breaks by including ascii.h in the  
file that uses is_valid_ascii().  
  
Author: Jubilee Young  
Reviewed-by: Tom Lane, John Naylor, Andres Freund, Eric Ridge  
Discussion: https://postgr.es/m/CAPNHn3oKJJxMsYq%2BqLYzVJOFrUcOr4OF1EC-KtFT-qh8nOOOtQ%40mail.gmail.com  
Backpatch-through: 15  

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

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]  

commit   : b899e00e716bf21c1858c5d07995882a44638ab2    
  
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    

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]  

commit   : edbd1b41ab5bd4be06dbebb3c60149f7910d7c5c    
  
author   : Michael Paquier <[email protected]>    
date     : Thu, 25 Jan 2024 17:07:56 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Thu, 25 Jan 2024 17:07:56 +0900    

Three LOG messages are added in the recovery code paths, providing  
information that can be useful to track corruption issues depending on  
the state of the cluster, telling that:  
- Recovery has started from a backup_label.  
- Recovery is restarting from a backup start LSN, without a  
backup_label.  
- Recovery has completed from a backup.  
  
This was originally applied on HEAD as of 1d35f705e191, and there is  
consensus that this can be useful for older versions.  This applies  
cleanly down to 15, so do it down to this version for now (older  
versions have heavily refactored the WAL recovery paths, making the  
change less straight-forward to do).  
  
Author: Andres Freund  
Reviewed-by: David Steele, Laurenz Albe, Michael Paquier  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 15  

commit   : f57a580fd280fd1057f9526ca98d63f4805fa17b    
  
author   : Michael Paquier <[email protected]>    
date     : Mon, 29 Jan 2024 08:06:03 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Mon, 29 Jan 2024 08:06:03 +0900    

This commit fixes failures with "tuple already updated by self" when  
listing twice the same role and in a DROP ROLE query.  
  
This is an oversight in 6566133c5f52, that has introduced a two-phase  
logic in DropRole() where dependencies of all the roles to drop are  
removed in a first phase, with the roles themselves removed from  
pg_authid in a second phase.  
  
The code is simplified to not rely on a List of ObjectAddress built in  
the first phase used to remove the pg_authid entries in the second  
phase, switching to a list of OIDs.  Duplicated OIDs can be simply  
avoided in the first phase thanks to that.  Using ObjectAddress was not  
necessary for the roles as they are not used for anything specific to  
dependency.c, building all the ObjectAddress in the List with  
AuthIdRelationId as class ID.  
  
In 15 and older versions, where a single phase is used, DROP ROLE with  
duplicated role names would fail on "role \"blah\" does not exist" for  
the second entry after the CCI() done by the first deletion.  This is  
not really incorrect, but it does not seem worth changing based on a  
lack of complaints.  
  
Reported-by: Alexander Lakhin  
Reviewed-by: Tender Wang  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 16  

commit   : 807369d80384cdaa696cd65b4fcee46e32142344    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 26 Jan 2024 15:54:17 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 26 Jan 2024 15:54:17 -0500    

Oversight in 2489d76c4.  Preliminary analysis suggests that the  
problem may be unreachable --- but if we did have instances of  
the same column with different varnullingrels, we'd surely need  
to treat them as different Params.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 7204aea835d056ca97e86298c597a079d6ee8c97    
  
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    

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]  

commit   : 60ba7cae7cc758f09899429d1134a14adc35fd94    
  
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    

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  

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

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  

commit   : 8b31b689f4db9fca726a8d1bab20b89ebb3fa0b1    
  
author   : Peter Eisentraut <[email protected]>    
date     : Tue, 23 Jan 2024 12:15:21 +0100    
  
committer: Peter Eisentraut <[email protected]>    
date     : Tue, 23 Jan 2024 12:15:21 +0100    

portname is set to host_system, but host_system might still be changed  
later in the file.  As a consequence, platforms where host_system is  
changed later wouldn't find some of their platform-specific files  
(driven by portname), and the build would fail.  Move the assignment  
of portname further down after the last change of host_system (but  
before further overriding assignments to portname).  
  
Discussion: https://www.postgresql.org/message-id/flat/CAC7zN94TdsHhY88XkroJzSMx7E%3DBQpV9LKKjNSEnTM04ihoWCA%40mail.gmail.com  

commit   : c5a6d5337170a133490c91d7f6d27ac25c47480b    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Tue, 23 Jan 2024 10:38:07 +0200    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Tue, 23 Jan 2024 10:38:07 +0200    

This reverts commit 728f86fec65537eade8d9e751961782ddb527934.  
  
The signal handling was a few bricks shy of a load in that commit,  
which made the walreceiver non-responsive to SIGTERM while it was  
waiting for the connection to be established. That prevented a standby  
from being promoted.  
  
Since it was non-essential refactoring, let's revert it to make v16  
work the same as earlier releases. I reverted it in 'master' too, to  
keep the branches in sync. The refactoring was a good idea as such,  
but it needs a bit more work. Once we have developed a complete patch  
with this issue fixed, let's re-apply that to 'master'.  
  
Reported-by: Kyotaro Horiguchi  
Backpatch-through: 16  
Discussion: https://www.postgresql.org/message-id/[email protected]  

commit   : cae25d110e0898df2df4fe31fdc45208554ac908    
  
author   : Michael Paquier <[email protected]>    
date     : Tue, 23 Jan 2024 14:46:05 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Tue, 23 Jan 2024 14:46:05 +0900    

This commit tweaks a couple of things in 035_standby_logical_decoding to  
hopefully stabilize it:  
- Autovacuum is now disabled, as it could hold a global xmin with a  
transaction.  
- Conflicts are generated with command sequences that removed rows (on  
catalogs, shared or non-shared, or just plain relations) followed by a  
VACUUM.  This was unstable because these did not check that the horizon  
moved between the SQL commands and the VACUUM.  The logic is refactored  
as follows, to ensure that VACUUM removes dead rows before testing for  
slot invalidation on a standby (idea suggested by Andres Freund):  
-- Grab the current horizon.  
-- Launch SQL commands removing rows.  
-- Check that the snapshot horizon has been updated.  
-- Launch VACUUM on the relation whose rows have been removed by the  
first step.  
  
Note that there are still some issues because of standby snapshot WAL  
records generated by the bgwriter, but this makes the test much more  
stable.  
  
Per reports from buildfarm members dikkop and skink, with analysis and  
tests from Alexander Lakhin.  
  
While on it, fix a couple of incorrect comments.  
  
Author: Bertrand Drouvot  
Reviewed-by: Alexander Lakhin, Michael Paquier  
Discussion: https://postgr.es/m/OSZPR01MB6310ED3CEDB531BCEDBC6AF2FD479@OSZPR01MB6310.jpnprd01.prod.outlook.com  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 16  

commit   : 07b53de700390c8bdee99ce373d84f0cdcad74d6    
  
author   : Alvaro Herrera <[email protected]>    
date     : Mon, 22 Jan 2024 17:48:30 +0100    
  
committer: Alvaro Herrera <[email protected]>    
date     : Mon, 22 Jan 2024 17:48:30 +0100    

When a pipeline is opened with \startpipeline and not closed, pgbench  
will either error on the next transaction with a "already in pipeline  
mode" error or successfully end if this was the last transaction --  
despite not sending anything that was piped in the pipeline.  
  
Make it an error to reach end of script is reached while there's an  
open pipeline.  
  
Backpatch to 14, where pgbench got support for pipelines.  
  
Author: Anthonin Bonnefoy <[email protected]>  
Reported-by: Michael Paquier <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  

commit   : 74f770ef202fd3f1f1d1f0889f04c16440d23bd0    
  
author   : David Rowley <[email protected]>    
date     : Mon, 22 Jan 2024 22:45:33 +1300    
  
committer: David Rowley <[email protected]>    
date     : Mon, 22 Jan 2024 22:45:33 +1300    

This was previously fixed in 9e215378d but got broken again as a result  
of 2489d76c4.  It seems that commit causes ppi_clauses to contain  
duplicate clauses and it's no longer safe to check the list_length of  
that list to determine if there are join conditions other than what's  
mentioned in ppi_clauses.  
  
Here we adjust the check to count the distinct rinfo_serial mentioned in  
ppi_clauses.  We expect that extra->restrictlist won't have duplicate  
rinfo_serials.  
  
Reported-by: Amadeo Gallardo  
Author: Richard Guo  
Discussion: https://postgr.es/m/CADFREbW-BLJd7-a5J%2B5wjVumeFG1ByXiSOFzMtkmY_SDWckTxw%40mail.gmail.com  
Backpatch-through: 16, where 2489d76c4 was introduced.  

commit   : 5b5318c387451e3eb89eddb4574e57a61297102f    
  
author   : Jeff Davis <[email protected]>    
date     : Thu, 18 Jan 2024 15:00:15 -0800    
  
committer: Jeff Davis <[email protected]>    
date     : Thu, 18 Jan 2024 15:00:15 -0800    

Skip test when not using unix domain sockets.  
  
Discussion: https://postgr.es/m/CALDaNm29-8OozsBWo9H6DN_Tb_3yA1QjRJput-KhaN8ncDJtJA@mail.gmail.com  
Backpatch-through: 16  

commit   : 00f941356e56bd80427765a6a8261eb71e4eb3cc    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 18 Jan 2024 16:10:57 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 18 Jan 2024 16:10:57 -0500    

plpgsql fails on new-style CREATE FUNCTION/PROCEDURE commands within  
a routine or DO block, because make_execsql_stmt believes that a  
semicolon token always terminates a SQL command.  Now, that's actually  
been wrong since the day it was written, because CREATE RULE has long  
allowed multiple rule actions separated by semicolons.  But there are  
few enough people using multi-action rules that there was never an  
attempt to fix it.  New-style SQL functions, though, are popular.  
  
psql has this same problem of "does this semicolon really terminate  
the command?".  It deals with CREATE RULE by counting parenthesis  
nesting depth: a semicolon within parens doesn't end a command.  
Commits e717a9a18 and 029c5ac03 created a similar heuristic to count  
matching BEGIN/END pairs (but only within CREATEs, so as not to be  
fooled by plain BEGIN).  That's survived several releases now without  
trouble reports, so let's just absorb those heuristics into plpgsql.  
  
Per report from Samuel Dussault.  Back-patch to v14 where new-style  
SQL function syntax came in.  
  
Discussion: https://postgr.es/m/YT2PR01MB88552C3E9AD40A6C038774A781722@YT2PR01MB8855.CANPRD01.PROD.OUTLOOK.COM  

commit   : c030e263e7fed65d5f936e8b3bb13da22bb09fdb    
  
author   : Michael Paquier <[email protected]>    
date     : Thu, 18 Jan 2024 16:31:38 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Thu, 18 Jan 2024 16:31:38 +0900    

A REINDEX INDEX done on a partitioned index builds a list of the indexes  
to work on before processing its partitions in individual transactions.  
When combined with a DROP of the partitioned index, there was a window  
where it was possible to see some unexpected "could not open relation  
with OID", synonym of relation lookup error.  The code was robust enough  
to handle the case where the parent relation is missing, but not the  
case where an index would be gone missing.  
  
This is similar to 1d65416661bb.  
  
Support for REINDEX on partitioned relations has been introduced in  
a6642b3ae060, so backpatch down to 14.  
  
Author: Fei Changhong  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 14  

commit   : 7ce65c6f7209fcbc73605c914c37c4b2a6406213    
  
author   : Michael Paquier <[email protected]>    
date     : Thu, 18 Jan 2024 15:04:31 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Thu, 18 Jan 2024 15:04:31 +0900    

try_index_open() is able to open an index if its relkind fits, except  
that it would return NULL instead of generated an error if the relation  
does not exist.  This new routine will be used by an upcoming patch to  
make REINDEX on partitioned relations more robust when an index in a  
partition tree is dropped.  
  
Extracted from a larger patch by the same author.  
  
Author: Fei Changhong  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 14  

commit   : 6b14404b0b97530af080a1f5edb940d30464aa0a    
  
author   : Michael Paquier <[email protected]>    
date     : Thu, 18 Jan 2024 10:12:51 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Thu, 18 Jan 2024 10:12:51 +0900    

Oversight in 681d9e4621aa where the test has been added.  
  
Reported-by: Justin Pryzby  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 16  

commit   : 4cf9ef670e4cb6c73aeaec8c1939f4aa26358353    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Wed, 17 Jan 2024 15:44:10 +0200    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Wed, 17 Jan 2024 15:44:10 +0200    

The comment was copy-pasted from the call to ProcSignalInit() in  
AuxiliaryProcessMain(), which uses a similar scheme of having reserved  
slots for aux processes after MaxBackends slots for backends. However,  
ProcSignalInit() indexing starts from 1, whereas BackendStatusArray  
starts from 0. The code is correct, but the comment was wrong.  
  
Discussion: https://www.postgresql.org/message-id/[email protected]  
Backpatch-through: v14  

commit   : 6614d38d8780670d2337090bdf2ec81c0b8bab8e    
  
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    

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  

commit   : a1d50b69b5b637e3ac403bd314cec783bc1676ba    
  
author   : Daniel Gustafsson <[email protected]>    
date     : Tue, 16 Jan 2024 13:51:15 +0100    
  
committer: Daniel Gustafsson <[email protected]>    
date     : Tue, 16 Jan 2024 13:51:15 +0100    

One instance of "WITH clause" was not using <literal> tags around  
WITH, while others were, so add markup to the last one to ensure  
consistency.  Backpatch to v15 where MERGE was added.  
  
Reported-by: jian he <[email protected]>  
Discussion: https://postgr.es/m/CACJufxGJKY9ZCPV2WDM6xFsXq9C8r7r3vU6AkScN+p9k6CEpMw@mail.gmail.com  
Backpatch-through: v15  

commit   : 39aab11085177e4026cec6065a78a425c44e23e3    
  
author   : Alvaro Herrera <[email protected]>    
date     : Tue, 16 Jan 2024 12:27:52 +0100    
  
committer: Alvaro Herrera <[email protected]>    
date     : Tue, 16 Jan 2024 12:27:52 +0100    

Commit b8ba7344e9eb added in PQgetResult a derefence to a pointer  
returned by pqPrepareAsyncResult(), before some other code that was  
already testing that pointer for nullness.  But since commit  
618c16707a6d (in Postgres 15), pqPrepareAsyncResult() doesn't ever  
return NULL (a statically-allocated result is returned if OOM).  So in  
branches 15 and up, we can remove the redundant pointer check with no  
harm done.  
  
However, in branch 14, pqPrepareAsyncResult() can indeed return NULL if  
it runs out of memory.  Fix things there by adding a null pointer check  
before dereferencing the pointer.  This should hint Coverity that the  
preexisting check is not redundant but necessary.  
  
Backpatch to 14, like b8ba7344e9eb.  
  
Per Coverity.  

commit   : 23e0ba59c777b810e42a03ebf36dd9b60031e77c    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 14 Jan 2024 12:38:41 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 14 Jan 2024 12:38:41 -0500    

When ExecBRUpdateTriggers switches to a new target tuple as a result  
of the EvalPlanQual logic, it must form a new proposed update tuple.  
Since commit 86dc90056, that tuple (the result of  
ExecGetUpdateNewTuple) has been a virtual tuple that might contain  
pointers to by-ref fields of the new target tuple (in "oldslot").  
However, immediately after that we materialize oldslot, causing it to  
drop its buffer pin, whereupon the by-ref pointers are unsafe to use.  
This is a live bug only when the new target tuple is in a different  
page than the original target tuple, since we do still hold a pin on  
the original one.  (Before 86dc90056, there was no bug because the  
EPQ plantree would hold a pin on the new target tuple; but now that's  
not assured.)  To fix, forcibly materialize the new tuple before we  
materialize oldslot.  This costs nothing since we would have done that  
shortly anyway.  
  
The real-world impact of this is probably minimal.  A visible failure  
could occur if the new target tuple's buffer were recycled for some  
other page in the short interval before we materialize newslot within  
the trigger-calling loop; but that's quite unlikely given that we'd  
just touched that page.  There's a larger hazard that some other  
process could prune and repack that page within the window.  We have  
lock on the new target tuple, but that wouldn't prevent it being moved  
on the page.  
  
Alexander Lakhin and Tom Lane, per bug #17798 from Alexander Lakhin.  
Back-patch to v14 where 86dc90056 came in.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 56dcd71decb79be31a54eac582e656e20c39f4a4    
  
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    

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

commit   : 7e2561e1a258ced4250c5d5d1b3b0221930dbf7e    
  
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    

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  

commit   : 41820e640af14ab9d2a8d29692fc8b2b79655ecb    
  
author   : Jeff Davis <[email protected]>    
date     : Fri, 12 Jan 2024 21:39:35 -0800    
  
committer: Jeff Davis <[email protected]>    
date     : Fri, 12 Jan 2024 21:39:35 -0800    

Introduced in commit c3afe8cf5a.  
  
Discussion: https://postgr.es/m/[email protected]  
Reviewed-by: Nathan Bossart, Tom Lane  
Backpatch-through: 16  

commit   : 4c03ac7e2bc46988fe4ecf3b1aef393488786f12    
  
author   : Jeff Davis <[email protected]>    
date     : Fri, 12 Jan 2024 13:42:09 -0800    
  
committer: Jeff Davis <[email protected]>    
date     : Fri, 12 Jan 2024 13:42:09 -0800    

A superuser may create a subscription with password_required=true, but  
which uses a connection string without a password.  
  
Previously, if the owner of such a subscription was changed to a  
non-superuser, the non-superuser was able to utilize a password from  
another source (like a password file or the PGPASSWORD environment  
variable), which should not have been allowed.  
  
This commit adds a step to re-validate the connection string before  
connecting.  
  
Reported-by: Jeff Davis  
Author: Vignesh C  
Reviewed-by: Peter Smith, Robert Haas, Amit Kapila  
Discussion: https://www.postgresql.org/message-id/flat/e5892973ae2a80a1a3e0266806640dae3c428100.camel%40j-davis.com  
Backpatch-through: 16  

commit   : 9c00e4c7751f50e81636b0e837809b309bfe7ef6    
  
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    

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]  

commit   : 506c77f9b2e5870fec6ff845d69678195438de5b    
  
author   : Michael Paquier <[email protected]>    
date     : Fri, 12 Jan 2024 13:59:51 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Fri, 12 Jan 2024 13:59:51 +0900    

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  

commit   : 714bfb7813ede66724f0b7d02b3a0240754eb499    
  
author   : Michael Paquier <[email protected]>    
date     : Fri, 12 Jan 2024 13:53:07 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Fri, 12 Jan 2024 13:53:07 +0900    

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  

commit   : 80bece312c4b957ea5a93db84be1d1776f0e5e67    
  
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    

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]  

commit   : af36f1993da1dc35a45337faab22a46e068443c3    
  
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    

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]  

commit   : ba33775fd0302befddfc5102c51e0e9fb1f282d3    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 10 Jan 2024 18:09:29 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 10 Jan 2024 18:09:29 -0500    

In commit 3e51b278d I (tgl) caused initdb to leave lc_messages and  
other lc_xxx GUCs commented-out in the installed postgresql.conf file  
if they were going to be set to 'C'.  This was a hack for cosmetic  
purposes, and it was buggy because lc_messages' wired-in default is  
not 'C' but '' (empty string).  That led to --no-locale not having  
the expected effect, since the postmaster would then obtain  
lc_messages from its startup environment.  
  
Let's just revert to the prior behavior of always de-commenting the  
lc_xxx entries; the argument for changing that longstanding behavior  
was weak in the first place.  
  
Also, fix postgresql.conf.sample's erroneous claim that the default  
value of lc_messages is 'C'.  I suspect that was what misled me into  
making this mistake in the first place.  
  
Report and patch by Kyotaro Horiguchi.  Back-patch to v16 where  
the problem was introduced.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : ee955321869e46289d11b0c77255c74d62caf3a5    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 10 Jan 2024 13:36:34 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 10 Jan 2024 13:36:34 -0500    

Commit 9d9c02ccd, which added the notion of a "run condition" for  
window functions, neglected to teach nodeFuncs.c to process the new  
field.  Remarkably, that doesn't seem to have had any ill effects  
before we invented Var.varnullingrels, but now it can cause visible  
failures in join-removal scenarios.  
  
I have no faith that there's not reachable problems in v15 too,  
so back-patch the code change to v15 where 9d9c02ccd came in.  
The test case seems irrelevant to v15, though.  
  
Per bug #18277 from Zuming Jiang.  Diagnosis and patch by  
Richard Guo.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 65ee2ed0d0da6dd45853b050b4d59634d64479bd    
  
author   : Bruce Momjian <[email protected]>    
date     : Wed, 10 Jan 2024 11:20:15 -0500    
  
committer: Bruce Momjian <[email protected]>    
date     : Wed, 10 Jan 2024 11:20:15 -0500    

Discussion: https://postgr.es/m/[email protected]  
  
Backpatch-through: 16  

commit   : a12774ba0e0a6125f46d8ddd59a5afe83a6e7a78    
  
author   : Tatsuo Ishii <[email protected]>    
date     : Tue, 9 Jan 2024 19:46:36 +0900    
  
committer: Tatsuo Ishii <[email protected]>    
date     : Tue, 9 Jan 2024 19:46:36 +0900    

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  

commit   : 20a566cd43bb45561c64315f7744282100abb7f1    
  
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    

Backpatch-through: 12  

commit   : cf6f802bf538ab1c9c0ef60a6e9d6fafdfb06b98    
  
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    

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]  

commit   : 714a987bc1333121bb83415f764076c8e7e8d8fb    
  
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    

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  

commit   : 37c5516633c833de6bdb57a1752a2f8e8f0d5420    
  
author   : Michael Paquier <[email protected]>    
date     : Fri, 5 Jan 2024 20:10:46 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Fri, 5 Jan 2024 20:10:46 +0900    

A typo has been introduced by 31966b151e6a when updating the state of a  
local buffer when a temporary relation is extended, for the case of a  
block included in the relation range extended, when it is already found  
in the hash table holding the local buffers.  In this case, BM_VALID  
should be cleared, but the buffer state was changed so as BM_VALID  
remained while clearing the other flags.  
  
As reported on the thread, it was possible to corrupt the state of the  
local buffers on ENOSPC, but the states would be corrupted on any kind  
of ERROR during the relation extend (like partial writes or some other  
errno).  
  
Reported-by: Alexander Lakhin  
Author: Tender Wang  
Reviewed-by: Richard Guo, Alexander Lakhin, Michael Paquier  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 16  

commit   : 6298673f4b91b8b5815855785cc30f0ac390988e    
  
author   : David Rowley <[email protected]>    
date     : Thu, 4 Jan 2024 20:40:11 +1300    
  
committer: David Rowley <[email protected]>    
date     : Thu, 4 Jan 2024 20:40:11 +1300    

1349d2790 added code to allow DISTINCT and ORDER BY aggregates to work  
more efficiently by using presorted input.  That commit added some code  
that made use of the AggState's tmpcontext and adjusted the  
ecxt_outertuple and ecxt_innertuple slots before checking if the current  
row is distinct from the previously seen row.  That code forgot to set the  
TupleTableSlots back to what they were originally, which could result in  
errors such as:  
  
ERROR:  attribute 1 of type record has wrong type  
  
This only affects aggregate functions which have multiple arguments when  
DISTINCT is used.  For example: string_agg(DISTINCT col, ', ')  
  
Thanks to Tom Lane for identifying the breaking commit.  
  
Bug: #18264  
Reported-by: Vojtěch Beneš  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 16, where 1349d2790 was added  

commit   : 79a2af3e7277122858da61eff8177d5fe487ce92    
  
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    

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

commit   : fb464a1ae3c9cafffe18bb921c8f7bff7597305e    
  
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    

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]  

commit   : 65218693d0c7a78cd00840c00cc00edd6afb3076    
  
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    

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

commit   : b2c9936a7156926ace70b89ffb9cfbe1e3b9a559    
  
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    

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]  

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

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  

commit   : d02cceb85cf1a46a36c36825dd8266a30aed134f    
  
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    

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  

commit   : e87252ceb8dc5cffca7867a1458053f0ace51c31    
  
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    

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]  

commit   : c72049dbc341ad995579658c572a1ec8f6209f36    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 26 Dec 2023 17:03:02 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 26 Dec 2023 17:03:02 -0500    

Brown-paper-bag bug in commit 58c3151bb.  Per buildfarm.  

commit   : b0115e7e20a6cbf1705d0661be09383c89c59bc1    
  
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    

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]  

commit   : 06bbe735410e9ba987a2e700f1b0546e8c14b3d8    
  
author   : Amit Kapila <[email protected]>    
date     : Tue, 26 Dec 2023 11:18:05 +0530    
  
committer: Amit Kapila <[email protected]>    
date     : Tue, 26 Dec 2023 11:18:05 +0530    

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  

commit   : 11652f919d44f865aa21e85c99fcd070bb36d883    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 23 Dec 2023 11:50:33 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 23 Dec 2023 11:50:33 -0500    

Commit 664d75753 pulled 010_tab_completion.pl's infrastructure for  
invoking an interactive psql session out into a generally-useful test  
function, but it didn't move enough stuff.  We need to set up various  
environment variables that readline will look at, both to ensure  
stability of test results and to prevent test actions from cluttering  
the calling user's ~/.psql_history.  Expecting calling scripts to  
remember to do that is too failure-prone: the other existing caller  
001_password.pl did not do it.  Hence, remove those initialization  
steps from 010_tab_completion.pl and put them into interactive_psql().  
Since interactive_psql was already making a local ENV hash, this has  
no effect on calling scripts.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 0977bd64e294bba50efc354479ebe3925cffa0ef    
  
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    

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]  

commit   : 7f07384dc2697abb405e47a7447c6edf7e07d5f9    
  
author   : Dean Rasheed <[email protected]>    
date     : Thu, 21 Dec 2023 12:53:48 +0000    
  
committer: Dean Rasheed <[email protected]>    
date     : Thu, 21 Dec 2023 12:53:48 +0000    

Fix a bug during MERGE if a cross-partition update is attempted on a  
partitioned table with a BEFORE DELETE ROW trigger that returns NULL,  
to prevent the update. This would cause an error to be thrown, or an  
assert failure in an assert-enabled build.  
  
This was an oversight in 9321c79c86, which failed to properly  
distinguish a DELETE prevented by a trigger from one prevented by a  
concurrent update. Fix by having ExecDelete() return the TM_Result  
status to ExecCrossPartitionUpdate(), so that it can distinguish the  
two cases, and make ExecCrossPartitionUpdate() return the TM_Result  
status to ExecUpdateAct(), so that it can return the correct status  
from a concurrent update.  
  
In addition, ensure that the command tag is correctly updated by  
having ExecMergeMatched() pass canSetTag to ExecUpdateAct(), rather  
than passing false, so that it updates the command tag if it does a  
cross-partition update, making this code path in ExecMergeMatched()  
consistent with ExecUpdate().  
  
Per bug #18238 from Alexander Lakhin. Back-patch to v15, where MERGE  
was introduced.  
  
Dean Rasheed, reviewed by Richard Guo and Jian He.  
  
Discussion: https://postgr.es/m/18238-2f2bdc7f720180b9%40postgresql.org  

commit   : 5b5db413d26ff49e9fd6506258a838ba0a9ea151    
  
author   : Daniel Gustafsson <[email protected]>    
date     : Wed, 20 Dec 2023 22:37:28 +0100    
  
committer: Daniel Gustafsson <[email protected]>    
date     : Wed, 20 Dec 2023 22:37:28 +0100    

The pg_dump compression was using strdup() instead of pg_strdup()  
and failed to check the returned pointer for out-of-memory before  
dereferencing it. Fix by using pg_strdup() instead which probably  
was the intention here in the original patch.  
  
Backpatch to v16 where pg_dump compression was introduced.  
  
Reviewed-by: Tristan Partin <[email protected]>  
Reviewed-by: Nathan Bossart <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 16  

commit   : 94415b04ed0d1f3334c413924e367b25df57f2fd    
  
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    

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]  

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

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  

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

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  

commit   : 8b9d39254816195abb55ab204e39f8fa476aad23    
  
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    

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]  

commit   : 152bfc0af89de25400abe49205f1d9861a199b61    
  
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    

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]  

commit   : db69101a1d000d857a552e16e45f601adbb4dbc6    
  
author   : Michael Paquier <[email protected]>    
date     : Thu, 14 Dec 2023 09:59:47 +0100    
  
committer: Michael Paquier <[email protected]>    
date     : Thu, 14 Dec 2023 09:59:47 +0100    

This fixes an error introduced by efb0ef909f60, that changed the  
description of this field to "shared/local" while these I/O timings  
relate to shared buffers.  This information is available when  
track_io_timing is enabled.  Note that HEAD has added new counters for  
local buffers in 295c36c0c1fa, so there is no need to touch it.  The  
description is updated to "shared" to be compatible with HEAD.  
  
Per discussion with Nazir Bilal Yavuz and Hubert Depesz Lubaczewski,  
whose EXPLAIN analyzer tool was not actually able to parse the previous  
term because of the slash character.  
  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 15  

commit   : 8ae87728c583eb05714bd01430945fb7c7a74a7c    
  
author   : Peter Eisentraut <[email protected]>    
date     : Thu, 14 Dec 2023 09:48:24 +0100    
  
committer: Peter Eisentraut <[email protected]>    
date     : Thu, 14 Dec 2023 09:48:24 +0100    

Reported-by: Junwang Zhao <[email protected]>  

commit   : 0e2c05af90ee51f87564e37abdd1df1a8f554064    
  
author   : Michael Paquier <[email protected]>    
date     : Tue, 12 Dec 2023 17:05:27 +0100    
  
committer: Michael Paquier <[email protected]>    
date     : Tue, 12 Dec 2023 17:05:27 +0100    

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  

commit   : 810c9609f8a5f82025db7d2b4023966d22785898    
  
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    

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]  

commit   : ebbd499d4b55c6a6223e01e914308f4a3b936a88    
  
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    

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]  

commit   : 01cc92fa6251c4d1a0ac128806db6f7d8f31ec7f    
  
author   : Amit Kapila <[email protected]>    
date     : Mon, 11 Dec 2023 08:36:17 +0530    
  
committer: Amit Kapila <[email protected]>    
date     : Mon, 11 Dec 2023 08:36:17 +0530    

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]  

commit   : 8ca56620caffd6a1761eebd6a9498235321f222b    
  
author   : Thomas Munro <[email protected]>    
date     : Fri, 8 Dec 2023 15:10:48 +1300    
  
committer: Thomas Munro <[email protected]>    
date     : Fri, 8 Dec 2023 15:10:48 +1300    

While checking if a record could fit in the circular WAL decoding  
buffer, the coding from commit 3f1ce973 used arithmetic that could  
overflow.  64 bit systems were unaffected for various technical reasons,  
which probably explains the lack of problem reports.  Likewise for 32  
bit systems running known 32 bit kernels.  The systems at risk of  
problems appear to be 32 bit processes running on 64 bit kernels, with  
unlucky placement in memory.  
  
Per complaint from GCC -fsanitize=undefined -m32, while testing  
variations of 039_end_of_wal.pl.  
  
Back-patch to 15.  
  
Reviewed-by: Nathan Bossart <[email protected]>  
Reviewed-by: Robert Haas <[email protected]>  
Discussion: https://postgr.es/m/CA%2BhUKGKH0oRPOX7DhiQ_b51sM8HqcPp2J3WA-Oen%3DdXog%2BAGGQ%40mail.gmail.com  

commit   : a09aa18eaa6aafd33bae7c32d99eb9e86a6ca3d6    
  
author   : Michael Paquier <[email protected]>    
date     : Fri, 8 Dec 2023 10:37:34 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Fri, 8 Dec 2023 10:37:34 +0900    

During a pg_upgrade test using an old dump, all references to the old  
regress shared library path (so, dylib or dll) are updated to point to  
the library path used by the new build, to ensure a consistent  
comparison between the old and new dumps.  
  
The test previously relied on a hardcoded value of "src/test/regress/"  
to build the new path value, which would point to an incorrect location  
for the meson and vpath builds.  This is replaced by REGRESS_SHLIB, able  
to point to the correct location of the regress shared library.  
  
Author: Alexander Lakhin  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 15  

commit   : 6248a2bb92ccd4c591437c415775ab3b34c61d4c    
  
author   : Michael Paquier <[email protected]>    
date     : Wed, 6 Dec 2023 14:11:41 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Wed, 6 Dec 2023 14:11:41 +0900    

This has been broken since b060dbe0001a that has reworked the callback  
mechanism of XLogReader, most likely unnoticed because any form of  
development involving WAL happens on platforms where this compiles fine.  
  
Author: Bharath Rupireddy  
Discussion: https://postgr.es/m/CALj2ACVF14WKQMFwcJ=3okVDhiXpuK5f7YdT+BdYXbbypMHqWA@mail.gmail.com  
Backpatch-through: 13  

commit   : a499c08dca5e0162e210cc8a411698e2808a04da    
  
author   : Michael Paquier <[email protected]>    
date     : Wed, 6 Dec 2023 09:55:00 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Wed, 6 Dec 2023 09:55:00 +0900    

This commit removes the restriction that would not apply filters to the  
dumps used for comparison in the TAP test of pg_upgrade when using the  
same base version for the old and new nodes.  
  
The previous logic would fail on Windows if loading a dump while using  
the same set of binaries for the old and new nodes, as the library  
dependencies updated in the old dump would append CRLFs to the dump  
file as it is treated as a text file.  The dump filtering logic replaces  
all CRLFs (\r\n) by LFs (\n), which is able to prevent this issue.  
  
When the old and new versions of the binaries are the same,  
AdjustUpgrade removes all blank lines, removes version-based comments  
generated by pg_dump and replaces CRLFs by LFs.  
  
Reported-by: Alexander Lakhin  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 15  

commit   : 8da1fb13bdb14b7a3f3ecad2d4b1530fd00227da    
  
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    

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  

commit   : 878aa41f8257b1e8b36a690d62475b4e6f1ede33    
  
author   : Alvaro Herrera <[email protected]>    
date     : Tue, 5 Dec 2023 12:43:24 +0100    
  
committer: Alvaro Herrera <[email protected]>    
date     : Tue, 5 Dec 2023 12:43:24 +0100    

The logic to keep the libpq command queue in sync with queries that have  
been processed had a bug when errors were returned for reasons other  
than problems in queries -- for example, when a connection is lost.  We  
incorrectly consumed an element from the command queue every time, but  
this is wrong and can lead to the queue becoming empty ahead of time,  
leading to later malfunction: PQgetResult would return nothing,  
potentially causing the calling application to enter a busy loop.  
  
Fix by making the SYNC queue element a barrier that can only be consumed  
when a SYNC message is received.  
  
Backpatch to 14.  
  
Reported by: Иван Трофимов (Ivan Trofimov) <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  

commit   : 419cac053b6b27e4111216b8a529a1a0887580bb    
  
author   : Alvaro Herrera <[email protected]>    
date     : Mon, 4 Dec 2023 14:00:51 +0100    
  
committer: Alvaro Herrera <[email protected]>    
date     : Mon, 4 Dec 2023 14:00:51 +0100    

It draws an unnecessary error in builds compiled without thread support.  
  
Added by commit 038f586d5f1d, which was backpatched to 14; though in  
branch master we no longer support such builds, there's no reason to  
have this there, so remove it in all branches since 14.  
  
Reported-by: Michael Paquier <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  

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

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  

commit   : 267f33f684173296897a5157e760c5fb7009964d    
  
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    

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  

commit   : 1dac2dd6779a7a5b35bd222f74bee1fe8c6e560d    
  
author   : Peter Eisentraut <[email protected]>    
date     : Fri, 1 Dec 2023 08:40:45 +0100    
  
committer: Peter Eisentraut <[email protected]>    
date     : Fri, 1 Dec 2023 08:40:45 +0100    

Commit f40c6969d0 added the information schema usage tables but added  
documentation that they did not fully work yet.  Commit e717a9a18b  
then added SQL-standard function bodies, which made the information  
schema views fully functional, but it neglected to update the  
documentation.  This is now done here.  
  
Reported-by: Erki Eessaar <[email protected]>  
Reviewed-by: Erki Eessaar <[email protected]>  
Discussion: https://www.postgresql.org/message-id/flat/AM9PR01MB8268EC7B696F9FE346CA5B93FEB8A%40AM9PR01MB8268.eurprd01.prod.exchangelabs.com  

commit   : 70516b8fc3ee77113013930efb7bfdbabcfed885    
  
author   : Andres Freund <[email protected]>    
date     : Thu, 30 Nov 2023 17:43:39 -0800    
  
committer: Andres Freund <[email protected]>    
date     : Thu, 30 Nov 2023 17:43:39 -0800    

The just released meson 1.3 strongly deprecated a hack we were using, emitting  
a noisy warning (the hack basically depended on an implementation detail to  
work). Turns out there has been a better way available for a while, I just  
hadn't found it. 1.4 added a more convenient approach, but we can't rely on  
that.  
  
Reviewed-by: Tristan Partin <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  
Backpatch: 16-, where the meson build was added.  

commit   : cf84755575d1052770e92d291d1427720c8b53ca    
  
author   : Thomas Munro <[email protected]>    
date     : Fri, 1 Dec 2023 14:58:40 +1300    
  
committer: Thomas Munro <[email protected]>    
date     : Fri, 1 Dec 2023 14:58:40 +1300    

Commit 7389aad6 removed the notion of backends started from inside a  
signal handler.  A stray comment still referred to them, while  
explaining the need for a call to set_stack_base().  That leads to the  
question of whether we still need the call in !EXEC_BACKEND builds.  
There doesn't seem to be much point in suppressing it now, as it doesn't  
hurt and probably helps to measure the stack base from the exact same  
place in EXEC_BACKEND and !EXEC_BACKEND builds.  
  
Back-patch to 16.  
  
Reported-by: Heikki Linnakangas <[email protected]>  
Reported-by: Tristan Partin <[email protected]>  
Reported-by: Andres Freund <[email protected]>  
Discussion: https://postgr.es/m/CA%2BhUKG%2BEJHcevNGNOxVWxTNFbuB%3Dvjf4U68%2B85rAC_Sxvy2zEQ%40mail.gmail.com  

commit   : 1f5e38847b26265c15bf367de516b46491c3a7c3    
  
author   : Peter Eisentraut <[email protected]>    
date     : Thu, 30 Nov 2023 07:22:51 +0100    
  
committer: Peter Eisentraut <[email protected]>    
date     : Thu, 30 Nov 2023 07:22:51 +0100    

When we look for the Python installation using the meson python  
module, we should make it use the python program previously determined  
by the 'PYTHON' option.  Otherwise, it will just use its own search  
and the 'PYTHON' option won't affect it.  We need this to be able to  
select the Python installation to build PL/Python against.  
  
Reviewed-by: Andres Freund <[email protected]>  
Discussion: https://www.postgresql.org/message-id/flat/3f5427e8-cef6-474d-ae88-13db1bfdc1a7%40eisentraut.org  

commit   : 2d758dca1b31baed43c3f17ea742bee6a9ed7dbd    
  
author   : Masahiko Sawada <[email protected]>    
date     : Thu, 30 Nov 2023 11:23:05 +0900    
  
committer: Masahiko Sawada <[email protected]>    
date     : Thu, 30 Nov 2023 11:23:05 +0900    

Backpatch through 16 where this was introduced by 664d757531e1.  
  
Reviewed-by: Daniel Gustafsson  
Backpatch-through: 16  
Discussion: http://postgr.es/m/CAD21AoBXMEqDBLoDuAWVWoTLYB4aNsxx4oYNmyJJbhfq_vGQBQ@mail.gmail.com  

commit   : c684d7c80f5cb60d2c67a42ef4568dbc121fed6e    
  
author   : Masahiko Sawada <[email protected]>    
date     : Thu, 30 Nov 2023 10:14:26 +0900    
  
committer: Masahiko Sawada <[email protected]>    
date     : Thu, 30 Nov 2023 10:14:26 +0900    

The set_query_timer_restart() required an argument to define a value  
to query_timer_restart, but none of the existing callers passes an  
argument to this function.  
  
This changes the function to set a value without an argument.  
  
Backpatch through 16 where the background psql TAP functions were  
refactored by 664d757531e1.  
  
Reviewed-by: Bharath Rupireddy, Tom Lane  
Discussion: https://postgr.es/m/CAD21AoA0B6VKe_5A9nZi8i5umwSN-zJJuPVNht9DaOZ9SJumMA@mail.gmail.com  
Backpatch-through: 16  

commit   : efa8f606402c3d7ca361932418cbcc2600b6c059    
  
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    

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  

commit   : 9fee3232a1d3661981c3cbf87227bfd02ee36c7b    
  
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    

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  

commit   : 07cb7bc1c7a88299e6bce281320397f07ca045c2    
  
author   : Michael Paquier <[email protected]>    
date     : Tue, 28 Nov 2023 08:35:56 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Tue, 28 Nov 2023 08:35:56 +0900    

scram_SaltedPassword() could take a long time to compute when the number  
of iterations used is large enough, and this code uses a tight loop to  
compute a salted password.  
  
Note that the same issue exists in libpq when using \password and a  
large iteration number, but this cannot be interrupted.  A CFI in the  
backend is useful for server-side computations, at least.  
  
Backpatch down to 16, where the user-settable GUC scram_iterations has  
been added.  
  
Author: Bowen Shi  
Reviewed-by: Aleksander Alekseev, Daniel Gustafsson  
Discussion: https://postgr.es/m/CAM_vCueV6xfr08KczfaCEk5J_qeTZtgqN7+orkNLx=g+phE82Q@mail.gmail.com  
Backpatch-through: 16  

commit   : bc22bd2575518cd69351c9fc2b459315a5858019    
  
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    

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  

commit   : d7ca9209c9707703d6fd3bb7dc6d539803a72876    
  
author   : Amit Kapila <[email protected]>    
date     : Mon, 27 Nov 2023 08:59:12 +0530    
  
committer: Amit Kapila <[email protected]>    
date     : Mon, 27 Nov 2023 08:59:12 +0530    

52e4f0cd4 introduced a bug in pgoutput in which missing values in tuples  
were incorrectly filled in with NULL. The problem was the use of  
CreateTupleDescCopy where CreateTupleDescCopyConstr was required, as the  
former drops the constraints in the tuple description (specifically, the  
default value constraint) on the floor.  
  
The bug could result in incorrectness when a table replicated via  
`REPLICA IDENTITY FULL` underwent a schema change that added a column  
with a default value. The problem is that in such cases updates fill NULL  
values in old tuples for missing columns for default values. Then on the  
subscriber, we failed to find a matching tuple and missed updating the  
required row.  
  
Author: Nikhil Benesch  
Reviewed-by: Hou Zhijie, Amit Kapila  
Backpatch-through: 15  
Discussion: http://postgr.es/m/CAPWqQZTEpZQamYsGMn6ZDRvVywwpVPiKH6OY4KSgA+NmeqFNzA@mail.gmail.com  

commit   : 8984480b545dcd8d09d8b877d71d9eae0b3bcb92    
  
author   : Michael Paquier <[email protected]>    
date     : Mon, 27 Nov 2023 09:40:49 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Mon, 27 Nov 2023 09:40:49 +0900    

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  

commit   : 9033e7019821d9ca9e931e2a70e79b9b401c5f01    
  
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    

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  

commit   : c136eb02981566d56e950f12ab7ee4a6ea51d698    
  
author   : Bruce Momjian <[email protected]>    
date     : Fri, 24 Nov 2023 17:56:28 -0500    
  
committer: Bruce Momjian <[email protected]>    
date     : Fri, 24 Nov 2023 17:56:28 -0500    

Reported-by: Kyotaro HORIGUCHI  
  
Discussion: https://postgr.es/m/[email protected]  
  
Co-authored-by: Kyotaro HORIGUCHI  
  
Backpatch-through: 16  

commit   : 7471230cc697fec3dc3c4094aa81469c02fa53c6    
  
author   : Bruce Momjian <[email protected]>    
date     : Fri, 24 Nov 2023 14:36:00 -0500    
  
committer: Bruce Momjian <[email protected]>    
date     : Fri, 24 Nov 2023 14:36:00 -0500    

Reported-by: David Rowley  
  
Discussion: https://postgr.es/m/CAKJS1f_OQpz7rpe-KJmskVxbU06buiXbfonxG3JLB+nGCJ5E=g@mail.gmail.com  
  
Backpatch-through: 16  

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

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]  

commit   : 501cfd07dac6dde5f8dae2d00fcf65d42e2caf80    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Thu, 23 Nov 2023 13:30:13 +0200    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Thu, 23 Nov 2023 13:30:13 +0200    

If an error is thrown after calling CreateWaitEventSet(), the memory  
of a WaitEventSet is free'd as it's allocated in the short-lived  
memory context, but the file descriptor (on epoll- or kqueue-based  
systems) or handles (on Windows) that it contains are leaked.  
  
Use PG_TRY-FINALLY to ensure it gets freed. (On master, I will apply a  
better fix, using ResourceOwners to track the WaitEventSet, but that's  
not backpatchable.)  
  
The added test doesn't check for leaking resources, so it passed even  
before this commit. But at least it covers the code path.  
  
In the passing, fix misleading comment on what the 'nevents' argument  
to WaitEventSetWait means.  
  
Report by Alexander Lakhin, analysis and suggestion for the fix by Tom  
Lane. Fixes bug #17828. Backpatch to v14 where async execution was  
introduced, but master gets a different fix.  
  
Discussion: https://www.postgresql.org/message-id/[email protected]  
Discussion: https://www.postgresql.org/message-id/[email protected]  

commit   : 1b6da28e0668eb977dcab6987d192ddedf32b752    
  
author   : Amit Kapila <[email protected]>    
date     : Wed, 22 Nov 2023 11:27:38 +0530    
  
committer: Amit Kapila <[email protected]>    
date     : Wed, 22 Nov 2023 11:27:38 +0530    

The copy command formed for initial sync was using parenthesis for tables  
with no columns leading to syntax error. This patch avoids adding  
parenthesis for such tables.  
  
Reported-by: Justin G  
Author: Vignesh C  
Reviewed-by: Peter Smith, Amit Kapila  
Backpatch-through: 15  
Discussion: http://postgr.es/m/[email protected]  

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

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  

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

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  

commit   : ee32b824dcc1c9e7efdc065dd152eed39bd97e13    
  
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    

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  

commit   : f47482609f26c1ea28a9a7f599f53c6dac427de0    
  
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    

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

commit   : 72d0c135bd7a9ab4602ea1bece0054bb1e8d372d    
  
author   : Dean Rasheed <[email protected]>    
date     : Sat, 18 Nov 2023 14:46:02 +0000    
  
committer: Dean Rasheed <[email protected]>    
date     : Sat, 18 Nov 2023 14:46:02 +0000    

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  

commit   : 3b6728910ace14c64ffa43b538a84508f4fe6408    
  
author   : Dean Rasheed <[email protected]>    
date     : Sat, 18 Nov 2023 12:39:49 +0000    
  
committer: Dean Rasheed <[email protected]>    
date     : Sat, 18 Nov 2023 12:39:49 +0000    

On the MERGE page, the description of the privileges required could be  
taken to imply that the SELECT privilege is required on all columns of  
the data source, whereas actually it is only required on the columns  
referred to by conditions or expressions in the MERGE command. Re-word  
it to make that a little clearer, and mention expressions as well as  
conditions.  
  
Also, add a glossary entry for MERGE, and nearby on the glossary page,  
mention MERGE in the list of commands that cannot update a  
materialized view.  
  
Noted by Jian He. Patch by me, reviewed by Jian He.  
  
Discussion: https://postgr.es/m/CACJufxHuSoRXKwr0MtSFLXuT2nFVWcVfEWhxg7qdP9h%2Bs3a%2BUw%40mail.gmail.com  

commit   : be08a359db7231f81f8d64975f4babf6dd24bfec    
  
author   : Andres Freund <[email protected]>    
date     : Fri, 17 Nov 2023 16:29:48 -0800    
  
committer: Andres Freund <[email protected]>    
date     : Fri, 17 Nov 2023 16:29:48 -0800    

This could lead to an error like  
  
ERROR: File 'contrib/sepgsql/sepgsql.sql' could not be found  
  
Backpatch: 16-, where meson was added  

commit   : 2cf50585e54a7b0c6bc62a087c69043ae57e4252    
  
author   : Daniel Gustafsson <[email protected]>    
date     : Fri, 17 Nov 2023 10:14:45 +0100    
  
committer: Daniel Gustafsson <[email protected]>    
date     : Fri, 17 Nov 2023 10:14:45 +0100    

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  

commit   : f07a3039c72b4a7afbe2b898fd1194575d13c37e    
  
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    

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]  

commit   : 2927b1dca7ae55a7bd4e24a2053afa62d9796404    
  
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    

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  

commit   : 8737faa68edd15e747e29210c87cf040941c34b5    
  
author   : Peter Eisentraut <[email protected]>    
date     : Tue, 14 Nov 2023 10:45:53 +0100    
  
committer: Peter Eisentraut <[email protected]>    
date     : Tue, 14 Nov 2023 10:45:53 +0100    

commit   : f1674ac6b05b39c979f245947ad98fe306a2d4a0    
  
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    

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

commit   : 64d2467fc8d34b2a0c84d1c1aadb349a0df4b618    
  
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    

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]  

commit   : f5b75be030d588a119a19eca336527b7cfa77ec9    
  
author   : Bruce Momjian <[email protected]>    
date     : Mon, 13 Nov 2023 16:35:55 -0500    
  
committer: Bruce Momjian <[email protected]>    
date     : Mon, 13 Nov 2023 16:35:55 -0500    

Reported-by: Ngigi Waithaka & Alex Malek  
  
Bug: 15172  
  
Discussion: https://postgr.es/m/[email protected]  
  
Backpatch-through: 16  

commit   : 17d490ef32cc217a54323819bb78d6d2813a2c35    
  
author   : Bruce Momjian <[email protected]>    
date     : Mon, 13 Nov 2023 16:08:01 -0500    
  
committer: Bruce Momjian <[email protected]>    
date     : Mon, 13 Nov 2023 16:08:01 -0500    

Clarify handling of infinite range bounds.  
  
Reported-by: [email protected]  
  
Discussion: https://postgr.es/m/[email protected]  
  
Co-authored-by: Laurenz Albe  
  
Backpatch-through: 16  

commit   : e72821ca086a1caa9a22a2c131b7527753a1ab93    
  
author   : Bruce Momjian <[email protected]>    
date     : Mon, 13 Nov 2023 14:27:38 -0500    
  
committer: Bruce Momjian <[email protected]>    
date     : Mon, 13 Nov 2023 14:27:38 -0500    

Clarify that default privileges are not inherited and reorder  
paragraphs.  This is a follow up to a recent ALTER DEFAULT PRIVILEGES  
doc patch.  
  
Reported-by: Sanjay Minni  
  
Diagnosed-by: AMpxBo=M35hcH1g4Vg=KRJ0-77FOJcvdrdiVF5KSOAdOG-LvKQ@mail.gmail.com  
  
Co-authored-by: Laurenz Albe  
  
Backpatch-through: 16  

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

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

commit   : f76b975d5887e7e668862e7068eb09073ec23c63    
  
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    

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  

commit   : a3e92622f1cf4f9cd2a8505ee0b5a633ac9dce32    
  
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    

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  

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

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  

commit   : 6bf2efb38285626a9de3004dd1c23d9a85453372    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 9 Nov 2023 15:46:16 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 9 Nov 2023 15:46:16 -0500    

We can simplify FieldSelect on a whole-row Var into a plain Var  
for the selected field.  However, we should copy the whole-row Var's  
varnullingrels when we do so, because the new Var is clearly nullable  
by exactly the same rels as the original.  Failure to do this led to  
errors like "wrong varnullingrels (b) (expected (b 3)) for Var 2/2".  
  
Richard Guo, per bug #18184 from Marian Krucina.  Back-patch to  
v16 where varnullingrels was introduced.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 06a546382aafe0cc9d895b2861c5b8a8e9f0b002    
  
author   : Dean Rasheed <[email protected]>    
date     : Thu, 9 Nov 2023 11:27:04 +0000    
  
committer: Dean Rasheed <[email protected]>    
date     : Thu, 9 Nov 2023 11:27:04 +0000    

When executing a MERGE UPDATE action, if the UPDATE is turned into a  
cross-partition DELETE then INSERT, do not attempt to invoke AFTER  
UPDATE ROW triggers, or any of the other post-update actions in  
ExecUpdateEpilogue().  
  
For consistency with a plain UPDATE command, such triggers should not  
be fired (and typically fail anyway), and similarly, other post-update  
actions, such as WCO/RLS checks should not be executed, and might also  
lead to unexpected failures.  
  
Therefore, as with ExecUpdate(), make ExecMergeMatched() return  
immediately if ExecUpdateAct() reports that a cross-partition update  
was done, to be sure that no further processing is done for that  
tuple.  
  
Back-patch to v15, where MERGE was introduced.  
  
Discussion: https://postgr.es/m/CAEZATCWjBgagyNZs02vgDF0DvASYj-iHTFtXG2-nP3orZhmtcw%40mail.gmail.com  

commit   : ef7c36555179e5b80054eb9e9e303c7ae53eb7a1    
  
author   : David Rowley <[email protected]>    
date     : Fri, 10 Nov 2023 00:16:41 +1300    
  
committer: David Rowley <[email protected]>    
date     : Fri, 10 Nov 2023 00:16:41 +1300    

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  

commit   : c396aca2b712f7872dcc4641a2a0fa553f232f76    
  
author   : Dean Rasheed <[email protected]>    
date     : Thu, 9 Nov 2023 09:53:05 +0000    
  
committer: Dean Rasheed <[email protected]>    
date     : Thu, 9 Nov 2023 09:53:05 +0000    

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  

commit   : 179c4639cf1dcbe54f3469d7f44a11f172332893    
  
author   : Michael Paquier <[email protected]>    
date     : Thu, 9 Nov 2023 10:05:07 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Thu, 9 Nov 2023 10:05:07 +0900    

This looks like a copy-paste mistake introduced in de2aca288569, that  
has added checks for more patterns of SET statements while ignoring the  
original test block that existed.  
  
Backpatch down to where this has been introduced, as this shaves some  
cycles.  
  
Author: Sergei Kornilov  
Discussion: https://postgr.es/m/5689421699428803@mail-sendbernar-production-main-46.myt.yp-c.yandex.net  
Backpatch-through: 16  

commit   : 42f8326851fd7b4fe1fcf9808785001c8da8173c    
  
author   : Alvaro Herrera <[email protected]>    
date     : Wed, 8 Nov 2023 16:44:08 +0100    
  
committer: Alvaro Herrera <[email protected]>    
date     : Wed, 8 Nov 2023 16:44:08 +0100    

When PQsendFlushRequest() was added by commit 69cf1d5429d4, we argued  
against adding a PQflush() call in it[1].  This is still the right  
decision: if the user wants a flush to occur, they can just call that.  
However, we failed to realize that the message bytes could still be  
given to the kernel for transmitting when this can be made without  
blocking.  That's what pqPipelineFlush() does, and it is done for every  
single other message type sent by libpq, so do that.  
  
(When the socket is in blocking mode this may indeed block, but that's  
what all the other libpq message-sending routines do, too.)  
  
[1] https://www.postgresql.org/message-id/202106252352.5ca4byasfun5%40alvherre.pgsql  
  
Author: Jelte Fennema-Nio <[email protected]>  
Discussion: https://postgr.es/m/CAGECzQTxZRevRWkKodE-SnJk1Yfm4eKT+8E4Cyq3MJ9YKTnNew@mail.gmail.com  

commit   : b7caeaff31ea1d0d0899241f30452353b78e840a    
  
author   : Peter Eisentraut <[email protected]>    
date     : Wed, 8 Nov 2023 11:27:28 +0100    
  
committer: Peter Eisentraut <[email protected]>    
date     : Wed, 8 Nov 2023 11:27:28 +0100    

It should be handled as a test module per commit b6a0d469ca.  

commit   : 2a08dda29128472879cf4f70bc06806595505def    
  
author   : Michael Paquier <[email protected]>    
date     : Wed, 8 Nov 2023 17:29:22 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Wed, 8 Nov 2023 17:29:22 +0900    

`openssl` is an optional dependency in the meson build as it may not be  
installed in an environment even if SSL libraries are around.  The meson  
scripts assume that, but the SSL tests thought that it was a hard  
dependency, causing a meson installation to fail if `openssl` could not  
be found.  Like similar tests that depend on external commands, and to  
be consistent with ./configure for the SSL tests, this commit makes the  
command existence optional in the tests.  
  
Author: Tristan Partin  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 16  

commit   : 4dccf9575369410f0c853e6f1b0b0579c8ec1c05    
  
author   : Michael Paquier <[email protected]>    
date     : Wed, 8 Nov 2023 14:06:36 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Wed, 8 Nov 2023 14:06:36 +0900    

false_positive_rate is a parameter that can be set with the bloom  
opclass in BRIN, and setting it to a value of exactly 0.25 would trigger  
an assertion in the first INSERT done on the index with value set.  
  
The assertion changed here relied on BLOOM_{MIN|MAX}_FALSE_POSITIVE_RATE  
that are somewhat arbitrary values, and specifying an out-of-range value  
would also trigger a failure when defining such an index.  So, as-is,  
the assertion was just doubling on the min-max check of the reloption.  
This is now enlarged to check that it is a correct percentage value,  
instead, based on a suggestion by Tom Lane.  
  
Author: Alexander Lakhin  
Reviewed-by: Tom Lane, Shihao Zhong  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 14