PostgreSQL 16.3 commit log

commit   : 05ffe9398b758bbb8d30cc76e9bbc638dab2d477    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 6 May 2024 16:21:25 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 6 May 2024 16:21:25 -0400    

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

Security: CVE-2024-4317  

commit   : 2485a85e96db137f7962a2e702b99869957f0990    
  
author   : Nathan Bossart <[email protected]>    
date     : Mon, 6 May 2024 09:00:07 -0500    
  
committer: Nathan Bossart <[email protected]>    
date     : Mon, 6 May 2024 09:00:07 -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   : 3855bf9c10ae27d0d55c0b0b3ee9bad4cc40d80e    
  
author   : Alvaro Herrera <[email protected]>    
date     : Mon, 6 May 2024 12:45:17 +0200    
  
committer: Alvaro Herrera <[email protected]>    
date     : Mon, 6 May 2024 12:45:17 +0200    

This datatype is purposefully not documented.  
  
Erik Wienhold <[email protected]>  
Discussion: https://postgr.es/m/om3g7p7u3ztlrdp4tfswgulavljgn2fe6u2agk34mrr65dffuu@cpzlzuv6flko  

commit   : dde58eccae71c578f39255c72c351f3b0976c6a2    
  
author   : Peter Eisentraut <[email protected]>    
date     : Mon, 6 May 2024 12:08:30 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Mon, 6 May 2024 12:08:30 +0200    

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

commit   : 9fc09cc294ff9fcf961758bf4d020c9899c4af13    
  
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   : 7155cc4a60e7bfc837233b2dea2563a2edc673fd    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 3 May 2024 14:10:45 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 3 May 2024 14:10:45 -0400    

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

commit   : 11d40a44ba325f254562a3fbd8ccd2791f12b9b5    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 2 May 2024 17:36:31 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 2 May 2024 17:36:31 -0400    

Same as 42b041243, except that the trouble case is a publication  
WHERE clause that depends on a column.  
  
Again reported by Alexander Lakhin.  Back-patch to v15 where  
we added publication WHERE clauses.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : ec235d8649170cfae3d6bd11859758538dd0d0f6    
  
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   : 0e66ed142106f8397bbb1f0be736f7d808b9493f    
  
author   : Peter Eisentraut <[email protected]>    
date     : Thu, 2 May 2024 07:55:53 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Thu, 2 May 2024 07:55:53 +0200    

It was claiming that the ICU locale provider is used by default, which  
is not correct.  (From commit fcb21b3acdc; it was once contemplated to  
make it the default, but it wouldn't have been part of that patch in  
any case.)  
  
Reviewed-by: Kashif Zeeshan <[email protected]>  
Discussion: https://www.postgresql.org/message-id/flat/a71023c2-0ae0-45ad-9688-cf3b93d0d65b%40eisentraut.org  

commit   : 5a0ac6855a21917ada42d8bb83d3d5ac4c2eeda8    
  
author   : Alvaro Herrera <[email protected]>    
date     : Wed, 1 May 2024 11:50:05 +0200    
  
committer: Alvaro Herrera <[email protected]>    
date     : Wed, 1 May 2024 11:50:05 +0200    

When testing pg_upgrade against an old server, ignore failures on the  
check to upgrade invalid databases.  This is necessary because old  
servers don't know to raise the appropriate error of the database being  
invalid.  
  
This change causes no reduction in coverage, because such old versions  
don't know to mark databases invalid when a drop is interrupted; but  
testing against such old servers is useful in some circumstances.  
  
Backpatch to 16, where it cherry-picks with minimal conflicts.  
  
On 16, perltidy 20230309 chooses to change an unrelated line.  I let it  
do that because that's the version we document as preferred for that  
branch, even though it would make other changes to many other files in  
the tree.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 9d36b883bfaaeee04f09101c5e7cde96906a256e    
  
author   : David Rowley <[email protected]>    
date     : Wed, 1 May 2024 16:35:05 +1200    
  
committer: David Rowley <[email protected]>    
date     : Wed, 1 May 2024 16:35:05 +1200    

94985c210 added code to detect when WindowFuncs were monotonic and  
allowed additional quals to be "pushed down" into the subquery to be  
used as WindowClause runConditions in order to short-circuit execution  
in nodeWindowAgg.c.  
  
The Node representation of runConditions wasn't well selected and  
because we do qual pushdown before planning the subquery, the planning  
of the subquery could perform subquery pull-up of nested subqueries.  
For WindowFuncs with args, the arguments could be changed after pushing  
the qual down to the subquery.  
  
This was made more difficult by the fact that the code duplicated the  
WindowFunc inside an OpExpr to include in the WindowClauses runCondition  
field.  This could result in duplication of subqueries and a pull-up of  
such a subquery could result in another initplan parameter being issued  
for the 2nd version of the subplan.  This could result in errors such as:  
  
ERROR:  WindowFunc not found in subplan target lists  
  
Here in the backbranches, we don't have the flexibility to improve the  
Node representation to resolve this, so instead we just disable the  
runCondition optimization for ntile() unless the argument is a Const,  
(v16 only) and likewise for count(expr) (both v15 and v16).  count(*) is  
unaffected.  All other window functions which support this optimization  
all take zero arguments and therefore are unaffected.  
  
Bug: #18170  
Reported-by: Zuming Jiang  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through 15 (master will be fixed independently)  

commit   : f199436c12819d2c01b72eaa6429de0ca5838471    
  
author   : Masahiko Sawada <[email protected]>    
date     : Wed, 1 May 2024 12:34:04 +0900    
  
committer: Masahiko Sawada <[email protected]>    
date     : Wed, 1 May 2024 12:34:04 +0900    

A parallel worker's buffer usage is accumulated to its pgBufferUsage  
and then is accumulated into the leader's one at the end of the  
parallel vacuum. However, since the leader process used to use  
dedicated VacuumPage{Hit, Miss, Dirty} globals for the buffer usage  
reporting, the worker's buffer usage was not included, leading to an  
incorrect buffer usage report.  
  
To fix the problem, this commit makes vacuum use pgBufferUsage  
instruments for buffer usage reporting instead of VacuumPage{Hit,  
Miss, Dirty} globals. These global variables are still used by ANALYZE  
command and autoanalyze.  
  
This also fixes the buffer usage report of vacuuming on temporary  
tables, since the buffers dirtied by MarkLocalBufferDirty() were not  
tracked by the VacuumPageDirty variable.  
  
Parallel vacuum was introduced in 13, but the buffer usage reporting  
for VACUUM command with the VERBOSE option was implemented in  
15. So backpatch to 15.  
  
Reported-by: Anthonin Bonnefoy  
Author: Anthonin Bonnefoy  
Reviewed-by: Alena Rybakina, Masahiko Sawada  
Discussion: https://postgr.es/m/CAO6_XqrQk+QZQcYs_C6nk0cMfHuUWk85vT9CrcA1NffFbAVE2A@mail.gmail.com  
Backpatch-through: 15  

commit   : 68d358545037c51723a7ff0ab96f489e066a6fdd    
  
author   : David Rowley <[email protected]>    
date     : Wed, 1 May 2024 13:21:50 +1200    
  
committer: David Rowley <[email protected]>    
date     : Wed, 1 May 2024 13:21:50 +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   : 92685c389d5416f87553bfb80205d79d5670a695    
  
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   : b19255ca66f74fe9f8d0372db7d644d0bb4d6ac9    
  
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   : 3752e3d210287787a881ae3c68da019aa86f414e    
  
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   : 52f44615cecf0c0038d79374423d4b5042f0a07c    
  
author   : John Naylor <[email protected]>    
date     : Sat, 27 Apr 2024 11:38:41 +0700    
  
committer: John Naylor <[email protected]>    
date     : Sat, 27 Apr 2024 11:38:41 +0700    

In the wake of commits dac048f71 and ecaf7c5df, `make headerscheck`  
no longer generated all headers that are included by other headers,  
causing headerscheck/cpluspluscheck to fail. To fix, backpatch enough  
makefile rules from 721856ff2 to generate all required headers.  
  
Reported by Marina Polyakova  
Backpatch to version 16 only, as the issue is not present on master  
  
Discussion: https://postgr.es/m/231ea1127719b2b3d6d1c05f75808981%40postgrespro.ru  

commit   : 2209c70c652e57314961a25725266821721415b8    
  
author   : Andres Freund <[email protected]>    
date     : Thu, 25 Apr 2024 07:51:33 -0700    
  
committer: Andres Freund <[email protected]>    
date     : Thu, 25 Apr 2024 07:51:33 -0700    

In e6927270cd1 I added a 'touch meson.build' to configure.ac, to ensure  
conflicts between in-tree configure based builds and meson builds are  
automatically detected. Unfortunately I omitted spaces around the condition  
restricting this to in-tree builds, leading to touch meson.build to also be  
executed in vpath builds. While the only consequence of this buglet is an  
unnecessary empty file in build directories, it seems worth backpatching.  
  
Reported-by: Christoph Berg <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  
Backpatch: 16-, where the meson based build was added  

commit   : a9155efc7004a49b387f061dd90cb0b59a6d146f    
  
author   : Amit Kapila <[email protected]>    
date     : Thu, 25 Apr 2024 10:52:34 +0530    
  
committer: Amit Kapila <[email protected]>    
date     : Thu, 25 Apr 2024 10:52:34 +0530    

We missed performing table sync if the invalidation happened while the  
non-ready tables list was being prepared. This occurs because the sync  
state was set to valid at the end of non-ready table list preparation  
irrespective of the invalidations processed while the list is being  
prepared.  
  
Fix it by changing the boolean variable to a tri-state enum and by setting  
table state to valid only if no invalidations have occurred while the list  
is being prepared.  
  
Reprted-by: Alexander Lakhin  
Diagnosed-by: Alexander Lakhin  
Author: Vignesh C  
Reviewed-by: Hou Zhijie, Alexander Lakhin, Ajin Cherian, Amit Kapila  
Backpatch-through: 15  
Discussion: https://postgr.es/m/[email protected]  

commit   : cd0678a9bbdbaea524b2937a5c16b6d486290741    
  
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   : a7ed15f3ab8160d627e8281bd62a048a4fca371f    
  
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   : 9e6faeb3249d420a22ad8a5fbcf093b272c02cb8    
  
author   : Tomas Vondra <[email protected]>    
date     : Sun, 21 Apr 2024 21:21:55 +0200    
  
committer: Tomas Vondra <[email protected]>    
date     : Sun, 21 Apr 2024 21:21:55 +0200    

When specifying the createdb strategy, the documentation suggests valid  
options are FILE_COPY and WAL_LOG, but the code does case-sensitive  
comparison and accepts only "file_copy" and "wal_log" as valid.  
  
Fixed by doing a case-insensitive comparison using pg_strcasecmp(), same  
as for other string parameters nearby.  
  
While at it, apply fmtId() to a nearby "locale_provider". This already  
did the comparison in case-insensitive way, but the value would not be  
double-quoted, confusing the parser and the error message.  
  
Backpatch to 15, where the strategy was introduced.  
  
Backpatch-through: 15  
Reviewed-by: Tom Lane  
Discussion: https://postgr.es/m/[email protected]  

commit   : 75929b6cfaff143c28b3ba6bb8801dc67aab4a9b    
  
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   : 877a64869996b702bb9cd5b39ebbc45febcd081a    
  
author   : Tomas Vondra <[email protected]>    
date     : Sat, 20 Apr 2024 18:54:09 +0200    
  
committer: Tomas Vondra <[email protected]>    
date     : Sat, 20 Apr 2024 18:54:09 +0200    

Commit 9c08aea6a309 introduced -S/--strategy option, but forgot to  
rename the parameter when copying the -T/--template bit.  

commit   : 0d8931c12aa91a080252957f0e2351b62c4daeda    
  
author   : David Rowley <[email protected]>    
date     : Sat, 20 Apr 2024 13:54:24 +1200    
  
committer: David Rowley <[email protected]>    
date     : Sat, 20 Apr 2024 13:54:24 +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   : e5745fd65d7d0e26afeeac400c1fbef0bc7a3760    
  
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   : dd3fddc8519a7d18cc02045d8996ead09f63be66    
  
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   : 0018f0af5a51f9af5d7d3f1c17a38620f9ec8a18    
  
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   : 392e6e9e6adab1af013b16158dc3aec0dc3739d0    
  
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   : 91800af1371029f75e8e34d55e9b412706eec182    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 16 Apr 2024 11:03:43 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 16 Apr 2024 11:03:43 -0400    

When building a join clause derived from an EquivalenceClass, if the  
clause is to be used with an appendrel child relation then make sure  
its clause_relids include the relids of that child relation.  
Normally this would be true already because the EquivalenceMember  
would be a Var of that relation.  However, if the appendrel represents  
a flattened UNION ALL construct then some child EquivalenceMembers  
could be constants with no relids.  The resulting under-marked clause  
is problematic because it could mislead join_clause_is_movable_into  
about where the clause should be evaluated.  We do not have an example  
showing incorrect plan generation, but there are existing cases in  
the regression tests that will fail the Asserts this patch adds to  
get_baserel_parampathinfo.  A similarly wrong conclusion about a  
clause being considered by get_joinrel_parampathinfo would lead to  
wrong placement of the clause.  (This also squares with the way  
that clause_relids is calculated for non-equijoin clauses in  
adjust_appendrel_attrs.)  
  
The other reason for wanting these new Asserts is that the previous  
blithe assumption that the results of generate_join_implied_equalities  
"necessarily satisfy join_clause_is_movable_into" turns out to be  
wrong pre-v16.  If it's still wrong it'd be good to find out.  
  
Per bug #18429 from Benoît Ryder.  The bug as filed was fixed by  
commit 2489d76c4, but these changes correlate with the fix we  
will need to apply in pre-v16 branches.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 7c93f31dee5ff740b1367db472e69cdd290d8de2    
  
author   : Michael Paquier <[email protected]>    
date     : Tue, 16 Apr 2024 12:25:48 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Tue, 16 Apr 2024 12:25:48 +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   : cc1eb6a3cccdf656df29bf5dd585a4a7068fb814    
  
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   : 8cea358b128fea93c8360c9521dcf954775a38ca    
  
author   : Tomas Vondra <[email protected]>    
date     : Sun, 14 Apr 2024 18:19:52 +0200    
  
committer: Tomas Vondra <[email protected]>    
date     : Sun, 14 Apr 2024 18:19:52 +0200    

Commit 6bcda4a721 replaced PG_DETOAST_DATUM with PG_DETOAST_DATUM_PACKED  
in two BRIN output functions, for minmax-multi and bloom opclasses. But  
this is incorrect - the code is accessing the data through structs that  
already include a 4B header, so the detoast needs to match that. But the  
PACKED macro may keep the 1B header, which means the struct fields will  
point to incorrect data.  
  
Backpatch-through: 16  
Discussion: https://postgr.es/m/1df00a66-db5a-4e66-809a-99b386a06d86%40enterprisedb.com  

commit   : ccd8f0fa1e541e6b59ac2727509cafa6367e5886    
  
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   : 4e62ba21a921b77df2da4bf1f4c1545da5da44e7    
  
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   : e9b905325c1360f3270cd68a8ba9ae0f01b0517e    
  
author   : Noah Misch <[email protected]>    
date     : Sat, 13 Apr 2024 07:56:14 -0700    
  
committer: Noah Misch <[email protected]>    
date     : Sat, 13 Apr 2024 07:56:14 -0700    

This corrects doc commit 21912e3c0262e2cfe64856e028799d6927862563.  
Back-patch to v16, like that one.  
  
Reviewed by David G. Johnston.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : e177da5c87a10abac97c028bfb427bafb7353aa2    
  
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   : 3ceb2f96d2d1e2a2e9b884c86c705419e80f39ec    
  
author   : Peter Eisentraut <[email protected]>    
date     : Thu, 11 Apr 2024 12:44:54 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Thu, 11 Apr 2024 12:44:54 +0200    

The test for pstat was removed from configure by 9db300ce6e3 but not  
from meson.build.  Do that now.  

commit   : e79ceafe93a85820188e835adb392d38331ceed2    
  
author   : Etsuro Fujita <[email protected]>    
date     : Thu, 11 Apr 2024 19:05:00 +0900    
  
committer: Etsuro Fujita <[email protected]>    
date     : Thu, 11 Apr 2024 19:05:00 +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   : 574c7c754666a2b5634efd700d3602629d261362    
  
author   : Michael Paquier <[email protected]>    
date     : Thu, 11 Apr 2024 17:19:35 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Thu, 11 Apr 2024 17:19:35 +0900    

Two variables storing a slot's effective_xmin and effective_catalog_xmin  
were saved as XLogRecPtr, which is incorrect as these should be  
TransactionIds.  
  
Oversight in 818fefd8fd44.  
  
Author: Bharath Rupireddy  
Discussion: https://postgr.es/m/CALj2ACVPSB74mrDTFezz-LV3Oi6F3SN71QA0oUHvndzi5dwTNg@mail.gmail.com  
Backpatch-through: 16  

commit   : 48f216dc634bcda522c92de7de61036fdc26847f    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 10 Apr 2024 15:45:58 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 10 Apr 2024 15:45:58 -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   : f6dcddf3e851c00e877c5b4302a54e49e2775c44    
  
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   : bf1cfe77ed49a4929695ba6c0367f784f2f6a10c    
  
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   : db4a0280d3671f0f88836e4f6987e333303fc771    
  
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   : a85e3ba1c9482dd04bec11588a5169a3430939af    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 8 Apr 2024 17:00:07 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 8 Apr 2024 17:00:07 -0400    

After a query cancel, the tail end of ExecQueryAndProcessResults  
took care to clear any not-yet-read PGresults; but it forgot about  
the one it has already read.  There would only be such a result  
when handling a multi-command string made with "\;", so that you'd  
have to cancel an earlier command in such a string to reach the  
bug at all.  Even then, there would only be leakage of a single  
PGresult per cancel, so it's not surprising nobody noticed this.  
But a leak is a leak.  
  
Noted while re-reviewing 90f517821, but this is independent of that:  
it dates to 7844c9918.  Back-patch to v15 where that came in.  

commit   : 974374dcd394c80f37e20b692b7d8b122aa8ed33    
  
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   : a690920015bddc9c20f93d1a828c53ac3c21e489    
  
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   : dfe402f955be8e7676e4da86517b8cdf75a072a2    
  
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   : 854dd250ee178aca201e73923c99aac09b25ea9c    
  
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   : 118558e6d46b512d2ba04d7fc799c5750305ce71    
  
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   : f6f61a4bd9cc8d771c3b33feeee5cfc039c5e05d    
  
author   : Etsuro Fujita <[email protected]>    
date     : Thu, 4 Apr 2024 17:25:00 +0900    
  
committer: Etsuro Fujita <[email protected]>    
date     : Thu, 4 Apr 2024 17:25:00 +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   : bafad43c37bf531f392e65ba726c253040b608f2    
  
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   : cbfbb14bd7de9e90fb107cdcaa783264bf8fcdb9    
  
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   : 3235a11c128b5979bce84d56b8044c7fb2e6b61d    
  
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   : 14e4e8f8c66b2d4316ecb1276e688d67c25659c2    
  
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   : ca4c60e05f81c57b4d72da867173fc524c76aa71    
  
author   : Bruce Momjian <[email protected]>    
date     : Wed, 27 Mar 2024 17:58:10 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Wed, 27 Mar 2024 17:58:10 -0400    

This wording typo was added in PG 16.  
  
Reported-by: [email protected]  
  
Discussion: https://postgr.es/m/[email protected]  
  
Backpatch-through: 16  

commit   : a94f51a7bfc9e65ce3799d8cb12945bd596c5ba8    
  
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   : f5d0e866404a249d3a87a016e3ec562ab2dc6706    
  
author   : David Rowley <[email protected]>    
date     : Thu, 28 Mar 2024 00:14:17 +1300    
  
committer: David Rowley <[email protected]>    
date     : Thu, 28 Mar 2024 00:14:17 +1300    

Buildfarm member avocet has shown a plan change by switching the  
finalize aggregate stage to use a GroupAggregate rather than a  
HashAggregate.  This is consistent with autovacuum having triggered on  
the table, per analysis by Alexander Lakhin.  
  
Fix this by disabling autovacuum on the table.  
  
Reported-by: Alexander Lakhin  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 16, where this test was added.  

commit   : 7445f092814dbb8ac3061524fc341a209f805d80    
  
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   : 7651fd387697a8872d0e11ba2fcecfaf6cbaa39f    
  
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   : 408209d6a9ae90a822edd48ce3c173b8b7e04ab7    
  
author   : Andres Freund <[email protected]>    
date     : Mon, 25 Mar 2024 19:58:10 -0700    
  
committer: Andres Freund <[email protected]>    
date     : Mon, 25 Mar 2024 19:58:10 -0700    

Since 82a4edabd27 we can bulk extend relations. The bulk relation extension  
logic has a heuristic component. Normally the heurstic does not trigger in the  
occasionally-failing test case, as the relation is only extended once. But  
with very small shared_buffers the limits for the number of buffers pinned at  
once prevent the extension from happening at once. With the second "bulk"  
extension, the heuristic kicks in, and the relation ends up one block bigger.  
That's ok from a correctness perspective, but changes the results of the test  
query due to one additional block.  
  
We discussed a few more expansive fixes, but for now have decided to avoid  
this by making the table a bit smaller.  
  
Author: Heikki Linnakangas <[email protected]>  
Reported-by:  
Discussion: https://postgr.es/m/[email protected]  
Discussion: https://postgr.es/m/[email protected]  
Backpatch: 16-, where the new relation extension logic was added  

commit   : 90677b52126af98d40676cd379b56b52e1428188    
  
author   : Andres Freund <[email protected]>    
date     : Mon, 25 Mar 2024 13:06:58 -0700    
  
committer: Andres Freund <[email protected]>    
date     : Mon, 25 Mar 2024 13:06:58 -0700    

The CI base image used to have a python3 with headers etc installed in PATH,  
but doesn't anymore. Instead of relying on a specific version in the base  
image, explicitly install one ourselves.  
  
On 16 and HEAD this lead to a build without python support, but on 15 CI  
failed, due to explicitly enabled python3 support.  

commit   : 022068ea2c60fd0b1ec9b9be5d1cc680b640335c    
  
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   : d82dc79ba03c783fa41be768c1bf13cb8200a340    
  
author   : Nathan Bossart <[email protected]>    
date     : Sun, 24 Mar 2024 15:24:09 -0500    
  
committer: Nathan Bossart <[email protected]>    
date     : Sun, 24 Mar 2024 15:24:09 -0500    

Since commit 3d14e171e9, SET ROLE has required the current session  
user to have membership with the SET option in the target role, but  
the SET ROLE documentation only mentions the membership  
requirement.  This commit adds this important detail to the SET  
ROLE page.  
  
Reviewed-by: Robert Haas  
Discussion: https://postgr.es/m/CA%2BRLCQysHtME0znk2KUMJN343ksboSRQSU-hCnOjesX6VK300Q%40mail.gmail.com  
Backpatch-through: 16  

commit   : 3676b846b129b975034927cdf5f57297211d6f15    
  
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   : a6ddb8ad0ad0947bf86e8cd99c87b156f0956228    
  
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   : 14e991db89b1e0fd39e8875b80da7f0b0c3533a4    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 22 Mar 2024 17:13:53 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 22 Mar 2024 17:13:53 -0400    

Up to now, all of the "catcache list" objects within a catalog cache  
were just chained together on a single dlist, requiring O(N) time to  
search.  Remarkably, we've not had serious performance problems with  
that so far; but we got a complaint of a bad performance regression  
from v15 in a case with a large number of roles in the system, which  
traced down to O(N^2) total time when we probed N catcache lists.  
  
Replace that data structure with a hashtable having an enlargeable  
number of dlists, in an exactly parallel way to the data structure  
we've used for years for the plain CatCTup cache members.  The extra  
cost of maintaining a hash table seems negligible, since we were  
already computing a hash value for list searches.  
  
Normally this'd be HEAD-only material, but in view of the performance  
regression it seems advisable to back-patch into v16.  In the v16  
version of the patch, leave the dead cc_lists field where it is and  
add the new fields at the end of struct catcache, to avoid possible  
ABI breakage in case any external code is looking at these structs.  
(We assume no external code is actually allocating new catcache  
structs.)  
  
Per report from alex work.  
  
Discussion: https://postgr.es/m/CAGvXd3OSMbJQwOSc-Tq-Ro1CAz=vggErdSG7pv2s6vmmTOLJSg@mail.gmail.com  

commit   : 5863bacb87c1e6cd1a322c9c4a5a861b27768379    
  
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   : e6c4e01bf4405ea779ec0b942d7eaa81e18423e1    
  
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   : 1f4eb734200a2420f45d0204d95b65ddf707888c    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Mon, 18 Mar 2024 14:04:13 +0200    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Mon, 18 Mar 2024 14:04:13 +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   : 34c854b93fbec6d7b6dce4ee48c5b7459364a124    
  
author   : Dean Rasheed <[email protected]>    
date     : Sun, 17 Mar 2024 10:19:31 +0000    
  
committer: Dean Rasheed <[email protected]>    
date     : Sun, 17 Mar 2024 10:19:31 +0000    

Given a subplan in a MERGE query, EXPLAIN would sometimes fail to  
properly display expressions involving Params referencing variables in  
other parts of the plan tree.  
  
This would affect subplans outside the topmost join plan node, for  
which expansion of Params would go via the top-level ModifyTable plan  
node.  The problem was that "inner_tlist" for the ModifyTable node's  
deparse_namespace was set to the join node's targetlist, but  
"inner_plan" was set to the ModifyTable node itself, rather than the  
join node, leading to incorrect results when descending to the  
referenced variable.  
  
Fix and backpatch to v15, where MERGE was introduced.  
  
Discussion: https://postgr.es/m/CAEZATCWAv-sZuH%2BwG5xJ-%2BGt7qGNGX8wUQd3XYydMFDKgRB9nw%40mail.gmail.com  

commit   : 56432629999736b5cdd6fa8e56545d8ac5da281f    
  
author   : Daniel Gustafsson <[email protected]>    
date     : Fri, 15 Mar 2024 17:02:07 +0100    
  
committer: Daniel Gustafsson <[email protected]>    
date     : Fri, 15 Mar 2024 17:02:07 +0100    

Commit c855872074b introduced a new parameter to pg_regress to set  
the directory where to look for expected files, but accidentally  
only implemented it for when compiling pg_regress for ECPG tests.  
Fix by adding support for the parameter to the main regression test  
compilation of pg_regress as well.  
  
Backpatch to v16 where --expecteddir was introduced.  
  
Author: Anthonin Bonnefoy <[email protected]>  
Discussion: https://postgr.es/m/CAO6_Xqq5yKJHcJsq__LPcKwSY0XHRqVERNWGxx5ttNXXj7+W=A@mail.gmail.com  
Backpatch-through: 16  

commit   : 4e1ff2aadefbfbf798a4d318514ac85b2fbdc5aa    
  
author   : David Rowley <[email protected]>    
date     : Fri, 15 Mar 2024 11:55:50 +1300    
  
committer: David Rowley <[email protected]>    
date     : Fri, 15 Mar 2024 11:55:50 +1300    

Similar to d8a295389, trim off any PathKeys which are for ORDER BY /  
DISTINCT aggregate functions from the PathKey List for the Gather Merge  
paths created by gather_grouping_paths().  These additional PathKeys are  
not valid to use after grouping has taken place as these PathKeys belong  
to columns which are inputs to an aggregate function and, therefore are  
unavailable after aggregation.  
  
Reported-by: Alexander Lakhin  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 16, where 1349d2790 was added  

commit   : 52898c63e724cd6e18728b4bc0f8d9ec49f12b14    
  
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   : d4c573d8e81ed28ee335e9cb2115098b99d38e71    
  
author   : Dean Rasheed <[email protected]>    
date     : Wed, 13 Mar 2024 13:15:07 +0000    
  
committer: Dean Rasheed <[email protected]>    
date     : Wed, 13 Mar 2024 13:15:07 +0000    

In the synopsis, make the syntax for merge_update consistent with the  
syntax for a plain UPDATE command. It was missing the optional "ROW"  
keyword that can be used in a multi-column assignment, and the option  
to assign from a multi-column subquery, both of which have been  
supported by MERGE since it was introduced.  
  
In the parameters section for the with_query parameter, mention that  
WITH RECURSIVE isn't supported, since this is different from plain  
INSERT, UPDATE, and DELETE commands. While at it, move that entry to  
the top of the list, for consistency with the other pages.  
  
Back-patch to v15, where MERGE was introduced.  
  
Discussion: https://postgr.es/m/CAEZATCWoQyWkMFfu7JXXQr8dA6%3DgxjhYzgpuBP2oz0QoJTxGWw%40mail.gmail.com  

commit   : 9158e4b9eb9916fa586feb26a6149b59566b78e1    
  
author   : Andres Freund <[email protected]>    
date     : Wed, 13 Mar 2024 01:40:48 -0700    
  
committer: Andres Freund <[email protected]>    
date     : Wed, 13 Mar 2024 01:40:48 -0700    

Starting with the Sonoma toolchain macos' linker emits warnings when the same  
library is linked to twice. That's ill considered, as the same library can be  
used by multiple subsidiary libraries. Luckily there's a flag to suppress that  
warning.  
  
On Ventura meson's default of -Wl,-undefined,dynamic_lookup caused warnings,  
which we suppressed with -Wl,-undefined,error. Unfortunately that causes a  
warning on Sonoma, which is absurd, as it's documented linker default. To  
avoid that warning, only add -Wl,-undefined,error if it does not trigger  
warnings. Luckily dynamic_lookup doesn't trigger a warning on Sonoma anymore.  
  
Discussion: https://postgr.es/m/[email protected]  
Backpatch: 16-, where the meson build was added  

commit   : 40d1bdeb72b2d7dfa9e0d91785f0a056b719ebb1    
  
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   : 539e328b1c3a4047c7ff525524edbcca2bac6e10    
  
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   : 0d795a14df1c55c2f4bf70c120e0406ca1649994    
  
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   : 407cb6c6589fa2b757c9f2724278ae101749d9f7    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Mon, 11 Mar 2024 09:28:09 +0200    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Mon, 11 Mar 2024 09:28:09 +0200    

It's important for 'all_visible_according_to_vm' to correctly reflect  
whether the VM bit is set or not, even when we are not trusting the VM  
to skip pages, because contrary to what the comment said,  
lazy_scan_prune() relies on it.  
  
If it's incorrectly set to 'false', when the VM bit is in fact set,  
lazy_scan_prune() will try to set the VM bit again and dirty the page  
unnecessarily. As a result, if you used DISABLE_PAGE_SKIPPING, all  
heap pages were dirtied, even if there were no changes. We would also  
fail to clear any VM bits that were set incorrectly.  
  
This was broken in commit 980ae17310, so backpatch to v16.  
  
Backpatch-through: 16  
Reviewed-by: Melanie Plageman, Peter Geoghegan  
Discussion: https://www.postgresql.org/message-id/[email protected]  

commit   : 348233cb128d32fd3a61f4473eda9564efdcd29c    
  
author   : David Rowley <[email protected]>    
date     : Mon, 11 Mar 2024 18:20:39 +1300    
  
committer: David Rowley <[email protected]>    
date     : Mon, 11 Mar 2024 18:20:39 +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   : 7607671826dd3050b2656700cf1a9cc99a73a4df    
  
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   : 6a9e2cb2b457d962bc3952931a05ad7d5b5be252    
  
author   : David Rowley <[email protected]>    
date     : Mon, 11 Mar 2024 12:27:46 +1300    
  
committer: David Rowley <[email protected]>    
date     : Mon, 11 Mar 2024 12:27:46 +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   : 6a2c80e955a83e8683f1f4d1ef583250bc4b9631    
  
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   : dd73d10adf0048d2d8dc4e94cd64ce5e5ff45a4b    
  
author   : Dean Rasheed <[email protected]>    
date     : Thu, 7 Mar 2024 09:55:39 +0000    
  
committer: Dean Rasheed <[email protected]>    
date     : Thu, 7 Mar 2024 09:55:39 +0000    

When an UPDATE or DELETE action in MERGE returns TM_SelfModified,  
there are 2 possible causes:  
  
1). The target tuple was already updated or deleted by the current  
    command. This can happen if the target row joins to more than one  
    source row, and the SQL standard explicitly says that this must be  
    an error.  
  
2). The target tuple was already updated or deleted by a later command  
    in the current transaction. This can happen if the tuple is  
    modified by a BEFORE trigger or a volatile function used in the  
    query, and should be an error for the same reason that it is in a  
    plain UPDATE or DELETE command.  
  
In MERGE's primary error handling block, it failed to check for (2),  
causing it to return a misleading error message in such cases.  
  
In the secondary error handling block, following a concurrent update  
from another session, it failed to check for (1), causing it to  
silently ignore target rows joined to more than one source row,  
instead of reporting an error.  
  
Fix this, and add tests for both of these cases.  
  
Per report from Wenjiang Zhang. Back-patch to v15, where MERGE was  
introduced.  
  
Discussion: https://postgr.es/m/tencent_41DE0FF443FE14B94A5898D373792109E408%40qq.com  

commit   : c46817ee512afa156561cce2dd6dc8440fe98d55    
  
author   : Michael Paquier <[email protected]>    
date     : Thu, 7 Mar 2024 08:31:00 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Thu, 7 Mar 2024 08:31:00 +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   : 1b3029be5df0b0c9abd72fad13283d6d5f4c6a9f    
  
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   : 4ec8f7708b6b4c494bd0ccd937fc28d34a872b49    
  
author   : Michael Paquier <[email protected]>    
date     : Wed, 6 Mar 2024 17:24:05 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Wed, 6 Mar 2024 17:24:05 +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   : 8870c54d8a17da3e2f7597acf2922f0fb8eadfa5    
  
author   : Jeff Davis <[email protected]>    
date     : Tue, 5 Mar 2024 09:25:04 -0800    
  
committer: Jeff Davis <[email protected]>    
date     : Tue, 5 Mar 2024 09:25:04 -0800    

Commit 19d8e2308b changed when the HOT update optimization is possible  
but neglected to update the Heap-Only Tuples (HOT) documentation.  This  
patch updates that documentation accordingly.  
  
Author: Elizabeth Christensen  
Backpatch-through: 16  
Reviewed-By: Stephen Frost, Alvaro Herrera  
Discussion: https://postgr.es/m/CABoUFXRjisr58Ct_3VsFEdQx+fJeQTWTdJnM7XAp=8MUbtoa9A@mail.gmail.com  

commit   : ac7e6a01c7171447ab54270a07d27e89ac3646a3    
  
author   : David Rowley <[email protected]>    
date     : Tue, 5 Mar 2024 16:17:53 +1300    
  
committer: David Rowley <[email protected]>    
date     : Tue, 5 Mar 2024 16:17:53 +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   : b78f4d22b2f21a3efd1cb8969c9e8fa1f52466c5    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 4 Mar 2024 12:00:39 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 4 Mar 2024 12:00:39 -0500    

The backend treats GUC names case-insensitively, so this code should  
too.  This avoids ending up with a confusing set of redundant entries  
in the generated postgresql.conf file.  
  
Per report from Kyotaro Horiguchi.  Back-patch to v16 where this  
feature was added (in commit 3e51b278d).  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 896bd6da8e2bfcf912cd8c2d4f07e4656b3f8155    
  
author   : Daniel Gustafsson <[email protected]>    
date     : Mon, 4 Mar 2024 10:52:19 +0100    
  
committer: Daniel Gustafsson <[email protected]>    
date     : Mon, 4 Mar 2024 10:52:19 +0100    

The datatype for analyze_sampling had accidentally been set to text  
and not string.  Backpatch to v16 where analyze_sampling first was  
introduced.  
  
Author: Shinya Kato <[email protected]>  
Reviewed-by: Laurenz Albe <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: v16  

commit   : a30a305584b81fd25eb890337ebec53acfbdc96b    
  
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   : 17db5436efb063fc43d0f539bc2f1d0f46fda3d8    
  
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   : c4bd6ff57c9a7b188cbd93855755f1029d7a5662    
  
author   : Alvaro Herrera <[email protected]>    
date     : Mon, 26 Feb 2024 18:19:03 +0100    
  
committer: Alvaro Herrera <[email protected]>    
date     : Mon, 26 Feb 2024 18:19:03 +0100    

Add a note about the additional privileges required after the fix in  
4989ce72644b (wording per Tom Lane); also change marked-up mentions of  
"target_table_name" to be simply "the target table" or the like.  Also,  
note that "join_condition" is scouted for requisite privileges.  
  
Backpatch to 15.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 22cecaddf7c8a88d7de7abb7985f5a4c1b5e0284    
  
author   : Amit Kapila <[email protected]>    
date     : Mon, 26 Feb 2024 09:33:57 +0530    
  
committer: Amit Kapila <[email protected]>    
date     : Mon, 26 Feb 2024 09:33:57 +0530    

This commit fixes the intermittent buildfarm failures in 031_column_list.  
I missed to back-patch while committing b6df0798a5 in the HEAD.  
  
Diagnosed-by: Amit Kapila  
Author: Vignesh C  
Backpatch-through: 15  
Discussion: https://postgr.es/m/[email protected]  

commit   : 8c785d354c6139467516ae2592338c99d0788f47    
  
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   : b3b3effca60f11a6d95207f328c9462894b27924    
  
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   : ef0333e6763349b0553dad296cd88a82207d1348    
  
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   : a6155c43cc82af2816af563704c9dcb78b09a779    
  
author   : Peter Eisentraut <[email protected]>    
date     : Fri, 23 Feb 2024 14:40:25 +0100    
  
committer: Peter Eisentraut <[email protected]>    
date     : Fri, 23 Feb 2024 14:40:25 +0100    

Fix for c9f57541d97: Feature F302-02 was renamed to F305, but that  
commit failed to delete the old line.  
  
Reported-by: Satoru Koizumi (小泉 悟) <[email protected]>  
Discussion: https://www.postgresql.org/message-id/flat/170866661469.645.14101429540172934386%40wrigleys.postgresql.org  

commit   : a3f5d2056ceba95d94607be3138fa52499a957e6    
  
author   : Alvaro Herrera <[email protected]>    
date     : Wed, 21 Feb 2024 17:18:52 +0100    
  
committer: Alvaro Herrera <[email protected]>    
date     : Wed, 21 Feb 2024 17:18:52 +0100    

Verify that a user running MERGE with a DO NOTHING clause has  
privileges to read the table, even if no columns are referenced.  Such  
privileges were already required if the ON clause or any of the WHEN  
conditions referenced any column at all, so there's no functional change  
in practice.  
  
This change fixes an assertion failure in the case where no column is  
referenced by the command and the WHEN clauses are all DO NOTHING.  
  
Backpatch to 15, where MERGE was introduced.  
  
Reported-by: Alena Rybakina <[email protected]>  
Reported-by: Alexander Lakhin <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  

commit   : 21d521ded33fdc9901cba7e8ecb3e03003007845    
  
author   : Daniel Gustafsson <[email protected]>    
date     : Wed, 21 Feb 2024 09:22:18 +0100    
  
committer: Daniel Gustafsson <[email protected]>    
date     : Wed, 21 Feb 2024 09:22:18 +0100    

Commit a2c84990bea7 accidentally used the link for pg_hba_file_rules  
when linking to pg_ident_file_mappings.  Backpatch to v16 where this  
was introduced.  
  
Author: Erik Wienhold <[email protected]>  
Discussion: https://postgr.es/m/qt5hvgvfi4qzlgml2dfssaut2t2x5nwf7b5l63fklr7fpxwm6g@hle3mtglpm4y  
Backpatch-through: v16  

commit   : 3ad319b8cad497d0a130fe92a372e9177f9f7ee8    
  
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   : 5ad6c7218e1cef1a9098594e62df0d5e233be372    
  
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   : 59cea09f03a56a40bce70a7461226c4d45740d02    
  
author   : Michael Paquier <[email protected]>    
date     : Tue, 20 Feb 2024 13:43:56 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Tue, 20 Feb 2024 13:43:56 +0900    

The invalidation of an active slot is done in two steps:  
- Termination of the backend holding it, if any.  
- Report that the slot is obsolete, with a conflict cause depending on  
the slot's data.  
  
This can be racy because between these two steps the slot mutex would be  
released while doing system calls, which means that the effective_xmin  
and effective_catalog_xmin could advance during that time, detecting a  
conflict cause different than the one originally wanted before the  
process owning a slot is terminated.  
  
Holding the mutex longer is not an option, so this commit changes the  
code to record the LSNs stored in the slot during the termination of the  
process owning the slot.  
  
Bonus thanks to Alexander Lakhin for the various tests and the analysis.  
  
Author: Bertrand Drouvot  
Reviewed-by: Michael Paquier, Bharath Rupireddy  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 16  

commit   : ec4fcf4a9292378a6a586c7533ef970edf083831    
  
author   : Michael Paquier <[email protected]>    
date     : Tue, 20 Feb 2024 11:59:10 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Tue, 20 Feb 2024 11:59:10 +0900    

This inconsistency has been introduced in efb6f4a4f9b6.  
  
Reported-by: Julien Rouhaud  
Author: Bertrand Drouvot  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 16  

commit   : fb95cc72bfe7a31efa8a711b8094a0c41ffad291    
  
author   : David Rowley <[email protected]>    
date     : Tue, 20 Feb 2024 12:50:09 +1300    
  
committer: David Rowley <[email protected]>    
date     : Tue, 20 Feb 2024 12:50:09 +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   : c59a97313ba34aeb4b1670307c0228fb94694adb    
  
author   : Noah Misch <[email protected]>    
date     : Mon, 19 Feb 2024 12:52:28 -0800    
  
committer: Noah Misch <[email protected]>    
date     : Mon, 19 Feb 2024 12:52:28 -0800    

Before the previous commit, the test could hang until  
LOG_SNAPSHOT_INTERVAL_MS (15s), until checkpoint_timeout (300s), or  
indefinitely.  An indefinite hang was awfully improbable.  It entailed  
the test reaching checkpoint_timeout before the  
DecodingContextFindStartpoint() of a CREATE SUBSCRIPTION, yet after the  
preceding WAL record.  Back-patch to v16, which introduced the test.  
  
Bertrand Drouvot, reported by Noah Misch.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : f024746484b966f916e6d8e1d0bd39de51aad2e1    
  
author   : Noah Misch <[email protected]>    
date     : Mon, 19 Feb 2024 12:52:07 -0800    
  
committer: Noah Misch <[email protected]>    
date     : Mon, 19 Feb 2024 12:52:07 -0800    

One IPC::Run::start() used an IPC::Run::timer() without checking for  
expiration.  The other used no timeout or timer.  Back-patch to v16,  
which introduced the test.  
  
Reviewed by Bertrand Drouvot.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 6257ebf1e335b0ca73a460aa9774e3c782506cee    
  
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   : 88e03d055d18c5f54f81589d13edc76945f0875c    
  
author   : Michael Paquier <[email protected]>    
date     : Mon, 19 Feb 2024 11:38:44 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Mon, 19 Feb 2024 11:38:44 +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   : 2c7f2eb0c8aa8b2163cc41c1666c71de4267f80c    
  
author   : Peter Eisentraut <[email protected]>    
date     : Fri, 16 Feb 2024 11:39:09 +0100    
  
committer: Peter Eisentraut <[email protected]>    
date     : Fri, 16 Feb 2024 11:39:09 +0100    

The file was removed by ac25173cdbc.  
  
Author: Jelte Fennema-Nio <[email protected]>  
Discussion: https://www.postgresql.org/message-id/flat/CAGECzQQGzbroAXi%2BYicp3HvcCo4%3Dg84kaOgjuvQ5MW9F0ubOGg%40mail.gmail.com  

commit   : 1a6dcfecab9f63a54f29056a51f15ade66095fb1    
  
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   : aafa4513fd31268202ac41a64792c9e0335b9e66    
  
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   : f2f09b825ca5925b1613bb351e7fd3e6f435c8c1    
  
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   : f15d01cb5dbdc44276f82178759586023896a3b7    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 13 Feb 2024 12:18:25 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 13 Feb 2024 12:18:25 -0500    

For a long time, our outfuncs.c code has supposed that the string  
contents of a BitString node could just be printed literally with  
no concern for quoting/escaping.  Now, that's okay if the string  
literal contains only valid binary or hex digits ... but our lexer  
doesn't check that, preferring to let bitin() be the sole authority  
on what's valid.  So we could have raw parse trees that contain  
incorrect BitString literals, and that can result in failures when  
WRITE_READ_PARSE_PLAN_TREES debugging is enabled.  
  
Fix by using outToken() to print the string field, and debackslash()  
to read it.  This results in a change in the emitted representation  
only in cases that would have failed before, and don't represent valid  
SQL in the first place.  Between that and the fact that we don't store  
raw parse trees in the catalogs, I judge this safe to apply without a  
catversion bump.  
  
Per bug #18340 from Alexander Lakhin.  Back-patch to v16; before that,  
we lacked readfuncs support for BitString nodes, so that the problem  
was only cosmetic.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 103235888d9e74755ec4c7a72d640d4c7fabc596    
  
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   : 0460e4ecc0fa532468331a4b71ad0fbe8ff1a416    
  
author   : Thomas Munro <[email protected]>    
date     : Mon, 12 Feb 2024 10:47:57 +1300    
  
committer: Thomas Munro <[email protected]>    
date     : Mon, 12 Feb 2024 10:47:57 +1300    

Commit 5579388d removed code that supplied a fallback implementation of  
getaddrinfo(), which was dead code on modern systems.  One tiny piece of  
the removed code was still doing something useful on Windows, though:  
that OS's own gai_strerror()/gai_strerrorA() function returns a pointer  
to a static buffer that it overwrites each time, so it's not  
thread-safe.  In rare circumstances, a multi-threaded client program  
could get an incorrect or corrupted error message.  
  
Restore the replacement gai_strerror() function, though now that it's  
only for Windows we can put it into a win32-specific file and cut it  
down to the errors that Windows documents.  The error messages here are  
taken from FreeBSD, because Windows' own messages seemed too verbose.  
  
Back-patch to 16.  
  
Reviewed-by: Kyotaro Horiguchi <[email protected]>  
Discussion: https://postgr.es/m/CA%2BhUKGKz%2BF9d2PTiXwfYV7qJw%2BWg2jzACgSDgPizUw7UG%3Di58A%40mail.gmail.com  

commit   : 4eb261165d1294f590c7c279a8825e73abe57ecd    
  
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   : 52afe563206e753f4c45c014fee2459ad0855826    
  
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   : 9440d23a018cab5e78cb4aa11e8a5c558dd0bb36    
  
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   : e3e05addee42c643867557a3065debb085f1d169    
  
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  

commit   : 86d2b434c9a3520a10db4feae236b74452d3d157    
  
author   : Peter Eisentraut <[email protected]>    
date     : Fri, 9 Feb 2024 07:57:31 +0100    
  
committer: Peter Eisentraut <[email protected]>    
date     : Fri, 9 Feb 2024 07:57:31 +0100    

Fix for 344d62fb9a9: That commit introduced unlogged sequences and  
made it so that identity/serial sequences automatically get the  
persistence level of their owning table.  But this works only for  
CREATE TABLE and not for ALTER TABLE / ADD COLUMN.  The latter would  
always create the sequence as logged (default), independent of the  
persistence setting of the table.  This is fixed here.  
  
Note: It is allowed to change the persistence of identity sequences  
directly using ALTER SEQUENCE.  So mistakes in existing databases can  
be fixed manually.  
  
Reviewed-by: Ashutosh Bapat <[email protected]>  
Discussion: https://www.postgresql.org/message-id/flat/c4b6e2ed-bcdf-4ea7-965f-e49761094827%40eisentraut.org  

commit   : e13205a5e4ad0fb75110a25f81654511303566f8    
  
author   : Daniel Gustafsson <[email protected]>    
date     : Thu, 8 Feb 2024 12:19:34 +0100    
  
committer: Daniel Gustafsson <[email protected]>    
date     : Thu, 8 Feb 2024 12:19:34 +0100    

Commit 9c08aea6a30 accidentally added one too many end brackets  
in the synopsis for CREATE DATABASE .. strategy = strat. Fix by  
removing. Backpatch to v15 where it was introduced.  
  
Reported-by: [email protected]  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: v15  

commit   : 5c699c857cac84a81eebb869ba3f8b539d66f620    
  
author   : Peter Eisentraut <[email protected]>    
date     : Thu, 8 Feb 2024 10:18:50 +0100    
  
committer: Peter Eisentraut <[email protected]>    
date     : Thu, 8 Feb 2024 10:18:50 +0100    

The documentation output format htmlhelp is no longer supported, but a  
comment still mentioned it.  

commit   : 17f3196599303abbfc605f5ea5c5e314ce856e38    
  
author   : Alvaro Herrera <[email protected]>    
date     : Wed, 7 Feb 2024 19:25:07 +0100    
  
committer: Alvaro Herrera <[email protected]>    
date     : Wed, 7 Feb 2024 19:25:07 +0100    

Cover scram_iterations, which was added in commit b577743000cd.  While  
at it, turn the list into a <simplelist> with 2 columns, which is much  
nicer to read.  
  
In master, remove mentions of antediluvian versions before which some  
parameters were not reported.  
  
Noticed while investigating a question by Maiquel Grassi.  
  
Backpatch to 16.  
  
Reviewed-by: Daniel Gustafsson <[email protected]>  
Reviewed-by: Jelte Fennema-Nio <[email protected]>  
Discussion: https://postgr.es/m/[email protected]