PostgreSQL 13.12 commit log

commit   : c9d50b21a72d2bbc092ea9d7de4d4c044d8f8275    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 7 Aug 2023 16:11:34 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 7 Aug 2023 16:11:34 -0400    

commit   : 5d81700859adc9462b9663789f4491611c3d11b8    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 7 Aug 2023 12:50:15 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 7 Aug 2023 12:50:15 -0400    

Security: CVE-2023-39417, CVE-2023-39418  

commit   : b1b585e0fc3dd195bc2e338c80760bede08de5f1    
  
author   : Noah Misch <[email protected]>    
date     : Mon, 7 Aug 2023 06:05:56 -0700    
  
committer: Noah Misch <[email protected]>    
date     : Mon, 7 Aug 2023 06:05:56 -0700    

Substituting such values in extension scripts facilitated SQL injection  
when @extowner@, @extschema@, or @extschema:...@ appeared inside a  
quoting construct (dollar quoting, '', or "").  No bundled extension was  
vulnerable.  Vulnerable uses do appear in a documentation example and in  
non-bundled extensions.  Hence, the attack prerequisite was an  
administrator having installed files of a vulnerable, trusted,  
non-bundled extension.  Subject to that prerequisite, this enabled an  
attacker having database-level CREATE privilege to execute arbitrary  
code as the bootstrap superuser.  By blocking this attack in the core  
server, there's no need to modify individual extensions.  Back-patch to  
v11 (all supported versions).  
  
Reported by Micah Gate, Valerie Woolard, Tim Carey-Smith, and Christoph  
Berg.  
  
Security: CVE-2023-39417  

commit   : 2f89d0c97d25fdb7920a5709267f996ef47fcebd    
  
author   : Peter Eisentraut <[email protected]>    
date     : Mon, 7 Aug 2023 12:30:06 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Mon, 7 Aug 2023 12:30:06 +0200    

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

commit   : 466b0d393e48360753889a379cd885c5feae26cc    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 5 Aug 2023 16:47:04 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 5 Aug 2023 16:47:04 -0400    

commit   : cc20236d15b373839657af3a33c8c52ac694f25c    
  
author   : Etsuro Fujita <[email protected]>    
date     : Thu, 3 Aug 2023 17:45:06 +0900    
  
committer: Etsuro Fujita <[email protected]>    
date     : Thu, 3 Aug 2023 17:45:06 +0900    

Commit f49842d1e added a new callback for custom scan paths, but missed  
updating the documentation.  
  
Back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/CAPmGK15ODkN%2B%3DhkBCufj1HBW0x5OTb65Xuy7ryXchMdiCMpx_g%40mail.gmail.com  

commit   : 4eb8b9c28256f9470c846452ec3d2e082626e136    
  
author   : Etsuro Fujita <[email protected]>    
date     : Thu, 3 Aug 2023 17:15:06 +0900    
  
committer: Etsuro Fujita <[email protected]>    
date     : Thu, 3 Aug 2023 17:15:06 +0900    

Commit e7cb7ee14 allowed custom scan providers to create CustomPath  
paths for join relations as well, but missed updating the comments.  
  
Back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/CAPmGK15ODkN%2B%3DhkBCufj1HBW0x5OTb65Xuy7ryXchMdiCMpx_g%40mail.gmail.com  

commit   : 74a5bf1b676f75f67f63e57db7e97edd8a1e923f    
  
author   : David Rowley <[email protected]>    
date     : Wed, 2 Aug 2023 01:41:55 +1200    
  
committer: David Rowley <[email protected]>    
date     : Wed, 2 Aug 2023 01:41:55 +1200    

This was failing for queries which try to get the .type() of a  
jpiLikeRegex.  For example:  
  
select jsonb_path_query('["string", "string"]',  
                        '($[0] like_regex ".{7}").type()');  
  
Reported-by: Alexander Kozhemyakin  
Bug: #18035  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 12, where SQL/JSON path was added.  

commit   : 730f983effa51f578e85db27a5b4b906725ecd7a    
  
author   : Etsuro Fujita <[email protected]>    
date     : Fri, 28 Jul 2023 15:45:06 +0900    
  
committer: Etsuro Fujita <[email protected]>    
date     : Fri, 28 Jul 2023 15:45:06 +0900    

Commit e7cb7ee14, which introduced the infrastructure for FDWs and  
custom scan providers to replace joins with scans, failed to add support  
handling of pseudoconstant quals assigned to replaced joins in  
createplan.c, leading to an incorrect plan without a gating Result node  
when postgres_fdw replaced a join with such a qual.  
  
To fix, we could add the support by 1) modifying the ForeignPath and  
CustomPath structs to store the list of RestrictInfo nodes to apply to  
the join, as in JoinPaths, if they represent foreign and custom scans  
replacing a join with a scan, and by 2) modifying create_scan_plan() in  
createplan.c to use that list in that case, instead of the  
baserestrictinfo list, to get pseudoconstant quals assigned to the join;  
but #1 would cause an ABI break.  So fix by modifying the infrastructure  
to just disallow replacing joins with such quals.  
  
Back-patch to all supported branches.  
  
Reported by Nishant Sharma.  Patch by me, reviewed by Nishant Sharma and  
Richard Guo.  
  
Discussion: https://postgr.es/m/CADrsxdbcN1vejBaf8a%2BQhrZY5PXL-04mCd4GDu6qm6FigDZd6Q%40mail.gmail.com  

commit   : 288b4288c3db3af24404cf6d4c1d9d5a9c9c1922    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 27 Jul 2023 12:07:48 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 27 Jul 2023 12:07:48 -0400    

Historically, hba.c limited tokens in the authentication configuration  
files (pg_hba.conf and pg_ident.conf) to less than 256 bytes.  We have  
seen a few reports of this limit causing problems; notably, for  
moderately-complex LDAP configurations.  Increase the limit to 10240  
bytes as a low-risk stop-gap solution.  
  
In v13 and earlier, this also requires raising MAX_LINE, the limit  
on overall line length.  I'm hesitant to make this code consume  
too much stack space, so I only raised that to 20480 bytes.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 291c0254025bb67ceedeaca8531f1b14b8aaeeff    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 20 Jul 2023 14:23:46 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 20 Jul 2023 14:23:46 -0400    

If both the passed-in plan pointer and plansource->gplan are  
NULL, CachedPlanIsSimplyValid would think that the plan pointer  
is possibly-valid and try to dereference it.  For the one extant  
call site in plpgsql, this situation doesn't normally happen  
which is why we've not noticed. However, it appears to be possible  
if the previous use of the cached plan failed, as per report from  
Justin Pryzby.  Add an extra check to prevent crashing.  
Back-patch to v13 where this code was added.  
  
Discussion: https://postgr.es/m/ZLlV+STFz1l/[email protected]  

commit   : 27e945944bdb55de0e5362a2a89848fec5cfb45f    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 19 Jul 2023 11:00:34 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 19 Jul 2023 11:00:34 -0400    

IN and NOT IN work fine on records and arrays, so just say that  
they accept "expressions" not "scalar expressions".  I think that  
that phrasing was meant to say that they don't work on set-returning  
expressions, but that's not the common meaning of "scalar".  
  
Revise the description of row-constructor comparisons to make it  
perhaps a bit less confusing.  (This partially reverts some  
dubious wording changes made by commit f56651519.)  
  
Per gripe from Ilya Nenashev.  Back-patch to supported branches.  
In HEAD and v16, also drop a NOTE about pre-8.2 behavior, which  
is hopefully no longer of interest to anybody.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : dc2d9efcb47eaff04f9c0213ed60a9b5eb8aa129    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 18 Jul 2023 11:59:39 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 18 Jul 2023 11:59:39 -0400    

The "count" argument of SPI_exec() only limits execution when  
the query is actually returning rows.  This was not the case  
before PG 9.0, so this example was correct when written; but  
we missed updating it in commit 2ddc600f8.  Extend the example  
to show the behavior both with and without RETURNING.  
  
While here, improve the commentary and markup for the rest  
of the example.  
  
David G. Johnston and Tom Lane, per report from Curt Kolovson.  
Back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/CANhYJV6HWtgz_qjx_APfK0PAgLUzY-2vjLuj7i_o=TZF1LAQew@mail.gmail.com  

commit   : b3ca4f0a5cdb1f1d1191e71e7d65f62ac1fe05ff    
  
author   : Michael Paquier <[email protected]>    
date     : Tue, 18 Jul 2023 14:04:51 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Tue, 18 Jul 2023 14:04:51 +0900    

This has been missed in cb0cca1, noticed before buildfarm member koel  
has been able to complain while poking at a different patch.  Like the  
other commit, backpatch all the way down to limit the odds of merge  
conflicts.  
  
Backpatch-through: 11  

commit   : db59108a2b6703bd359f01dc84665308c9d7ee73    
  
author   : Michael Paquier <[email protected]>    
date     : Tue, 18 Jul 2023 13:44:33 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Tue, 18 Jul 2023 13:44:33 +0900    

A crash in the middle of a checkpoint with some two-phase state data  
already flushed to disk by this checkpoint could cause a follow-up crash  
recovery to recover twice the same transaction, once from what has been  
found in pg_twophase/ at the beginning of recovery and a second time  
when replaying its corresponding record.  
  
This would lead to FATAL failures in the startup process during  
recovery, where the same transaction would have a state recovered twice  
instead of once:  
LOG:  recovering prepared transaction 731 from shared memory  
LOG:  recovering prepared transaction 731 from shared memory  
FATAL:  lock ExclusiveLock on object 731/0/0 is already held  
  
This issue is fixed by skipping the addition of any 2PC state coming  
from a record whose equivalent 2PC state file has already been loaded in  
TwoPhaseState at the beginning of recovery by restoreTwoPhaseData(),  
which is OK as long as the system has not reached a consistent state.  
  
The timing to get a messed up recovery processing is very racy, and  
would very unlikely happen.  The thread that has reported the issue has  
demonstrated the bug using injection points to force a PANIC in the  
middle of a checkpoint.  
  
Issue introduced in 728bd99, so backpatch all the way down.  
  
Reported-by: "suyu.cmj" <[email protected]>  
Author: "suyu.cmj" <[email protected]>  
Author: Michael Paquier  
Discussion: https://postgr.es/m/109e6994-b971-48cb-84f6-829646f18b4c.mengjuan.cmj@alibaba-inc.com  
Backpatch-through: 11  

commit   : bdaaf1bf1d90d8c510f18f81edbe90e54262c9df    
  
author   : Michael Paquier <[email protected]>    
date     : Fri, 14 Jul 2023 11:16:10 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Fri, 14 Jul 2023 11:16:10 +0900    

RelationReloadIndexInfo() is a fast-path used for index reloads in the  
relation cache, and it has always forgotten about updating  
indisreplident, which is something that would happen after an index is  
selected for a replica identity.  This can lead to incorrect cache  
information provided when executing a command in a transaction context  
that updates indisreplident.  
  
None of the code paths currently on HEAD that need to check upon  
pg_index.indisreplident fetch its value from the relation cache, always  
relying on a fresh copy on the syscache.  Unfortunately, this may not be  
the case of out-of-core code, that could see out-of-date value.  
  
Author: Shruthi Gowda  
Reviewed-by: Robert Haas, Dilip Kumar, Michael Paquier  
Discussion: https://postgr.es/m/CAASxf_PBcxax0wW-3gErUyftZ0XrCs3Lrpuhq4-Z3Fak1DoW7Q@mail.gmail.com  
Backpatch-through: 11  

commit   : c89d74c18b508a865849a422d5ac1df1299ac898    
  
author   : Michael Paquier <[email protected]>    
date     : Fri, 14 Jul 2023 10:13:20 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Fri, 14 Jul 2023 10:13:20 +0900    

indisvalid is switched to true for partitioned indexes when all its  
partitions have valid indexes when attaching a new partition, up to the  
top-most parent if all its leaves are themselves valid when dealing with  
multiple layers of partitions.  
  
The copy of the tuple from pg_index used to switch indisvalid to true  
came from the relation cache, which is incorrect.  Particularly, in the  
case reported by Shruthi Gowda, executing a series of commands in a  
single transaction would cause the validation of partitioned indexes to  
use an incorrect version of a pg_index tuple, as indexes are reloaded  
after an invalidation request with RelationReloadIndexInfo(), a much  
faster version than a full index cache rebuild.  In this case, the  
limited information updated in the cache leads to an incorrect version  
of the tuple used.  One of the symptoms reported was the following  
error, with a replica identity update, for instance:  
"ERROR: attempted to update invisible tuple"  
  
This is incorrect since 8b08f7d, so backpatch all the way down.  
  
Reported-by: Shruthi Gowda  
Author: Michael Paquier  
Reviewed-by: Shruthi Gowda, Dilip Kumar  
Discussion: https://postgr.es/m/CAASxf_PBcxax0wW-3gErUyftZ0XrCs3Lrpuhq4-Z3Fak1DoW7Q@mail.gmail.com  
Backpatch-through: 11  

commit   : 81ce000067e3c7d5f08adb615806453567ee142f    
  
author   : Andres Freund <[email protected]>    
date     : Thu, 13 Jul 2023 13:03:34 -0700    
  
committer: Andres Freund <[email protected]>    
date     : Thu, 13 Jul 2023 13:03:34 -0700    

Until now, when DROP DATABASE got interrupted in the wrong moment, the removal  
of the pg_database row would also roll back, even though some irreversible  
steps have already been taken. E.g. DropDatabaseBuffers() might have thrown  
out dirty buffers, or files could have been unlinked. But we continued to  
allow connections to such a corrupted database.  
  
To fix this, mark databases invalid with an in-place update, just before  
starting to perform irreversible steps. As we can't add a new column in the  
back branches, we use pg_database.datconnlimit = -2 for this purpose.  
  
An invalid database cannot be connected to anymore, but can still be  
dropped.  
  
Unfortunately we can't easily add output to psql's \l to indicate that some  
database is invalid, it doesn't fit in any of the existing columns.  
  
Add tests verifying that a interrupted DROP DATABASE is handled correctly in  
the backend and in various tools.  
  
Reported-by: Evgeny Morozov <[email protected]>  
Author: Andres Freund <[email protected]>  
Reviewed-by: Daniel Gustafsson <[email protected]>  
Reviewed-by: Thomas Munro <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  
Discussion: https://postgr.es/m/[email protected]  
Backpatch: 11-, bug present in all supported versions  

commit   : 53336e8f6675c30e35e85f87993d9df0db7e1cb0    
  
author   : Andres Freund <[email protected]>    
date     : Thu, 13 Jul 2023 13:03:34 -0700    
  
committer: Andres Freund <[email protected]>    
date     : Thu, 13 Jul 2023 13:03:34 -0700    

When vac_truncate_clog() encounters bogus datfrozenxid / datminmxid values, it  
returns early. Unfortunately, until now, it did not release  
WrapLimitsVacuumLock. If the backend later tries to acquire  
WrapLimitsVacuumLock, the session / autovacuum worker hangs in an  
uncancellable way. Similarly, other sessions will hang waiting for the  
lock. However, if the backend holding the lock exited or errored out for some  
reason, the lock was released.  
  
The bug was introduced as a side effect of 566372b3d643.  
  
It is interesting that there are no production reports of this problem. That  
is likely due to a mix of bugs leading to bogus values having gotten less  
common, process exit releasing locks and instances of hangs being hard to  
debug for "normal" users.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 7fffcc2ee9104787f8968c573ac4a5e19ddaf907    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 13 Jul 2023 13:07:51 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 13 Jul 2023 13:07:51 -0400    

GiST compress functions (like all GiST opclass functions) are  
supposed to be called in short-lived memory contexts, so that  
minor memory leaks in them are not of concern, and indeed  
explicit pfree's are likely slightly counterproductive.  
But this one in g_intbig_compress() is more than  
slightly counterproductive, because it's guarded by  
"if (in != DatumGetArrayTypeP(entry->key))" which means  
that if this test succeeds, we've detoasted the datum twice.  
(And to add insult to injury, the extra detoast result is  
leaked.)  Let's just drop the whole stanza, relying on the  
GiST temporary context mechanism to clean up in good time.  
  
The analogous bit in g_int_compress() is  
       if (r != (ArrayType *) DatumGetPointer(entry->key))  
           pfree(r);  
which doesn't have the gratuitous-detoast problem so  
I left it alone.  Perhaps there is a case for removing  
unnecessary pfree's more widely, but I'm not sure if it's  
worth the code churn.  
  
The potential extra decompress seems expensive enough to  
justify calling this a (minor) performance bug and  
back-patching.  
  
Konstantin Knizhnik, Matthias van de Meent, Tom Lane  
  
Discussion: https://postgr.es/m/CAEze2Wi86=DxErfvf+SCB2UKmU2amKOF60BKuJOX=w-RojRn0A@mail.gmail.com  

commit   : 6b51fe8340bb7e31e4c87a112923aa1ffb7636e7    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 10 Jul 2023 12:14:34 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 10 Jul 2023 12:14:34 -0400    

Since PostgresMain calls sigsetjmp, any local variables that are not  
marked "volatile" have a risk of unspecified behavior.  In practice  
this means that when control returns via longjmp, such variables might  
get reset to their values as of the time of sigsetjmp, depending on  
whether the compiler chose to put them in registers or on the stack.  
We were careful about this for "send_ready_for_query", but not the  
other local variables.  
  
In the case of the timeout_enabled flags, resetting them to  
their initial "false" states is actually good, since we do  
"disable_all_timeouts()" in the longjmp cleanup code path.  If that  
does not happen, we risk uselessly calling "disable_timeout()" later,  
which is harmless but a little bit expensive.  Let's explicitly reset  
these flags so that the behavior is correct and platform-independent.  
(This change means that we really don't need the new "volatile"  
markings after all, but let's install them anyway since any change  
in this logic could re-introduce a problem.)  
  
There is no issue for "firstchar" and "input_message" because those  
are explicitly reinitialized each time through the query processing  
loop.  To make that clearer, move them to be declared inside the loop.  
That leaves us with all the function-lifespan locals except the  
sigjmp_buf itself marked as volatile, which seems like a good policy  
to have going forward.  
  
Because of the possibility of extra disable_timeout() calls, this  
seems worth back-patching.  
  
Sergey Shinderuk and Tom Lane  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : f5b075adcf4c20c82a45096d1d9c6a51ca415481    
  
author   : Michael Paquier <[email protected]>    
date     : Mon, 10 Jul 2023 09:40:17 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Mon, 10 Jul 2023 09:40:17 +0900    

As coded, the code would use as a base comparison the namespace OID from  
the first object scanned in pg_depend when switching its namespace  
dependency entry to the new one, and use it as a base of comparison for  
any follow-up checks.  It would also be used as the old namespace OID to  
switch *from* for the extension's pg_depend entry.  Hence, if the first  
object scanned has a namespace different than the one stored in the  
extension, we would finish by:  
- Not checking that the extension objects map with the extension's  
schema.  
- Not switching the extension -> namespace dependency entry to the new  
namespace provided by the user, making ALTER EXTENSION ineffective.  
  
This issue exists since this command has been introduced in d9572c4 for  
relocatable extension, so backpatch all the way down to 11.  The test  
case has been provided by Heikki, that I have tweaked a bit to show the  
effects on pg_depend for the extension.  
  
Reported-by: Heikki Linnakangas  
Author: Michael Paquier, Heikki Linnakangas  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 11  

commit   : 09391ddc9578f1526baeb8590b1b48b9249cef8b    
  
author   : Andres Freund <[email protected]>    
date     : Thu, 6 Jul 2023 08:34:17 -0700    
  
committer: Andres Freund <[email protected]>    
date     : Thu, 6 Jul 2023 08:34:17 -0700    

Also add comment to make the reasoning behind the Assert() more explicit (per  
Tom).  
  
Reported-by: Ranier Vilela  
Discussion: https://postgr.es/m/CAEudQAocXNJ6s1VLz+hMamLAQAiewRoW17OJ6-+9GACKfj6iPQ@mail.gmail.com  
Backpatch: 11-  

commit   : 9ebe6fdc5c684c21a44aeaf98837c54d7415ca2a    
  
author   : Andrew Dunstan <[email protected]>    
date     : Thu, 6 Jul 2023 12:27:40 -0400    
  
committer: Andrew Dunstan <[email protected]>    
date     : Thu, 6 Jul 2023 12:27:40 -0400    

On Windows, it's sometimes difficult to create a file with a path longer  
than 255 chars, and if it can be created it might not be seen by the  
archiver. This can be triggered by the test for tar backups with  
filenames greater than 100 bytes. So we skip that test if the path would  
exceed 255.  
  
Backpatch to all live branches.  
  
Reviewed by Daniel Gustafsson  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : c50b869edad40455efc9a7287c45648d7a2715b2    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Thu, 6 Jul 2023 17:25:29 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Thu, 6 Jul 2023 17:25:29 +0300    

We create a file, so we better WAL-log it. In practice, all the  
built-in index AMs and all extensions that I'm aware of write a  
metapage to the init fork, which is WAL-logged, and replay of the  
metapage implicitly creates the fork too. But if ambuildempty() didn't  
write any page, we would miss it.  
  
This can be seen with dummy_index_am. Set up replication, create a  
'dummy_index_am' index on an unlogged table, and look at the files  
created in the replica: the init fork is not created on the  
replica. Dummy_index_am doesn't do anything with the relation files,  
however, so it doesn't lead to any user-visible errors.  
  
Backpatch to all supported versions.  
  
Reviewed-by: Robert Haas  
Discussion: https://www.postgresql.org/message-id/6e5bbc08-cdfc-b2b3-9e23-1a914b9850a9%40iki.fi  

commit   : 34f6c606356887d6f5090c92fe7247cbf7946ef0    
  
author   : Amit Kapila <[email protected]>    
date     : Thu, 6 Jul 2023 08:05:27 +0530    
  
committer: Amit Kapila <[email protected]>    
date     : Thu, 6 Jul 2023 08:05:27 +0530    

This commit reverts the work done by commits 3ba59ccc89 and 72e78d831a.  
Those commits were incorrect in asserting that we never acquire any other  
heavy-weight lock after acquring page lock other than relation extension  
lock. We can acquire a lock on catalogs while doing catalog look up after  
acquring page lock.  
  
This won't impact any existing feature but we need to think some other way  
to achieve this before parallelizing other write operations or even  
improving the parallelism in vacuum (like allowing multiple workers  
for an index).  
  
Reported-by: Jaime Casanova  
Author: Amit Kapila  
Backpatch-through: 13  
Discussion: https://postgr.es/m/CAJKUy5jffnRKNvRHKQ0LynRb0RJC-o4P8Ku3x9vGAVLwDBWumQ@mail.gmail.com  

commit   : 59c2a6fe9b6518255d99a6bbf9006a98a0aefa6b    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Wed, 5 Jul 2023 13:13:13 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Wed, 5 Jul 2023 13:13:13 +0300    

llvm_release_context() called llvm_enter_fatal_on_oom(), but was missing  
the corresponding llvm_leave_fatal_on_oom() call. As a result, if JIT was  
used at all, we were almost always in the "fatal-on-oom" state.  
  
It only makes a difference if you use an extension written in C++, and  
run out of memory in a C++ 'new' call. In that case, you would get a  
PostgreSQL FATAL error, instead of the default behavior of throwing a  
C++ exception.  
  
Back-patch to all supported versions.  
  
Reviewed-by: Daniel Gustafsson  
Discussion: https://www.postgresql.org/message-id/[email protected]  

commit   : acc8cdff424529ce34e93a7ae51eb410b02c7b30    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Tue, 4 Jul 2023 17:57:03 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Tue, 4 Jul 2023 17:57:03 +0300    

If you create a table and don't insert any data into it, the relation file  
is never fsync'd. You don't lose data, because an empty table doesn't have  
any data to begin with, but if you crash and lose the file, subsequent  
operations on the table will fail with "could not open file" error.  
  
To fix, register an fsync request in mdcreate(), like we do for mdwrite().  
  
Per discussion, we probably should also fsync the containing directory  
after creating a new file. But that's a separate and much wider issue.  
  
Backpatch to all supported versions.  
  
Reviewed-by: Andres Freund, Thomas Munro  
Discussion: https://www.postgresql.org/message-id/d47d8122-415e-425c-d0a2-e0160829702d%40iki.fi  

commit   : 75373ff6c0ef2c517eff57c8b6ea996a4858a0ba    
  
author   : Peter Eisentraut <[email protected]>    
date     : Tue, 4 Jul 2023 11:14:53 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Tue, 4 Jul 2023 11:14:53 +0200    

The Homebrew package manager changed its default installation prefix  
for the new architecture, so a couple of tests need tweaks to find  
binaries.  
  
This is a partial backpatch of dc513bc654.  

commit   : a0003572f214c0e4b40374aefa46c818ad92d999    
  
author   : Thomas Munro <[email protected]>    
date     : Tue, 4 Jul 2023 15:16:34 +1200    
  
committer: Thomas Munro <[email protected]>    
date     : Tue, 4 Jul 2023 15:16:34 +1200    

It's OK to be lazy about re-binning memory segments when allocating,  
because that can only leave segments in a bin that's too high.  We'll  
search higher bins if necessary while allocating next time, and  
also eventually re-bin, so no memory can become unreachable that way.  
  
However, when freeing memory, the largest contiguous range of free pages  
might go up, so we should re-bin eagerly to make sure we don't leave the  
segment in a bin that is too low for get_best_segment() to find.  
  
The re-binning code is moved into a function of its own, so it can be  
called whenever free pages are returned to the segment's free page map.  
  
Back-patch to all supported releases.  
  
Author: Dongming Liu <[email protected]>  
Reviewed-by: Robert Haas <[email protected]> (earlier version)  
Reviewed-by: Thomas Munro <[email protected]>  
Discussion: https://postgr.es/m/CAL1p7e8LzB2LSeAXo2pXCW4%2BRya9s0sJ3G_ReKOU%3DAjSUWjHWQ%40mail.gmail.com  

commit   : fc15473840bcccecb10030ae9a900171d2371027    
  
author   : Thomas Munro <[email protected]>    
date     : Mon, 3 Jul 2023 16:20:01 +1200    
  
committer: Thomas Munro <[email protected]>    
date     : Mon, 3 Jul 2023 16:20:01 +1200    

The ginfast.c code previously checked for conflicts in before locking  
the relevant buffer, leaving a window where a RW conflict could be  
missed.  Re-order.  
  
There was also a place where buffer ID and block number were confused  
while trying to predicate-lock a page, noted by visual inspection.  
  
Back-patch to all supported releases.  Fixes one more problem discovered  
with the reproducer from bug #17949, in this case when Dmitry tried  
other index types.  
  
Reported-by: Artem Anisimov <[email protected]>  
Reported-by: Dmitry Dolgov <[email protected]>  
Reviewed-by: Heikki Linnakangas <[email protected]>  
Discussion: https://postgr.es/m/17949-a0f17035294a55e2%40postgresql.org  

commit   : 8976ac5c5c009e9bac448c20950120b90f286f4f    
  
author   : Thomas Munro <[email protected]>    
date     : Mon, 3 Jul 2023 16:18:20 +1200    
  
committer: Thomas Munro <[email protected]>    
date     : Mon, 3 Jul 2023 16:18:20 +1200    

When performing a bitmap heap scan, we don't want to miss concurrent  
writes that occurred after we observed the heap's rs_nblocks, but before  
we took predicate locks on index pages.  Therefore, we can't skip  
fetching any heap tuples that are referenced by the index, because we  
need to test them all with CheckForSerializableConflictOut().  The  
old optimization that would ignore any references to blocks >=  
rs_nblocks gets in the way of that requirement, because it means that  
concurrent writes in that window are ignored.  
  
Removing that optimization shouldn't affect correctness at any isolation  
level, because any new tuples shouldn't be visible to an MVCC snapshot.  
There also shouldn't be any error-causing references to heap blocks past  
the end, because we should have held at least an AccessShareLock on the  
table before the index scan.  It can't get smaller while our transaction  
is running.  For now, though, we'll keep the optimization at lower  
levels to avoid making unnecessary changes in a bug fix.  
  
Back-patch to all supported releases.  In release 11, the code is in a  
different place but not fundamentally different.  Fixes one aspect of  
bug #17949.  
  
Reported-by: Artem Anisimov <[email protected]>  
Reviewed-by: Dmitry Dolgov <[email protected]>  
Reviewed-by: Heikki Linnakangas <[email protected]>  
Discussion: https://postgr.es/m/17949-a0f17035294a55e2%40postgresql.org  

commit   : 8f705d7b9d01a0b9ab350bca9fc17ded333faca9    
  
author   : Thomas Munro <[email protected]>    
date     : Mon, 3 Jul 2023 16:16:27 +1200    
  
committer: Thomas Munro <[email protected]>    
date     : Mon, 3 Jul 2023 16:16:27 +1200    

When predicate-locking btrees, we have a special case for completely  
empty btrees, since there is no page to lock.  This was racy, because,  
without buffer lock held, a matching key could be inserted between the  
_bt_search() and the PredicateLockRelation() calls.  
  
Fix, by rechecking _bt_search() after taking the relation-level SIREAD  
lock, if using SERIALIZABLE isolation and an empty btree is discovered.  
  
Back-patch to all supported releases.  Fixes one aspect of bug #17949.  
  
Reported-by: Artem Anisimov <[email protected]>  
Reviewed-by: Dmitry Dolgov <[email protected]>  
Reviewed-by: Heikki Linnakangas <[email protected]>  
Discussion: https://postgr.es/m/17949-a0f17035294a55e2%40postgresql.org  

commit   : 753f20c179f7be94a335e9dc67a5d58c6036d119    
  
author   : Andrew Dunstan <[email protected]>    
date     : Mon, 3 Jul 2023 10:53:16 -0400    
  
committer: Andrew Dunstan <[email protected]>    
date     : Mon, 3 Jul 2023 10:53:16 -0400    

Version 13 and older are missing the required infrastructure.  

commit   : 162c75dc2dff337f7f5ca34ed8ce602e5774791d    
  
author   : Andrew Dunstan <[email protected]>    
date     : Mon, 3 Jul 2023 10:46:49 -0400    
  
committer: Andrew Dunstan <[email protected]>    
date     : Mon, 3 Jul 2023 10:46:49 -0400    

Commit 83ed4de20f inadvertently used the new package names. In version  
14 or older, use TestLib intead of using PostgreSQL::Test::Utils  

commit   : d7a186c775834d4bf07c84a6c3de16ba94c82afa    
  
author   : Andrew Dunstan <[email protected]>    
date     : Mon, 3 Jul 2023 10:06:26 -0400    
  
committer: Andrew Dunstan <[email protected]>    
date     : Mon, 3 Jul 2023 10:06:26 -0400    

Creation of a file with a very long name can create problems on Windows  
due to its file path limits. Work around that by creating the file via a  
symlink with a shorter name.  
  
Error displayed by buildfarm animal fairywren.o  
  
Backpatch to all live branches  

commit   : b102e80ab82203e5e65e902c28cdab491d1468b0    
  
author   : Michael Paquier <[email protected]>    
date     : Mon, 3 Jul 2023 10:06:18 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Mon, 3 Jul 2023 10:06:18 +0900    

When set, this environment variable was only effective for data  
directories but not for all the other temporary files created by  
PostgreSQL::Test::Utils.  Keeping the temporary files after a successful  
run can be useful for debugging purposes.  
  
The documentation is updated to reflect the new behavior, with contents  
available in doc/ since v16 and in src/test/perl/README since v15.  
  
Author: Jacob Champion  
Reviewed-by: Daniel Gustafsson  
Discussion: https://postgr.es/m/CAAWbhmgHtDH1SGZ+Fw05CsXtE0mzTmjbuUxLB9mY9iPKgM6cUw@mail.gmail.com  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 11  

commit   : 984c23f6f5926f7cfb304b8f931e9bb66174b41c    
  
author   : Tomas Vondra <[email protected]>    
date     : Sun, 2 Jul 2023 20:29:01 +0200    
  
committer: Tomas Vondra <[email protected]>    
date     : Sun, 2 Jul 2023 20:29:01 +0200    

Commit f24523672d fixed a memory leak by moving the modifiedCols bitmap  
into the per-row memory context. In the case of AFTER UPDATE triggers,  
the bitmap is however referenced from an event kept until the end of the  
query, resulting in a use-after-free bug.  
  
Fixed by copying the bitmap into the AfterTriggerEvents memory context,  
which is the one where we keep the trigger events. There's only one  
place that needs to do the copy, but the memory context may not exist  
yet. Doing that in a separate function seems more readable.  
  
Report by Alexander Pyhalov, fix by me. Backpatch to 13, where the  
bitmap was added to the event by commit 71d60e2aa0.  
  
Reported-by: Alexander Pyhalov  
Backpatch-through: 13  
Discussion: https://postgr.es/m/[email protected]  

commit   : 3ce761d5cafeb0d63f2cb0e9876ba1578c1333c5    
  
author   : Tomas Vondra <[email protected]>    
date     : Sun, 2 Jul 2023 18:54:09 +0200    
  
committer: Tomas Vondra <[email protected]>    
date     : Sun, 2 Jul 2023 18:54:09 +0200    

The Incremental Sort had a couple issues, resulting in leaking memory  
during rescans, possibly triggering OOM. The code had a couple of  
related flaws:  
  
1. During rescans, the sort states were reset but then also set to NULL  
   (despite the comment saying otherwise). ExecIncrementalSort then  
   sees NULL and initializes a new sort state, leaking the memory used  
   by the old one.  
  
2. Initializing the sort state also automatically rebuilt the info about  
   presorted keys, leaking the already initialized info. presorted_keys  
   was also unnecessarily reset to NULL.  
  
Patch by James Coleman, based on patches by Laurenz Albe and Tom Lane.  
Backpatch to 13, where Incremental Sort was introduced.  
  
Author: James Coleman, Laurenz Albe, Tom Lane  
Reported-by: Laurenz Albe, Zu-Ming Jiang  
Backpatch-through: 13  
Discussion: https://postgr.es/m/b2bd02dff61af15e3526293e2771f874cf2a3be7.camel%40cybertec.at  
Discussion: https://postgr.es/m/db03c582-086d-e7cd-d4a1-3bc722f81765%40inf.ethz.ch  

commit   : 537b70b82c2ccc79f7a81a5c662c2816cc8d0a34    
  
author   : Michael Paquier <[email protected]>    
date     : Fri, 30 Jun 2023 13:54:59 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Fri, 30 Jun 2023 13:54:59 +0900    

The logic that introduced partitioned indexes missed a few things when  
invalidating a partitioned index when these are created, still the code  
is written to handle recursions:  
1) If created from scratch because a mapping index could not be found,  
the new index created could be itself invalid, if for example it was a  
partitioned index with one of its leaves invalid.  
2) A CCI was missing when indisvalid is set for a parent index, leading  
to inconsistent trees when recursing across more than one level for a  
partitioned index creation if an invalidation of the parent was  
required.  
  
This could lead to the creation of a partition index tree where some of  
the partitioned indexes are marked as invalid, but some of the parents  
are marked valid, which is not something that should happen (as  
validatePartitionedIndex() defines, indisvalid is switched to true for a  
partitioned index iff all its partitions are themselves valid).  
  
This patch makes sure that indisvalid is set to false on a partitioned  
index if at least one of its partition is invalid.  The flag is set to  
true if *all* its partitions are valid.  
  
The regression test added in this commit abuses of a failed concurrent  
index creation, marked as invalid, that maps with an index created on  
its partitioned table afterwards.  
  
Reported-by: Alexander Lakhin  
Reviewed-by: Alexander Lakhin  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 11  

commit   : d0ab203bc192382053d3782062bef6872bdc0e53    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 29 Jun 2023 10:19:10 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 29 Jun 2023 10:19:10 -0400    

If the given composite datum is toasted out-of-line,  
DatumGetHeapTupleHeader will perform database accesses to detoast it.  
That can invalidate the result of get_cached_rowtype, as documented  
(perhaps not plainly enough) in that function's API spec; which leads  
to strange errors or crashes when we try to use the TupleDesc to read  
the tuple.  In short then, trying to update a field of a composite  
column could fail intermittently if the overall column value is wide  
enough to require toasting.  
  
We can fix the bug at no cost by just changing the order of  
operations, since we don't need the TupleDesc until after detoasting.  
(Other callers of get_cached_rowtype appear to get this right already,  
so there's only one bug.)  
  
Note that the added regression test case reveals this bug reliably  
only with debug_discard_caches/CLOBBER_CACHE_ALWAYS.  
  
Per bug #17994 from Alexander Lakhin.  Sadly, this patch does not fix  
the missing-values issue revealed in the bug discussion; we'll need  
some more work to cover that.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : f42844069755c0a6761fede783b8acb063e880a5    
  
author   : Michael Paquier <[email protected]>    
date     : Wed, 28 Jun 2023 15:57:51 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Wed, 28 Jun 2023 15:57:51 +0900    

A portion of ALTER TABLE .. ATTACH PARTITION is to ensure that the  
partition being attached to the partitioned table has a correct set of  
indexes, so as there is a consistent index mapping between the  
partitioned table and its new-to-be partition.  However, as introduced  
in 8b08f7d, the current logic could choose an invalid index as a match,  
which is something that can exist when dealing with more than two levels  
of partitioning, like attaching a partitioned table (that has  
partitions, with an index created by CREATE INDEX ON ONLY) to another  
partitioned table.  
  
A partitioned index with indisvalid set to false is equivalent to an  
incomplete partition tree, meaning that an invalid partitioned index  
does not have indexes defined in all its partitions.  Hence, choosing an  
invalid partitioned index can create inconsistent partition index trees,  
where the parent attaching to is valid, but its partition may be  
invalid.  
  
In the report from Alexander Lakhin, this showed up as an assertion  
failure when validating an index.  Without assertions enabled, the  
partition index tree would be actually broken, as indisvalid should  
be switched to true for a partitioned index once all its partitions are  
themselves valid.  With two levels of partitioning, the top partitioned  
table used a valid index and was able to link to an invalid index stored  
on its partition, itself a partitioned table.  
  
I have studied a few options here (like the possibility to switch  
indisvalid to false for the parent), but came down to the conclusion  
that we'd better rely on a simple rule: invalid indexes had better never  
be chosen, so as the partition attached uses and creates indexes that  
the parent expects.  Some regression tests are added to provide some  
coverage.  Note that the existing coverage is not impacted.  
  
This is a problem since partitioned indexes exist, so backpatch all the  
way down to v11.  
  
Reported-by: Alexander Lakhin  
Discussion: https://postgr.es/[email protected]  
Backpatch-through: 11  

commit   : b6ab18a990ffd0daa55665e3153bfed9db547fa7    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 24 Jun 2023 17:18:08 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 24 Jun 2023 17:18:08 -0400    

TParserGet() recurses for some token types, meaning it's possible  
to drive it to stack overflow.  Since this is a minority behavior,  
I chose to add the check_stack_depth() call to the two places that  
recurse rather than doing it during every single call.  
  
While at it, add CHECK_FOR_INTERRUPTS(), because this can run  
unpleasantly long for long inputs.  
  
Per bug #17995 from Zuming Jiang.  This is old, so back-patch  
to all supported branches.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 8aa9a26236aa424e99f2c146f7ba3c5c9dcf0b19    
  
author   : Peter Eisentraut <[email protected]>    
date     : Sun, 19 Jul 2020 12:14:42 +0200    
  
committer: Michael Paquier <[email protected]>    
date     : Sun, 19 Jul 2020 12:14:42 +0200    

This avoids deprecation warnings from newer OpenSSL versions (3.0.0 in  
particular).  
  
This has been originally applied as 4d3db13 for v14 and newer versions,  
but not on the older branches out of caution, and this commit closes the  
gap to remove all these deprecation warnings in all the branches still  
supported.  
  
OPENSSL_API_COMPAT's value is set based on the oldest version of OpenSSL  
supported on a branch: 1.0.1 for Postgres 13 and 0.9.8 for Postgres 11  
and 12.  
  
Reviewed-by: Daniel Gustafsson  
Discussion: https://postgr.es/m/[email protected]  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 11  

commit   : f7ee11693b9313bd2d2b373b32942221c14ff544    
  
author   : Bruce Momjian <[email protected]>    
date     : Fri, 23 Jun 2023 22:50:55 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Fri, 23 Jun 2023 22:50:55 -0400    

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

commit   : 19867d5f2d5ff3b9c4d791fd9f8b37292255adb6    
  
author   : Amit Kapila <[email protected]>    
date     : Thu, 22 Jun 2023 12:08:07 +0530    
  
committer: Amit Kapila <[email protected]>    
date     : Thu, 22 Jun 2023 12:08:07 +0530    

By default, triggers and rules do not fire on a logical replication  
subscriber based on the "session_replication_role" GUC being set to  
"replica". However, the docs in the logical replication section assumed  
that the reader understood how this GUC worked. This modifies the docs to  
be more explicit and links back to the GUC itself.  
  
Author: Jonathan Katz, Peter Smith  
Reviewed-by: Vignesh C, Euler Taveira  
Backpatch-through: 11  
Discussion: https://postgr.es/m/[email protected]  

commit   : c909bd87ce09b00c15707c9420a01bfc8facad3f    
  
author   : David Rowley <[email protected]>    
date     : Thu, 22 Jun 2023 12:50:13 +1200    
  
committer: David Rowley <[email protected]>    
date     : Thu, 22 Jun 2023 12:50:13 +1200    

Statistics defined by the CREATE STATISTICS command are only used to  
assist with the selectivity estimations of base relations, never for  
joins.  Here we mention this fact in the notes section of the CREATE  
STATISTICS command.  
  
Discussion: https://postgr.es/m/CAApHDvrMuVgDOrmg_EtFDZ=AOovq6EsJNnHH1ddyZ8EqL4yzMw@mail.gmail.com  
Backpatch-through: 11  

commit   : b6311824f011d3ba03a6c5c1c0bbd7f31e27dbc6    
  
author   : Peter Geoghegan <[email protected]>    
date     : Wed, 21 Jun 2023 17:41:52 -0700    
  
committer: Peter Geoghegan <[email protected]>    
date     : Wed, 21 Jun 2023 17:41:52 -0700    

Avoid "right sibling %u of block %u is not next child" errors when  
vacuuming a corrupt nbtree index.  Just LOG the issue and press on.  
That way VACUUM will have a decent chance of finishing off all required  
processing for the index (and for the table as a whole).  
  
This is similar to recent work from commit 5abff197, as well as work  
from commit 5b861baa (later backpatched as commit 43e409ce), which  
taught nbtree VACUUM to keep going when its "re-find" check fails.  The  
hardening added by this commit takes place directly after the "re-find"  
check, right before the critical section for the first stage of page  
deletion.  
  
Author: Peter Geoghegan <[email protected]>  
Discussion: https://postgr.es/m/CAH2-Wz=dayg0vjs4+er84TS9ami=csdzjpuiCGbEw=idhwqhzQ@mail.gmail.com  
Backpatch: 11- (all supported versions).  

commit   : e966b3d12105d23c6933d89948d066df4fa35069    
  
author   : Bruce Momjian <[email protected]>    
date     : Wed, 21 Jun 2023 19:20:07 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Wed, 21 Jun 2023 19:20:07 -0400    

Reported-by: Pierre <[email protected]>  
  
Discussion: https://postgr.es/m/[email protected]  
  
Backpatch-through: 11  

commit   : d1fc0f382da15d2901bb740d9dfdd6be6488a1e4    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 21 Jun 2023 11:07:11 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 21 Jun 2023 11:07:11 -0400    

exec_parse_message() wants to create a cached plan in all cases,  
including for empty input.  The empty-input path does not have  
a test for being in an aborted transaction, making it possible  
that plancache.c will fail due to trying to do database lookups  
even though there's no real work to do.  
  
One solution would be to throw an aborted-transaction error in  
this path too, but it's not entirely clear whether the lack of  
such an error was intentional or whether some clients might be  
relying on non-error behavior.  Instead, let's hack plancache.c  
so that it treats empty statements with the same logic it  
already had for transaction control commands, ensuring that it  
can soldier through even in an already-aborted transaction.  
  
Per bug #17983 from Alexander Lakhin.  Back-patch to all  
supported branches.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 43090e1e705953d159553c91669a3ee7453ec271    
  
author   : Michael Paquier <[email protected]>    
date     : Wed, 21 Jun 2023 16:16:27 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Wed, 21 Jun 2023 16:16:27 +0900    

This partially reverts 68cb5af, as using archiving to enforce the  
rename of the last partial segment of the old timeline at promotion to  
use .partial as suffix is impacting the tests when it does switchovers.  
As showed by the logs gathered by the CI in the tests that failed, a new  
standby may fail to find the WAL segment it needs to follow a promoted  
instance with its timeline jump, as it got renamed to .partial.  
  
This problem would manifest as a run timeout with 009_twophase.pl, as  
the new standby repeatedly requests a segment from the promoted primary  
that it would not find.  
  
Reported-by: Nathan Bossart  
Discussion: https://postgr.es/m/20230621043345.GA787473@nathanxps13  
Backpatch-through: 13  

commit   : 4b4ee1e2b073ffe719e7ad1bb1c22253fb1096e2    
  
author   : Amit Kapila <[email protected]>    
date     : Wed, 21 Jun 2023 10:07:47 +0530    
  
committer: Amit Kapila <[email protected]>    
date     : Wed, 21 Jun 2023 10:07:47 +0530    

The existing errhint message and docs were missing the fact that we can't  
disassociate from the slot unless the subscription is disabled.  
  
Author: Robert Sjöblom, Peter Smith  
Reviewed-by: Peter Eisentraut, Amit Kapila  
Backpatch-through: 11  
Discussion: https://postgr.es/m/[email protected]  

commit   : 2f97105e93c286a1377ddc0e2c9c7a5af4a2eee3    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 20 Jun 2023 17:47:36 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 20 Jun 2023 17:47:36 -0400    

If the inner-side expressions contain PARAM_EXEC Params, we must  
re-hash whenever the values of those Params change.  The executor  
mechanism for that exists already, but we failed to invoke it because  
finalize_plan() neglected to search the Hash.hashkeys field for  
Params.  This allowed a previous scan's hash table to be re-used  
when it should not be, leading to rows missing from the join's output.  
(I believe incorrectly-included join rows are impossible however,  
since checking the real hashclauses would reject false matches.)  
  
This bug is very ancient, dating probably to d24d75ff1 of 7.4.  
Sadly, this simple fix depends on the plan representational changes  
made by 2abd7ae9b, so it will only work back to v12.  I thought  
about trying to make some kind of hack for v11, but I'm leery  
of putting code significantly different from what is used in the  
newer branches into a nearly-EOL branch.  Seeing that the bug  
escaped detection for a full twenty years, problematic cases  
must be rare; so I don't feel too awful about leaving v11 as-is.  
  
Per bug #17985 from Zuming Jiang.  Back-patch to v12.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : c360594155e5c0704a952d6b26a01bcbe07cd591    
  
author   : Michael Paquier <[email protected]>    
date     : Tue, 20 Jun 2023 10:25:49 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Tue, 20 Jun 2023 10:25:49 +0900    

This is a follow-up of f663b00, that has been committed to v13 and v14,  
tweaking the TAP test for two-phase transactions so as it provides  
coverage for the bug that has been fixed.  This change is done in its  
own commit for clarity, as v15 and HEAD did not show the problematic  
behavior, still missed coverage for it.  
  
While on it, this adds a comment about the dependency of the last  
partial segment rename and RecoverPreparedTransactions() at the end of  
recovery, as that can be easy to miss.  
  
Author: Michael Paquier  
Reviewed-by: Kyotaro Horiguchi  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 13  

commit   : 896012b88396f45ce67bbc3fd15f72245f5239d1    
  
author   : Michael Paquier <[email protected]>    
date     : Tue, 20 Jun 2023 09:36:58 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Tue, 20 Jun 2023 09:36:58 +0900    

When archiving is enabled, a promotion request would fail with the  
following error when some 2PC transaction needs to be recovered from  
WAL, preventing the promotion to complete:  
FATAL:  requested WAL segment pg_wal/000000010000000000000001 has already been removed  
  
The origin of the problem is that the last partial segment of the old  
timeline is renamed before recovering the 2PC data via  
RecoverPreparedTransactions() at the end of recovery, causing the FATAL  
because the segment wanted is now renamed with a .partial suffix.  This  
commit reorders a bit the end-of-recovery actions so as the execution of  
recovery_end_command, the cleanup of the old segments of the old  
timeline (RemoveNonParentXlogFiles) and the last partial segment rename  
are done after the 2PC transaction data is recovered with  
RecoverPreparedTransactions().  This makes the order of these  
end-of-recovery actions more consistent with ~15, at the exception of  
the end-of-recovery checkpoint that still needs to happen before all the  
actions reordered here in v13 and v14, contrary to what 15~ does.  
  
v15 and newer versions have "fixed" this problem somewhat accidentally  
with 811051c, where the end-of-recovery actions got reordered.  In this  
case, the recovery of 2PC transactions happens before the renaming of  
the last partial segment of the old timeline.  
  
v13 and v14 are the versions that can easily see this problem as per the  
refactoring of 38a95731 where XLogReaderState is reset in  
XLogBeginRead() before reading the 2PC transaction data.  v11 and v12  
could also see this problem, but may finish by reading the 2PC data from  
some of the WAL buffers instead.  Perhaps something could be done for  
these two branches, but I am not really excited about doing something on  
these per the lack of complaints and per the fact that v11 is soon going  
to be EOL'd soon (there is always a risk of breaking something).  
  
Note that the TAP test 009_twophase.pl is able to exhibit the issue if  
it enables archiving on the primary node, which does not impact the test  
coverage as restore_command would remain unused.  This is something that  
should be changed on v15 and HEAD as well, so this will be changed in a  
separate commit for clarity.  
  
Author: Julian Markwort  
Reviewed-by: Kyotaro Horiguchi, Michael Paquier  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 13  

commit   : 06286f8a2f0e7980a93f02a876b34be196001daa    
  
author   : David Rowley <[email protected]>    
date     : Mon, 19 Jun 2023 13:02:24 +1200    
  
committer: David Rowley <[email protected]>    
date     : Mon, 19 Jun 2023 13:02:24 +1200    

Here we adjust relation_has_unique_index_for() so that it no longer makes  
use of partial unique indexes as uniqueness proofs.  It is incorrect to  
use these as the predicates used by check_index_predicates() to set  
predOK makes use of not only baserestrictinfo quals as proofs, but also  
qual from join conditions.  For relation_has_unique_index_for()'s case, we  
need to know the relation is unique for a given set of columns before any  
joins are evaluated, so if predOK was only set to true due to some join  
qual, then it's unsafe to use such indexes in  
relation_has_unique_index_for().  The final plan may not even make use  
of that index, which could result in reading tuples that are not as  
unique as the planner previously expected them to be.  
  
Bug: #17975  
Reported-by: Tor Erik Linnerud  
Backpatch-through: 11, all supported versions  
Discussion: https://postgr.es/m/17975-98a90c156f25c952%40postgresql.org  

commit   : d5300bc79dff0ada2132d82d59dfe1703a6e9ed1    
  
author   : Amit Langote <[email protected]>    
date     : Fri, 16 Jun 2023 10:04:22 +0900    
  
committer: Amit Langote <[email protected]>    
date     : Fri, 16 Jun 2023 10:04:22 +0900    

Back-patch down to 11.  
  
Author: Sho Kato (<[email protected]>)  
Discussion: https://postgr.es/m/TYCPR01MB68499042A33BC32241193AAF9F5BA%40TYCPR01MB6849.jpnprd01.prod.outlook.com  

commit   : ae9aac64a38faee824a920efd2c5631175eb30af    
  
author   : Michael Paquier <[email protected]>    
date     : Thu, 15 Jun 2023 13:45:41 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Thu, 15 Jun 2023 13:45:41 +0900    

As gist__int_ops stands in intarray, it is possible to store GiST  
entries for leaf pages that can cause corruptions when decompressed.  
Leaf nodes are stored as decompressed all the time by the compression  
method, and the decompression method should map with that, retrieving  
the contents of the page without doing any decompression.  However, the  
code authorized the insertion of leaf page data with a higher number of  
array items than what can be supported, generating a NOTICE message to  
inform about this matter (199 for a 8k page, for reference).  When  
calling the decompression method, a decompression would be attempted on  
this leaf node item but the contents should be retrieved as they are.  
  
The NOTICE message generated when dealing with the compression of a leaf  
page and too many elements in the input array for gist__int_ops has been  
introduced by 08ee64e, removing the marker stored in the array to track  
if this is actually a leaf node.  However, it also missed the fact that  
the decompression path should do nothing for a leaf page.  Hence, as the  
code stand, a too-large array would be stored as uncompressed but the  
decompression path would attempt a decompression rather that retrieving  
the contents as they are.  
  
This leads to various problems.  First, even if 08ee64e tried to address  
that, it is possible to do out-of-bound chunk writes with a large input  
array, with the backend informing about that with WARNINGs.  On  
decompression, retrieving the stored leaf data would lead to incorrect  
memory reads, leading to crashes or even worse.  
  
Perhaps somebody would be interested in expanding the number of array  
items that can be handled in a leaf page for this operator in the  
future, which would require revisiting the choice done in 08ee64e, but  
based on the lack of reports about this problem since 2005 it does not  
look so.  For now, this commit prevents the insertion of data for leaf  
pages when using more array items that the code can handle on  
decompression, switching the NOTICE message to an ERROR.  If one wishes  
to use more array items, gist__intbig_ops is an optional choice.  
  
While on it, use ERRCODE_PROGRAM_LIMIT_EXCEEDED as error code when a  
limit is reached, because that's what the module is facing in such  
cases.  
  
Author: Ankit Kumar Pandey, Alexander Lakhin  
Reviewed-by: Richard Guo, Michael Paquier  
Discussion: https://postgr.es/m/[email protected]  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 11  

commit   : a36d0014f11fd0687f6adf7451f63550290a1de2    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 13 Jun 2023 15:58:37 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 13 Jun 2023 15:58:37 -0400    

rewriteRuleAction neglected to check for SubLink nodes in the  
securityQuals of range table entries.  This could lead to failing  
to convert such a SubLink to a SubPlan, resulting in assertion  
crashes or weird errors later in planning.  
  
In passing, fix some poor coding in rewriteTargetView:  
we should not pass the source parsetree's hasSubLinks  
field to ReplaceVarsFromTargetList's outer_hasSubLinks.  
ReplaceVarsFromTargetList knows enough to ignore that  
when a Query node is passed, but it's still confusing  
and bad precedent: if we did try to update that flag  
we'd be updating a stale copy of the parsetree.  
  
Per bug #17972 from Alexander Lakhin.  This has been broken since  
we added RangeTblEntry.securityQuals (although the presented test  
case only fails back to 215b43cdc), so back-patch all the way.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 6f23b5f74f5fd86d7bbadc89359b8f2175665400    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 12 Jun 2023 10:54:28 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 12 Jun 2023 10:54:28 -0400    

Commit 927d9abb6 purported to make datetime() accept any string  
that could be output for a datetime value by to_jsonb().  But it  
overlooked the possibility of fractional seconds being present,  
so that cases as simple as to_jsonb(now()) would defeat it.  
  
Fix by adding formats that include ".US" to the list in  
executeDateTimeMethod().  (Note that while this is nominally  
microseconds, it'll do the right thing for fractions with  
fewer than six digits.)  
  
In passing, re-order the list to restore the datatype ordering  
specified in its comment.  The violation accidentally did not  
break anything; but the next edit might be less lucky, so add  
more comments.  
  
Per report from Tim Field.  Back-patch to v13 where datetime()  
was added, like the previous patch.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 78bf0a256d129b517ca6a5fea14586489acea296    
  
author   : Michael Paquier <[email protected]>    
date     : Mon, 12 Jun 2023 09:14:17 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Mon, 12 Jun 2023 09:14:17 +0900    

isspace() can be locale-sensitive depending on the platform, causing  
hstore to consider as whitespaces characters it should not see as such.  
For example, U+0105, being decoded as 0xC4 0x85 in UTF-8, would be  
discarded from the input given.  
  
This problem is similar to 9ae2661, though it was missed that hstore  
can also manipulate non-ASCII inputs, so replace the existing isspace()  
calls with scanner_isspace().  
  
This problem exists for a long time, so backpatch all the way down.  
  
Author: Evan Jones  
Discussion: https://postgr.es/m/CA+HWA9awUW0+RV_gO9r1ABZwGoZxPztcJxPy8vMFSTbTfi4jig@mail.gmail.com  
Backpatch-through: 11  

commit   : 37236ca0694550a5caac5ca382bea19005833ee3    
  
author   : Michael Paquier <[email protected]>    
date     : Sun, 11 Jun 2023 10:33:56 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Sun, 11 Jun 2023 10:33:56 +0900    

This commit fixes an oversight introduced in 10520f4, that has added  
delayChkptEnd to PGPROC to avoid ABI breakages on stable branches, where  
two spots have missed to initialize this variable (delayChkpt was  
switched back from int to bool, and it was initialized as 0 so there was  
no consequences for it):  
- InitProcess(), where the per-process data structures of a backend are  
initialized.  
- InitAuxiliaryProcess(), same but for auxiliary processes.  
  
An interruption during relation truncation while this flag is set could  
cause an assertion failure when a follow-up process does a relation  
truncation while reusing the same PGPROC entry.  A second effect could  
be incorrect checkpoint end delays.  
  
While on it, add an assertion in ProcArrayClearTransaction() for  
delayChkptEnd to be in line with 5788e25.  This is needed only for v14.  
  
This issue affects v11~v14, but not v15~, as we use a single field  
called delayChkptFlags to delay checkpoints there.  
  
Author: suyu.cmj ([email protected])  
Reviewed-by: Kyotaro Horiguchi, Michael Paquier  
Discussion: https://postgr.es/m/9c3d2a49-db5f-43cb-840b-d58f9a684295.mengjuan.cmj@alibaba-inc.com  
Backpatch-through: 11  

commit   : a9231fedae7a840433bb8eacc211b8e2b5f8893e    
  
author   : Michael Paquier <[email protected]>    
date     : Fri, 9 Jun 2023 11:56:43 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Fri, 9 Jun 2023 11:56:43 +0900    

The same routine to check if a specific pattern can be found in the  
server logs was copied over four different test scripts.  This refactors  
the whole to use a single routine located in PostgreSQL::Test::Cluster,  
named log_contains, to grab the contents of the server logs and check  
for a specific pattern.  
  
On HEAD, the code previously used assumed that slurp_file() could not  
handle an undefined offset, setting it to zero, but slurp_file() does  
do an extra fseek() before retrieving the log contents only if an offset  
is defined.  In two places, the test was retrieving the full log  
contents with slurp_file() after calling substr() to apply an offset,  
ignoring that slurp_file() would be able to handle that.  
  
Backpatch all the way down to ease the introduction of new tests that  
could rely on the new routine.  
  
Author: Vignesh C  
Reviewed-by: Andrew Dunstan, Dagfinn Ilmari Mannsåker, Michael Paquier  
Discussion: https://postgr.es/m/CALDaNm0YSiLpjCmajwLfidQrFOrLNKPQir7s__PeVvh9U3uoTQ@mail.gmail.com  
Backpatch-through: 11  

commit   : 1536e321e65d5fbee41c45876622fe40ae20e68b    
  
author   : Fujii Masao <[email protected]>    
date     : Thu, 8 Jun 2023 20:11:52 +0900    
  
committer: Fujii Masao <[email protected]>    
date     : Thu, 8 Jun 2023 20:11:52 +0900    

In the documentation, previously the example command for  
ALTER FOREIGN TABLE ... OPTIONS incorrectly included both  
the option name and value with the DROP operation.  
The correct syntax for the DROP operation requires only  
the name of the option to be specified. This commit fixes  
the example by removing the option value from the DROP operation.  
  
Back-patch to all supported versions.  
  
Author: Mehmet Emin KARAKAS <[email protected]>  
Reviewed-by: Fujii Masao  
Discussion: https://postgr.es/m/CANQrdXAHzbcEYhjGoe5A42OmfvdQhHFJzyKj9gJvHuDKyOF5Ng@mail.gmail.com  

commit   : c504aa85707151392b0e4a6673f200dbd6fb33a3    
  
author   : Tomas Vondra <[email protected]>    
date     : Wed, 7 Jun 2023 16:48:50 +0200    
  
committer: Tomas Vondra <[email protected]>    
date     : Wed, 7 Jun 2023 16:48:50 +0200    

Commit fc22b6623b (generated columns) replaced ExecGetUpdatedCols() with  
ExecGetAllUpdatedCols() in a couple places handling UPDATE (triggers and  
lock mode). However, ExecGetUpdatedCols() did exec_rt_fetch() while  
ExecGetAllUpdatedCols() also allocates memory through bms_union()  
without paying attention to the memory context and happened to use the  
long-lived ExecutorState, leaking the memory until the end of the query.  
  
The amount of leaked memory is proportional to the number of (updated)  
attributes, types of UPDATE triggers, and the number of processed rows  
(which for UPDATE ... FROM ... may be much higher than updated rows).  
  
Fixed by switching to the per-tuple context in GetAllUpdatedColumns().  
This is fine for all in-core callers, but external callers may need to  
copy the result. But we're not aware of any such callers.  
  
Note the issue was introduced by fc22b6623b, but the macros were later  
renamed by f50e888990.  
  
Backpatch to 12, where the issue was introduced.  
  
Reported-by: Tomas Vondra  
Reviewed-by: Andres Freund, Tom Lane, Jakub Wartak  
Backpatch-through: 12  
Discussion: https://postgr.es/m/[email protected]  

commit   : 8b8cd437b500d160d379ffdc9aa2c1c29a265a86    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Tue, 6 Jun 2023 20:30:53 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Tue, 6 Jun 2023 20:30:53 +0300    

In reality, recordXtime will always be set by the getRecordTimestamp  
call, but the compiler doesn't necessarily see that.  
  
Back-patch to all supported versions.  
  
Author: Tristan Partin  
Discussion: https://www.postgresql.org/message-id/CT5MN8E11U0M.1NYNCHXYUHY41@gonk  

commit   : 9b1e89c6690d3e90dc118fee9d712f55f85bb46e    
  
author   : Bruce Momjian <[email protected]>    
date     : Thu, 1 Jun 2023 10:22:16 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Thu, 1 Jun 2023 10:22:16 -0400    

Backpatch-through: 11  

commit   : 8f876d15ca93f7b62b5daf07ab896573991eb935    
  
author   : Peter Geoghegan <[email protected]>    
date     : Thu, 25 May 2023 15:32:50 -0700    
  
committer: Peter Geoghegan <[email protected]>    
date     : Thu, 25 May 2023 15:32:50 -0700    

Avoid "right sibling's left-link doesn't match" errors when vacuuming a  
corrupt nbtree index.  Just LOG the issue and press on.  That way VACUUM  
will have a decent chance of finishing off all required processing for  
the index (and for the table as a whole).  
  
This error was seen in the field from time to time (it's more than a  
theoretical risk), so giving VACUUM the ability to press on like this  
has real value.  Nothing short of a REINDEX is expected to fix the  
underlying index corruption, so giving up (by throwing an error) risks  
making a bad situation far worse.  Anything that blocks forward progress  
by VACUUM like this might go unnoticed for a long time.  This could  
eventually lead to a wraparound/xidStopLimit outage.  
  
Note that _bt_unlink_halfdead_page() has always been able to bail on  
page deletion when the target page's left sibling page was in an  
inconsistent state.  It now does the same thing (returns false to back  
out of the second phase of deletion) when it notices sibling link  
corruption in the target page's right sibling page.  
  
This is similar to the work from commit 5b861baa (later backpatched as  
commit 43e409ce), which taught nbtree to press on with vacuuming an  
index when page deletion fails to "re-find" a downlink in the target  
page's parent page.  The "re-find" check seems to make VACUUM bail on  
page deletion more often in practice, but there is no reason to take any  
chances here.  
  
Author: Peter Geoghegan <[email protected]>  
Reviewed-By: Heikki Linnakangas <[email protected]>  
Discussion: https://postgr.es/m/CAH2-Wzko2q2kP1+UvgJyP9g0mF4hopK0NtQZcxwvMv9_ytGhkQ@mail.gmail.com  
Backpatch: 11- (all supported versions).  

commit   : 956c6256a98efcb53e982eb670a68658d3a38874    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 19 May 2023 14:26:34 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 19 May 2023 14:26:34 -0400    

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

commit   : 7d3c0b1f8f511be49062a3d3e47f427d076bd35e    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 19 May 2023 10:57:46 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 19 May 2023 10:57:46 -0400    

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

commit   : 6c512fc6e90d7f0be99090fa084c01418dfe80b3    
  
author   : Tomas Vondra <[email protected]>    
date     : Fri, 19 May 2023 00:00:22 +0200    
  
committer: Tomas Vondra <[email protected]>    
date     : Fri, 19 May 2023 00:00:22 +0200    

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

commit   : 2b1ab28b9dc9226b8a87cf8886ac3aebe591ac9a    
  
author   : Tomas Vondra <[email protected]>    
date     : Thu, 18 May 2023 13:00:31 +0200    
  
committer: Tomas Vondra <[email protected]>    
date     : Thu, 18 May 2023 13:00:31 +0200    

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

commit   : 0409c7fc746b2597edeaab3132d3f3554660283d    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 16 May 2023 10:53:42 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 16 May 2023 10:53:42 -0400    

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

commit   : 71fe2372278760714a442c82eb2ef524b7ea392a    
  
author   : Peter Geoghegan <[email protected]>    
date     : Wed, 10 May 2023 10:49:43 -0700    
  
committer: Peter Geoghegan <[email protected]>    
date     : Wed, 10 May 2023 10:49:43 -0700    

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