PostgreSQL 15.1 commit log

commit   : c5dc80c1bc216f0e21a2f79f5e0415c2d4cfb35d    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 7 Nov 2022 16:36:53 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 7 Nov 2022 16:36:53 -0500    

commit   : 0bc9872b1106fa5cdd488bc0ddafb270b2e7540a    
  
author   : Alvaro Herrera <[email protected]>    
date     : Mon, 7 Nov 2022 19:21:03 +0100    
  
committer: Alvaro Herrera <[email protected]>    
date     : Mon, 7 Nov 2022 19:21:03 +0100    

Source-Git-URL: ssh://[email protected]/pgtranslation/messages.git  
Source-Git-Hash: 0a578288026cfaae6b3d120b3ecf719aaa94dfdc  

commit   : b7f9c762a8e10a64866309b64b785a4496bcd194    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 7 Nov 2022 13:02:24 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 7 Nov 2022 13:02:24 -0500    

commit   : 5fe0ab42015ae8b084d959ac79cd7ee26de57b62    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 7 Nov 2022 11:36:45 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 7 Nov 2022 11:36:45 -0500    

Commit 4ab5dae94 broke mdunlinkfork's logic for removing additional  
segments of a multi-gigabyte table, because it neglected to advance  
"segno" after unlinking the first segment, in the code path where it  
chooses to unlink that one immediately.  Then the main remove loop  
gets ENOENT at segment zero and figures it's done, so we never remove  
whatever additional segments might exist.  
  
The main problem here is with large temporary tables, but WAL replay  
of a drop of a large regular table would also fail to remove extra  
segments.  The third case where this path is taken is for non-main  
forks; but I doubt it matters for those since they probably never  
exceed 1GB.  
  
The simplest fix is just to increment segno after that unlink().  
(Probably this logic could do with a more thorough rethink, but not  
with mere hours to go before 15.1 wraps.)  
  
While here, also fix an incautious assumption that  
register_forget_request cannot change errno.  I don't think that  
that has any really bad consequences, as we'd end up trying to unlink  
the zero'th segment either way, but it greatly complicates reasoning  
about what could happen here.  Also make a couple of other cosmetic  
fixes.  
  
Per bug #17679 from Balazs Szilfai.  Back-patch into v15, as the  
faulty patch was.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 7134af1149247d956d32c994fa00a844f2bdc796    
  
author   : Peter Eisentraut <[email protected]>    
date     : Mon, 7 Nov 2022 14:04:05 +0100    
  
committer: Peter Eisentraut <[email protected]>    
date     : Mon, 7 Nov 2022 14:04:05 +0100    

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

commit   : ca3f0d44ac6a6794a89e59b1ff80613b12c792ba    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 6 Nov 2022 11:07:28 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 6 Nov 2022 11:07:28 -0500    

commit   : bc62182f0afe6b01fec45b8d26df03fc9de4599a    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 4 Nov 2022 12:46:02 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 4 Nov 2022 12:46:02 -0400    

As usual, the release notes for other branches will be made by cutting  
these down, but put them up for community review first.  
  
Also as usual for a .1 release, there are some entries here that  
are not really relevant for v15 because they already appeared in 15.0.  
Those'll be removed later.  

commit   : 2c6d43650d16d91a3e731d236315beffd98db729    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 4 Nov 2022 10:39:52 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 4 Nov 2022 10:39:52 -0400    

Commit aa0105141 repeated one of the oldest mistakes in our book:  
thinking that OID is the same as int32.  It isn't of course, and  
unsurprisingly the first person who came along with a database  
OID above 2 billion broke it.  Repair.  
  
Per bug #17677 from Sergey Pankov.  Back-patch to v15.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 81173264440d7d3bd6479313b1d4611a2bfe8031    
  
author   : Etsuro Fujita <[email protected]>    
date     : Fri, 4 Nov 2022 19:15:01 +0900    
  
committer: Etsuro Fujita <[email protected]>    
date     : Fri, 4 Nov 2022 19:15:01 +0900    

"Triggers on partitioned tables cannot have transition tables." is  
incorrect as we allow statement-level triggers on partitioned tables to  
have transition tables.  
  
This has been wrong since commit 86f575948; back-patch to v11 where that  
commit came in.  
  
Reviewed by Tom Lane.  
  
Discussion: https://postgr.es/m/CAPmGK17gk4vXLzz2iG%2BG4LWRWCoVyam70nZ3OuGm1hMJwDrhcg%40mail.gmail.com  

commit   : 387e059f8e9c506aba17d63e7220cad2f488f238    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 3 Nov 2022 19:53:35 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 3 Nov 2022 19:53:35 -0400    

In the docs, the GUC flags that pg_settings_get_flags() reported were  
listed using <simplelist>. But the list was treated as separate lines  
in the existing function table and didn't look good. For better view,  
this commit separates the list from the table entry for  
pg_settings_get_flags() and adds the table for it at the bottom of  
the existing function table.  
  
Author: Fujii Masao  
Reviewed-by: Alvaro Herrera, Michael Paquier  
Discussion: https://postgr.es/m/[email protected]  
  
Back-patch of f2d0c7f18 into v15.  
Discussion: https://postgr.es/m/[email protected]  

commit   : c301e1c0c09cfedce9eb469744384a6d15e50745    
  
author   : Alvaro Herrera <[email protected]>    
date     : Thu, 3 Nov 2022 20:40:21 +0100    
  
committer: Alvaro Herrera <[email protected]>    
date     : Thu, 3 Nov 2022 20:40:21 +0100    

Commit f56f8f8da6af added some code in CloneFkReferencing that's way too  
lax about a Constraint node it manufactures, not initializing enough  
struct members -- initially_valid in particular was forgotten.  This  
causes some FKs in partitions added by ALTER TABLE ATTACH PARTITION to  
be marked as not validated.  Set initially_valid true, which fixes the  
bug.  
  
While at it, make the struct initialization more complete.  Very similar  
code was added in two other places by the same commit; make them all  
follow the same pattern for consistency, though no bugs are apparent  
there.  
  
This bug has never been reported: I only happened to notice while  
working on commit 614a406b4ff1.  The test case that was added there with  
the improper result is repaired.  
  
Backpatch to 12.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : f2dc7f9e35a288d21dfdd74e56f8809862d02dd6    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 3 Nov 2022 12:01:57 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 3 Nov 2022 12:01:57 -0400    

If a syntax error occurred in a SQL-language or PL/pgSQL-language  
CREATE FUNCTION or DO command executed in a logical replication worker,  
we'd suffer a null pointer dereference or assertion failure.  That  
seems like a rather contrived case, but nonetheless worth fixing.  
  
The cause is that function_parse_error_transpose assumes it must be  
executing within the context of a Portal, but logical/worker.c  
doesn't create a Portal since it's not running the standard executor.  
We can just back off the hard Assert check and make it fail gracefully  
if there's not an ActivePortal.  (I have a feeling that the aggressive  
check here was my fault originally, probably because I wasn't sure if  
the case would always hold and wanted to find out.  Well, now we know.)  
  
The hazard seems to exist in all branches that have logical replication,  
so back-patch to v10.  
  
Maxim Orlov, Anton Melnikov, Masahiko Sawada, Tom Lane  
  
Discussion: https://postgr.es/m/[email protected]  
Discussion: https://postgr.es/m/[email protected]  

commit   : 725cd4d2e4819056993ce32336ea130473eb02a1    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 3 Nov 2022 10:47:31 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 3 Nov 2022 10:47:31 -0400    

Casting the result of palloc etc. to the intended type is more per  
project style anyway.  
  
(The fact that cpluspluscheck doesn't notice these problems is  
because it doesn't expand any macros, which seems like a troubling  
shortcoming.  Don't have a good idea about improving that.)  
  
Back-patch to v13, which is as far as the patch applies cleanly;  
doesn't seem worth working harder.  
  
David Geier  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : a5737e765d85c170a035ee5eedf5d4cd8e9d5128    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 2 Nov 2022 17:37:26 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 2 Nov 2022 17:37:26 -0400    

If we have no special-case code in s_lock.h for the current platform,  
but the compiler has __sync_lock_test_and_set, use that instead of  
failing.  It's unlikely that anybody's __sync_lock_test_and_set  
would be so awful as to be worse than our semaphore-based fallback,  
but if it is, they can (continue to) use --disable-spinlocks.  
  
This allows removal of the RISC-V special case installed by commit  
c32fcac56, which generated exactly the same code but only on that  
platform.  Usefully, the RISC-V buildfarm animals should now test  
at least the int variant of this patch.  
  
I've manually tested both variants on ARM by dint of removing the  
ARM-specific stanza.  We don't want to drop that, because it already  
has some special knowledge and is likely to grow more over time.  
Likewise, this is not meant to preclude installing special cases  
for other arches if that proves worthwhile.  
  
Per discussion of a request to install the same code for loongarch64.  
Like the previous patch, we might as well back-patch to supported  
branches.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 414d29a826f3a63fabae5e9ac2eb5b17f03787d8    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 2 Nov 2022 12:29:39 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 2 Nov 2022 12:29:39 -0400    

Since partitions can be foreign tables not only plain tables, but  
logical replication only supports plain tables, we'd better check the  
relkind of a partition after we find it.  (There was some discussion  
of checking this when adding a partitioned table to a subscription;  
but that would be inadequate since the troublesome partition could be  
added later.)  Without this, the situation leads to a segfault or  
assertion failure.  
  
In passing, add a separate variable for the target Relation of  
a cross-partition UPDATE; reusing partrel seemed mighty confusing  
and error-prone.  
  
Shi Yu and Tom Lane, per report from Ilya Gladyshev.  Back-patch  
to v13 where logical replication into partitioned tables became  
a thing.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 0eede9625659d47a9b3fb1292f71c8b16667326b    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 2 Nov 2022 11:30:04 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 2 Nov 2022 11:30:04 -0400    

Thinko in commit 5209c0ba0: I checked the wrong object's  
DUMP_COMPONENT_COMMENT bit in two places.  
  
Per bug #17675 from Franz-Josef Färber.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : d5e1748f02fb54cff276e7714be474f4e9a9de72    
  
author   : Etsuro Fujita <[email protected]>    
date     : Wed, 2 Nov 2022 18:15:01 +0900    
  
committer: Etsuro Fujita <[email protected]>    
date     : Wed, 2 Nov 2022 18:15:01 +0900    

commit   : 468a9f37fb69065760054c83d2ee9aa01910a495    
  
author   : Michael Paquier <[email protected]>    
date     : Wed, 2 Nov 2022 11:56:28 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Wed, 2 Nov 2022 11:56:28 +0900    

pg_ident_file_mappings.line_number was described as a line number in  
pg_ident.conf for a "rule" number, but this should refer to a "map".  
The same inconsistent term was used in the main paragraph describing the  
view.  
  
Extracted from a patch by the same author.  Issue introduced by  
a2c8499 where this view has been added.  
  
Author: Julien Rouhaud  
Discussion: https://postgr.es/m/20221026031948.cbrnzgy5e7glsq2d@jrouhaud  
Backpatch-through: 15  

commit   : 23f44276123031d21cffeb699d9863149e1c734f    
  
author   : David Rowley <[email protected]>    
date     : Wed, 2 Nov 2022 15:29:49 +1300    
  
committer: David Rowley <[email protected]>    
date     : Wed, 2 Nov 2022 15:29:49 +1300    

This was outdated by 77bae396d.  
  
Backpatch-through: 15, where 77bae396d was added  

commit   : c3d16eb3d5f1ee843017a059fe3e272061bb9875    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 1 Nov 2022 17:08:28 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 1 Nov 2022 17:08:28 -0400    

DST law changes in Chile, Fiji, Iran, Jordan, Mexico, Palestine,  
and Syria.  Historical corrections for Chile, Crimea, Iran, and  
Mexico.  
  
Also, the Europe/Kiev zone has been renamed to Europe/Kyiv  
(retaining the old name as a link).  
  
The following zones have been merged into nearby, more-populous zones  
whose clocks have agreed since 1970: Antarctica/Vostok, Asia/Brunei,  
Asia/Kuala_Lumpur, Atlantic/Reykjavik, Europe/Amsterdam,  
Europe/Copenhagen, Europe/Luxembourg, Europe/Monaco, Europe/Oslo,  
Europe/Stockholm, Indian/Christmas, Indian/Cocos, Indian/Kerguelen,  
Indian/Mahe, Indian/Reunion, Pacific/Chuuk, Pacific/Funafuti,  
Pacific/Majuro, Pacific/Pohnpei, Pacific/Wake and Pacific/Wallis.  
(This indirectly affects zones that were already links to one of  
these: Arctic/Longyearbyen, Atlantic/Jan_Mayen, Iceland,  
Pacific/Ponape, Pacific/Truk, and Pacific/Yap.)  America/Nipigon,  
America/Rainy_River, America/Thunder_Bay, Europe/Uzhgorod, and  
Europe/Zaporozhye were also merged into nearby zones after discovering  
that their claimed post-1970 differences from those zones seem to have  
been errors.  
  
While the IANA crew have been working on merging zones that have no  
post-1970 differences for some time, this batch of changes affects  
some zones that are significantly more populous than those merged  
in the past, notably parts of Europe.  The loss of pre-1970 timezone  
history for those zones may be troublesome for applications  
expecting consistency of timestamptz display.  As an example, the  
stored value '1944-06-01 12:00 UTC' would previously display as  
'1944-06-01 13:00:00+01' if the Europe/Stockholm zone is selected,  
but now it will read out as '1944-06-01 14:00:00+02'.  
  
There exists a "packrat" option that will build the timezone data  
files with this old data preserved, but the problem is that it also  
resurrects a bunch of other, far less well-attested data; so much so  
that actually more zones' contents change from 2022a with that option  
than without it.  I have chosen not to do that here, for that reason  
and because it appears that no major OS distributions are using the  
"packrat" option, so that doing so would cause Postgres' behavior  
to diverge significantly depending on whether it was built with  
--with-system-tzdata.  However, for anyone for whom these changes pose  
significant problems, there is a solution: build a set of timezone  
files with the "packrat" option and use those with Postgres.  

commit   : 1f1865e9083625239769c26f68b9c2861b8d4b1c    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 1 Nov 2022 14:34:44 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 1 Nov 2022 14:34:44 -0400    

Some cases would result in "cache lookup failed for statistics object",  
due to trying to fetch inherited statistics when only non-inherited  
ones are available or vice versa.  
  
Richard Guo and Justin Pryzby  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 8b0a5cf3fe48a929b26e6e305f0765cf383d2ade    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 1 Nov 2022 12:48:01 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 1 Nov 2022 12:48:01 -0400    

When executing a utility statement, we must fetch everything  
we need out of the PlannedStmt data structure before calling  
standard_ProcessUtility.  In certain cases (possibly only ROLLBACK  
in extended query protocol), that data structure will get freed  
during command execution.  The situation is probably often harmless  
in production builds, but in debug builds we intentionally overwrite  
the freed memory with garbage, leading to picking up garbage values  
of statement location and length, typically causing an assertion  
failure later in pg_stat_statements.  In non-debug builds, if  
something did go wrong it would likely lead to storing garbage  
for the query string.  
  
Report and fix by zhaoqigui (with cosmetic adjustments by me).  
It's an old problem, so back-patch to all supported versions.  
  
Discussion: https://postgr.es/m/[email protected]  
Discussion: https://postgr.es/m/[email protected]  

commit   : d2354b6eecccb78fe697a270bd97298cbc63f477    
  
author   : Peter Eisentraut <[email protected]>    
date     : Tue, 1 Nov 2022 14:17:36 +0100    
  
committer: Peter Eisentraut <[email protected]>    
date     : Tue, 1 Nov 2022 14:17:36 +0100    

This name was incorrect in the underlying commit message.  (The  
correct name is already listed.)  
  
Reported-by: Mark Wong  

commit   : 3395cc1dbae5f5713373e59510425138da8cecb4    
  
author   : Noah Misch <[email protected]>    
date     : Sat, 29 Oct 2022 10:42:16 -0700    
  
committer: Noah Misch <[email protected]>    
date     : Sat, 29 Oct 2022 10:42:16 -0700    

Per buildfarm member kittiwake.  Back-patch to v15, where this test  
first appeared.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : ca4070f2b4b1ed62e3d333a51a2f412b1c841ba4    
  
author   : Michael Paquier <[email protected]>    
date     : Wed, 26 Oct 2022 09:41:13 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Wed, 26 Oct 2022 09:41:13 +0900    

Contrary to what is documented in src/backend/access/transam/README,  
ginHeapTupleFastInsert() had a few ordering issues with the way it does  
its WAL operations when inserting items in its fast path.  
  
First, when using a separate list, XLogBeginInsert() was being always  
called before START_CRIT_SECTION(), and in this case a second thing was  
wrong when merging lists, as an exclusive lock was taken on the tail  
page *before* calling XLogBeginInsert().  Finally, when inserting items  
into a tail page, the order of XLogBeginInsert() and  
START_CRIT_SECTION() was reversed.  This commit addresses all these  
issues by moving the calls of XLogBeginInsert() after all the pages  
logged are locked and pinned, within a critical section.  
  
This has been applied first only on HEAD as of 56b6625, but as per  
discussion with Tom Lane and Álvaro Herrera, a backpatch is preferred to  
keep all the branches consistent and to respect the transam's README  
where we can.  
  
Author:  Matthias van de Meent, Zhang Mingli  
Discussion: https://postgr.es/m/CAEze2WhL8uLMqynnnCu1LAPwxD5RKEo0nHV+eXGg_N6ELU88HQ@mail.gmail.com  
Backpatch-through: 10  

commit   : f975df7203607c51f2f6284b54e7394a33f575ed    
  
author   : Michael Paquier <[email protected]>    
date     : Tue, 25 Oct 2022 09:29:54 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Tue, 25 Oct 2022 09:29:54 +0900    

This entry was listed as a "string", but it is a "number.  The other  
fields are correctly described, on a second look.  
  
Reported-by: Nuko Yokohama  
Author: Tatsuo Ishii  
Discussion: https://postgr.es/m/CAF3Gu1awoVoDP5d0_eN=cR=QkGVwH+OtFvwJkkc5cB_ZMWjyeA@mail.gmail.com  
Backpatch-through: 15  

commit   : fb2a83b2b750a32ddfd107a75a3bc173f4f0a81f    
  
author   : Alvaro Herrera <[email protected]>    
date     : Mon, 24 Oct 2022 12:52:43 +0200    
  
committer: Alvaro Herrera <[email protected]>    
date     : Mon, 24 Oct 2022 12:52:43 +0200    

Oversight in 7103ebb7aae8.  Backpatch to 15.  
  
Author: Richard Guo <[email protected]>  
Discussion: https://postgr.es/m/CAMbWs48gnDjZXq3-b56dVpQCNUJ5hD9kdtWN4QFwKCEapspNsA@mail.gmail.com  

commit   : 4a6de748d3429cfa081942c46411d62341867bfd    
  
author   : Peter Eisentraut <[email protected]>    
date     : Sat, 22 Oct 2022 09:41:38 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Sat, 22 Oct 2022 09:41:38 +0200    

Because of a small thinko in 7844c9918a43b494adde3575891d217a37062378,  
psql -c would exit successfully when a query is canceled.  Fix this so  
that it exits with a nonzero status, just like for all other errors.  

commit   : 5c013e620c911d728f653785843eb3c272c43538    
  
author   : Robert Haas <[email protected]>    
date     : Fri, 21 Oct 2022 08:21:55 -0400    
  
committer: Robert Haas <[email protected]>    
date     : Fri, 21 Oct 2022 08:21:55 -0400    

Specifically, when pg_basebackup is invoked with -Tx=y, don't error  
out if x could plausibly be an absolute path either on Windows or on  
non-Windows systems. We don't know whether the remote system is  
running the same OS as the local system, so it's not appropriate to  
assume that our local rule about absolute pathnames is the same as  
the rule on the remote system.  
  
Patch by me, reviewed by Tom Lane, Andrew Dunstan, and  
Davinder Singh.  
  
Discussion: http://postgr.es/m/CA+TgmoY+jC3YiskomvYKDPK3FbrmsDU7_8+wMHt02HOdJeRb0g@mail.gmail.com  

commit   : 10eaa975018f7ea88f5d0af5af40b2d3749b3ca8    
  
author   : Amit Kapila <[email protected]>    
date     : Fri, 21 Oct 2022 12:43:28 +0530    
  
committer: Amit Kapila <[email protected]>    
date     : Fri, 21 Oct 2022 12:43:28 +0530    

Previously in commit 42681dffaf, we added CFI during decoding changes but  
missed another similar case that can happen while restoring changes  
spilled to disk back into memory in a loop.  
  
Reported-by: Robert Haas  
Author: Amit Kapila  
Backpatch-through: 10  
Discussion: https://postgr.es/m/CA+TgmoaLObg0QbstbC8ykDwOdD1bDkr4AbPpB=0DPgA2JW0mFg@mail.gmail.com  

commit   : 343afa9671060c3d6482d1252207a64cc5ddd23d    
  
author   : Amit Kapila <[email protected]>    
date     : Fri, 21 Oct 2022 10:03:35 +0530    
  
committer: Amit Kapila <[email protected]>    
date     : Fri, 21 Oct 2022 10:03:35 +0530    

This problem has been introduced by commit 272248a0c1 where we started  
assigning the subtransactions to the top-level transaction when we mark  
both the top-level transaction and its subtransactions as containing  
catalog changes. After we assign subtransactions to the top-level  
transaction, we were not allowed to execute any invalidations associated  
with it when we decide to skip the transaction.  
  
The reason to assign the subtransactions to the top-level transaction was  
to avoid the assertion failure in AssertTXNLsnOrder() as they have the  
same LSN when we sometimes start accumulating transaction changes for  
partial transactions after the restart. Now that with commit 64ff0fe4e8,  
we skip this assertion check until we reach the LSN at which we start  
decoding the contents of the transaction, so, there is no reason for such  
an assignment anymore.  
  
The assignment change was introduced in 15 and prior versions but this bug  
doesn't exist in branches prior to 14 since we don't add invalidation  
messages to subtransactions. We decided to backpatch through 11 for  
consistency but not for 10 since its final release is near.  
  
Reported-by: Kuroda Hayato  
Author: Masahiko Sawada  
Reviewed-by: Amit Kapila  
Backpatch-through: 11  
Discussion: https://postgr.es/m/TYAPR01MB58660803BCAA7849C8584AA4F57E9%40TYAPR01MB5866.jpnprd01.prod.outlook.com  
Discussion: https://postgr.es/m/a89b46b6-0239-2fd5-71a9-b19b1f7a7145%40enterprisedb.com  

commit   : 536a3b87037b7eac1e9e2780738a0056d89634f6    
  
author   : David Rowley <[email protected]>    
date     : Fri, 21 Oct 2022 09:29:56 +1300    
  
committer: David Rowley <[email protected]>    
date     : Fri, 21 Oct 2022 09:29:56 +1300    

56788d215 adjusted the parallel seq scan code so that instead of handing  
out a single block at a time to parallel workers, it now hands out ranges  
of blocks.  
  
Here we update the documentation which still claimed that workers received  
just 1 block at a time.  
  
Reported-by: Zhang Mingli  
Discussion: https://postgr.es/m/17c99615-2c3b-4e4e-9d0b-424a66a7bccd@Spark  
Backpatch-through: 14, where 56788d215 was added.  

commit   : 64ff0fe4e8c47fc390bb645d48ba38675494a2b4    
  
author   : Amit Kapila <[email protected]>    
date     : Thu, 20 Oct 2022 09:43:59 +0530    
  
committer: Amit Kapila <[email protected]>    
date     : Thu, 20 Oct 2022 09:43:59 +0530    

When the logical decoding restarts from NEW_CID, since there is no  
association between the top transaction and its subtransaction, both are  
created as top transactions and have the same LSN. This caused the  
assertion failure in AssertTXNLsnOrder().  
  
This patch skips the assertion check until we reach the LSN at which we  
start decoding the contents of the transaction, specifically  
start_decoding_at LSN in SnapBuild. This is okay because we don't  
guarantee to make the association between top transaction and  
subtransaction until we try to decode the actual contents of transaction.  
The ordering of the records prior to the start_decoding_at LSN should have  
been checked before the restart.  
  
The other assertion failure is due to the reason that we forgot to track  
that we have considered top-level transaction id in the list of catalog  
changing transactions that were committed when one of its subtransactions  
is marked as containing catalog change.  
  
Reported-by: Tomas Vondra, Osumi Takamichi  
Author: Masahiko Sawada, Kuroda Hayato  
Reviewed-by: Amit Kapila, Dilip Kumar, Kuroda Hayato, Kyotaro Horiguchi, Masahiko Sawada  
Backpatch-through: 10  
Discussion: https://postgr.es/m/a89b46b6-0239-2fd5-71a9-b19b1f7a7145%40enterprisedb.com  
Discussion: https://postgr.es/m/TYCPR01MB83733C6CEAE47D0280814D5AED7A9%40TYCPR01MB8373.jpnprd01.prod.outlook.com  

commit   : af64846e1cca9628fd3d816d3de3ae414c4891b4    
  
author   : Thomas Munro <[email protected]>    
date     : Wed, 19 Oct 2022 22:18:54 +1300    
  
committer: Thomas Munro <[email protected]>    
date     : Wed, 19 Oct 2022 22:18:54 +1300    

Per https://llvm.org/docs/OpaquePointers.html, support for non-opaque  
pointers still exists and we can request that on our context.  We have  
until LLVM 16 to move to opaque pointers, a much larger change.  
  
Back-patch to 11, where LLVM support arrived.  
  
Author: Thomas Munro <[email protected]>  
Author: Andres Freund <[email protected]>  
Discussion: https://postgr.es/m/CAMHz58Sf_xncdyqsekoVsNeKcruKootLtVH6cYXVhhUR1oKPCg%40mail.gmail.com  

commit   : 5d2a47a2924240606ce1c57c98490fa41752ad41    
  
author   : Michael Paquier <[email protected]>    
date     : Wed, 19 Oct 2022 14:07:01 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Wed, 19 Oct 2022 14:07:01 +0900    

As currently designed, with a callback registered in a ERROR_CLEANUP  
block, the shutdown callback would get called twice when updating  
archive_library on SIGHUP, which is something that we want to avoid to  
ease the life of extension writers.  
  
Anyway, an ERROR in the archiver process is treated as a FATAL, stopping  
it immediately, hence there is no need for a ERROR_CLEANUP block.  
Instead of that, the shutdown callback is not called upon  
before_shmem_exit(), giving to the modules the opportunity to do any  
cleanup actions before the server shuts down its subsystems.  
  
While on it, this commit adds some testing coverage for the shutdown  
callback.  Neither shell_archive nor basic_archive have been using it,  
and one is added to shell_archive, whose trigger is checked in a TAP  
test through a shutdown sequence.  
  
Author: Nathan Bossart, Bharath Rupireddy  
Reviewed-by: Kyotaro Horiguchi, Michael Paquier  
Discussion: https://postgr.es/m/20221015221328.GB1821022@nathanxps13  
Backpatch-through: 15  

commit   : 25fb9579bbb97c65d6b007c3de803c81abb4b240    
  
author   : Alvaro Herrera <[email protected]>    
date     : Tue, 18 Oct 2022 11:46:58 +0200    
  
committer: Alvaro Herrera <[email protected]>    
date     : Tue, 18 Oct 2022 11:46:58 +0200    

The original hint says to use SET PUBLICATION when really ADD/DROP  
PUBLICATION is called for, so this is arguably a bug fix.  
  
Also, a very similar message elsewhere was using an inconsistent  
SQLSTATE.  
  
While at it, unwrap some strings.  
  
Backpatch to 15.  
  
Author: Hou zj <[email protected]>  
Discussion: https://postgr.es/m/OS0PR01MB57160AD0E7386547BA978EB394299@OS0PR01MB5716.jpnprd01.prod.outlook.com  

commit   : f2f7e509e6a96329805ecaf30fb64ba4c7f4b0d2    
  
author   : Michael Paquier <[email protected]>    
date     : Tue, 18 Oct 2022 10:22:40 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Tue, 18 Oct 2022 10:22:40 +0900    

Per discussion, the existing routine name able to initialize a SRF  
function with materialize mode is unpopular, so rename it.  Equally, the  
flags of this function are renamed, as of:  
- SRF_SINGLE_USE_EXPECTED -> MAT_SRF_USE_EXPECTED_DESC  
- SRF_SINGLE_BLESS -> MAT_SRF_BLESS  
The previous function and flags introduced in 9e98583 are kept around  
for compatibility purposes, so as any extension code already compiled  
with v15 continues to work as-is.  The declarations introduced here for  
compatibility will be removed from HEAD in a follow-up commit.  
  
The new names have been suggested by Andres Freund and Melanie  
Plageman.  
  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 15  

commit   : ef325ee04dd407b7f3cef35e0e5722cbb5a9576d    
  
author   : Bruce Momjian <[email protected]>    
date     : Mon, 17 Oct 2022 15:21:29 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Mon, 17 Oct 2022 15:21:29 -0400    

It was previously easily overlooked at the end of several tables.  
  
Reported-by: Alex Denman  
  
Discussion: https://postgr.es/m/[email protected]  
  
Backpatch-through: 10  

commit   : 189db21e2ac41a719b8e70ac35b3d0b05b352f14    
  
author   : Bruce Momjian <[email protected]>    
date     : Mon, 17 Oct 2022 15:07:03 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Mon, 17 Oct 2022 15:07:03 -0400    

The fix is to run ANALYZE.  
  
Discussion: https://postgr.es/m/[email protected],  
   https://postgr.es/m/flat/CAKJS1f8DTbCHf9gedU0He6ARsd58E6qOhEHM1caomqj_r9MOiQ%40mail.gmail.com,  
   https://postgr.es/m/CAKJS1f80o98hcfSk8j%3DfdN09S7Sjz%2BvuzhEwbyQqvHJb_sZw0g%40mail.gmail.com  
  
Backpatch-through: 10  

commit   : 4a41a069e7ac78e0a8b700fac181f59a234f8606    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 17 Oct 2022 12:14:39 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 17 Oct 2022 12:14:39 -0400    

DefineQueryRewrite() has long required that ON SELECT rules be named  
"_RETURN".  But we overlooked the converse case: we should forbid  
non-ON-SELECT rules that are named "_RETURN".  In particular this  
prevents using CREATE OR REPLACE RULE to overwrite a view's _RETURN  
rule with some other kind of rule, thereby breaking the view.  
  
Per bug #17646 from Kui Liu.  Back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 2e3326929b0ba9f421f2ab1270c57b294c208a99    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 17 Oct 2022 11:35:23 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 17 Oct 2022 11:35:23 -0400    

The executor will dump core if it's asked to execute a seqscan on  
a relation having no table AM, such as a view.  While that shouldn't  
really happen, it's possible to get there via catalog corruption,  
such as a missing ON SELECT rule.  It seems worth installing a defense  
against that.  There are multiple plausible places for such a defense,  
but I picked the planner's get_relation_info().  
  
Per discussion of bug #17646 from Kui Liu.  Back-patch to v12 where  
the tableam APIs were introduced; in older versions you won't get a  
SIGSEGV, so it seems less pressing.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 9ebcb5ffdf3a1f49388c38ba5273370f49bf7d19    
  
author   : Michael Paquier <[email protected]>    
date     : Mon, 17 Oct 2022 11:40:19 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Mon, 17 Oct 2022 11:40:19 +0900    

The file name used for its temporary destination, before renaming it to  
the real deal, has been using a microseconds in a timestamp aimed to be  
originally in milli-seconds.  This is harmless as this is aimed at being  
a safeguard against name collisions (note MyProcPid in the name), but  
let's be correct with the maths.  
  
While on it, add a note in the module's makefile to document why  
installcheck is not supported.  
  
Author: Nathan Bossart  
Reviewed-by: Bharath Rupireddy  
Discussion: https://postgr.es/m/20221014044106.GA1673343@nathanxps13  
Backpatch-through: 15  

commit   : d4abb0bc5abb5dcb351956aed70f317a6bc494ba    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 16 Oct 2022 19:18:08 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 16 Oct 2022 19:18:08 -0400    

If the non-recursive term of a SEARCH BREADTH FIRST recursive  
query has only constants in its target list, the planner will  
fold the starting RowExpr added by rewrite into a simple Const  
of type RECORD.  The executor doesn't have any problem with  
that --- but EXPLAIN VERBOSE will encounter the Const as the  
ultimate source of truth about what the field names of the  
SET column are, and it didn't know what to do with that.  
Fortunately, we can pull the identifying typmod out of the  
Const, in much the same way that record_out would.  
  
For reasons that remain a bit obscure to me, this only fails  
with SEARCH BREADTH FIRST, not SEARCH DEPTH FIRST or CYCLE.  
But I added regression test cases for both of those options  
too, just to make sure we don't break it in future.  
  
Per bug #17644 from Matthijs van der Vleuten.  Back-patch  
to v14 where these constructs were added.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 24c4c2617138b1b14def8bd39dfe228c862ea129    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 16 Oct 2022 15:27:04 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 16 Oct 2022 15:27:04 -0400    

In the latest version of Apple's macOS SDK, <sys/socket.h>  
fails to compile if "REF" is #define'd as something.  
Apple may or may not agree that this is a bug, and even if  
they do accept the bug report I filed, they probably won't  
fix it very quickly.  In the meantime, our back branches will all  
fail to compile gram.y.  v15 and HEAD currently escape the problem  
thanks to the refactoring done in 98e93a1fc, but that's purely  
accidental.  Moreover, since that patch removed a widely-visible  
inclusion of <netdb.h>, back-patching it seems too likely to break  
third-party code.  
  
Instead, change the token's code name to REF_P, following our usual  
convention for naming parser tokens that are likely to have symbol  
conflicts.  The effects of that should be localized to the grammar  
and immediately surrounding files, so it seems like a safer answer.  
  
Per project policy that we want to keep recently-out-of-support  
branches buildable on modern systems, back-patch all the way to 9.2.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : bd4b2926ecc25b4435f816ce4ec542d9a01cdb09    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 16 Oct 2022 11:47:44 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 16 Oct 2022 11:47:44 -0400    

snprintf.c has always fallen back on libc's *printf implementation  
when printing pointers (%p) and floats.  When this code originated,  
we were still supporting some platforms that lacked native snprintf,  
so we used sprintf for that.  That's not actually unsafe in our usage,  
but nonetheless builds on macOS are starting to complain about sprintf  
being unconditionally deprecated; and I wouldn't be surprised if other  
platforms follow suit.  There seems little reason to believe that any  
platform supporting C99 wouldn't have standards-compliant snprintf,  
so let's just use that instead to suppress such warnings.  
  
Back-patch to v12, which is where we started to require C99.  It's  
also where we started to use our snprintf.c everywhere, so this  
wouldn't be enough to suppress the warning in older branches anyway  
--- that is, in older branches these aren't necessarily all our  
usages of libc's sprintf.  It is enough in v12+ because any  
deprecation annotation attached to libc's sprintf won't apply to  
pg_sprintf.  (Whether all our usages of pg_sprintf are adequately  
safe is not a matter I intend to address here, but perhaps it could  
do with some review.)  
  
Per report from Andres Freund and local testing.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 16d11d68437a6a37af1fea08d4a29ef463f0d62c    
  
author   : Alvaro Herrera <[email protected]>    
date     : Sat, 15 Oct 2022 19:24:26 +0200    
  
committer: Alvaro Herrera <[email protected]>    
date     : Sat, 15 Oct 2022 19:24:26 +0200    

While directly targetting a foreign table with MERGE was already  
expressly forbidden, we failed to catch the case of a partitioned table  
that has a foreign table as a partition; and the result if you try is an  
incomprehensible error.  Fix that by adding a specific check.  
  
Backpatch to 15.  
  
Reported-by: Tatsuhiro Nakamori <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  

commit   : 27ca0bce5f41cecc3b219cc9d675239a79d7562a    
  
author   : Alvaro Herrera <[email protected]>    
date     : Fri, 14 Oct 2022 19:06:26 +0200    
  
committer: Alvaro Herrera <[email protected]>    
date     : Fri, 14 Oct 2022 19:06:26 +0200    

When a query whose results were requested in single-row mode is the last  
in the queue by the time those results are being read, the single-row  
flag was not being reset, because we were returning early from  
pqPipelineProcessQueue.  Move that stanza up so that the flag is always  
reset at the end of sending that query's results.  
  
Add a test for the situation.  
  
Backpatch to 14.  
  
Author: Denis Laxalde <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  

commit   : f7eec7fe38676f0be78640f0d4d77c3e4ffcc6d6    
  
author   : Alvaro Herrera <[email protected]>    
date     : Thu, 13 Oct 2022 13:36:14 +0200    
  
committer: Alvaro Herrera <[email protected]>    
date     : Thu, 13 Oct 2022 13:36:14 +0200    

While at it, simplify wording a bit.  
  
Author: Takamichi Osumi <[email protected]>  
Reviewed-by: Peter Smith <[email protected]>  
Discussion: https://postgr.es/m/TYCPR01MB8373F93F5D094A2BE648990DED259@TYCPR01MB8373.jpnprd01.prod.outlook.com  

commit   : 91416f45f8bb8c4466e577efd79822be11645794    
  
author   : Michael Paquier <[email protected]>    
date     : Thu, 13 Oct 2022 08:53:44 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Thu, 13 Oct 2022 08:53:44 +0900    

The output plugin name is a mandatory option when creating a logical  
slot, but the grammar documented was not described as such.  While on  
it, fix two comments in repl_gram.y to show that TEMPORARY is an  
optional grammar choice.  
  
Author: Ayaki Tachikake  
Discussion: https://postgr.es/m/OSAPR01MB2852607B2329FFA27834105AF1229@OSAPR01MB2852.jpnprd01.prod.outlook.com  
Backpatch-through: 15  

commit   : 42d203ccfa8741ca8086e33f98aaa6c169063ef7    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 12 Oct 2022 10:51:11 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 12 Oct 2022 10:51:11 -0400    

Add  
    After=network-online.target  
    Wants=network-online.target  
to the suggested unit file for starting a Postgres server.  
This delays startup until the network interfaces have been  
configured; without that, any attempt to bind to a specific  
IP address will fail.  
  
If listen_addresses is set to "localhost" or "*", it might be  
possible to get away with the less restrictive "network.target",  
but I don't think we need to get into such detail here.  
  
Per suggestion from Pablo Federico.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : e7b4ff327c4d5cc8ff3eaebff9c79c28232cabdd    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 11 Oct 2022 18:54:31 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 11 Oct 2022 18:54:31 -0400    

The postmaster is not supposed to do anything that depends  
fundamentally on shared memory contents, because that creates  
the risk that a backend crash that trashes shared memory will  
take the postmaster down with it, preventing automatic recovery.  
In commit 969d7cd43 I lost sight of this principle and coded  
AssignPostmasterChildSlot() in such a way that it could fail  
or even crash if the shared PMSignalState structure became  
corrupted.  Remarkably, we've not seen field reports of such  
crashes; but I managed to induce one while testing the recent  
changes around palloc chunk headers.  
  
To fix, make a semi-duplicative state array inside the postmaster  
so that we need consult only local state while choosing a "child  
slot" for a new backend.  Ensure that other postmaster-executed  
routines in pmsignal.c don't have critical dependencies on the  
shared state, either.  Corruption of PMSignalState might now  
lead ReleasePostmasterChildSlot() to conclude that backend X  
failed, when actually backend Y was the one that trashed things.  
But that doesn't matter, because we'll force a cluster-wide reset  
regardless.  
  
Back-patch to all supported branches, since this is an old bug.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 07ce6769824c4081208122ae3c1b38812e4715ed    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 11 Oct 2022 18:24:14 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 11 Oct 2022 18:24:14 -0400    

DEFAULT markers appearing in an INSERT on an updatable view  
could be mis-processed if they were in a multi-row VALUES clause.  
This would lead to strange errors such as "cache lookup failed  
for type NNNN", or in older branches even to crashes.  
  
The cause is that commit 41531e42d tried to re-use rewriteValuesRTE()  
to remove any SetToDefault nodes (that hadn't previously been replaced  
by the view's own default values) appearing in "product" queries,  
that is DO ALSO queries.  That's fundamentally wrong because the  
DO ALSO queries might not even be INSERTs; and even if they are,  
their targetlists don't necessarily match the view's column list,  
so that almost all the logic in rewriteValuesRTE() is inapplicable.  
  
What we want is a narrow focus on replacing any such nodes with NULL  
constants.  (That is, in this context we are interpreting the defaults  
as being strictly those of the view itself; and we already replaced  
any that aren't NULL.)  We could add still more !force_nulls tests  
to further lobotomize rewriteValuesRTE(); but it seems cleaner to  
split out this case to a new function, restoring rewriteValuesRTE()  
to the charter it had before.  
  
Per bug #17633 from jiye_sw.  Patch by me, but thanks to  
Richard Guo and Japin Li for initial investigation.  
Back-patch to all supported branches, as the previous fix was.  
  
Discussion: https://postgr.es/m/[email protected]