PostgreSQL 14.12 commit log

commit   : cf07a47dc0c3b16778291e62d730537b45da51ef    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 6 May 2024 16:24:45 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 6 May 2024 16:24:45 -0400    

commit   : b7712704f0bb3dc82f286516a7057b0fa5b1d260    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 6 May 2024 12:27:27 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 6 May 2024 12:27:27 -0400    

Security: CVE-2024-4317  

commit   : c3425383ba67ae6ecaddc8896025a91faadb430a    
  
author   : Nathan Bossart <[email protected]>    
date     : Mon, 6 May 2024 09:00:19 -0500    
  
committer: Nathan Bossart <[email protected]>    
date     : Mon, 6 May 2024 09:00:19 -0500    

The catalog view pg_stats_ext fails to consider privileges for  
expression statistics.  The catalog view pg_stats_ext_exprs fails  
to consider privileges and row-level security policies.  To fix,  
restrict the data in these views to table owners or roles that  
inherit privileges of the table owner.  It may be possible to apply  
less restrictive privilege checks in some cases, but that is left  
as a future exercise.  Furthermore, for pg_stats_ext_exprs, do not  
return data for tables with row-level security enabled, as is  
already done for pg_stats_ext.  
  
On the back-branches, a fix-CVE-2024-4317.sql script is provided  
that will install into the "share" directory.  This file can be  
used to apply the fix to existing clusters.  
  
Bumps catversion on 'master' branch only.  
  
Reported-by: Lukas Fittl  
Reviewed-by: Noah Misch, Tomas Vondra, Tom Lane  
Security: CVE-2024-4317  
Backpatch-through: 14  

commit   : 0288acb0c61f6b0d68d3a625c92bcc54a655442e    
  
author   : Peter Eisentraut <[email protected]>    
date     : Mon, 6 May 2024 12:12:28 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Mon, 6 May 2024 12:12:28 +0200    

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

commit   : 6cb4d1d486220c8e194009466ea5a25108afb19c    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 5 May 2024 13:31:09 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 5 May 2024 13:31:09 -0400    

commit   : 9a8b3525e8a9f031ac235b06c7583b20590f43ea    
  
author   : Peter Eisentraut <[email protected]>    
date     : Thu, 2 May 2024 08:21:18 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Thu, 2 May 2024 08:21:18 +0200    

The documentation said that you need to pick a suitable LC_COLLATE  
setting in addition to setting the DETERMINISTIC flag.  This would  
have been correct if the libc provider supported nondeterministic  
collations, but since it doesn't, you actually need to set the LOCALE  
option.  
  
Reviewed-by: Kashif Zeeshan <[email protected]>  
Discussion: https://www.postgresql.org/message-id/flat/a71023c2-0ae0-45ad-9688-cf3b93d0d65b%40eisentraut.org  

commit   : e6b0efc65e5885a0e46050df341c88f4a5ee76cd    
  
author   : David Rowley <[email protected]>    
date     : Wed, 1 May 2024 13:22:41 +1200    
  
committer: David Rowley <[email protected]>    
date     : Wed, 1 May 2024 13:22:41 +1200    

As an optimization, we store "name" columns as cstrings in btree  
indexes.  
  
Here we modify it so that Index Only Scans convert these cstrings back  
to names with NAMEDATALEN bytes rather than storing the cstring in the  
tuple slot, as was happening previously.  
  
Bug: #17855  
Reported-by: Alexander Lakhin  
Reviewed-by: Alexander Lakhin, Tom Lane  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 12, all supported versions  

commit   : 51189f98a9fc88a63ae6a9635da8adb427f9958c    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 30 Apr 2024 15:22:55 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 30 Apr 2024 15:22:55 -0400    

We have long disallowed all forms of ALTER TABLE if the table is  
already opened by some outer SQL command in the same session.  
This has the same purpose as obtaining AccessExclusiveLock, but  
since a session's own locks don't conflict the lock only blocks use  
of the table by other sessions, not our own.  Without this check,  
the ALTER might confuse the outer SQL command since any previous  
inspection of the table would potentially become invalid.  
  
However, the RelisBecomingView code path in DefineQueryRewrite never  
got that memo, and assumed that AccessExclusiveLock is sufficient  
for performing something morally equivalent to a rather invasive  
ALTER TABLE.  Unsurprisingly, this can confuse an outer command  
that is trying to do something with the table.  
  
This was submitted as a security issue, but the security team  
has been unable to identify any consequence worse than a null  
pointer dereference (from trying to access rd_tableam methods  
that the relation no longer has).  Therefore, in accordance  
with our usual policy, it's not security material and should  
just be fixed as a routine bug.  
  
Fix by disallowing the operation if the table is open locally,  
exactly as ALTER TABLE does it.  
  
Per an anonymous security researcher, via Bundesamt für Sicherheit  
in der Informationstechnik.  
  
Patch v12-v15 only.  In v16 and later, we removed this code  
altogether (cf. commit b23cd185f), so that there's no issue.  

commit   : 2ca19aa8165c6bec84c1d527fc5f3100c2161b1a    
  
author   : Noah Misch <[email protected]>    
date     : Mon, 29 Apr 2024 10:24:56 -0700    
  
committer: Noah Misch <[email protected]>    
date     : Mon, 29 Apr 2024 10:24:56 -0700    

vac_update_datfrozenxid() did multiple loads of relfrozenxid and  
relminmxid from buffer memory, and it assumed each would get the same  
value.  Not so if a concurrent vac_update_relstats() did an inplace  
update.  Commit 2d2e40e3befd8b9e0d2757554537345b15fa6ea2 fixed the same  
kind of bug in vac_truncate_clog().  Today's bug could cause the  
rel-level field and XIDs in the rel's rows to precede the db-level  
field.  A cluster having such values should VACUUM affected tables.  
Back-patch to v12 (all supported versions).  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 617a23927249c78f23ef005aaa78b508570f4cc8    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 28 Apr 2024 14:34:21 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 28 Apr 2024 14:34:21 -0400    

ALTER COLUMN TYPE wasn't expecting to find any pg_proc objects  
depending on the column whose type is to be altered.  That indeed  
wasn't possible when this code was written, but it is possible  
since we introduced new-style SQL function bodies.  
  
It's about as difficult to fix this case as it is to fix dependent  
views, and we've been punting on those for years, so I don't feel  
too awful about punting for functions too.  (I sure wouldn't risk  
back-patching such code.)  So just throw a more user-facing error.  
Also, adjust some of the existing comments to reflect that these  
are all pretty much the same issue.  
  
(This patch also fixes it so we will tolerate finding such a  
dependency during ALTER COLUMN SET EXPRESSION; in that, we need  
not do anything to the function, so no error is wanted.  That  
problem is new in HEAD.)  
  
Per bug #18449 from Alexander Lakhin.  Back-patch to v14 where  
we added new-style SQL functions.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 1748379b636152b6633498c6488fd98aa015bc99    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 28 Apr 2024 13:42:13 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 28 Apr 2024 13:42:13 -0400    

In commit 25cd2d640 I (tgl) opined that "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".  This is demonstrably wrong however  
for the microseconds field, and given that discovery it seems prudent  
to be paranoid about the months addition as well.  
  
Report and patch by Joseph Koshakow.  As before, back-patch to all  
supported branches.  (However, the test case doesn't work before  
v15 because we didn't allow wider-than-int32 numbers in interval  
literals.  A variant test could probably be built that fits within  
that restriction, but it didn't seem worth the trouble.)  
  
Discussion: https://postgr.es/m/CAAvxfHf77sRHKoEzUw9_cMYSpbpNS2C+J_+8Dq4+0oi8iKopeA@mail.gmail.com  

commit   : 6189a0d3795e10b32753eb7ae3d155429b8fd4cd    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 24 Apr 2024 10:18:16 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 24 Apr 2024 10:18:16 -0400    

Since schemas have more than one kind of privilege, we should  
use the synopsis form that shows the privilege being possibly  
repeated.  
  
Yugo Nagata  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 630ed7ec4d3633130d3e8466e78d8d205dbd64a7    
  
author   : Peter Eisentraut <[email protected]>    
date     : Wed, 24 Apr 2024 11:31:47 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Wed, 24 Apr 2024 11:31:47 +0200    

The paragraph describing the JavaScript string literals allowed in  
jsonpath expressions unnecessarily mentions JSON by erroneously  
listing \v as allowed by JSON and mentioning the \xNN and \u{N...}  
backslash escapes as deviations from JSON when in fact both are  
accepted by ECMAScript/JavaScript.  Fix this by only referring to  
JavaScript.  
  
Author: Erik Wienhold <[email protected]>  
Discussion: https://www.postgresql.org/message-id/flat/[email protected]  

commit   : 3ed6e1698521211f1d4fc199e490c3b5944785d4    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 21 Apr 2024 13:46:20 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 21 Apr 2024 13:46:20 -0400    

This should have the same results for all practical purposes.  
The advantage of selecting 'GMT' is that it's guaranteed to work  
even when the remote system's timezone database is missing  
entries, because pg_tzset() hard-wires handling of that,  
at least in 9.2 and later.  
  
(It seems like it would be a good idea to similarly hard-wire  
correct handling of 'UTC', but that'll be a little more invasive  
than I want to consider back-patching.  Leave that for another  
day when we're not in feature freeze.)  
  
Per trouble report from Adnan Dautovic.  Back-patch to all  
supported branches.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : c6e229d5f76ff4ecf36c24aae6a824c40b019706    
  
author   : David Rowley <[email protected]>    
date     : Sat, 20 Apr 2024 13:55:07 +1200    
  
committer: David Rowley <[email protected]>    
date     : Sat, 20 Apr 2024 13:55:07 +1200    

The documents were clear that queryid should not be assumed to be stable  
between major versions but said nothing about minor versions and left  
the reader to guess if that was implied by the mention of the  
instability of queryid between major versions.  
  
Here we give minor versions an explicit mention to indicate queryid can  
generally be assumed stable between minor versions.  
  
Reviewed-by: Michael Paquier  
Discussion: https://postgr.es/m/CAApHDvpYGE6h0cD9UO-eHySPynPj1L3J%3DHxT%2BA7Ud8_Yo6AuzA%40mail.gmail.com  
Backpatch-through: 12  

commit   : 41c0c493ad70f2939a461c135b3a54b2a21be64a    
  
author   : Daniel Gustafsson <[email protected]>    
date     : Fri, 19 Apr 2024 14:50:10 +0200    
  
committer: Daniel Gustafsson <[email protected]>    
date     : Fri, 19 Apr 2024 14:50:10 +0200    

These operators were removed by 2f70fdb0644c in the v14 cycle but they were  
accidentally left in the table of build-in operator classes. Backpatch down  
to v14 where the operators where removed.  
  
Author: Aleksander Alekseev <[email protected]>  
Reported-by: Colin Caine <[email protected]>  
Discussion: https://postgr.es/m/CADwQTQbbr2UQ_fpbyc+8ay=RwEYgYk=TZxH3+RHDqAQfoG+EWA@mail.gmail.com  
Backpatch-through: v14  

commit   : de84608e263920a77f2c1b2a86c90642c8e35fe9    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 19 Apr 2024 01:07:16 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 19 Apr 2024 01:07:16 -0400    

Forgot to inject -DCMDLINESYM=123 ...  
  
Per buildfarm.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : df66319f776d01a83b1fb1aab8b74578f9c64421    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 18 Apr 2024 20:47:37 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 18 Apr 2024 20:47:37 -0400    

While back-patching commit 6f0cef935, I forgot that the MSVC  
build scripts would also need adjustment in the back branches.  
This is a blind attempt at a fix, but it's basically copying  
nearby code so I think it will work.  
  
Per buildfarm (via Andrew Dunstan)  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 4631646391ec105c54ee3ed27211ae85d2f2a3d6    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 16 Apr 2024 12:31:32 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 16 Apr 2024 12:31:32 -0400    

The code associated with EXEC SQL DEFINE was unreadable and full of  
bugs, notably:  
  
* It'd attempt to free a non-malloced string if the ecpg program  
tries to redefine a macro that was defined on the command line.  
  
* Possible memory stomp if user writes "-D=foo".  
  
* Undef'ing or redefining a macro defined on the command line would  
change the state visible to the next file, when multiple files are  
specified on the command line.  (While possibly that could have been  
an intentional choice, the code clearly intends to revert to the  
original macro state; it's just failing to consider this interaction.)  
  
* Missing "break" in defining a new macro meant that redefinition  
of an existing name would cause an extra entry to be added to the  
definition list.  While not immediately harmful, a subsequent undef  
would result in the prior entry becoming visible again.  
  
* The interactions with input buffering are subtle and were entirely  
undocumented.  
  
It's not that surprising that we hadn't noticed these bugs,  
because there was no test coverage at all of either the -D  
command line switch or multiple input files.  This patch adds  
such coverage (in a rather hacky way I guess).  
  
In addition to the code bugs, the user documentation was confused  
about whether the -D switch defines a C macro or an ecpg one, and  
it failed to mention that you can write "-Dsymbol=value".  
  
These problems are old, so back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : ab2402268c04401533f163d959cdccd0e124f526    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 16 Apr 2024 11:22:39 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 16 Apr 2024 11:22:39 -0400    

get_baserel_parampathinfo previously assumed without checking that  
the results of generate_join_implied_equalities "necessarily satisfy  
join_clause_is_movable_into".  This turns out to be wrong in the  
presence of outer joins, because the generated clauses could include  
Vars that mustn't be evaluated below a relevant outer join.  That  
led to applying clauses at the wrong plan level and possibly getting  
incorrect query results.  We must check each clause's nullable_relids,  
and really the right thing to do is test join_clause_is_movable_into.  
  
However, trying to fix it that way exposes an oversight in  
equivclass.c: it wasn't careful about marking join clauses for  
appendrel children with the correct clause_relids.  That caused the  
modified get_baserel_parampathinfo code to reject some clauses it  
still needs to accept.  (See parallel commit for HEAD/v16 for more  
commentary about that.)  
  
Per bug #18429 from Benoît Ryder.  This misbehavior existed for  
a long time before commit 2489d76c4, so patch v12-v15 this way.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 6fa5e67e832bbab80ea7b936701e2c03c22fe059    
  
author   : Michael Paquier <[email protected]>    
date     : Tue, 16 Apr 2024 12:26:15 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Tue, 16 Apr 2024 12:26:15 +0900    

Some functions are used in the tree and are currently marked as  
deprecated by upstream.  This commit refreshes the code to use the  
recommended functions, leading to the following changes:  
- xmlSubstituteEntitiesDefault() is gone, and needs to be replaced with  
XML_PARSE_NOENT for the paths doing the parsing.  
- xmlParseMemory() -> xmlReadMemory().  
  
These functions, as well as more functions setting global states, have  
been officially marked as deprecated by upstream in August 2022.  Their  
replacements exist since the 2001-ish area, as far as I have checked,  
so that should be safe.  
  
This has been originally applied as 65c5864d7fac without a backpatch,  
and this has come up as well when working on 400928b83.  Per request  
from Tom Lane, for new buildfarm member indri that is able to see  
deprecation warnings with xmlSubstituteEntitiesDefault() in 16 and older  
stable branches.  
  
Author: Dmitry Koval  
Discussion: https://postgr.es/m/[email protected]  
Discussion: https://postgr.es/m/[email protected]  
Bakpatch-through: 12  

commit   : 78e81e14db797713b26ee6fccb371128afa66b4e    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 15 Apr 2024 12:56:56 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 15 Apr 2024 12:56:56 -0400    

Commit 2ed8f9a01 intended to institute a policy that if a  
RangeTblFunction has a coldeflist, then the function return type is  
certainly RECORD, and we should use the coldeflist as the source of  
truth about what the columns of the record type are.  When the  
original function has been folded to a constant, inspection of the  
constant might give a different answer.  This situation will lead to  
a tuple-type-mismatch error at execution, but up until that point we  
need to consistently believe the coldeflist, or we'll have problems  
from different bits of code reaching different conclusions.  
  
expandRTE didn't get that memo though, and would try to produce a  
tupdesc based on the constant in this situation, leading to an  
assertion failure.  (Desultory testing suggests that non-assert  
builds often manage to give the expected error, although I also  
saw a "cache lookup failed for type 0" error, and it seems at  
least possible that a crash could happen.)  
  
Some other callers of get_expr_result_type and get_expr_result_tupdesc  
were also being incautious about this.  While none of them seem to  
have actual bugs, they're working harder than necessary in this case,  
besides which it seems safest to have an explicit policy of not using  
those functions on an RTE with a coldeflist.  Adjust the code  
accordingly, and add commentary to funcapi.c about this policy.  
  
Also fix an obsolete comment that claimed "get_expr_result_type()  
doesn't know how to extract type info from a RECORD constant".  
That hasn't been true since commit d57534740.  
  
Per bug #18422 from Alexander Lakhin.  
As with the previous commit, back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : ad23af83dad3d341c8ac5b699518fb64eaff88db    
  
author   : Tomas Vondra <[email protected]>    
date     : Sun, 14 Apr 2024 17:58:59 +0200    
  
committer: Tomas Vondra <[email protected]>    
date     : Sun, 14 Apr 2024 17:58:59 +0200    

Properly update the number of bits set in the bitmap after merging the  
filters in brin_bloom_union.  
  
This is mostly harmless, as the counter is used only in the output  
function, which means pageinspect may show incorrect information about  
the BRIN summary. The counter does not affect correctness.  
  
Discovered while adding a regression test comparing indexes built with  
and without parallelism. The parallel index builds exercise the union  
procedure when merging results from workers, which is otherwise very  
hard to do in a test. Which is why this went unnoticed until now.  
  
Backpatch through 14, where the BRIN bloom opclasses were introduced.  
  
Backpatch-through: 14  
Discussion: https://postgr.es/m/1df00a66-db5a-4e66-809a-99b386a06d86%40enterprisedb.com  

commit   : 08059fc049ff5461d2a8f18c7a3e84150d74529c    
  
author   : Noah Misch <[email protected]>    
date     : Sat, 13 Apr 2024 08:34:20 -0700    
  
committer: Noah Misch <[email protected]>    
date     : Sat, 13 Apr 2024 08:34:20 -0700    

GetPageWithFreeSpace() callers assume the returned block exists in the  
main fork, failing with "could not read block" errors if that doesn't  
hold.  Make that assumption reliable now.  It hadn't been guaranteed,  
due to the weak WAL and data ordering of participating components.  Most  
operations on the fsm fork are not WAL-logged.  Relation extension is  
not WAL-logged.  Hence, an fsm-fork block on disk can reference a  
main-fork block that no WAL record has initialized.  That could happen  
after an OS crash, a replica promote, or a PITR restore.  wal_log_hints  
makes the trouble easier to hit; a replica promote or PITR ending just  
after a relevant fsm-fork FPI_FOR_HINT may yield this broken state.  The  
v16 RelationAddBlocks() mechanism also makes the trouble easier to hit,  
since it bulk-extends even without extension lock waiters.  Commit  
917dc7d2393ce680dea7a59418be9ff341df3c14 stopped trouble around  
truncation, but vectors involving PageIsNew() pages remained.  
  
This implementation adds a RelationGetNumberOfBlocks() call when the  
cached relation size doesn't confirm a block exists.  We've been unable  
to identify a benchmark that slows materially, but this may show up as  
additional time in lseek().  An alternative without that overhead would  
be a new ReadBufferMode such that ReadBufferExtended() returns NULL  
after a 0-byte read, with all other errors handled normally.  However,  
each GetFreeIndexPage() caller would then need code for the return-NULL  
case.  Back-patch to v14, due to earlier versions not caching relation  
size and the absence of a pre-v16 problem report.  
  
Ronan Dunklau.  Reported by Ronan Dunklau.  
  
Discussion: https://postgr.es/m/1878547.tdWV9SEqCh%40aivenlaptop  

commit   : da11a14e0c79af98869ce8929fa9bdfe7cc690cb    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 11 Apr 2024 11:09:00 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 11 Apr 2024 11:09:00 -0400    

November doesn't have 31 days.  Remarkably, this thinko  
has escaped detection since commit 3f1998727.  
  
Noted by Y. Saburov.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : b714bc40cf066dde745fcb78fde160788730a7be    
  
author   : Etsuro Fujita <[email protected]>    
date     : Thu, 11 Apr 2024 19:05:04 +0900    
  
committer: Etsuro Fujita <[email protected]>    
date     : Thu, 11 Apr 2024 19:05:04 +0900    

This function would have the same issue we solved in commit 501cfd07d:  
If an error is thrown after calling CreateWaitEventSet(), the file  
descriptor (on epoll- or kqueue-based systems) or handles (on Windows)  
that the WaitEventSet contains are leaked.  
  
Like that commit, use PG_TRY-PG_FINALLY (PG_TRY-PG_CATCH in v12) to make  
sure the WaitEventSet is freed properly.  
  
Back-patch to all supported versions, but as we do not have this issue  
in HEAD (cf. commit 50c67c201), no need to apply this patch to it.  
  
Discussion: https://postgr.es/m/CAPmGK16MqdDoD8oatp8SQWaEa4vS3nfQqDN_Sj9YRuu5J3Lj9g%40mail.gmail.com  

commit   : dc5824a06e979e1f4412849d63d166ca16d1f84d    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 10 Apr 2024 15:45:59 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 10 Apr 2024 15:45:59 -0400    

Up to now, read_sql_construct() has collected all the source text from  
the statement or expression's initial token up to the character just  
before the "until" token.  It normally tries to strip trailing  
whitespace from that, largely for neatness.  If there was a "-- text"  
comment after the expression, this resulted in removing the newline  
that terminates the comment, which creates a hazard if we try to paste  
the collected text into a larger SQL construct without inserting a  
newline after it.  In particular this caused our handling of CASE  
constructs to fail if there's a comment after a WHEN expression.  
  
Commit 4adead1d2 noticed a similar problem with cursor arguments,  
and worked around it through the rather crude hack of suppressing  
the whitespace-trimming behavior for those.  Rather than do that  
and leave the hazard open for future hackers to trip over, let's  
fix it properly.  pl_scanner.c already has enough infrastructure  
to report the end location of the expression's last token, so  
we can copy up to that location and never collect any trailing  
whitespace or comment to begin with.  
  
Erik Wienhold and Tom Lane, per report from Michal Bartak.  
Back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/CAAVzF_FjRoi8fOVuLCZhQJx6HATQ7MKm=aFOHWZODFnLmjX-xA@mail.gmail.com  

commit   : 2e56ad6a319e02f35444bec391cb777498796851    
  
author   : Daniel Gustafsson <[email protected]>    
date     : Wed, 10 Apr 2024 13:53:25 +0200    
  
committer: Daniel Gustafsson <[email protected]>    
date     : Wed, 10 Apr 2024 13:53:25 +0200    

The tools.ietf.org site has been decommissioned and replaced by a  
number of sites serving various purposes.  Links to RFCs and BCPs  
are now 301 redirected to their new respective IETF sites.  Since  
this serves no purpose and only adds network overhead, update our  
links to the new locations.  
  
Backpatch to all supported versions.  
  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: v12  

commit   : 7fe32eaa4a878500280ed7d33ce711c06b6939ff    
  
author   : Thomas Munro <[email protected]>    
date     : Wed, 10 Apr 2024 10:46:15 +1200    
  
committer: Thomas Munro <[email protected]>    
date     : Wed, 10 Apr 2024 10:46:15 +1200    

Commit 72559438 started copying more attributes from AttributeTemplate  
to the functions we generate on the fly.  In the case of deform  
functions, which return void, this meant that "noundef", from  
AttributeTemplate's return value (a Datum) was copied to a void type.  
Older LLVM releases were OK with that, but LLVM 18 crashes.  
  
Update our llvm_copy_attributes() function to skip copying the attribute  
for the return value, if the target function returns void.  
  
Thanks to Dmitry Dolgov for help chasing this down.  
  
Back-patch to all supported releases, like 72559438.  
  
Reported-by: Pavel Stehule <[email protected]>  
Reviewed-by: Dmitry Dolgov <[email protected]>  
Discussion: https://postgr.es/m/CAFj8pRACpVFr7LMdVYENUkScG5FCYMZDDdSGNU-tch%2Bw98OxYg%40mail.gmail.com  

commit   : 1435cc87d3a793a239d63bf7b20d35faba05f28f    
  
author   : Daniel Gustafsson <[email protected]>    
date     : Tue, 9 Apr 2024 23:39:38 +0200    
  
committer: Daniel Gustafsson <[email protected]>    
date     : Tue, 9 Apr 2024 23:39:38 +0200    

Back in 7.2 the list of options had short options and long options  
on the same line separated by comma, but since 7.3 they are listed  
separate lines. The comma on -X was left behind so fix by removing  
and backpatching all the way.  
  
Reported-by: [email protected]  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: v12  

commit   : 25ee58e8f26df9ce3037258206eb100a3fc55103    
  
author   : Andres Freund <[email protected]>    
date     : Sun, 7 Apr 2024 19:00:11 -0700    
  
committer: Andres Freund <[email protected]>    
date     : Sun, 7 Apr 2024 19:00:11 -0700    

While SH_STAT() is only used for debugging, the allocated array can be large,  
and therefore should be freed.  
  
It's unclear why coverity started warning now.  
  
Reported-by: Tom Lane <[email protected]>  
Reported-by: Coverity  
Discussion: https://postgr.es/m/[email protected]  
Backpatch: 12-  

commit   : 7a0541301078bdd0fb548141c43b335fbabcaf81    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 7 Apr 2024 15:36:08 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 7 Apr 2024 15:36:08 -0400    

What the documentation calls an exclude_element is an index_elem  
according to gram.y, and it allows all the same options that  
a CREATE INDEX column specification does.  The COLLATE patch  
neglected to update the CREATE/ALTER TABLE docs about that,  
and later the opclass-parameters patch made the same oversight.  
Add those options to the syntax synopses, and polish the  
associated text a bit.  
  
Back-patch to v13 where opclass parameters came in.  We could  
update v12 with just the COLLATE omission, but it doesn't quite  
seem worth the trouble at this point.  
  
Shihao Zhong, reviewed by Daniel Vérité, Shubham Khanna and myself  
  
Discussion: https://postgr.es/m/CAGRkXqShbVyB8E3gapfdtuwiWTiK=Q67Qb9qwxu=+-w0w46EBA@mail.gmail.com  

commit   : 3d5a9bb8df65ac6446ae5ad769c0adc5f332c164    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Sun, 7 Apr 2024 20:21:27 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Sun, 7 Apr 2024 20:21:27 +0300    

If the test script die()d before running the first test, the whole test  
was interpreted as SKIPped rather than failed. The PostgreSQL::Cluster  
module got this right.  
  
Backpatch to all supported versions.  
  
Discussion: https://www.postgresql.org/message-id/[email protected]  

commit   : 1843a27efb56eee2f679a246c47bd56ad891592c    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Sun, 7 Apr 2024 20:21:21 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Sun, 7 Apr 2024 20:21:21 +0300    

If the OpenLDAP installation directory is not found, set $setup to 0  
so that the LDAP tests are skipped. The macOS checks were already  
doing that, but the checks on other OS's were not. While we're at it,  
improve the error message when the tests are skipped, to specify  
whether the OS is supported at all, or if we just didn't find the  
installation directory.  
  
This was accidentally "working" without this, i.e. we were skipping  
the tests if the OpenLDAP installation was not found, because of a bug  
in the LdapServer test module: the END block clobbered the exit code  
so if the script die()s before running the first subtest, the whole  
test script was marked as SKIPped. The next commit will fix that bug,  
but we need to fix the setup code first.  
  
These checks should probably go into configure/meson, but this is  
better than nothing and allows fixing the bug in the END block.  
  
Backpatch to all supported versions.  
  
Discussion: https://www.postgresql.org/message-id/[email protected]  

commit   : d3167ed3f7cde873f356673ce9b742f4177924a4    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 4 Apr 2024 15:31:53 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 4 Apr 2024 15:31:53 -0400    

ecpg wants to emit a warning if it parses a SQL construct that the  
backend can parse but will immediately throw a FEATURE_NOT_SUPPORTED  
error for.  The way it was testing for this was to see if the string  
ERRCODE_FEATURE_NOT_SUPPORTED appeared anywhere in the gram.y code.  
This is, of course, not nearly good enough, as there are plenty of  
rules in gram.y that throw that error only conditionally.  There was  
a hack dating to 2008 to suppress the warning in one rule that  
doesn't even exist anymore, but nothing for other cases we've created  
since then.  End result was that you could get "unsupported feature  
will be passed to server" warnings while compiling perfectly good SQL  
code in ecpg.  Somehow we'd not heard complaints about this, but  
it was exposed by the recent addition of an ecpg test for a SQL/JSON  
construct.  
  
To fix, suppress the warning if the rule contains any "if" statement.  
Manual comparison of gram.y with the generated preproc.y file shows  
that the warning is now emitted only in rules where it's sensible.  
  
This problem has existed for a long time, so back-patch to all  
supported branches.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : e10ca95ff7db67325ef8d4463465539e7527bf19    
  
author   : Etsuro Fujita <[email protected]>    
date     : Thu, 4 Apr 2024 17:25:04 +0900    
  
committer: Etsuro Fujita <[email protected]>    
date     : Thu, 4 Apr 2024 17:25:04 +0900    

No configured-by-FDW events would result in "return" directly out of a  
PG_TRY block, making the exception stack dangling.  Repair.  
  
Oversight in commit 501cfd07d; back-patch to v14, like that commit, but  
as we do not have this issue in HEAD (cf. commit 50c67c201), no need to  
apply this patch to it.  
  
In passing, improve a comment about the handling of in-process requests  
in a postgres_fdw.c function called from this function.  
  
Alexander Pyhalov, with comment adjustment/improvement by me.  
  
Discussion: https://postgr.es/m/425fa29a429b21b0332737c42a4fdc70%40postgrespro.ru  

commit   : 19b8481b42efd29ac265e0d14566a7609b8d474b    
  
author   : Alexander Korotkov <[email protected]>    
date     : Wed, 3 Apr 2024 21:29:18 +0300    
  
committer: Alexander Korotkov <[email protected]>    
date     : Wed, 3 Apr 2024 21:29:18 +0300    

Specify OldTable first, NewTable second as used by  
table_relation_copy_for_cluster() and as implemented in  
heapam_relation_copy_for_cluster().  
  
Backpatch to PostgreSQL 12, where TableAmRoutine was introduced.  
  
Discussion: https://postgr.es/m/ME3P282MB3166860D4911AE82F92DF7C5B63F2%40ME3P282MB3166.AUSP282.PROD.OUTLOOK.COM  
Author: Japin Li  
Reviewed-by: Pavel Borisov  
Backpatch-through: 12  

commit   : ca392df8dd183f93575dd21f1b76390656ca9550    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 2 Apr 2024 14:59:04 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 2 Apr 2024 14:59:04 -0400    

If temp tables have dependencies (such as sequences) then it's  
possible for autovacuum's cleanup of orphan temp tables to deadlock  
against an incoming backend that's trying to clean out the temp  
namespace for its own use.  That can happen because RemoveTempRelations'  
performDeletion call can visit objects within the namespace in  
an order different from the order in which a per-table deletion  
will visit them.  
  
To fix, observe that performDeletion will begin by taking an exclusive  
lock on the temp namespace (even though it won't actually delete it).  
So, if we can get a shared lock on the namespace, we can be sure we're  
not running concurrently with RemoveTempRelations, while also not  
conflicting with ordinary use of the namespace.  This requires  
introducing a conditional version of LockDatabaseObject, but that's no  
big deal.  (It's surprising we've got along without that this long.)  
  
Report and patch by Mikhail Zhilin.  Back-patch to all supported  
branches.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 0de5274f59c9d84d803d7f3dc75577d8aa6e56b8    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 1 Apr 2024 19:01:18 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 1 Apr 2024 19:01:18 -0400    

If we are building with openssl but USE_SSL_ENGINE didn't get set,  
initialize_SSL's variable "pkey" is declared but used nowhere.  
Apparently this combination hasn't been exercised in the buildfarm  
before now, because I've not seen this warning before, even though  
the code has been like this a long time.  Move the declaration  
to silence the warning (and remove its useless initialization).  
  
Per buildfarm member sawshark.  Back-patch to all supported branches.  

commit   : d96f72569743842eb3d0cf4e97a77427b2729f38    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 1 Apr 2024 15:15:03 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 1 Apr 2024 15:15:03 -0400    

The "pltargs" variable wasn't marked volatile, which makes it unsafe  
to change its value within the PG_TRY block.  It looks like the worst  
outcome would be to fail to release a refcount on Py_None during an  
(improbable) error exit, which would likely go unnoticed in the field.  
Still, it's a bug.  A one-liner fix could be to mark pltargs volatile,  
but on the whole it seems cleaner to arrange things so that we don't  
change its value within PG_TRY.  
  
Per report from Xing Guo.  This has been there for quite awhile,  
so back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/CACpMh+DLrk=fDv07MNpBT4J413fDAm+gmMXgi8cjPONE+jvzuw@mail.gmail.com  

commit   : 0d30e48c2578a6857aa2869f1b2696b6eb5fef68    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 27 Mar 2024 13:39:03 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 27 Mar 2024 13:39:03 -0400    

When a plain aggregate is used as a window function, and the window  
frame start is specified as UNBOUNDED PRECEDING, the frame's head  
cannot move so we do not need to use moving-aggregate mode.  The check  
for that was put into initialize_peragg(), failing to notice that  
ExecInitWindowAgg() calls that function before it's filled in  
winstate->frameOptions.  Since makeNode() would have zeroed the field,  
this didn't provoke uninitialized-value complaints, nor would the  
erroneous decision have resulted in more than a little inefficiency.  
Still, it's wrong, so move the initialization of  
winstate->frameOptions earlier to make it work properly.  
  
While here, also fix a thinko in a comment.  Both errors crept in in  
commit a9d9acbf2 which introduced the moving-aggregate mode.  
  
Spotted by Vallimaharajan G.  Back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 66bbad581ce289fab8a55152987a223fe8795fee    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 26 Mar 2024 15:28:16 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 26 Mar 2024 15:28:16 -0400    

Ordinary ALTER TABLE SET SCHEMA will also move any owned sequences  
into the new schema.  We failed to do likewise for foreign tables,  
because AlterTableNamespaceInternal believed that only certain  
relkinds could have indexes, owned sequences, or constraints.  
We could simply add foreign tables to that relkind list, but it  
seems likely that the same oversight could be made again in  
future.  Instead let's remove the relkind filter altogether.  
These functions shouldn't cost much when there are no objects  
that they need to process, and surely this isn't an especially  
performance-critical case anyway.  
  
Per bug #18407 from Vidushi Gupta.  Back-patch to all supported  
branches.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : d82605bcd6663cb7dc506fc9c0c5c9c7d80e144b    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 26 Mar 2024 11:44:49 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 26 Mar 2024 11:44:49 -0400    

The musl dynamic linker saves a pointer to the process' environment  
value of LD_LIBRARY_PATH very early in startup.  When we move/clobber  
the environment to make more room for ps status strings, we clobber  
that value and thereby prevent libraries from being found via  
LD_LIBRARY_PATH, which breaks the use of a temporary installation  
for testing purposes.  To fix, stop collecting usable space for  
ps status if we notice that the variable we are about to clobber  
is LD_LIBRARY_PATH.  This will result in some reduction in how long  
the ps status can be, but it's only likely to occur in temporary  
test contexts, so it doesn't seem like a big problem.  In any case,  
we don't have to do it if we see we are on glibc, which surely is  
where the majority of our Linux testing is done.  
  
Thomas Munro, Bruce Momjian, and Tom Lane, per report from Wolfgang  
Walther.  Back-patch to all supported branches, with the hope that  
we'll set up a buildfarm animal to test on this platform.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 24d1b9989134e96f643ba31cd0e379fce5062534    
  
author   : Jeff Davis <[email protected]>    
date     : Mon, 25 Mar 2024 11:51:44 -0700    
  
committer: Jeff Davis <[email protected]>    
date     : Mon, 25 Mar 2024 11:51:44 -0700    

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

commit   : 4e8529da48baf780f2a2c7e0255a0c9ea02b0d11    
  
author   : Alexander Korotkov <[email protected]>    
date     : Sat, 23 Mar 2024 23:00:06 +0200    
  
committer: Alexander Korotkov <[email protected]>    
date     : Sat, 23 Mar 2024 23:00:06 +0200    

It might happen that the varlena value wasn't compressed by index_form_tuple()  
due to current storage parameters.  If compression is currently enabled, we  
need to compress such values to match index tuple coming from the heap.  
  
Backpatch to all supported versions.  
  
Discussion: https://postgr.es/m/flat/7bdbe559-d61a-4ae4-a6e1-48abdf3024cc%40postgrespro.ru  
Author: Andrey Borodin  
Reviewed-by: Alexander Lakhin, Michael Zhilin, Jian He, Alexander Korotkov  
Backpatch-through: 12  

commit   : 5df5d9cd7ea4f40f6e3efec650bdc7615b6d16ed    
  
author   : Alexander Korotkov <[email protected]>    
date     : Sat, 23 Mar 2024 22:59:56 +0200    
  
committer: Alexander Korotkov <[email protected]>    
date     : Sat, 23 Mar 2024 22:59:56 +0200    

In the heap, tuples may contain short varlena datum with both 1B header and 4B  
headers.  But the corresponding index tuple should always have such varlena's  
with 1B headers.  So, for fingerprinting, we need to convert.  
  
Backpatch to all supported versions.  
  
Discussion: https://postgr.es/m/flat/7bdbe559-d61a-4ae4-a6e1-48abdf3024cc%40postgrespro.ru  
Author: Michael Zhilin  
Reviewed-by: Alexander Lakhin, Andrey Borodin, Jian He, Alexander Korotkov  
Backpatch-through: 12  

commit   : a1a51dc4fab7efdcf3c3a50d9dd9f0a4a420f4f7    
  
author   : Jeff Davis <[email protected]>    
date     : Sat, 23 Mar 2024 13:36:19 -0700    
  
committer: Jeff Davis <[email protected]>    
date     : Sat, 23 Mar 2024 13:36:19 -0700    

Already removed incidentally in version 15 (c4649cce3), so this commit  
is only applied to versions 13 and 14.  
  
The comment above is misleading in all versions 13 and later, so that  
will be fixed in a separate commit.  
  
Discussion: https://postgr.es/m/cfd84cb8-12fe-433a-a4bb-f460a4515f9c.zhaotinghai.zth%40alibaba-inc.com  
Reported-by: Tinghai Zhao  
Backpatch-through: 13  

commit   : 6ebd4372550a08c286ad08da4e39c6571bb07e10    
  
author   : Daniel Gustafsson <[email protected]>    
date     : Fri, 22 Mar 2024 01:01:30 +0100    
  
committer: Daniel Gustafsson <[email protected]>    
date     : Fri, 22 Mar 2024 01:01:30 +0100    

Some last minute polish of the patch managed to break the SQL  
query for extracting the role comments due to fat-fingering.  
  
Per the buildfarm Xversion tests.  

commit   : be01c8c3450e48fbe8baa13625e1d36e0814c29b    
  
author   : Daniel Gustafsson <[email protected]>    
date     : Thu, 21 Mar 2024 23:31:57 +0100    
  
committer: Daniel Gustafsson <[email protected]>    
date     : Thu, 21 Mar 2024 23:31:57 +0100    

Commit 9a83d56b38c added support for allowing pg_dumpall to dump  
roles without including passwords, which accidentally made dumps  
omit COMMENTs on roles.  This fixes it by using pg_authid to get  
the comment.  
  
Backpatch to all supported versions. Patch simultaneously written  
independently by Álvaro and myself.  
  
Author: Álvaro Herrera <[email protected]>  
Author: Daniel Gustafsson <[email protected]>  
Reported-by: Bartosz Chroł <[email protected]>  
Discussion: https://postgr.es/m/AS8P194MB1271CDA0ADCA7B75FCD8E767F7332@AS8P194MB1271.EURP194.PROD.OUTLOOK.COM  
Discussion: https://postgr.es/m/CAEP4nAz9V4H41_4ESJd1Gf0v%3DdevkqO1%3Dpo91jUw-GJSx8Hxqg%40mail.gmail.com  
Backpatch-through: v12  

commit   : 33bfbef1d60fdccbfb72423b2e1e7c4074a640b9    
  
author   : Alvaro Herrera <[email protected]>    
date     : Wed, 20 Mar 2024 15:28:14 +0100    
  
committer: Alvaro Herrera <[email protected]>    
date     : Wed, 20 Mar 2024 15:28:14 +0100    

Remove a redundant comment, and document pg_class.reltablespace properly  
in catalogs.sgml.  
  
After commits a36c84c3e4a9, 87259588d0ab and others.  
  
Backpatch to 12.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 262757b73286d6dab2c563123ff11bee2b295e31    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Mon, 18 Mar 2024 14:04:19 +0200    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Mon, 18 Mar 2024 14:04:19 +0200    

Previously, bitmap heap scans only counted lossy and exact pages for  
explain when there was at least one visible tuple on the page.  
  
heapam_scan_bitmap_next_block() returned true only if there was a  
"valid" page with tuples to be processed. However, the lossy and exact  
page counters in EXPLAIN should count the number of pages represented  
in a lossy or non-lossy way in the constructed bitmap, regardless of  
whether or not the pages ultimately contained visible tuples.  
  
Backpatch to all supported versions.  
  
Author: Melanie Plageman  
Discussion: https://www.postgresql.org/message-id/CAAKRu_ZwCwWFeL_H3ia26bP2e7HiKLWt0ZmGXPVwPO6uXq0vaA@mail.gmail.com  
Discussion: https://www.postgresql.org/message-id/CAAKRu_bxrXeZ2rCnY8LyeC2Ls88KpjWrQ%[email protected]  

commit   : 3621ffd9f21b313116e84301a1dce0d3f1dc2f8a    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 14 Mar 2024 14:57:16 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 14 Mar 2024 14:57:16 -0400    

Commit a3c7a993d fixed some cases involving target columns that are  
arrays or composites by applying transformAssignedExpr to the VALUES  
entries, and then stripping off any assignment ArrayRefs or  
FieldStores that the transformation added.  But I forgot about domains  
over arrays or composites :-(.  Such cases would either fail with  
surprising complaints about mismatched datatypes, or insert unexpected  
coercions that could lead to odd results.  To fix, extend the  
stripping logic to get rid of CoerceToDomain if it's atop an ArrayRef  
or FieldStore.  
  
While poking at this, I realized that there's a poorly documented and  
not-at-all-tested behavior nearby: we coerce each VALUES column to  
the domain type separately, and rely on the rewriter to merge those  
operations so that the domain constraints are checked only once.  
If that merging did not happen, it's entirely possible that we'd get  
unexpected domain constraint failures due to checking a  
partially-updated container value.  There's no bug there, but while  
we're here let's improve the commentary about it and add some test  
cases that explicitly exercise that behavior.  
  
Per bug #18393 from Pablo Kharo.  Back-patch to all supported  
branches.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 649bbba1134dce05998e26137fcb32d0e0cb6311    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 12 Mar 2024 18:16:10 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 12 Mar 2024 18:16:10 -0400    

There is a very ancient hack in check_sql_fn_retval that allows a  
single SELECT targetlist entry of composite type to be taken as  
supplying all the output columns of a function returning composite.  
(This is grotty and fundamentally ambiguous, but it's really hard  
to do nested composite-returning functions without it.)  
  
As far as I know, that doesn't cause any problems in ordinary  
functions.  It's disastrous for procedures however.  All procedures  
that have any output parameters are labeled with prorettype RECORD,  
and the CALL code expects it will get back a record with one column  
per output parameter, regardless of whether any of those parameters  
is composite.  Doing something else leads to an assertion failure  
or core dump.  
  
This is simple enough to fix: we just need to not apply that rule  
when considering procedures.  However, that requires adding another  
argument to check_sql_fn_retval, which at least in principle might be  
getting called by external callers.  Therefore, in the back branches  
convert check_sql_fn_retval into an ABI-preserving wrapper around a  
new function check_sql_fn_retval_ext.  
  
Per report from Yahor Yuzefovich.  This has been broken since we  
implemented procedures, so back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/CABz5gWHSjj2df6uG0NRiDhZ_Uz=Y8t0FJP-_SVSsRsnrQT76Gg@mail.gmail.com  

commit   : bf1f593e899ee9aa1de80164a3005b02474deb50    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Tue, 12 Mar 2024 10:18:32 +0200    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Tue, 12 Mar 2024 10:18:32 +0200    

Commit 387da18874 moved the code to put socket into non-blocking mode  
from socket_set_nonblocking() into the one-time initialization  
function, pq_init(). In socket_set_nonblocking(), there indeed was a  
risk of recursion on failure like the comment said, but in pq_init(),  
ERROR or FATAL is fine. There's even another elog(FATAL) just after  
this, if setting FD_CLOEXEC fails.  
  
Note that COMMERROR merely logged the error, it did not close the  
connection, so if putting the socket to non-blocking mode failed we  
would use the connection anyway. You might not immediately notice,  
because most socket operations in a regular backend wait for the  
socket to become readable/writable anyway. But e.g. replication will  
be quite broken.  
  
Backpatch to all supported versions.  
  
Discussion: https://www.postgresql.org/message-id/[email protected]  

commit   : 5b97461fb068bc348e6b7fc4e5a3b22c86a00b0c    
  
author   : Bruce Momjian <[email protected]>    
date     : Mon, 11 Mar 2024 13:31:13 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Mon, 11 Mar 2024 13:31:13 -0400    

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

commit   : 72b8507db2cc24810a29153838a62777d32f412f    
  
author   : David Rowley <[email protected]>    
date     : Mon, 11 Mar 2024 18:21:48 +1300    
  
committer: David Rowley <[email protected]>    
date     : Mon, 11 Mar 2024 18:21:48 +1300    

For pass-by-reference types, the code added in 0b053e78b, which aimed to  
resolve a memory leak, was overly aggressive in resetting the per-tuple  
memory context which could result in pfree'd memory being accessed  
resulting in failing to find previously cached results in the hash  
table.  
  
What was happening was prepare_probe_slot() was switching to the  
per-tuple memory context and calling ExecEvalExpr().  ExecEvalExpr() may  
have required a memory allocation.  Both MemoizeHash_hash() and  
MemoizeHash_equal() were aggressively resetting the per-tuple context  
and after determining the hash value, the context would have gotten reset  
before MemoizeHash_equal() was called.  This could have resulted in  
MemoizeHash_equal() looking at pfree'd memory.  
  
This is less likely to have caused issues on a production build as some  
other allocation would have had to have reused the pfree'd memory to  
overwrite it.  Otherwise, the original contents would have been intact.  
However, this clearly caused issues on MEMORY_CONTEXT_CHECKING builds.  
  
Author: Tender Wang, Andrei Lepikhov  
Reported-by: Tender Wang (using SQLancer)  
Reviewed-by: Andrei Lepikhov, Richard Guo, David Rowley  
Discussion: https://postgr.es/m/CAHewXNnT6N6UJkya0z-jLFzVxcwGfeRQSfhiwA+NyLg-x8iGew@mail.gmail.com  
Backpatch-through: 14, where Memoize was added  

commit   : 84cc1a5527564beef86ba500d8318e2f659f6969    
  
author   : Alexander Korotkov <[email protected]>    
date     : Fri, 16 Feb 2024 16:02:00 +0200    
  
committer: Alexander Korotkov <[email protected]>    
date     : Fri, 16 Feb 2024 16:02:00 +0200    

Backpatch changes from d57b7cc333, 75bcba6cbd to all supported branches per  
proposal of Egor Chindyaskin.  
  
Discussion: https://postgr.es/m/DE5FD776-A8CD-4378-BCFA-3BF30F1F6D60%40mail.ru  

commit   : 628c3f2e17fef9cee9329f8d142db6a69105c681    
  
author   : David Rowley <[email protected]>    
date     : Mon, 11 Mar 2024 12:28:40 +1300    
  
committer: David Rowley <[email protected]>    
date     : Mon, 11 Mar 2024 12:28:40 +1300    

For UNION ALL queries where a union child query contained a foreign  
table, if the targetlist of that query contained a constant, and the  
top-level query performed an ORDER BY which contained the column for the  
constant value, then postgres_fdw would find the EquivalenceMember with  
the Const and then try to produce an ORDER BY containing that Const.  
  
This caused problems with INT typed Consts as these could appear to be  
requests to order by an ordinal column position rather than the constant  
value.  This could lead to either an error such as:  
  
ERROR:  ORDER BY position <int const> is not in select list  
  
or worse, if the constant value is a valid column, then we could just  
sort by the wrong column altogether.  
  
Here we fix this issue by just not including these Consts in the ORDER  
BY clause.  
  
In passing, add a new section for testing ORDER BY in the postgres_fdw  
tests and move two existing tests which were misplaced in the WHERE  
clause testing section into it.  
  
Reported-by: Michał Kłeczek  
Reviewed-by: Ashutosh Bapat, Richard Guo  
Bug: #18381  
Discussion: https://postgr.es/m/0714C8B8-8D82-4ABB-9F8D-A0C3657E7B6E%40kleczek.org  
Discussion: https://postgr.es/m/18381-137456acd168bf93%40postgresql.org  
Backpatch-through: 12, oldest supported version  

commit   : 473babd4290e88a6d01b52f19dc0ec54e3fbcd73    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 7 Mar 2024 19:37:51 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 7 Mar 2024 19:37:51 -0500    

In OpenSSL 3.0.0 and later, ERR_reason_error_string randomly refuses  
to provide a string for error codes representing system errno values  
(e.g., "No such file or directory").  There is a poorly-documented way  
to extract the errno from the SSL error code in this case, so do that  
and apply strerror, rather than falling back to reporting the error  
code's numeric value as we were previously doing.  
  
Problem reported by David Zhang, although this is not his proposed  
patch; it's instead based on a suggestion from Heikki Linnakangas.  
Back-patch to all supported branches, since any of them are likely  
to be used with recent OpenSSL.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 49b971298a9b4271a9d5f91dcc969c5cb1acfbc1    
  
author   : Michael Paquier <[email protected]>    
date     : Thu, 7 Mar 2024 08:31:07 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Thu, 7 Mar 2024 08:31:07 +0900    

This reverts commit eae7be600be7, following a discussion with Tom Lane,  
due to concerns that this impacts the decisions made by the planner for  
the number of workers spawned based on the inlining and const-folding of  
index expressions and predicate for cases that would have worked until  
this commit.  
  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 12  

commit   : a595c3075fb4b8ab4211b074485eb0a17062ec7f    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 6 Mar 2024 14:41:13 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 6 Mar 2024 14:41:13 -0500    

In the corner case where a function returning RECORD has been  
simplified to a RECORD constant or an inlined ROW() expression,  
ExecInitFunctionScan failed to cross-check the function's result  
rowtype against the coldeflist provided by the calling query.  
That happened because get_expr_result_type is able to extract a  
tupdesc from such expressions, which led ExecInitFunctionScan to  
ignore the coldeflist.  (Instead, it used the extracted tupdesc  
to check the function's output, which of course always succeeds.)  
  
I have not been able to demonstrate any really serious consequences  
from this, because if some column of the result is of the wrong  
type and is directly referenced by a Var of the calling query,  
CheckVarSlotCompatibility will catch it.  However, we definitely do  
fail to report the case where the function returns more columns than  
the coldeflist expects, and in the converse case where it returns  
fewer columns, we get an assert failure (but, seemingly, no worse  
results in non-assert builds).  
  
To fix, always build the expected tupdesc from the coldeflist if there  
is one, and consult get_expr_result_type only when there isn't one.  
  
Also remove the failing Assert, even though it is no longer reached  
after this fix.  It doesn't seem to be adding anything useful, since  
later checking will deal with cases with the wrong number of columns.  
  
The only other place I could find that is doing something similar  
is inline_set_returning_function.  There's no live bug there because  
we cannot be looking at a Const or RowExpr, but for consistency  
change that code to agree with ExecInitFunctionScan.  
  
Per report from PetSerAl.  After some debate I've concluded that  
this should be back-patched.  There is a small risk that somebody  
has been relying on such a case not throwing an error, but I judge  
this outweighed by the risk that I've missed some way in which the  
failure to cross-check has worse consequences than sketched above.  
  
Discussion: https://postgr.es/m/CAKygsHSerA1eXsJHR9wft3Gn3wfHQ5RfP8XHBzF70_qcrrRvEg@mail.gmail.com  

commit   : 56a8ab2fc6f76ec2ca7a257f36ef8138a3fd473a    
  
author   : Michael Paquier <[email protected]>    
date     : Wed, 6 Mar 2024 17:24:10 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Wed, 6 Mar 2024 17:24:10 +0900    

As coded, the planner logic that calculates the number of parallel  
workers to use for a parallel index build uses expressions and  
predicates from the relcache, which are flattened for the planner by  
eval_const_expressions().  
  
As reported in the bug, an immutable parallel-unsafe function flattened  
in the relcache would become a Const, which would be considered as  
parallel-safe, even if the predicate or the expressions including the  
function are not safe in parallel workers.  Depending on the expressions  
or predicate used, this could cause the parallel build to fail.  
  
Tests are included that check parallel index builds with parallel-unsafe  
predicate and expressions.  Two routines are added to lsyscache.h to be  
able to retrieve expressions and predicate of an index from its pg_index  
data.  
  
Reported-by: Alexander Lakhin  
Author: Tender Wang  
Reviewed-by: Jian He, Michael Paquier  
Discussion: https://postgr.es/m/CAHewXN=UaAaNn9ruHDH3Os8kxLVmtWqbssnf=dZN_s9=evHUFA@mail.gmail.com  
Backpatch-through: 12  

commit   : 0c2dda109a6cfd9fbfeef77dad4996d39faebeae    
  
author   : David Rowley <[email protected]>    
date     : Tue, 5 Mar 2024 16:18:42 +1300    
  
committer: David Rowley <[email protected]>    
date     : Tue, 5 Mar 2024 16:18:42 +1300    

The error message(s) were reporting the stats kind of 'f', which is not  
correct as that's for the "dependencies" statistics kind.  
  
Reported-by: Horst Reiterer  
Reviewed-by: Richard Guo  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 12, where MCV extended stats were added.  

commit   : 217928ddb45a8a3b03fc1f9d3d97166f1d9a9d12    
  
author   : Daniel Gustafsson <[email protected]>    
date     : Thu, 29 Feb 2024 12:19:52 +0100    
  
committer: Daniel Gustafsson <[email protected]>    
date     : Thu, 29 Feb 2024 12:19:52 +0100    

dsa_dump would print a large negative number instead of zero for  
segment bin 0.  Fix by explicitly checking for underflow and add  
special case for bin 0. Backpatch to all supported versions.  
  
Author: Ian Ilyasov <[email protected]>  
Reviewed-by: Robert Haas <[email protected]>  
Discussion: https://postgr.es/m/GV1P251MB1004E0D09D117D3CECF9256ECD502@GV1P251MB1004.EURP251.PROD.OUTLOOK.COM  
Backpatch-through: v12  

commit   : fe3b1b575e24748ddb9b3b67394fa10c279090ac    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 28 Feb 2024 14:00:30 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 28 Feb 2024 14:00:30 -0500    

In the case where the target timestamp is before the origin timestamp  
and their difference is already an exact multiple of the stride, the  
code incorrectly subtracted the stride anyway.  
  
Also detect several integer-overflow cases that previously produced  
bogus results.  (The submitted patch tried to avoid overflow, but  
I'm not convinced it's right, and problematic cases are so far out of  
the plausibly-useful range that they don't seem worth sweating over.  
Let's just use overflow-detecting arithmetic and throw errors.)  
  
timestamp_bin() and timestamptz_bin() are basically identical and  
so had identical bugs.  Fix both.  
  
Report and patch by Moaaz Assali, adjusted some by me.  Back-patch  
to v14 where date_bin() was introduced.  
  
Discussion: https://postgr.es/m/CALkF+nvtuas-2kydG-WfofbRSJpyODAJWun==W-yO5j2R4meqA@mail.gmail.com  

commit   : 09f09884c18d725db7a60e03a8f78bafdbc78b95    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 25 Feb 2024 16:15:07 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 25 Feb 2024 16:15:07 -0500    

When this assertion was installed (in commit d2f60a3ab), I thought  
it was only for catching server logic errors that caused accesses to  
catalogs that were undergoing index rebuilds.  However, it will also  
fire in case of a user-defined index expression that attempts to  
access its own table.  We occasionally see reports of people trying  
to do that, and typically getting unintelligible low-level errors  
as a result.  We can provide a more on-point message by making this  
a regular runtime check.  
  
While at it, adjust the similar error check in  
systable_beginscan_ordered to use the same message text.  That one  
is (probably) not reachable without a coding bug, but we might as  
well use a translatable message if we have one.  
  
Per bug #18363 from Alexander Lakhin.  Back-patch to all supported  
branches.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 2b997d7db26e4c2be6b2474eeca801a50825f18c    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 25 Feb 2024 15:29:09 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 25 Feb 2024 15:29:09 -0500    

Noted by Aidar Imamov.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : cbeb455275138e6525912dd480c421864994c9c1    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 23 Feb 2024 15:21:53 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 23 Feb 2024 15:21:53 -0500    

build_child_join_sjinfo creates a derived SpecialJoinInfo in  
the short-lived GEQO context, but afterwards the semi_rhs_exprs  
from that may be used in a UniquePath for a child base relation.  
This breaks the expectation that all base-relation-level structures  
are in the planning-lifespan context, leading to use of a dangling  
pointer with probable ensuing crash later on in create_unique_plan.  
To fix, copy the expression trees when making a UniquePath.  
  
Per bug #18360 from Alexander Lakhin.  This has been broken since  
partitionwise joins were added, so back-patch to all supported  
branches.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : ebf52e9b753250a0be07375c8c5f290e87edef2f    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 20 Feb 2024 14:35:12 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 20 Feb 2024 14:35:12 -0500    

The explanation of interval's behavior in datatype.sgml wasn't wrong  
exactly, but it was unclear, partly because it buried the lede about  
there being three internal fields.  Rearrange and wordsmith for more  
clarity.  
  
The discussion of extract() claimed that input of type date was  
handled by casting, but actually there's been a separate SQL function  
taking date for a very long time.  Also, it was mostly silent about  
how interval inputs are handled, but there are several field types  
for which it seems useful to be specific.  
  
Improve discussion of justify_days()/justify_hours() too.  
  
In passing, remove vertical space in some groups of examples,  
as there was little consistency about whether to have such space  
or not.  (I only did this within the datetime functions section;  
there are some related inconsistencies elsewhere.)  
  
Per discussion of bug #18348 from Michael Bondarenko.  There  
may be some code changes coming out of that discussion too,  
but we likely won't back-patch them.  This docs-only patch  
seems useful to back-patch, though I only carried it back to  
v13 because it didn't apply easily in v12.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : b992a707f78af859ca5dfcccc4dd5fcfb5fa29bb    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 20 Feb 2024 11:58:28 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 20 Feb 2024 11:58:28 -0500    

Commits 1b2c6b756 et al affected the core BRIN "bloom" opclasses,  
not contrib/bloom.  This only corrected a bad assertion so it's not  
too significant to end users, but since we documented it we should  
do so accurately.  
  
Spotted by Takatsuka Haruka.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : f9c8f7ccd6e34bc9222a09af3205600611bcda27    
  
author   : David Rowley <[email protected]>    
date     : Tue, 20 Feb 2024 12:50:57 +1300    
  
committer: David Rowley <[email protected]>    
date     : Tue, 20 Feb 2024 12:50:57 +1300    

Partition pruning wrongly assumed that, for a table partitioned on a  
boolean column, a clause in the form "boolcol IS NOT false" and "boolcol  
IS NOT true" could be inverted to correspondingly become "boolcol IS true"  
and "boolcol IS false".  These are not equivalent as the NOT version  
matches the opposite boolean value *and* NULLs.  This incorrect assumption  
meant that partition pruning pruned away partitions that could contain  
NULL values.  
  
Here we fix this by correctly not pruning partitions which could store  
NULLs.  
  
To be affected by this, the table must be partitioned by a NULLable boolean  
column and queries would have to contain "boolcol IS NOT false" or "boolcol  
IS NOT true".  This could result in queries filtering out NULL values  
with a LIST partitioned table and "ERROR:  invalid strategy number 0"  
for RANGE and HASH partitioned tables.  
  
Reported-by: Alexander Lakhin  
Bug: #18344  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 12  

commit   : eac4aff0b8a5d4cd003012ba4464bd0b39a9f875    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 19 Feb 2024 14:17:11 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 19 Feb 2024 14:17:11 -0500    

One case missed its trailing "|".  
  
Reported by Tim Needham.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : a05bb9addb3770d07cc90ebfd5e2486e63647bce    
  
author   : Michael Paquier <[email protected]>    
date     : Mon, 19 Feb 2024 11:38:49 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Mon, 19 Feb 2024 11:38:49 +0900    

intoasc(), a wrapper for PGTYPESinterval_to_asc that converts an  
interval to its textual representation, used a plain memcpy() when  
copying its result.  This could miss a zero-termination in the result  
string, leading to an incorrect result.  
  
The routines in informix.c do not provide the length of their result  
buffer, which would allow a replacement of strcpy() to safer strlcpy()  
calls, but this requires an ABI breakage and that cannot happen in  
back-branches.  
  
Author: Oleg Tselebrovskiy  
Reviewed-by: Ashutosh Bapat  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 12  

commit   : 6686e9676c8faff4ee04c1574e117ae38f117efa    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 15 Feb 2024 16:45:03 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 15 Feb 2024 16:45:03 -0500    

Clarify comments associated with max_parallel_workers and  
related settings.  
  
Per bug #18343 from Christopher Kline.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 078195eb618c86f9252300905f6e352f383fe7ef    
  
author   : Daniel Gustafsson <[email protected]>    
date     : Wed, 14 Feb 2024 11:05:10 +0100    
  
committer: Daniel Gustafsson <[email protected]>    
date     : Wed, 14 Feb 2024 11:05:10 +0100    

The pgcrypto docs contained a set of links for useful reading and  
technical references. These sets of links were however not actively  
curated and had stale content and dead links. Rather than investing  
time into maintining these, this removes them altogether since there  
are lots of resources online which are actively maintained.  
  
Backpatch to all supported versions since these links have been in  
the docs for a long time.  
  
Reported-by: Hanefi Onaldi <[email protected]>  
Reviewed-by: Magnus Hagander <[email protected]>  
Reviewed-by: Tom Lane <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: v12  

commit   : 9b8550fbd31e329481c5f73430185a2b672693d6    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Tue, 13 Feb 2024 21:23:41 +0200    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Tue, 13 Feb 2024 21:23:41 +0200    

Fixes bug #18341. Backpatch to all supported versions.  
  
Discussion: https://www.postgresql.org/message-id/[email protected]  

commit   : 99cd749ce267fd9c0f6461b282f84f65ed9d8535    
  
author   : Daniel Gustafsson <[email protected]>    
date     : Tue, 13 Feb 2024 14:09:52 +0100    
  
committer: Daniel Gustafsson <[email protected]>    
date     : Tue, 13 Feb 2024 14:09:52 +0100    

This reverts commit aeee173d229232f94acc61e7bfe81d40f56e478e.  
Per failure reports from the buildfarm.  

commit   : aeee173d229232f94acc61e7bfe81d40f56e478e    
  
author   : Daniel Gustafsson <[email protected]>    
date     : Tue, 13 Feb 2024 13:47:12 +0100    
  
committer: Daniel Gustafsson <[email protected]>    
date     : Tue, 13 Feb 2024 13:47:12 +0100    

The macOS Finder application creates .DS_Store files in directories  
when opened,  which creates problems for serverside utilities which  
expect all files to be PostgreSQL specific files.  Skip these files  
when encountered in pg_checksums, pg_rewind and pg_basebackup.  
  
This was extracted from a larger patchset for skipping hidden files  
and system files, where the concencus was to just skip these. Since  
this is equally likely to happen in every version, backpatch to all  
supported versions.  
  
Reported-by: Mark Guertin <[email protected]>  
Reviewed-by: Michael Paquier <[email protected]>  
Reviewed-by: Tobias Bussmann <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: v12  

commit   : d21690edbf414582f7f20c26bb355d49cbbeb8a0    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 9 Feb 2024 12:29:41 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 9 Feb 2024 12:29:41 -0500    

Since its introduction, pg_get_expr() has intended to silently  
return NULL if called with an invalid relation OID, as can happen  
when scanning the catalogs concurrently with relation drops.  
However, there is a race condition: we check validity of the OID  
at the start, but it could get dropped just afterward, leading to  
failures.  This is the cause of some intermittent instability we're  
seeing in a proposed new test case, and presumably it's a hazard in  
the field as well.  
  
We can fix this by AccessShareLock-ing the target relation for the  
duration of pg_get_expr().  Since we don't require any permissions  
on the target relation, this is semantically a bit undesirable.  But  
it turns out that the set_relation_column_names() subroutine already  
takes a transient AccessShareLock on that relation, and has done since  
commit 2ffa740be in 2012.  Given the lack of complaints about that, it  
seems like there should be no harm in holding the lock a bit longer.  
  
Back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 8ead39e3895ed7b1a60036a4bcc09fbe2f8d6bde    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 9 Feb 2024 11:21:08 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 9 Feb 2024 11:21:08 -0500    

We previously supposed that it was okay for different threads to  
call bindtextdomain() concurrently (cf. commit 1f655fdc3).  
It now emerges that there's at least one gettext implementation  
in which that triggers an abort() crash, so let's stop doing that.  
Add mutexes guarding libpq's and ecpglib's calls, which are the  
only ones that need worry about multithreaded callers.  
  
Note: in libpq, we could perhaps have piggybacked on  
default_threadlock() to avoid defining a new mutex variable.  
I judge that not terribly safe though, since libpq_gettext could  
be called from code that is holding the default mutex.  If that  
were the first such call in the process, it'd fail.  An extra  
mutex is cheap insurance against unforeseen interactions.  
  
Per bug #18312 from Christian Maurer.  Back-patch to all  
supported versions.  
  
Discussion: https://postgr.es/m/[email protected]  
Discussion: https://postgr.es/m/[email protected]  

commit   : 7d7cc7fd6fbdfca68fe144476078c03d3c36e158    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 9 Feb 2024 11:11:39 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 9 Feb 2024 11:11:39 -0500    

Fix pthread-win32.h and pthread-win32.c to provide a more complete  
emulation of POSIX pthread mutexes: define PTHREAD_MUTEX_INITIALIZER  
and make sure that pthread_mutex_lock() can operate on a mutex  
object that's been initialized that way.  Then we don't need the  
duplicative platform-specific logic in default_threadlock() and  
pgtls_init(), which we'd otherwise need yet a third copy of for  
an upcoming bug fix.  
  
Also, since default_threadlock() supposes that pthread_mutex_lock()  
cannot fail, try to ensure that that's actually true, by getting  
rid of the malloc call that was formerly involved in initializing  
an emulated mutex.  We can define an extra state for the spinlock  
field instead.  
  
Also, replace the similar code in ecpglib/misc.c with this version.  
While ecpglib's version at least had a POSIX-compliant API, it  
also had the potential of failing during mutex init (but here,  
because of CreateMutex failure rather than malloc failure).  Since  
all of misc.c's callers ignore failures, it seems like a wise idea  
to avoid failures here too.  
  
A further improvement in this area could be to unify libpq's and  
ecpglib's implementations into a src/port/pthread-win32.c file.  
But that doesn't seem like a bug fix, so I'll desist for now.  
  
In preparation for the aforementioned bug fix, back-patch to all  
supported branches.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 18388291aab8038b6abb6a9109ab6763e7a5b630    
  
author   : Alexander Korotkov <[email protected]>    
date     : Thu, 8 Feb 2024 12:45:26 +0200    
  
committer: Alexander Korotkov <[email protected]>    
date     : Thu, 8 Feb 2024 12:45:26 +0200    

The TransactionIdInRecentPast() should return false for all the transactions  
older than TransamVariables->oldestClogXid.  However, the function contains  
a bug in comparison FullTransactionId to TransactionID allowing full  
transactions between nextXid - 2^32 and oldestClogXid - 2^31.  
  
This commit fixes TransactionIdInRecentPast() by turning the oldestClogXid into  
FullTransactionId first, then performing the comparison.  
  
Backpatch to all supported versions.  
  
Reported-by: Egor Chindyaskin  
Bug: 18212  
Discussion: https://postgr.es/m/18212-547307f8adf57262%40postgresql.org  
Author: Karina Litskevich  
Reviewed-by: Kyotaro Horiguchi  
Backpatch-through: 12