PostgreSQL 17.0 (upcoming) commit log

commit   : e00b4f79e7367272b436dea6f15d6f421f3d6e1a    
  
author   : Andrew Dunstan <[email protected]>    
date     : Sat, 27 Apr 2024 07:02:57 -0400    
  
committer: Andrew Dunstan <[email protected]>    
date     : Sat, 27 Apr 2024 07:02:57 -0400    

JsonNonTerminal and JsonParserSem were added in commit 3311ea86ed  
  
These names of these two enums are not actually used, so there is no  
need for typedefs. Instead use plain enums to declare the constants.  
  
Noticed by Alvaro Herera.  

commit   : ed52df3b19ee77cca7cb5f202950704f6b12feb9    
  
author   : John Naylor <[email protected]>    
date     : Sat, 27 Apr 2024 14:42:01 +0700    
  
committer: John Naylor <[email protected]>    
date     : Sat, 27 Apr 2024 14:42:01 +0700    

- Bring memory context names in line with other naming  
- Fix typos, reported off-list by Alexander Lakhin  
- Remove copy-paste errors from comments  
- Remove duplicate #undef  

commit   : 1713e3d6cd393fcc1d4873e75c7fa1f6c7023d75    
  
author   : Robert Haas <[email protected]>    
date     : Fri, 26 Apr 2024 08:42:42 -0400    
  
committer: Robert Haas <[email protected]>    
date     : Fri, 26 Apr 2024 08:42:42 -0400    

The --tablespace-mapping option was specified with required_argument  
rather than no_argument, which is wrong. Since the actual argument  
string passed to getopt_long() included "T:", the single-character  
form of the option still worked, but the long form did not. Repair.  
  
The call to getopt_long() erroneously included "P", which doesn't  
correspond to any supported option. Remove.  
  
The help message used "do not" in one place and "don't" in another.  
Standardize on "do not".  
  
The documentation erroneously stated that the tablespace mappings  
would be applied relative to the pathnames in the first backup  
specified on the command line, rather than the final one. Fix.  
  
Thanks to Tomas Vondra and Daniel Gustafsson for alerting me to  
these mistakes.  
  
Discussion: http://postgr.es/m/CA+TgmoYFznwwaZhHSF1Ze7JeyBv-1yOoSrucKMw37WpF=7RP8g@mail.gmail.com  

commit   : 205db0114e03496f1d6febf276374900b6314e67    
  
author   : Robert Haas <[email protected]>    
date     : Thu, 25 Apr 2024 14:58:59 -0400    
  
committer: Robert Haas <[email protected]>    
date     : Thu, 25 Apr 2024 14:58:59 -0400    

If not all backups have the same checksum status, but the final backup  
has checksums enabled, then the output directory may include pages  
with invalid checksums. Document this limitation and explain how to  
work around it.  
  
In a future release, we may want to teach pg_combinebackup to  
recompute page checksums when required, but as feature freeze has come  
and gone, it seems a bit too late to do that for this release.  
  
Patch by me, reviewed by Daniel Gustafsson  
  
Discussion: http://postgr.es/m/CA+TgmoZugzOSmgkx97u3pc0M7U8LycWvugqoyWBv6j15a4hE5g@mail.gmail.com  

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

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

commit   : bb7f195ff78851e5fcee7230108a16d70be13579    
  
author   : Masahiko Sawada <[email protected]>    
date     : Thu, 25 Apr 2024 21:48:52 +0900    
  
committer: Masahiko Sawada <[email protected]>    
date     : Thu, 25 Apr 2024 21:48:52 +0900    

Also, fix a memory leak when updating from non-embeddable to  
embeddable. Both were unreachable without adding C code.  
  
Reported-by: Noah Misch  
Author: Noah Misch  
Reviewed-by: Masahiko Sawada, John Naylor  
Discussion: https://postgr.es/m/20240424210319.4c.nmisch%40google.com  

commit   : e03ec4641d2493db6fbfc60ff78d0f0b36d2ead1    
  
author   : Peter Eisentraut <[email protected]>    
date     : Thu, 25 Apr 2024 14:03:42 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Thu, 25 Apr 2024 14:03:42 +0200    

Formal tables should generally have an xref in the text that points to  
them.  Add them here.  

commit   : db08e8c6fa89ba9d2e80616448abe53316ceeef8    
  
author   : Amit Kapila <[email protected]>    
date     : Thu, 25 Apr 2024 14:01:44 +0530    
  
committer: Amit Kapila <[email protected]>    
date     : Thu, 25 Apr 2024 14:01:44 +0530    

Allow pg_sync_replication_slots() to error out during promotion of standby.  
This makes the behavior of the SQL function consistent with the slot sync  
worker. We also ensured that pg_sync_replication_slots() cannot be  
executed if sync_replication_slots is enabled and the slotsync worker is  
already running to perform the synchronization of slots. Previously, it  
would have succeeded in cases when the worker is idle and failed when it  
is performing sync which could confuse users.  
  
This patch fixes another issue in the slot sync worker where  
SignalHandlerForShutdownRequest() needs to be registered *before* setting  
SlotSyncCtx->pid, otherwise, the slotsync worker could miss handling  
SIGINT sent by the startup process(ShutDownSlotSync) if it is sent before  
worker could register SignalHandlerForShutdownRequest(). To be consistent,  
all signal handlers' registration is moved to a prior location before we  
set the worker's pid.  
  
Ensure that we clean up synced temp slots at the end of  
pg_sync_replication_slots() to avoid such slots being left over after  
promotion.  
  
Ensure that ShutDownSlotSync() captures SlotSyncCtx->pid under spinlock to  
avoid accessing invalid value as it can be reset by concurrent slot sync  
exit due to an error.  
  
Author: Shveta Malik  
Reviewed-by: Hou Zhijie, Bertrand Drouvot, Amit Kapila, Masahiko Sawada  
Discussion: https://postgr.es/m/CAJpy0uBefXUS_TSz=oxmYKHdg-fhxUT0qfjASW3nmqnzVC3p6A@mail.gmail.com  

commit   : 0afa288911d5af7b0f5bd7a1aa09cdea7f02590c    
  
author   : Peter Eisentraut <[email protected]>    
date     : Thu, 25 Apr 2024 10:08:07 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Thu, 25 Apr 2024 10:08:07 +0200    

A permission check is performed in be_lo_put() just after returning  
from inv_open(), but the permission is already checked in inv_open(),  
so we can remove the second check.  
  
This check was added in 8d9881911f0, but then the refactoring in  
ae20b23a9e7 should have removed it.  
  
Author: Yugo NAGATA <[email protected]>  
Discussion: https://www.postgresql.org/message-id/flat/20240424185932.9789628b99a49ec81b020425%40sraoss.co.jp  

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

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

commit   : ee3ef4af19d8ba140a8b33c6598d470d36eec10c    
  
author   : Michael Paquier <[email protected]>    
date     : Thu, 25 Apr 2024 10:20:49 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Thu, 25 Apr 2024 10:20:49 +0900    

This field is not used directly in the code, but it is important for  
query jumbling to be able to make a difference between a named  
DEALLOCATE and DEALLOCATE ALL (see bb45156f342c).  This behavior is  
tracked in the regression tests of pg_stat_statements, but the reason  
why this field is important can be easily missed, as a recent discussion  
has proved, so let's improve its comment to document the reason why it  
needs to be around.  
  
Wording has been suggested by Tom Lane  
  
Discussion: https://postgr.es/m/[email protected]  

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

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

commit   : cc893b82370b5d68e0a72f5bb1663644a3a0351d    
  
author   : Andrew Dunstan <[email protected]>    
date     : Wed, 24 Apr 2024 07:52:52 -0400    
  
committer: Andrew Dunstan <[email protected]>    
date     : Wed, 24 Apr 2024 07:52:52 -0400    

As noticed by Michael Paquier.  

commit   : 9d353639c3b37efea7a29b63027cef81a7c7e335    
  
author   : Daniel Gustafsson <[email protected]>    
date     : Wed, 24 Apr 2024 13:09:50 +0200    
  
committer: Daniel Gustafsson <[email protected]>    
date     : Wed, 24 Apr 2024 13:09:50 +0200    

The prompt in the crosstabview example was incorrectly indicating  
an open parenthesis where there is none in the example query. Fix  
by changing to the normal multi-line prompt.  
  
Reported-by: [email protected]  
Discussion: https://postgr.es/m/[email protected]  

commit   : b53d58097d7d5712d819d06e0416dec0a7db2479    
  
author   : Peter Eisentraut <[email protected]>    
date     : Wed, 24 Apr 2024 12:26:19 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Wed, 24 Apr 2024 12:26:19 +0200    

commit   : 83751691e9c89af15103220b62d78cf5be73dbfd    
  
author   : Peter Eisentraut <[email protected]>    
date     : Wed, 24 Apr 2024 12:12:57 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Wed, 24 Apr 2024 12:12:57 +0200    

(It was already on the man page.)  

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

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

commit   : 3886530caa01cac7179fed6b6e1d303710c027d9    
  
author   : Peter Eisentraut <[email protected]>    
date     : Wed, 24 Apr 2024 10:47:35 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Wed, 24 Apr 2024 10:47:35 +0200    

commit   : d80f2ce294653ce633984445c971dfb534578464    
  
author   : Daniel Gustafsson <[email protected]>    
date     : Wed, 24 Apr 2024 10:54:50 +0200    
  
committer: Daniel Gustafsson <[email protected]>    
date     : Wed, 24 Apr 2024 10:54:50 +0200    

The SSL_R_VERSION_TOO_LOW error reason is supported in LibreSSL since  
LibreSSL 3.6.3, shipped in OpenBSD 7.2.  SSL_R_VERSION_TOO_HIGH is on  
the other hand not supported in any version of LibreSSL.  Previously  
we only checked for SSL_R_VERSION_TOO_HIGH and then applied both under  
that guard since OpenSSL has only ever supported both at the same time.  
This breaks the check into one per reason to allow SSL_R_VERSION_TOO_LOW  
to work when using LibreSSL.  
  
Reviewed-by: Peter Eisentraut <[email protected]>  
Reviewed-by: Michael Paquier <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  

commit   : 44e27f0a6d07d194ee43e9e4095db75c0525112f    
  
author   : Daniel Gustafsson <[email protected]>    
date     : Wed, 24 Apr 2024 10:54:42 +0200    
  
committer: Daniel Gustafsson <[email protected]>    
date     : Wed, 24 Apr 2024 10:54:42 +0200    

LibreSSL doesn't support the SSL_OP_NO_RENEGOTIATION macro which is  
used by OpenSSL, instead it has invented a similar one for client-  
side renegotiation: SSL_OP_NO_CLIENT_RENEGOTIATION. This has been  
supported since LibreSSL 2.5.1 which by now can be considered well  
below the minimum requirement.  
  
Reviewed-by: Peter Eisentraut <[email protected]>  
Reviewed-by: Michael Paquier <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  

commit   : 91d6429fad55f0e440643993754216614a9f6b11    
  
author   : Daniel Gustafsson <[email protected]>    
date     : Wed, 24 Apr 2024 10:54:36 +0200    
  
committer: Daniel Gustafsson <[email protected]>    
date     : Wed, 24 Apr 2024 10:54:36 +0200    

The paragraph on SSL compression is largely describing events which  
took place many years ago, so reword with past tense.  
  
Reviewed-by: Peter Eisentraut <[email protected]>  
Reviewed-by: Michael Paquier <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  

commit   : 256b4b060614f4e54e49bb43a54404af4f1ef61d    
  
author   : Peter Eisentraut <[email protected]>    
date     : Wed, 24 Apr 2024 10:00:58 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Wed, 24 Apr 2024 10:00:58 +0200    

commit   : 286eea5d3ae33a8c22d46a051f8ac6069c8b779d    
  
author   : Peter Eisentraut <[email protected]>    
date     : Wed, 24 Apr 2024 09:19:59 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Wed, 24 Apr 2024 09:19:59 +0200    

Some options were listed in an order that was inconsistent with the  
--help output and everything else.  

commit   : f994ed89a98b9aed405c760f157a10125eb8d567    
  
author   : Peter Eisentraut <[email protected]>    
date     : Wed, 24 Apr 2024 08:56:21 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Wed, 24 Apr 2024 08:56:21 +0200    

It was working, but it was not shown in the --help output or on the  
man page.  

commit   : c3fa85b249e457898a24cb3125a4a1b6b9c0e631    
  
author   : Peter Eisentraut <[email protected]>    
date     : Wed, 24 Apr 2024 08:27:25 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Wed, 24 Apr 2024 08:27:25 +0200    

HAVE_LONG_LONG_INT was not added to ecpg_config.h.in by the meson  
build system, but rather than add it there, we decided to remove it  
from the makefile build system, to make both consistent that way.  
  
There is no documentation or examples that suggest that the presence  
of this symbol was publicly advertised, and of course the feature is  
required by C99 (but we don't necessarily require C99 for ecpg user  
code).  ecpg core code and ecpg tests use the symbol  
HAVE_LONG_LONG_INT_64 instead, which is still there.  
  
Discussion: https://www.postgresql.org/message-id/flat/bf35d032-02fc-4173-9f4f-840999cc3ef3%40eisentraut.org  

commit   : 89ad3e1316bf0374f9e57456bf2888d14bf070f6    
  
author   : Robert Haas <[email protected]>    
date     : Tue, 23 Apr 2024 16:33:19 -0400    
  
committer: Robert Haas <[email protected]>    
date     : Tue, 23 Apr 2024 16:33:19 -0400    

My previous attempt to add this had to be reverted in commit  
82023d47de9e262730b1f9b4ea77fae201a89d0a. I've revised the problematic  
code a bit; hopefully it is OK now.  
  
Discussion: http://postgr.es/m/CA+Tgmobiv1QJR5PEJoDKeZDrJHZFRmi4XmWOqufN49DJj-3e2g@mail.gmail.com  

commit   : ba3e6e2bca97df14920375b0a1ebf4eab95b78b5    
  
author   : Andrew Dunstan <[email protected]>    
date     : Tue, 23 Apr 2024 15:27:40 -0400    
  
committer: Andrew Dunstan <[email protected]>    
date     : Tue, 23 Apr 2024 15:27:40 -0400    

. Add missing copytight notices  
. improve code coverage  
. put work files in a temp directory in the standard location  
. improve error checking in C code  
. indent perl files with perltidy  
. add some comments  
  
per comments from Michael Paquier  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : b7d35d393edbe2d4333dde81496e8a362abc85bd    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 23 Apr 2024 12:55:26 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 23 Apr 2024 12:55:26 -0400    

JsonExprState.input_finfo is only assigned to, never read, and  
it's really fairly useless since the value can be gotten out of  
the adjacent input_fcinfo field.  Let's remove it before someone  
starts to depend on it.  
  
While here, also remove TidScanState.tss_htup and AggState.combinedproj,  
which are referenced nowhere.  Those should have been removed by the  
commits that caused them to become disused, but were not.  
  
I don't think a catversion bump is necessary here, since plan trees  
are never stored on disk.  
  
Matthias van de Meent  
  
Discussion: https://postgr.es/m/CAEze2WjsY4d0TBymLNGK4zpttUcg_YZaTjyWz2VfDUV6YH8wXQ@mail.gmail.com  

commit   : 598e0114a3b16bb7edcaba6784b3794f816889ae    
  
author   : Nathan Bossart <[email protected]>    
date     : Tue, 23 Apr 2024 10:54:04 -0500    
  
committer: Nathan Bossart <[email protected]>    
date     : Tue, 23 Apr 2024 10:54:04 -0500    

This commit fixes a few things:  
* Instead of checking for CPU support of the "xsave" extension, we  
  need to check for OS support of XGETBV instructions via the  
  "osxsave" flag.  
* We must check that additional XCR0 bits are set to be sure the  
  ZMM registers are fully enabled.  
* We should use the recommended ordering of steps.  Specifically,  
  we need to check that the ZMM registers are enabled prior to  
  checking for AVX-512 via CPUID.  
  
In passing, split this code into separate functions to improve  
readability.  
  
Reported-by: Andrew Kane  
Reviewed-by: Akash Shankaran, Raghuveer Devulapalli  
Discussion: https://postgr.es/m/20240418024459.GA3385227%40nathanxps13  

commit   : bb3ca232398658291d4b1eaae12cd6e88dfc96a3    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 23 Apr 2024 11:52:40 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 23 Apr 2024 11:52:40 -0400    

If the GUC has a unit, label the minimum and maximum values  
with the unit explicitly.  Per suggestion from Jian He.  
  
Discussion: https://postgr.es/m/CACJufxFJo6FyVg9W8yvNAxbjP+EJ9wieE9d9vw5LpPzyLnLLOQ@mail.gmail.com  

commit   : b29cbd3da4e37db17026b9fe58fb46fe83f467bf    
  
author   : Amit Kapila <[email protected]>    
date     : Tue, 23 Apr 2024 12:14:57 +0530    
  
committer: Amit Kapila <[email protected]>    
date     : Tue, 23 Apr 2024 12:14:57 +0530    

Do not allow ALTER SUBSCRIPTION ... SET (failover = on|off) in a  
transaction block as the changed failover option of the slot can't be  
rolled back. For the same reason, we refrain from altering the replication  
slot's failover property if the subscription is created with a valid  
slot_name and create_slot=false.  
  
Reprted-by: Kuroda Hayato  
Author: Hou Zhijie  
Reviewed-by: Shveta Malik, Bertrand Drouvot, Kuroda Hayato  
Discussion: https://postgr.es/m/OS0PR01MB57165542B09DFA4943830BF294082@OS0PR01MB5716.jpnprd01.prod.outlook.com  

commit   : 480bc6e3ed3a5719cdec076d4943b119890e8171    
  
author   : Peter Geoghegan <[email protected]>    
date     : Mon, 22 Apr 2024 13:58:06 -0400    
  
committer: Peter Geoghegan <[email protected]>    
date     : Mon, 22 Apr 2024 13:58:06 -0400    

Certain cases involving the use of cursors had assertion failures within  
_bt_preprocess_keys's recently added no-op return path.  The assertion  
in question made the faulty assumption that a second or third call to  
_bt_preprocess_keys (within the same btrescan) could only happen when  
another scheduled primitive index scan was just about to begin.  
  
It would be possible to address the problem by only allowing scans that  
have array keys to take the new no-op path, forcing affected cases to  
perform redundant preprocessing work.  It seems simpler to just remove  
the assertion, and reframe the no-op path as a more general mechanism.  
Take this simpler approach.  
  
The important underlying principle is that we only need to perform  
preprocessing once per btrescan (at most).  This is expected regardless  
of whether or not the scan happens to have array keys.  
  
Oversight in commit 1b134ca5, which enhanced nbtree ScalarArrayOp  
execution.  
  
Reported-By: Alexander Lakhin <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  

commit   : 7e44ac3741dd2ebf8c668d6ac6a10fa6ed7301b3    
  
author   : Peter Eisentraut <[email protected]>    
date     : Sun, 21 Apr 2024 18:41:57 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Sun, 21 Apr 2024 18:41:57 +0200    

for new downloaded files and new build results.  

commit   : 9e2e4f08bb6cc86710cb84459b7fd0f407e596a7    
  
author   : Peter Eisentraut <[email protected]>    
date     : Sun, 21 Apr 2024 18:40:21 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Sun, 21 Apr 2024 18:40:21 +0200    

No actual changes result.  

commit   : f46bee346c3b6aab0a0f3f39dc734732b79ce1ed    
  
author   : Michael Paquier <[email protected]>    
date     : Mon, 22 Apr 2024 15:15:36 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Mon, 22 Apr 2024 15:15:36 +0900    

pg_dump/restore failed to properly set the table access method for  
partitioned tables, as it relies on SET queries that would change  
default_table_access_method.  However, SET affects only tables and  
materialized views, not partitioned tables which would always be  
restored with their pg_class.relam set to 0, losing their table AM set  
by either a CREATE TABLE .. USING or by a ALTER TABLE .. SET ACCESS  
METHOD.  
  
Appending a USING clause to the definition of CREATE TABLE is not  
possible as users may specify --no-table-access-method at restore or for  
a dump, meaning that the table AM portions may have to be skipped.  
Rather than SET, the solution used by this commit is to generate an  
extra ALTER TABLE .. SET ACCESS METHOD when restoring a partitioned  
table, based on the table AM set in its TOC entry.  The choice of using  
a SET query or an ALTER TABLE query for a relation requires the addition  
of the relkind to the TOC entry to be able to choose between one or the  
other.  Note that using ALTER TABLE SET ACCESS METHOD on a relation with  
physical storage would require a full rewrite, which would be costly for  
one.  This also creates problems with binary upgrades where the rewrite  
would not be able to keep the OID of the relation consistent across the  
upgrade.  
  
This commit would normally require a protocol bump, but a45c78e3284b has  
already done one for this release cycle.  
  
Regression tests are adjusted with the new expected output, with some  
tweaks for the table AMs of the partitions to make the output more  
readable.  
  
Issue introduced by 374c7a229042, that has added support for table AMs  
in partitioned tables.  
  
Author: Michael Paquier  
Reviewed-by: Álvaro Herrera  
Discussion: https://postgr.es/m/[email protected]  

commit   : eff6a757fde3ba072a03dd06edc2eafeac5e602d    
  
author   : Peter Geoghegan <[email protected]>    
date     : Sun, 21 Apr 2024 22:51:56 -0400    
  
committer: Peter Geoghegan <[email protected]>    
date     : Sun, 21 Apr 2024 22:51:56 -0400    

This led to spurious assertion failures in certain scenarios involving  
pseudo types.  
  
Oversight in commit 5bf748b8, which enhanced nbtree ScalarArrayOp  
execution.  
  
Reported-By: Richard Guo <[email protected]>  
Discussion: https://postgr.es/m/CAMbWs48f5rDOwxaT76Zd40m7n9iGZQcjEk7vG_5p3YWNh6oPfA@mail.gmail.com  

commit   : 8c239ee15a4b093523ebe30bdc9af186aaccebfd    
  
author   : Tomas Vondra <[email protected]>    
date     : Sun, 21 Apr 2024 21:21:26 +0200    
  
committer: Tomas Vondra <[email protected]>    
date     : Sun, 21 Apr 2024 21:21:26 +0200    

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

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

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

commit   : f4fdc24aa35c2268f519905a3a66658ebd55a466    
  
author   : Tomas Vondra <[email protected]>    
date     : Sat, 20 Apr 2024 18:54:09 +0200    
  
committer: Tomas Vondra <[email protected]>    
date     : Sat, 20 Apr 2024 18:54:09 +0200    

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

commit   : 06a0f4d52be3a52a74725dd29c66cd486256a209    
  
author   : Michael Paquier <[email protected]>    
date     : Sat, 20 Apr 2024 18:01:03 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Sat, 20 Apr 2024 18:01:03 +0900    

This header is not used since the refactoring of resource owners done in  
b8bff07daa85, and all the functions declared in it became (well, mostly)  
static inline local to each resowner kind's code path.  
  
Author: Xing Guo  
Discussion: https://postgr.es/m/CACpMh+BFmtK5Z=b6PvH4HLKhUpWa_VtRTZSrB4-yK-tQejpWGw@mail.gmail.com  

commit   : 2d3389c28c5c8235221d2ae0776df4ab812b15c8    
  
author   : David Rowley <[email protected]>    
date     : Sat, 20 Apr 2024 13:53:35 +1200    
  
committer: David Rowley <[email protected]>    
date     : Sat, 20 Apr 2024 13:53:35 +1200    

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

commit   : 82023d47de9e262730b1f9b4ea77fae201a89d0a    
  
author   : Robert Haas <[email protected]>    
date     : Fri, 19 Apr 2024 17:21:56 -0400    
  
committer: Robert Haas <[email protected]>    
date     : Fri, 19 Apr 2024 17:21:56 -0400    

Commit 6bf5c42b5546984df29289918f952e6211069c54 cannot work on Windows,  
because it lacks symlink support. While the bug fix in commit  
cd64dc42d1e1b03e57e6ba3d316e4f9dec52a78d is correct as far as I know,  
the test case changes depend on the previous commit, so this will  
have to live without test coverage until we can come up with a better  
solution. Commit fa7036dd6644d13233b475874a94754a5903e35a was a test  
case bug fix on top of those two, to prevent failures on Linux, so that  
has to come out as well.  
  
Per the buildfarm, CI, and Thomas Munro.  

commit   : fa7036dd6644d13233b475874a94754a5903e35a    
  
author   : Robert Haas <[email protected]>    
date     : Fri, 19 Apr 2024 15:50:02 -0400    
  
committer: Robert Haas <[email protected]>    
date     : Fri, 19 Apr 2024 15:50:02 -0400    

After cd64dc42d1e1b03e57e6ba3d316e4f9dec52a78d, a significant  
percentage of the buildfarm got unhappy, because pg_basebackup chokes  
if it tries to create a tarfile with symlink more than 99 characters  
in length. To try to fix that problem, use tempdir_short instead of  
tempdir, as we do in pg_verifybackup's 003_corruption.pl.  
  
There's a more complicated workaround for the same issue in  
pg_basebackup's 010_pg_basebackup.pl, but I'm not clear whether  
there's any reason to do it that way here. For now, let's try this,  
to at least get the buildfarm green again.  
  
A better long-term fix would be to figure out how to generate tar  
files containing long symlinks, but that will have to wait for  
another time.  

commit   : cd64dc42d1e1b03e57e6ba3d316e4f9dec52a78d    
  
author   : Robert Haas <[email protected]>    
date     : Fri, 19 Apr 2024 13:30:42 -0400    
  
committer: Robert Haas <[email protected]>    
date     : Fri, 19 Apr 2024 13:30:42 -0400    

The previous coding mangled the pathname calculation for  
incremental files located in user-defined tablespaces.  
  
Enhance the test cases to cover such cases, as I should have  
done originally. Thanks to Andres Freund for alerting me to the  
lack of test coverage.  
  
Discussion: http://postgr.es/m/CA+TgmoYdXTjo9iQeoipTccDpWZzvBNS6EndY2uARM+T4yG_yDg@mail.gmail.com  

commit   : 6bf5c42b5546984df29289918f952e6211069c54    
  
author   : Robert Haas <[email protected]>    
date     : Wed, 17 Apr 2024 15:56:33 -0400    
  
committer: Robert Haas <[email protected]>    
date     : Wed, 17 Apr 2024 15:56:33 -0400    

This commit doesn't use this infrastructure for anything new, although  
it does adapt 010_pg_basebackup.pl to use it. However, a future commit  
will use this to improve test coverage for pg_combinebackup.  
  
Patch by me, reviewed (but not fully endorsed) by Andres Freund.  
  
Discussion: http://postgr.es/m/CA+TgmoYdXTjo9iQeoipTccDpWZzvBNS6EndY2uARM+T4yG_yDg@mail.gmail.com  

commit   : 41d2c6f952edc4841763d05296b65f3c0edad4f2    
  
author   : Tomas Vondra <[email protected]>    
date     : Fri, 19 Apr 2024 15:47:48 +0200    
  
committer: Tomas Vondra <[email protected]>    
date     : Fri, 19 Apr 2024 15:47:48 +0200    

The optimization for inserts into BRIN indexes added by c1ec02be1d79  
relies on a cache that needs to be explicitly released after calling  
index_insert(). The commit however failed to invoke the cleanup in  
validate_index(), which calls index_insert() indirectly through  
table_index_validate_scan().  
  
After inspecting index_insert() callers, it seems unique_key_recheck()  
is missing the call too.  
  
Fixed by adding the two missing index_insert_cleanup() calls.  
  
The commit does two additional improvements. The aminsertcleanup()  
signature is modified to have the index as the first argument, to make  
it more like the other AM callbacks. And the aminsertcleanup() callback  
is invoked even if the ii_AmCache is NULL, so that it can decide if the  
cleanup is necessary.  
  
Author: Alvaro Herrera, Tomas Vondra  
Reported-by: Alexander Lakhin  
Discussion: https://postgr.es/m/[email protected]  

commit   : 95d14b7ae26db5ed85d9945e29121bb0e9b59863    
  
author   : Tomas Vondra <[email protected]>    
date     : Fri, 19 Apr 2024 15:43:14 +0200    
  
committer: Tomas Vondra <[email protected]>    
date     : Fri, 19 Apr 2024 15:43:14 +0200    

Typos introduced by commits c1ec02be1d79, b43757171470 and dae761a87eda.  
  
Author: Alvaro Herrera  
Reported-by: Alexander Lakhin  
Discussion: https://postgr.es/m/[email protected]  

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

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

commit   : 0cd711271d42b0888d36f8eda50e1092c2fed4b3    
  
author   : Alvaro Herrera <[email protected]>    
date     : Fri, 19 Apr 2024 12:37:33 +0200    
  
committer: Alvaro Herrera <[email protected]>    
date     : Fri, 19 Apr 2024 12:37:33 +0200    

It is possible for certain cases to remove not-null constraints without  
maintaining the attnotnull in its correct state; for example if you drop  
a column that's part of the primary key, and the other columns of the PK don't  
have not-null constraints, then we should reset the attnotnull flags for  
those other columns; up to this commit, we didn't.  Handle those cases  
better by doing the attnotnull reset in RemoveConstraintById() instead  
of in dropconstraint_internal().  
  
However, there are some cases where we must not do so.  For example if  
those other columns are in replica identity indexes or are generated  
identity columns, we must keep attnotnull set, even though it results in  
the catalog inconsistency that no not-null constraint supports that.  
  
Because the attnotnull reset now happens in more places than before, for  
instance when a column of the primary key changes type, we need an  
additional trick to reinstate it as necessary.  Introduce a new  
alter-table pass that does this, which needs simply reschedule some  
AT_SetAttNotNull subcommands that were already being generated and  
ignored.  
  
Because of the exceptions in which attnotnull is not reset noted above,  
we also include a pg_dump hack to include a not-null constraint when the  
attnotnull flag is set even if no pg_constraint row exists.  This part  
is undesirable but necessary, because failing to handle the case can  
result in unrestorable dumps.  
  
Reported-by: Tender Wang <[email protected]>  
Co-authored-by: Tender Wang <[email protected]>  
Reviewed-by: jian he <[email protected]>  
Discussion: https://postgr.es/m/CAHewXN=hMbNa3d43NOR=OCgdgpTt18S-1fmueCoEGesyeK4bqw@mail.gmail.com  

commit   : 2e068db56e31dfb510fe7416e52b7affe26f278f    
  
author   : Dean Rasheed <[email protected]>    
date     : Fri, 19 Apr 2024 09:40:20 +0100    
  
committer: Dean Rasheed <[email protected]>    
date     : Fri, 19 Apr 2024 09:40:20 +0100    

Code quality improvement for 0294df2f1f84.  
  
Aleksander Alekseev, reviewed by Richard Guo.  
  
Discussion: https://postgr.es/m/CAJ7c6TMsiaV5urU_Pq6zJ2tXPDwk69-NKVh4AMN5XrRiM7N%2BGA%40mail.gmail.com  

commit   : f6e845133630fe08acf7ad640f6d8443f13b134a    
  
author   : Daniel Gustafsson <[email protected]>    
date     : Fri, 19 Apr 2024 09:58:04 +0200    
  
committer: Daniel Gustafsson <[email protected]>    
date     : Fri, 19 Apr 2024 09:58:04 +0200    

Commit aafc05de1bf5 removed StartSlotSyncWorker() but mistakenly left  
the prototype in slotsync.h.  Fix by removing.  
  
Reported-by: Alexander Lakhin <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  

commit   : 9c58bf1507bee00b8cda837a232401fec21e6873    
  
author   : Daniel Gustafsson <[email protected]>    
date     : Fri, 19 Apr 2024 09:58:00 +0200    
  
committer: Daniel Gustafsson <[email protected]>    
date     : Fri, 19 Apr 2024 09:58:00 +0200    

The function declaration for select_next_encryption_method use the  
variable name have_valid_connection, so fix the prototype in the  
header to match that.  
  
Reported-by: Alexander Lakhin <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  

commit   : 84db9a0eb10dd1dbee6db509c0e427fa237177dc    
  
author   : Daniel Gustafsson <[email protected]>    
date     : Thu, 18 Apr 2024 23:02:39 +0200    
  
committer: Daniel Gustafsson <[email protected]>    
date     : Thu, 18 Apr 2024 23:02:39 +0200    

This updates the link from pg_createsubscriber to initial data sync  
to actually link to the subsection in question as opposed to the  
main logical replication section.  
  
Author: Pavel Luzanov <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  

commit   : 950d4a2cb1d5f427dbccf70dbad510479cc4d8e6    
  
author   : Daniel Gustafsson <[email protected]>    
date     : Thu, 18 Apr 2024 21:28:07 +0200    
  
committer: Daniel Gustafsson <[email protected]>    
date     : Thu, 18 Apr 2024 21:28:07 +0200    

This fixes various typos, duplicated words, and tiny bits of whitespace  
mainly in code comments but also in docs.  
  
Author: Daniel Gustafsson <[email protected]>  
Author: Heikki Linnakangas <[email protected]>  
Author: Alexander Lakhin <[email protected]>  
Author: David Rowley <[email protected]>  
Author: Nazir Bilal Yavuz <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  

commit   : fbed6ebe41beb72d9b7978a414ed4e8515ed1b19    
  
author   : Robert Haas <[email protected]>    
date     : Thu, 18 Apr 2024 13:06:27 -0400    
  
committer: Robert Haas <[email protected]>    
date     : Thu, 18 Apr 2024 13:06:27 -0400    

Spotted by Martin Marqués.  
  
Discussion: http://postgr.es/m/CABeG9LvQMtsKrOkhcA_mKJu1duArw4v+smeJKurYGjPVBZFecg@mail.gmail.com  

commit   : f22e17f76cf569a797c45268081feadc8ebd68c7    
  
author   : Peter Geoghegan <[email protected]>    
date     : Thu, 18 Apr 2024 11:48:41 -0400    
  
committer: Peter Geoghegan <[email protected]>    
date     : Thu, 18 Apr 2024 11:48:41 -0400    

Preprocessing for nbtree index scans allowed array "input" scan keys  
already marked eliminated during array-specific preprocessing to be  
"fixed up" during preprocessing proper.  This allowed eliminated scan  
keys on DESC index columns to spurious have their strategy commuted,  
causing assertion failures.  
  
To fix, teach _bt_fix_scankey_strategy to ignore these scan keys.  This  
brings it in line with its only caller, _bt_preprocess_keys.  
  
Oversight in commit 5bf748b8, which enhanced nbtree ScalarArrayOp  
execution.  
  
Reported-By: Donghang Lin <[email protected]>  
Discussion: https://postgr.es/m/CAA=D8a2sHK6CAzZ=0CeafC-Y-MFXbYxnRSHvZTi=+JHu6kAa8Q@mail.gmail.com  

commit   : 9e72f6bfae1707fca1a297db433f6145d582a1c2    
  
author   : Robert Haas <[email protected]>    
date     : Thu, 18 Apr 2024 11:00:38 -0400    
  
committer: Robert Haas <[email protected]>    
date     : Thu, 18 Apr 2024 11:00:38 -0400    

Previously, they were recognized anywhere in an incremental backup  
directory; now, we restrict this to places where they are expected to  
appear. That means this code will need updating if we ever do  
incremental backups of files in other places (e.g. SLRU files), but  
it lets you create a file called INCREMENTAL.config (or something like  
that) at the top level of the data directory and still have things  
work.  
  
Patch by me, per request from David Steele, who also reviewed.  
  
Discussion: http://postgr.es/m/[email protected]  

commit   : d72d32f52d26c9588256de90b9bc54fe312cee60    
  
author   : Alvaro Herrera <[email protected]>    
date     : Thu, 18 Apr 2024 16:10:53 +0200    
  
committer: Alvaro Herrera <[email protected]>    
date     : Thu, 18 Apr 2024 16:10:53 +0200    

This part of my previous commit seems to have broken pg_upgrade on  
crake, at least from 9.2.  I'll see if there's a better fix, but in the  
meantime this should suffice to keep the buildfarm green.  

commit   : 2e2d4604d94318a304d350aee478bda91a521339    
  
author   : Robert Haas <[email protected]>    
date     : Thu, 18 Apr 2024 09:52:19 -0400    
  
committer: Robert Haas <[email protected]>    
date     : Thu, 18 Apr 2024 09:52:19 -0400    

We don't want users to think that pg_combinebackup is trying to check  
the validity of individual backups, because it isn't. Adjust the wording  
about sanity checks to make it clear that verification of individual  
backups is the job of pg_verifybackup, and that the checks performed  
by pg_combinebackup are around the relationships between the backups.  
  
Per discussion with David Steele.  
  
Discussion: http://postgr.es/m/[email protected]  

commit   : d9f686a72ee91f6773e5d2bc52994db8d7157a8e    
  
author   : Alvaro Herrera <[email protected]>    
date     : Thu, 18 Apr 2024 15:35:15 +0200    
  
committer: Alvaro Herrera <[email protected]>    
date     : Thu, 18 Apr 2024 15:35:15 +0200    

In tables with primary keys, pg_dump creates tables with primary keys by  
initially dumping them with throw-away not-null constraints (marked "no  
inherit" so that they don't create problems elsewhere), to later drop  
them once the primary key is restored.  Because of a unrelated  
consideration, on tables with children we add not-null constraints to  
all columns of the primary key when it is created.  
  
If both a table and its child have primary keys, and pg_dump happens to  
emit the child table first (and its throw-away not-null) and later its  
parent table, the creation of the parent's PK will fail because the  
throw-away not-null constraint collides with the permanent not-null  
constraint that the PK wants to add, so the dump fails to restore.  
  
We can work around this problem by letting the primary key "take over"  
the child's not-null.  This requires no changes to pg_dump, just two  
changes to ALTER TABLE: first, the ability to convert a no-inherit  
not-null constraint into a regular inheritable one (including recursing  
down to children, if there are any); second, the ability to "drop" a  
constraint that is defined both directly in the table and inherited from  
a parent (which simply means to mark it as no longer having a local  
definition).  
  
Secondarily, change ATPrepAddPrimaryKey() to acquire locks all the way  
down the inheritance hierarchy, in case we need to recurse when  
propagating constraints.  
  
These two changes allow pg_dump to reproduce more cases involving  
inheritance from versions 16 and older.  
  
Lastly, make two changes to pg_dump: 1) do not try to drop a not-null  
constraint that's marked as inherited; this allows a dump to restore  
with no errors if a table with a PK inherits from another which also has  
a PK; 2) avoid giving inherited constraints throwaway names, for the  
rare cases where such a constraint survives after the restore.  
  
Reported-by: Andrew Bille <[email protected]>  
Reported-by: Justin Pryzby <[email protected]>  
Discussion: https://postgr.es/m/CAJnzarwkfRu76_yi3dqVF_WL-MpvT54zMwAxFwJceXdHB76bOA@mail.gmail.com  
Discussion: https://postgr.es/m/Zh0aAH7tbZb-9HbC@pryzbyj2023  

commit   : e0d51e3bf45436bdf84d096916daea2af2c7ba6e    
  
author   : Peter Eisentraut <[email protected]>    
date     : Thu, 18 Apr 2024 11:32:22 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Thu, 18 Apr 2024 11:32:22 +0200    

Commit 7b8e2ae2f has turned cpluspluscheck from separate script into a  
--cplusplus option for headerscheck.  Update README correspondingly.  
  
Author: Anton Voloshin <[email protected]>  
Discussion: https://www.postgresql.org/message-id/[email protected]  

commit   : 2c7cea5a8e741b7f7f9f12700d59b49b376301a1    
  
author   : Amit Langote <[email protected]>    
date     : Thu, 18 Apr 2024 17:16:26 +0900    
  
committer: Amit Langote <[email protected]>    
date     : Thu, 18 Apr 2024 17:16:26 +0900    

c0fc0751862 wasn't careful about naming the DOMAIN used in some new  
tests in sqljson_queryfunc.sql so as not to clash with the name of a  
DOMAIN used in the nearby sqljson_jsontable.sql.  Fix by using a  
different name for the newly added DOMAIN in sqljson_queryfuncs.sql.  
  
Per buildfarm members canebrake and urutu.  
  
Discussion: https://postgr.es/m/CA+HiwqEjkbDxqqD3VJamc6R9+B102H7=SFYYOM7gKrxzJO35TQ@mail.gmail.com  

commit   : ef744ebb7340d42361ebd88d068b27b17e69de18    
  
author   : Amit Langote <[email protected]>    
date     : Thu, 18 Apr 2024 14:38:12 +0900    
  
committer: Amit Langote <[email protected]>    
date     : Thu, 18 Apr 2024 14:38:12 +0900    

This addresses some post-commit review comments for commits 6185c973,  
de3600452, and 9425c596a0, with the following changes:  
  
* Fix JSON_TABLE() syntax documentation to use the term  
  "path_expression" for JSON path expressions instead of  
  "json_path_specification" to be consistent with the other SQL/JSON  
  functions.  
  
* Fix a typo in the example code in JSON_TABLE() documentation.  
  
* Rewrite some newly added comments in jsonpath.h.  
  
* In JsonPathQuery(), add missing cast to int before printing an enum  
  value.  
  
Reported-by: Jian He <[email protected]>  
Discussion: https://postgr.es/m/CACJufxG_e0QLCgaELrr2ZNz7AxPeGCNKAORe3fHtFCQLsH4J4Q@mail.gmail.com  

commit   : c0fc0751862d4e9b7ca9d51f2cd79344690ec873    
  
author   : Amit Langote <[email protected]>    
date     : Thu, 18 Apr 2024 14:46:35 +0900    
  
committer: Amit Langote <[email protected]>    
date     : Thu, 18 Apr 2024 14:46:35 +0900    

SQL/JSON query functions allow specifying an expression to return  
when either of ON ERROR or ON EMPTY condition occurs when evaluating  
the JSON path expression.  The parser (transformJsonBehavior()) checks  
that the specified expression is one of the supported expressions, but  
there are two issues with how the check is done that are fixed in this  
commit:  
  
* No check for some expressions related to coercion, such as  
  CoerceViaIO, that may appear in the transformed user-specified  
  expressions that include cast(s)  
  
* An unsupported expression may be masked by a coercion-related  
  expression, which must be flagged by checking the latter's  
  argument expression recursively  
  
Author: Jian He <[email protected]>  
Author: Amit Langote <[email protected]>  
Reported-by: Jian He <[email protected]>  
Discussion: https://postgr.es/m/CACJufxEqhqsfrg_p7EMyo5zak3d767iFDL8vz_4%[email protected]  
Discussion: https://postgr.es/m/CACJufxGOerH1QJknm1noh-Kz5FqU4p7QfeZSeVT2tN_4SLXYNg@mail.gmail.com  

commit   : b4fad46b6bc8a9bf46ff689bcb1bd4edf8f267af    
  
author   : Amit Langote <[email protected]>    
date     : Thu, 18 Apr 2024 14:33:47 +0900    
  
committer: Amit Langote <[email protected]>    
date     : Thu, 18 Apr 2024 14:33:47 +0900    

This improves some error messages emitted by SQL/JSON query functions  
by mentioning column name when available, such as when they are  
invoked as part of evaluating JSON_TABLE() columns.  To do so, a new  
field column_name is added to both JsonFuncExpr and JsonExpr that is  
only populated when creating those nodes for transformed JSON_TABLE()  
columns.  
  
While at it, relevant error messages are reworded for clarity.  
  
Reported-by: Jian He <[email protected]>  
Suggested-by: Jian He <[email protected]>  
Discussion: https://postgr.es/m/CACJufxG_e0QLCgaELrr2ZNz7AxPeGCNKAORe3fHtFCQLsH4J4Q@mail.gmail.com  

commit   : 40126ac68f2ff96351cd6071350eb2d5cbd50145    
  
author   : Alexander Korotkov <[email protected]>    
date     : Thu, 18 Apr 2024 00:29:41 +0300    
  
committer: Alexander Korotkov <[email protected]>    
date     : Thu, 18 Apr 2024 00:29:41 +0300    

fefd9a3fed turned tail recursion of CommitTransactionCommand() and  
AbortCurrentTransaction() into iteration.  However, it splits the handling of  
cases between different functions.  
  
This commit puts the handling of all the cases into  
AbortCurrentTransactionInternal() and CommitTransactionCommandInternal().  
Now CommitTransactionCommand() and AbortCurrentTransaction() are just doing  
the repeated calls of internal functions.  
  
Reported-by: Andres Freund  
Discussion: https://postgr.es/m/20240415224834.w6piwtefskoh32mv%40awork3.anarazel.de  
Author: Andres Freund  

commit   : 3ab8cf92754d5ee4390af4e4840fb45d5bc25007    
  
author   : Andres Freund <[email protected]>    
date     : Wed, 17 Apr 2024 11:21:17 -0700    
  
committer: Andres Freund <[email protected]>    
date     : Wed, 17 Apr 2024 11:21:17 -0700    

GlobalVisTestNonRemovableHorizon() was only used for the implementation of  
snapshot_too_old, which was removed in f691f5b80a8. As using  
GlobalVisTestNonRemovableHorizon() is not particularly efficient, no new uses  
for it should be added. Therefore remove.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 0c2f5552d5d47c702f5077a2df131d3125d96132    
  
author   : Tomas Vondra <[email protected]>    
date     : Wed, 17 Apr 2024 18:31:43 +0200    
  
committer: Tomas Vondra <[email protected]>    
date     : Wed, 17 Apr 2024 18:31:43 +0200    

Commit b43757171470 added support for parallel builds of BRIN indexes,  
using code similar to BTREE. But there were to be a couple unnecessary  
differences, particularly in how the leader waits for the workers, and  
merges the results. So remove these, to make the code more similar.  
  
The leader never waited on the workersdonecv condition variable, but  
simply called WaitForParallelWorkersToFinish() in _brin_end_parallel()  
and then merged the per-worker results. This worked correctly, but it  
seems better to do the wait and merge before _brin_end_parallel().  
  
This commit moves the relevant code to _brin_parallel_heapscan/merge(),  
which means  _brin_end_parallel() remains responsible only for exiting  
the parallel mode and accumulating WAL usage data.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 0bd4b0689ba1f12fbbd9919ca76a71df3e7702a2    
  
author   : Tomas Vondra <[email protected]>    
date     : Wed, 17 Apr 2024 16:14:44 +0200    
  
committer: Tomas Vondra <[email protected]>    
date     : Wed, 17 Apr 2024 16:14:44 +0200    

As explained in 4d916dd876, the test instability is caused by delayed  
cleanup of deleted rows. This commit removes the DELETE, stabilizing the  
test without accidentally disabling parallel builds.  
  
The intent of the delete however was to produce empty ranges, and test  
that the parallel index build populates those correctly. But there's  
another way to create empty ranges - partial indexes, which does not  
rely on cleanup of deleted rows.  
  
Idea to use partial indexes by Matthias van de Meent, patch by me.  
  
Discussion: https://postgr.es/m/95d9cd43-5a92-407c-b7e4-54cd303630fe%40enterprisedb.com  

commit   : a89cd7bfcdbb45a2c23b4b6004f4503f04f83bd7    
  
author   : Tomas Vondra <[email protected]>    
date     : Wed, 17 Apr 2024 16:12:03 +0200    
  
committer: Tomas Vondra <[email protected]>    
date     : Wed, 17 Apr 2024 16:12:03 +0200    

This reverts commit 4d916dd876c3. The goal of that commit was to  
stabilize a test of parallel BRIN build, but using a TEMPORARY table  
disables parallel index builds on that table, making the test useless.  
  
Discussion: https://postgr.es/m/95d9cd43-5a92-407c-b7e4-54cd303630fe%40enterprisedb.com  

commit   : 5165d43680dafafcc3d8c1a0a781b9aa33064ea6    
  
author   : Peter Eisentraut <[email protected]>    
date     : Wed, 17 Apr 2024 15:16:39 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Wed, 17 Apr 2024 15:16:39 +0200    

The checks for  
  
HAVE_DECL_LLVMCREATEGDBREGISTRATIONLISTENER and  
HAVE_DECL_LLVMCREATEPERFJITEVENTLISTENER  
  
are in configure but are missing on the meson side.  This adds those.  
  
Reported-by: Heikki Linnakangas <[email protected]>  
Discussion: https://www.postgresql.org/message-id/[email protected]  

commit   : ca89db5f9d0b03a10706312bbe8b8a43b1ec7538    
  
author   : Peter Eisentraut <[email protected]>    
date     : Wed, 17 Apr 2024 10:46:43 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Wed, 17 Apr 2024 10:46:43 +0200    

The configure check for HAVE_DECL_LLVMORCREGISTERPERF was removed by  
e9a9843e138, but some code guarded by it was left.  (That commit  
removed the "register" calls but left the "unregister" calls.)  That  
code cannot be reached anymore, so remove it.  
  
Reported-by: Heikki Linnakangas <[email protected]>  
Discussion: https://www.postgresql.org/message-id/[email protected]  

commit   : 2e75492b3c33beaf226981b796d81b6127544fea    
  
author   : Peter Eisentraut <[email protected]>    
date     : Wed, 17 Apr 2024 09:09:53 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Wed, 17 Apr 2024 09:09:53 +0200    

commit   : f6f8ac8e75c9af5a599fa658d9125875f16ab08c    
  
author   : Masahiko Sawada <[email protected]>    
date     : Wed, 17 Apr 2024 16:10:18 +0900    
  
committer: Masahiko Sawada <[email protected]>    
date     : Wed, 17 Apr 2024 16:10:18 +0900    

ON_ERROR option values don't require quotations, which was  
inconsistent with the syntax synopsis in the documentation.  
  
Oversight in b725b7eec43.  
  
Author: Atsushi Torikoshi  
Reviewed-by: Masahiko Sawada  
Discussion: https://postgr.es/m/CAD21AoC%3Dn4xR3%2BKQiqodnfT9chSB62XwZqmMff39H%3Dx9DS4scQ%40mail.gmail.com  

commit   : 91fe092a966e6c08c0ead80388f474ac989dc9a3    
  
author   : Michael Paquier <[email protected]>    
date     : Wed, 17 Apr 2024 14:56:31 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Wed, 17 Apr 2024 14:56:31 +0900    

Databases exist, contrary to datatabases.  
  
Oversight in e83d1b0c40cc.  
  
Author: Japin Li  
Discussion: https://postgr.es/m/ME3P282MB316611A2F7BF43919F695228B6082@ME3P282MB3166.AUSP282.PROD.OUTLOOK.COM  

commit   : a6d0fa5ef840bc98e14cb34ecf672e6e2e245517    
  
author   : Masahiko Sawada <[email protected]>    
date     : Wed, 17 Apr 2024 11:31:27 +0900    
  
committer: Masahiko Sawada <[email protected]>    
date     : Wed, 17 Apr 2024 11:31:27 +0900    

The ON_ERROR option of the COPY command previously allowed omitting  
its value, which was inconsistent with the syntax synopsis in the  
documentation and the behavior of other non-boolean COPY options.  
  
This change enforces providing a value for the ON_ERROR option,  
ensuring consistency across other non-boolean options and aligning  
with the documented syntax.  
  
Author: Atsushi Torikoshi  
Reviewed-by: Masahiko Sawada  
Discussion: https://postgr.es/m/a9770bf57646d90dedc3d54cf32634b2%40oss.nttdata.com  

commit   : 58cf2e120e8aee2daed5a9b9ee4471574f712b3b    
  
author   : David Rowley <[email protected]>    
date     : Wed, 17 Apr 2024 10:49:09 +1200    
  
committer: David Rowley <[email protected]>    
date     : Wed, 17 Apr 2024 10:49:09 +1200    

Oversight in 29f6a959c.  
  
In passing, since we now have 4 memory context types to choose from,  
provide a brief overview of the specialities of each memory context  
type.  
  
Reported-by: Amul Sul  
Author: Amul Sul, David Rowley  
Discussion: https://postgr.es/m/CAAJ_b94U2s9nHh--DEK=sPEZUQ+x7vQJ7529fF8UAH97QJ9NXg@mail.gmail.com  

commit   : 6d2fd66b9908d1557d7e49b1bdb4c597192f3729    
  
author   : David Rowley <[email protected]>    
date     : Wed, 17 Apr 2024 10:40:31 +1200    
  
committer: David Rowley <[email protected]>    
date     : Wed, 17 Apr 2024 10:40:31 +1200    

BumpContext relies on using the head block from its 'blocks' field to  
use as the current block to allocate new chunks to.  When we receive an  
allocation request larger than allocChunkLimit, we place these chunks on  
a new dedicated block and, until now, we pushed the block onto the  
*head* of the 'blocks' list.  
  
This behavior caused the previous bump block to no longer be available  
for new normal-sized (non-large) allocations and would result in blocks  
only being partially filled if a large allocation request arrived before  
the block became full.  
  
Here adjust the code to push these dedicated blocks onto the *tail* of  
the blocks list so that the head block remains intact and available to  
be used by normal allocation request sizes until it becomes full.  
  
In passing, make the elog(ERROR) calls for the unsupported callbacks  
consistent.  Likewise for the header comments for those functions.  
  
Discussion: https://postgr.es/m/CAApHDvp9___r-ayJj0nZ6GD3MeCGwGZ0_6ZptWpwj+zqHtmwCw@mail.gmail.com  
Discussion: https://postgr.es/m/CAApHDvqerXpzUnuDQfUEi3DZA+9=Ud9WSt3ruxN5b6PcOosx2g@mail.gmail.com  

commit   : 2ea5d8bece85518b4b8c052ff134c294c21543e0    
  
author   : Peter Eisentraut <[email protected]>    
date     : Tue, 16 Apr 2024 20:22:41 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Tue, 16 Apr 2024 20:22:41 +0200    

Some new code probably didn't see 605721f819f and continued to use  
type int for parse location fields.  Fix those.  

commit   : ec07d0d7fae9ac990061bef1aa8995f842839a40    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 16 Apr 2024 13:00:40 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 16 Apr 2024 13:00:40 -0400    

Per buildfarm member koel.  

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

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

commit   : c62d2ebd9e6f94758f5ed3a28cf08861229ae421    
  
author   : Peter Geoghegan <[email protected]>    
date     : Tue, 16 Apr 2024 12:04:20 -0400    
  
committer: Peter Geoghegan <[email protected]>    
date     : Tue, 16 Apr 2024 12:04:20 -0400    

Oversight in commit c9c0589fda.  

commit   : 984c0eccd0ccfcd7df8df47586e3b935a8124a15    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 16 Apr 2024 11:37:51 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 16 Apr 2024 11:37:51 -0400    

6377e12a5 should not have removed AcquireSampleRowsFunc,  
as that's still in use.  Per buildfarm member koel.  

commit   : 4d916dd876c3d9a4ceff5a0c54c5c58a0d1052e3    
  
author   : Tomas Vondra <[email protected]>    
date     : Tue, 16 Apr 2024 17:31:03 +0200    
  
committer: Tomas Vondra <[email protected]>    
date     : Tue, 16 Apr 2024 17:31:03 +0200    

The test for parallel create of BRIN indexes added by commit 8225c2fd40  
happens to be unstable - a background transaction (e.g. auto-analyze)  
may hold back global xmin for the initial VACUUM / CREATE INDEX. If the  
cleanup happens before the next CREATE INDEX, the indexes will not be  
exactly the same.  
  
This is the same issue as e2933a6e11, so fix it the same way by making  
the table TEMPORARY, which uses an up-to-date cutoff xmin that is not  
held back by other processes.  
  
Reported by Alexander Lakhin, who also suggested the fix.  
  
Author: Alexander Lakhin  
Discussion: https://postgr.es/m/[email protected]  
Discussion: https://postgr.es/m/[email protected]  

commit   : 03107b4eda7f2946bb78308cb088a513b718c793    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 16 Apr 2024 11:03:43 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 16 Apr 2024 11:03:43 -0400    

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

commit   : f6987041557f2b2b96f116c1f3150f9ed9a77c89    
  
author   : Peter Geoghegan <[email protected]>    
date     : Tue, 16 Apr 2024 11:20:41 -0400    
  
committer: Peter Geoghegan <[email protected]>    
date     : Tue, 16 Apr 2024 11:20:41 -0400    

Oversight in commit 0d861bbb70.  

commit   : aa1def44c301ce7fae9ae33f0a95bc01efa297a3    
  
author   : Peter Geoghegan <[email protected]>    
date     : Tue, 16 Apr 2024 11:14:36 -0400    
  
committer: Peter Geoghegan <[email protected]>    
date     : Tue, 16 Apr 2024 11:14:36 -0400    

Oversight in commit e5d8a99903.  

commit   : 6377e12a5a5278446bb0d215439b4825ef8996d1    
  
author   : Alexander Korotkov <[email protected]>    
date     : Tue, 16 Apr 2024 13:14:20 +0300    
  
committer: Alexander Korotkov <[email protected]>    
date     : Tue, 16 Apr 2024 13:14:20 +0300    

This commit reverts 27bc1772fc and dd1f6b0c17.  Per review by Andres Freund.  
  
Discussion: https://postgr.es/m/20240415201057.khoyxbwwxfgzomeo%40awork3.anarazel.de  

commit   : bea97cd02ebb347ab469b78673c2b33a72109669    
  
author   : David Rowley <[email protected]>    
date     : Tue, 16 Apr 2024 16:21:31 +1200    
  
committer: David Rowley <[email protected]>    
date     : Tue, 16 Apr 2024 16:21:31 +1200    

There were no callers of BumpAllocLarge() in the regression tests, so  
here we add a sort with a tuple large enough to use that path in bump.c.  
  
Also, BumpStats() wasn't being called, so add a test to sysviews.sql to  
call pg_backend_memory_contexts() while a bump context exists in the  
backend.  
  
Reported-by: Andres Freund  
Discussion: https://postgr.es/m/[email protected]  

commit   : 768ceeeaa127a8001d60ad6a62846a8be3f35d93    
  
author   : Michael Paquier <[email protected]>    
date     : Tue, 16 Apr 2024 09:38:46 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Tue, 16 Apr 2024 09:38:46 +0900    

All backend-side variables should be marked with PGDLLIMPORT, as per  
policy introduced in 8ec569479f.  aafc05de1bf5 has forgotten  
MyClientSocket, and 05c3980e7f47 LoadedSSL.  
  
These can be spotted with a command like this one (be careful of not  
switching __pg_log_level):  
src/tools/mark_pgdllimport.pl $(git ls-files src/include/)  
  
Reported-by: Peter Eisentraut  
Discussion: https://postgr.es/m/[email protected]  

commit   : 09d9800e52822ed20d69d98aaa39d3fb10769c44    
  
author   : Robert Haas <[email protected]>    
date     : Mon, 15 Apr 2024 15:46:19 -0400    
  
committer: Robert Haas <[email protected]>    
date     : Mon, 15 Apr 2024 15:46:19 -0400    

Previously, we had consecutive, very short chapters called "Generic  
WAL" and "Custom WAL Resource Managers," explaining different approaches  
to the same problem. Merge them into a single chapter. Explain most  
of the differences between the approaches in the chapter's  
introductory text, rather than in the individual sections.  
  
Discussion: http://postgr.es/m/[email protected]  

commit   : 953cf49e166a1a64e1eaf2b091b84e02848b8c75    
  
author   : Nathan Bossart <[email protected]>    
date     : Mon, 15 Apr 2024 14:03:24 -0500    
  
committer: Nathan Bossart <[email protected]>    
date     : Mon, 15 Apr 2024 14:03:24 -0500    

The documentation for SET ROLE states that superusers who switch to  
a non-superuser role lose their superuser privileges.  While this  
is true for most commands, there are exceptions such as SET ROLE  
and SET SESSION AUTHORIZATION, which continue to use the current  
session user and the authenticated user, respectively.  
Furthermore, the description of this command already describes its  
effect, so it is arguably unnecessary to include this special case.  
This commit removes the note about the superuser case and adds a  
sentence about the aforementioned exceptions to the description.  
  
Co-authored-by: Yurii Rashkovskii  
Reviewed-by: Shubham Khanna, Robert Haas, Michael Paquier  
Discussion: https://postgr.es/m/CA%2BRLCQysHtME0znk2KUMJN343ksboSRQSU-hCnOjesX6VK300Q%40mail.gmail.com  

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

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

commit   : cee8db3f680b737b64d747530b48d30828cf4790    
  
author   : Alvaro Herrera <[email protected]>    
date     : Mon, 15 Apr 2024 15:07:47 +0200    
  
committer: Alvaro Herrera <[email protected]>    
date     : Mon, 15 Apr 2024 15:07:47 +0200    

When matching constraints in AttachPartitionEnsureIndexes() we weren't  
testing the constraint type, which could make a UNIQUE key lacking a  
not-null constraint incorrectly satisfy a primary key requirement.  Fix  
this by testing that the constraint types match.  (Other possible  
mismatches are verified by comparing index properties.)  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 9dfcac8e15acc3b4d4d5bc02383a56ccb07229fe    
  
author   : Alexander Korotkov <[email protected]>    
date     : Mon, 15 Apr 2024 15:41:37 +0300    
  
committer: Alexander Korotkov <[email protected]>    
date     : Mon, 15 Apr 2024 15:41:37 +0300    

The fixes relate to comments, error messages, and corresponding expected output  
of regression tests.  
  
Discussion: https://postgr.es/m/CAMbWs49DDsknxyoycBqiE72VxzL_sYHF6zqL8dSeNehKPJhkKg%40mail.gmail.com  
Discussion: https://postgr.es/m/86bfd241-a58c-479a-9a72-2c67a02becf8%40postgrespro.ru  
Discussion: https://postgr.es/m/CAHewXNkGMPU50QG7V6Q60JGFORfo8LfYO1_GCkCa0VWbmB-fEw%40mail.gmail.com  
Author: Richard Guo, Dmitry Koval, Tender Wang  

commit   : c3709100be73ad5af7ff536476d4d713bca41b1a    
  
author   : Alvaro Herrera <[email protected]>    
date     : Mon, 15 Apr 2024 12:20:56 +0200    
  
committer: Alvaro Herrera <[email protected]>    
date     : Mon, 15 Apr 2024 12:20:56 +0200    

In one of the many strange corner cases of multiple inheritance being  
used, commit b0e96f311985 missed a CommandCounterIncrement() call after  
updating the attnotnull flag during ALTER TABLE ADD COLUMN, which caused  
a catalog tuple to be update attempted twice in the same command, giving  
rise to a "tuple already updated by self" error.  Add the missing call  
to solve that, and a test case that reproduces the scenario.  
  
As a (perhaps surprising) secondary effect, this CCI addition triggers  
another behavior change: when a primary key is added to a parent  
partitioned table and the column in an existing partition does not have  
a not-null constraint, we no longer error out.  This will probably be a  
welcome change by some users, and I think it's unlikely that anybody  
will miss the old behavior.  
  
Reported-by: Alexander Lakhin <[email protected]>  
Discussion: http://postgr.es/m/[email protected]  

commit   : 6ff21c05302592874b8149421711e06043b954fe    
  
author   : Peter Eisentraut <[email protected]>    
date     : Mon, 15 Apr 2024 09:28:48 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Mon, 15 Apr 2024 09:28:48 +0200    

\dD showed domain check constraints in arbitrary order, which can  
cause regression test failures, which was exposed by commit  
9895b35cb8.  To fix, order the constraints by conname, which matches  
what psql does in other queries listing constraints.  

commit   : 9895b35cb88edc30b836661dbc26d7665716b5a0    
  
author   : Peter Eisentraut <[email protected]>    
date     : Mon, 15 Apr 2024 08:20:34 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Mon, 15 Apr 2024 08:20:34 +0200    

This addresses a few problems with commit e5da0fe3c22 ("Catalog domain  
not-null constraints").  
  
In CREATE DOMAIN, a NOT NULL constraint looks like  
  
    CREATE DOMAIN d1 AS int [ CONSTRAINT conname ] NOT NULL  
  
(Before e5da0fe3c22, the constraint name was accepted but ignored.)  
  
But in ALTER DOMAIN, a NOT NULL constraint looks like  
  
    ALTER DOMAIN d1 ADD [ CONSTRAINT conname ] NOT NULL VALUE  
  
where VALUE is where for a table constraint the column name would be.  
(This works as of e5da0fe3c22.  Before e5da0fe3c22, this syntax  
resulted in an internal error.)  
  
But for domains, this latter syntax is confusing and needlessly  
inconsistent between CREATE and ALTER.  So this changes it to just  
  
    ALTER DOMAIN d1 ADD [ CONSTRAINT conname ] NOT NULL  
  
(None of these syntaxes are per SQL standard; we are just living with  
the bits of inconsistency that have built up over time.)  
  
In passing, this also changes the psql \dD output to not show not-null  
constraints in the column "Check", since it's already shown in the  
column "Nullable".  This has also been off since e5da0fe3c22.  
  
Reviewed-by: jian he <[email protected]>  
Discussion: https://www.postgresql.org/message-id/flat/9ec24d7b-633d-463a-84c6-7acff769c9e8%40eisentraut.org  

commit   : d21d61b96f7a4d89e4b2e7cc9b9a1ec3f642fa12    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Sun, 14 Apr 2024 23:02:43 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Sun, 14 Apr 2024 23:02:43 +0300    

Coverity pointed out that the function checks for conn->sslmode !=  
NULL, which implies that it might be NULL, but later we access it  
without a NULL-check anyway. It doesn't know that it is in fact always  
initialized earlier, in conninfo_add_defaults(), and hence the  
NULL-check is not necessary. However, there is a lot of distance  
between conninfo_add_defaults() and pqConnectOptions2(), so it's not  
surprising that it doesn't see that. Put back the initialization code,  
as it existed before commit 05fd30c0e7, to silence the warning.  
  
In the long run, I'd like to refactor the libpq options handling and  
initalization code. It seems silly to strdup() and copy strings, for  
things like sslmode that have a limited set of possible values; it  
should be an enum. But that's for another day.  

commit   : cd4b6af620975bb9802c464a06d2289d2f97cbf4    
  
author   : Tomas Vondra <[email protected]>    
date     : Sun, 14 Apr 2024 20:34:29 +0200    
  
committer: Tomas Vondra <[email protected]>    
date     : Sun, 14 Apr 2024 20:34:29 +0200    

Commit 10e3226ba13d added padding to incremental backups to ensure the  
block data is properly aligned. The code in sendFile() however failed to  
consider that the header may be a multiple of BLCKSZ and thus already  
aligned, adding a full BLCKSZ of unnecessary padding.  
  
Not only does this make the incremental file a bit larger, but the other  
places calculating the amount of padding did realize it's not needed and  
did not include it in the formula. This resulted in pg_basebackup  
getting confused while parsing the data stream, trying to access files  
with invalid filenames (e.g. with binary data etc.) and failing.  

commit   : 8225c2fd40cd9f7d60a826affeacdd8bf0de7bee    
  
author   : Tomas Vondra <[email protected]>    
date     : Sun, 14 Apr 2024 18:58:30 +0200    
  
committer: Tomas Vondra <[email protected]>    
date     : Sun, 14 Apr 2024 18:58:30 +0200    

Adds a regression test for parallel CREATE INDEX for BRIN indexes, to  
improve coverage for BRIN code, particularly code to allow parallel  
index builds introduced by b43757171470.  
  
The test is added to pageinspect, as that allows comparing the index to  
one built without parallelism. Another option would be to just build the  
index with parallelism and then check it produces correct results. But  
checking the index is exactly as if built without parallelism makes  
these query checks unnecessary.  
  
Discussion: https://postgr.es/m/1df00a66-db5a-4e66-809a-99b386a06d86%40enterprisedb.com  

commit   : bb616ed3e6a2b263be320026e1660bd36827c858    
  
author   : Tomas Vondra <[email protected]>    
date     : Sun, 14 Apr 2024 18:19:52 +0200    
  
committer: Tomas Vondra <[email protected]>    
date     : Sun, 14 Apr 2024 18:19:52 +0200    

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

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

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

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

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

commit   : 68ba46dfe38c0bdb1078e25222322ad1043abd87    
  
author   : Noah Misch <[email protected]>    
date     : Sat, 13 Apr 2024 07:56:14 -0700    
  
committer: Noah Misch <[email protected]>    
date     : Sat, 13 Apr 2024 07:56:14 -0700    

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

commit   : 4cc1c76fe9f13aa96bae14f4fcfdf6d508af72a4    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Fri, 12 Apr 2024 19:52:39 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Fri, 12 Apr 2024 19:52:39 +0300    

In the libpq encryption negotiation tests, don't run the GSSAPI tests  
unless PG_TEST_EXTRA='kerberos' is also set. That makes it possible to  
still run most of the tests when GSSAPI support is compiled in, but  
there's no MIT Kerberos installation.  

commit   : 65dfe9d167e925cd8892dedb51dde29f69b7388d    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Fri, 12 Apr 2024 19:52:37 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Fri, 12 Apr 2024 19:52:37 +0300    

The test targets libpq's options, so 'src/test/interfaces/libpq/t' is  
a more natural place for it.  
  
While doing this, I noticed that I had missed adding the  
libpq_encryption subdir to the Makefile. That's why this commit only  
needs to remove it from the meson.build file.  
  
Per Peter Eisentraut's suggestion.  
  
Discussion: https://www.postgresql.org/message-id/[email protected]  

commit   : 084cae55131f71f32e15a6b2b7897aa1c7382c0a    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Fri, 12 Apr 2024 19:52:34 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Fri, 12 Apr 2024 19:52:34 +0300    

The #define is spelled ENABLE_GSS, not USE_GSS. Introduced in commit  
05fd30c0e7, reported by Thomas Munro.  
  
Discussion: https://www.postgresql.org/message-id/CA%2BhUKG%2BHRTtB%2Bx%[email protected]  

commit   : 0a5f2291891ffca96ccd3ef29c9c1541a9277970    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Fri, 12 Apr 2024 19:52:28 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Fri, 12 Apr 2024 19:52:28 +0300    

It correctly skipped tests involving SSL in the server when SSL  
support was not compiled in, but even when SSL is not enabled in the  
server and the connection is established without SSL, libpq behaves  
differently in many of the test scenarios when libpq is compiled  
without SSL support. For example, with sslmode=prefer, if libpq is  
compiled with SSL support it will attempt to use SSL, but without SSL  
support it will try authenticating in plaintext mode directly. The  
expected test output didn't take that into account.  
  
Discussion: https://www.postgresql.org/message-id/CA%2BhUKG%2BHRTtB%2Bx%[email protected]  

commit   : 929c05774b512bdf7ea4a5912fa2f4d63fc90712    
  
author   : Andrew Dunstan <[email protected]>    
date     : Fri, 12 Apr 2024 10:52:25 -0400    
  
committer: Andrew Dunstan <[email protected]>    
date     : Fri, 12 Apr 2024 10:52:25 -0400    

Per complaint from Andres Freund. Follow his suggestion to allocate the  
buffer once in the calling routine instead.  
  
Also make a tiny indentation improvement.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 42fa4b660143b66bea1fb90793ec90054e170c93    
  
author   : Andrew Dunstan <[email protected]>    
date     : Tue, 9 Apr 2024 15:30:48 -0400    
  
committer: Andrew Dunstan <[email protected]>    
date     : Tue, 9 Apr 2024 15:30:48 -0400    

Per gripes from Michael Paquier  
  
Discussion: https://postgr.es/m/[email protected]  
  
Along the way, also clean up a handful of typos in 3311ea86ed and  
ea7b4e9a2a, found by Alexander Lakhin, and a couple of stylistic  
snafus noted by Daniel Westermann and Daniel Gustafsson.  

commit   : b8a7bfa33324bc40c7180cb946a39378fb48309c    
  
author   : Andrew Dunstan <[email protected]>    
date     : Tue, 9 Apr 2024 14:35:08 -0400    
  
committer: Andrew Dunstan <[email protected]>    
date     : Tue, 9 Apr 2024 14:35:08 -0400    

Also delete live URLs  
  
Jacob Champion  
  
Discussion: https://postgr.es/m/CAOYmi+mtH=V1wZKAOauCd5QqQWr61hnXMJbJ9h-CZXAa1JXd3w@mail.gmail.com  

commit   : daf554dbeabf0957a25c9e37488d42c047c0ce23    
  
author   : Andrew Dunstan <[email protected]>    
date     : Tue, 9 Apr 2024 14:23:20 -0400    
  
committer: Andrew Dunstan <[email protected]>    
date     : Tue, 9 Apr 2024 14:23:20 -0400    

This just makes sure the test can run with a single iteration. A real  
performance test would test with many more.  

commit   : 661ab4e185784db79c194b5758555b1db3f30483    
  
author   : Andrew Dunstan <[email protected]>    
date     : Tue, 9 Apr 2024 09:07:14 -0400    
  
committer: Andrew Dunstan <[email protected]>    
date     : Tue, 9 Apr 2024 09:07:14 -0400    

Coverity complained about not freeing some memory associated with  
incrementally parsing backup manifests. To fix that, provide and use a new  
shutdown function for the JsonManifestParseIncrementalState object, in  
line with a suggestion from Tom Lane.  
  
While analysing the problem, I noticed a buglet in freeing memory for  
incremental json lexers. To fix that remove a bogus condition on  
freeing the memory allocated for them.  

commit   : b9ecefecc7aaad117e0255b56b759f524f0f4363    
  
author   : David Rowley <[email protected]>    
date     : Fri, 12 Apr 2024 23:15:52 +1200    
  
committer: David Rowley <[email protected]>    
date     : Fri, 12 Apr 2024 23:15:52 +1200    

Reported-by: Richard Guo  
Discussion: https://postgr.es/m/CAMbWs49kAsZUsj7-0SBLvE9+uKz0RCqMEmM3NVytc1YvS8sTrQ@mail.gmail.com  

commit   : 3741f2a09d5205ec32bd8af5d1f397e08995932b    
  
author   : Amit Kapila <[email protected]>    
date     : Fri, 12 Apr 2024 15:03:28 +0530    
  
committer: Amit Kapila <[email protected]>    
date     : Fri, 12 Apr 2024 15:03:28 +0530    

Ensure that when updating the catalog_xmin of the synced slots, it is  
first written to disk before changing the in-memory value  
(effective_catalog_xmin). This is to prevent a scenario where the  
in-memory value change triggers a vacuum to remove catalog tuples before  
the catalog_xmin is written to disk. In the event of a crash before the  
catalog_xmin is persisted, we would not know that some required catalog  
tuples have been removed and the synced slot would be invalidated.  
  
Change the sanity check to ensure that remote_slot's confirmed_flush LSN  
can't precede the local/synced slot during slot sync. Note that the  
restart_lsn of the synced/local slot can be ahead of remote_slot. This can  
happen when slot advancing machinery finds a running xacts record after  
reaching the consistent state at a later point than the primary where it  
serializes the snapshot and updates the restart_lsn.  
  
Make the check to sync slots robust by allowing to sync only when the  
confirmed_lsn, restart_lsn, or catalog_xmin of the remote slot is ahead of  
the synced/local slot.  
  
Reported-by: Amit Kapila and Shveta Malik  
Author: Hou Zhijie, Shveta Malik  
Reviewed-by: Amit Kapila, Bertrand Drouvot  
Discussion: https://postgr.es/m/OS0PR01MB57162B67D3CB01B2756FBA6D94062@OS0PR01MB5716.jpnprd01.prod.outlook.com  
Discussion: https://postgr.es/m/CAJpy0uCSS5zmdyUXhvw41HSdTbRqX1hbYqkOfHNj7qQ+2zn0AQ@mail.gmail.com  

commit   : 3af7040985b6df504a72cd307aad5d69ac5f5384    
  
author   : David Rowley <[email protected]>    
date     : Fri, 12 Apr 2024 20:07:53 +1200    
  
committer: David Rowley <[email protected]>    
date     : Fri, 12 Apr 2024 20:07:53 +1200    

b262ad440 added code to have the planner remove redundant IS NOT NULL  
quals and eliminate needless scans for IS NULL quals on tables where the  
qual's column has a NOT NULL constraint.  
  
That commit failed to consider that an inheritance parent table could  
have differing NOT NULL constraints between the parent and the child.  
This caused issues as if we eliminated a qual on the parent, when  
applying the quals to child tables in apply_child_basequals(), the qual  
might not have been added to the parent's baserestrictinfo.  
  
Here we fix this by not applying the optimization to remove redundant  
quals to RelOptInfos belonging to inheritance parents and applying the  
optimization again in apply_child_basequals().  Effectively, this means  
that the parent and child are considered independently as the parent has  
both an inh=true and inh=false RTE and we still apply the optimization  
to the RelOptInfo corresponding to the inh=false RTE.  
  
We're able to still apply the optimization in add_base_clause_to_rel()  
for partitioned tables as the NULLability of partitions must match that  
of their parent.  And, if we ever expand restriction_is_always_false()  
and restriction_is_always_true() to handle partition constraints then we  
can apply the same logic as, even in multi-level partitioned tables,  
there's no way to route values to a partition when the qual does not  
match the partition qual of the partitioned table's parent partition.  
The same is true for CHECK constraints as those must also match between  
arent partitioned tables and their partitions.  
  
Author: Richard Guo, David Rowley  
Discussion: https://postgr.es/m/CAMbWs4930gQSZmjR7aANzEapdy61gCg6z8dT-kAEYD0sYWKPdQ@mail.gmail.com  

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

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

commit   : 772faafca1b288c4dd66b7150a7831c27b768003    
  
author   : Alexander Korotkov <[email protected]>    
date     : Thu, 11 Apr 2024 16:30:32 +0300    
  
committer: Alexander Korotkov <[email protected]>    
date     : Thu, 11 Apr 2024 16:30:32 +0300    

This commit reverts 06c418e163, e37662f221, bf1e650806, 25f42429e2,  
ee79928441, and 74eaf66f98 per review by Heikki Linnakangas.  
  
Discussion: https://postgr.es/m/b155606b-e744-4218-bda5-29379779da1a%40iki.fi  

commit   : 922c4c461d213a422ee7eb6c38e399607539210a    
  
author   : Alexander Korotkov <[email protected]>    
date     : Thu, 11 Apr 2024 15:54:25 +0300    
  
committer: Alexander Korotkov <[email protected]>    
date     : Thu, 11 Apr 2024 15:54:25 +0300    

This commit reverts 02eb07ea89 per review by Andres Freund.  
  
Discussion: https://postgr.es/m/20240410165236.rwyrny7ihi4ddxw4%40awork3.anarazel.de  

commit   : 8dd0bb84da7d56a9e41241b26bfbf6b79644d574    
  
author   : Alexander Korotkov <[email protected]>    
date     : Thu, 11 Apr 2024 15:53:26 +0300    
  
committer: Alexander Korotkov <[email protected]>    
date     : Thu, 11 Apr 2024 15:53:26 +0300    

This commit reverts c35a3fb5e0 per review by Andres Freund.  
  
Discussion: https://postgr.es/m/20240410165236.rwyrny7ihi4ddxw4%40awork3.anarazel.de  

commit   : 193e6d18e553a104d315ff81892d509d89a30fd8    
  
author   : Alexander Korotkov <[email protected]>    
date     : Thu, 11 Apr 2024 15:51:35 +0300    
  
committer: Alexander Korotkov <[email protected]>    
date     : Thu, 11 Apr 2024 15:51:35 +0300    

This commit reverts 87985cc925 and 818861eb57 per review by Andres Freund.  
  
Discussion: https://postgr.es/m/20240410165236.rwyrny7ihi4ddxw4%40awork3.anarazel.de  

commit   : da841aa4dc279bb0053de56121c927ec943edff3    
  
author   : Alexander Korotkov <[email protected]>    
date     : Thu, 11 Apr 2024 15:47:53 +0300    
  
committer: Alexander Korotkov <[email protected]>    
date     : Thu, 11 Apr 2024 15:47:53 +0300    

This commit reverts b1484a3f19 per review by Andres Freund.  
  
Discussion: https://postgr.es/m/20240410165236.rwyrny7ihi4ddxw4%40awork3.anarazel.de  

commit   : bc1e2092ebb857802a9713d0d3588079e2f0216a    
  
author   : Alexander Korotkov <[email protected]>    
date     : Thu, 11 Apr 2024 15:46:35 +0300    
  
committer: Alexander Korotkov <[email protected]>    
date     : Thu, 11 Apr 2024 15:46:35 +0300    

This commit reverts 9bd99f4c26 and 422041542f per review by Andres Freund.  
  
Discussion: https://postgr.es/m/20240410165236.rwyrny7ihi4ddxw4%40awork3.anarazel.de  

commit   : 87840b9741864dfdb9f63b0056e2783cdb49b8a5    
  
author   : Peter Eisentraut <[email protected]>    
date     : Thu, 11 Apr 2024 12:44:54 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Thu, 11 Apr 2024 12:44:54 +0200    

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

commit   : 56c6703bd0beb1ade7816d6bdc4372c4933ec461    
  
author   : Etsuro Fujita <[email protected]>    
date     : Thu, 11 Apr 2024 19:25:00 +0900    
  
committer: Etsuro Fujita <[email protected]>    
date     : Thu, 11 Apr 2024 19:25:00 +0900    

We updated this comment in back branches (see commit f6f61a4bd et al);  
let's do so in HEAD as well for consistency.  
  
Discussion: https://postgr.es/m/CAPmGK142V1kqDfjo2H%2Bb54JTn2woVBrisFq%2B%3D9jwXwxr0VvbgA%40mail.gmail.com  

commit   : 8f136af3c41c3b7e6474d6dd05238f11059f26f1    
  
author   : Michael Paquier <[email protected]>    
date     : Thu, 11 Apr 2024 17:19:20 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Thu, 11 Apr 2024 17:19:20 +0900    

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

commit   : 810f64a01567610af7b92b0de930f16f3e20064e    
  
author   : Masahiko Sawada <[email protected]>    
date     : Thu, 11 Apr 2024 17:18:05 +0900    
  
committer: Masahiko Sawada <[email protected]>    
date     : Thu, 11 Apr 2024 17:18:05 +0900    

This reverts commit b840508644 and bcb14f4abc. These commits were made  
for commit 5bec1d6bc5 (Improve eviction algorithm in ReorderBuffer  
using max-heap for many subtransactions). However, per discussion,  
commit efb8acc0d0 replaced binary heap + index with pairing heap, and  
made these commits unnecessary.  
  
Reported-by: Jeff Davis  
Discussion: https://postgr.es/m/12747c15811d94efcc5cda72d6b35c80d7bf3443.camel%40j-davis.com  

commit   : efb8acc0d05894e0c6c20dfc00513b53098780f0    
  
author   : Masahiko Sawada <[email protected]>    
date     : Thu, 11 Apr 2024 17:04:38 +0900    
  
committer: Masahiko Sawada <[email protected]>    
date     : Thu, 11 Apr 2024 17:04:38 +0900    

A pairing heap can perform the same operations as the binary heap +  
index, with as good or better algorithmic complexity, and that's an  
existing data structure so that we don't need to invent anything new  
compared to v16. This commit makes the new binaryheap functionality  
that was added in commits b840508644 and bcb14f4abc unnecessary, but  
they will be reverted separately.  
  
Remove the optimization to only build and maintain the heap when the  
amount of memory used is close to the limit, becuase the bookkeeping  
overhead with the pairing heap seems to be small enough that it  
doesn't matter in practice.  
  
Reported-by: Jeff Davis  
Author: Heikki Linnakangas  
Reviewed-by: Michael Paquier, Hayato Kuroda, Masahiko Sawada  
Discussion: https://postgr.es/m/12747c15811d94efcc5cda72d6b35c80d7bf3443.camel%40j-davis.com  

commit   : 942219996c632ae9e66c2c4a759e93abc92014ff    
  
author   : Thomas Munro <[email protected]>    
date     : Thu, 11 Apr 2024 14:35:42 +1200    
  
committer: Thomas Munro <[email protected]>    
date     : Thu, 11 Apr 2024 14:35:42 +1200    

Reported-by: Michael Paquier <[email protected]>  
Discussion: https://postgr.es/m/ZhdKqj5DwoOzirFv%40paquier.xyz  

commit   : d8f5acbdb9b22106db583e3cbb177d34e6b18eeb    
  
author   : Thomas Munro <[email protected]>    
date     : Thu, 11 Apr 2024 13:19:29 +1200    
  
committer: Thomas Munro <[email protected]>    
date     : Thu, 11 Apr 2024 13:19:29 +1200    

The user can set RELSEG_SIZE to a high number at compile time, so we  
can't use it to control the size of an array on the stack: it could be  
many gigabytes in size.  On closer inspection, we don't really need that  
intermediate array anyway.  Let's just write directly into the output  
array, and then perform the absolute->relative adjustment in place.  
This fixes new code from commit dc212340058.  
  
Reviewed-by: Robert Haas <[email protected]>  
Discussion: https://postgr.es/m/CA%2BhUKG%2B2hZ0sBztPW4mkLfng0qfkNtAHFUfxOMLizJ0BPmi5%2Bg%40mail.gmail.com  

commit   : f56a9def71bb1d2ccf4fa01a4d1e082c1063d921    
  
author   : Michael Paquier <[email protected]>    
date     : Thu, 11 Apr 2024 09:20:51 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Thu, 11 Apr 2024 09:20:51 +0900    

aa5edbe379d6 has tweaked _hash_freeovflpage() so as the write buffer's  
LSN is updated only when necessary, when REGBUF_NO_CHANGE is not used.  
  
The replay code was not consistent with that, causing the write buffer's  
LSN to be updated and its page to be marked as dirty even if the buffer  
was registered in a "clean" state.  This was possible for the case of a  
squeeze record when there are no tuples to add to the write buffer, for  
(is_prim_bucket_same_wrt && !is_prev_bucket_same_wrt).  
  
I have performed some validation of this commit with  
wal_consistency_checking and a change in WAL that logs REGBUF_NO_CHANGE  
to a new BKPIMAGE_*.  Thanks to that, it is possible to know at replay  
if a buffer was clean when it was registered, then cross-checked the LSN  
of the "clean" page copy coming from WAL with the LSN of the block once  
the record has been replayed.  This eats one bit in bimg_info, which is  
not acceptable to be integrated as-is, but it could become handy in the  
future.  I didn't spot other areas than the one fixed by this commit at  
the extent of what the main regression test suite covers.  
  
As this is an oversight in aa5edbe379d6, no backpatch is required.  
  
Reported-by: Zubeyr Eryilmaz  
Author: Hayato Kuroda  
Reviewed-by: Amit Kapila, Michael Paquier  
Discussion: https://postgr.es/m/[email protected]  

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

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

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

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

commit   : 5105c90796811f62711538155d207e5311eacf9b    
  
author   : Michael Paquier <[email protected]>    
date     : Wed, 10 Apr 2024 13:48:13 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Wed, 10 Apr 2024 13:48:13 +0900    

f587338dec87 has introduced in the test module injection_points a SQL  
function called injection_points_set_local(), that can be used to make  
all the injection points linked to the process where they are attached,  
discarded automatically if any remain once the process exits.  
  
e2e3b8ae9ed7 has added a NO_INSTALLCHECK to the test module to prevent  
the use of installcheck.  Now that there is a way to make the test  
concurrent-safe, let's use it and remove the installcheck restriction.  
  
Concurrency issues could be easily reproduced by running in a tight  
loop a command like this one, in src/test/modules/gin/ (hardcoding  
pg_sleep() after attaching injection points enlarges the race window)  
and a second test suite like contrib/btree_gin/:  
  
  make installcheck USE_MODULE_DB=1  
  
Reviewed-by: Andrey Borodin  
Discussion: https://postgr.es/m/[email protected]  

commit   : 7e85d1c75f299b0772fbeb145706e019629530bd    
  
author   : Amit Kapila <[email protected]>    
date     : Wed, 10 Apr 2024 08:44:17 +0530    
  
committer: Amit Kapila <[email protected]>    
date     : Wed, 10 Apr 2024 08:44:17 +0530    

Wait for the standby to catch up before syncing the slots with  
pg_sync_replication_slots(), otherwise, the logical slot could be ahead  
and the sync would fail.  
  
The other way to fix the test is to change it to use slotsync worker and  
poll for the sync to get finished but the current approach is better as  
this is a predictable way to write the test.  
  
Per buildfarm  
  
Author: Hou Zhijie  
Reviewed-by: Amit Kapila  
Discussion: https://postgr.es/m/OS0PR01MB571665359F2F5DCD3ADABC9F94002@OS0PR01MB5716.jpnprd01.prod.outlook.com  

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

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

commit   : 8461424fd717877ead0706984ef9b6440b2a97ad    
  
author   : David Rowley <[email protected]>    
date     : Wed, 10 Apr 2024 11:53:32 +1200    
  
committer: David Rowley <[email protected]>    
date     : Wed, 10 Apr 2024 11:53:32 +1200    

This adjusts various appendStringInfo* function calls to use a more  
appropriate and efficient function with the same behavior.  For example,  
use appendStringInfoChar() when appending a single character rather than  
appendStringInfo() and appendStringInfoString() when no formatting is  
required rather than using appendStringInfo().  
  
All adjustments made here are in code that's new to v17, so it makes  
sense to fix these now rather than wait a few years and make  
backpatching harder.  
  
Discussion: https://postgr.es/m/CAApHDvojY2UvMiO+9_55ArTj10P1LBNJyyoGB+C65BLDNT0GsQ@mail.gmail.com  
Reviewed-by: Nathan Bossart, Tom Lane  

commit   : ff9f72c68f678ded340b431c3e280fe56644a3e7    
  
author   : Alexander Korotkov <[email protected]>    
date     : Wed, 10 Apr 2024 02:07:34 +0300    
  
committer: Alexander Korotkov <[email protected]>    
date     : Wed, 10 Apr 2024 02:07:34 +0300    

This commit reverts 72bd38cc99 due to implementation and design issues.  
  
Reported-by: Tom Lane  
Discussion: https://postgr.es/m/3604469.1712628736%40sss.pgh.pa.us  

commit   : 5a15bdea3b791223b4cc708d4953a0086f4332a6    
  
author   : David Rowley <[email protected]>    
date     : Wed, 10 Apr 2024 11:10:16 +1200    
  
committer: David Rowley <[email protected]>    
date     : Wed, 10 Apr 2024 11:10:16 +1200    

The bump allocator was recently added in 29f6a959c.  Our other  
allocators have a similar macro to this, but seemingly the version of  
the macro for those allocators is only used in places where the chunk  
header is decoded.  Since the bump allocator has no chunk header, none  
of those functions exist for bump therefore macro is unused.  Remove it.  
  
Reported-by: Peter Eisentraut  
Discussion: https://postgr.es/m/[email protected]  

commit   : c99ef1811a064a94fb78917f35bb5853059a92b7    
  
author   : Alexander Korotkov <[email protected]>    
date     : Wed, 10 Apr 2024 01:47:00 +0300    
  
committer: Alexander Korotkov <[email protected]>    
date     : Wed, 10 Apr 2024 01:47:00 +0300    

Check that the target partition actually belongs to the parent table.  
  
Reported-by: Alexander Lakhin  
Discussion: https://postgr.es/m/cd842601-cf1a-9806-f7b7-d2509b93ba61%40gmail.com  
Author: Dmitry Koval  

commit   : b1b13d2b524e64e3bf3538441366bdc8f6d3beda    
  
author   : David Rowley <[email protected]>    
date     : Wed, 10 Apr 2024 10:43:31 +1200    
  
committer: David Rowley <[email protected]>    
date     : Wed, 10 Apr 2024 10:43:31 +1200    

Although which is correct depends entirely on whether you pronounce SQL  
as "ess-que-ell" or "sequel", we have standardized on the former in our  
user-facing documentation, so use the correct article according to that  
pronunciation.  
  
Discussion: https://postgr.es/m/CAApHDvp3osQwQam+wNTp9BdhP+QfWO6aY6ZTixQQMfM-UArKCw@mail.gmail.com  

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

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

commit   : 27074bce08e994daf6b8fe9a84877ac257210fdd    
  
author   : Peter Eisentraut <[email protected]>    
date     : Tue, 9 Apr 2024 14:33:06 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Tue, 9 Apr 2024 14:33:06 +0200    

commit   : cfd6ea3ac04113b756e3e722af5d9247ff2da35f    
  
author   : Peter Eisentraut <[email protected]>    
date     : Tue, 9 Apr 2024 14:21:57 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Tue, 9 Apr 2024 14:21:57 +0200    

commit   : 43a9cab4844b9c933f1a24e24a38311ee24deefd    
  
author   : Peter Eisentraut <[email protected]>    
date     : Tue, 9 Apr 2024 11:32:48 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Tue, 9 Apr 2024 11:32:48 +0200    

commit   : bf183f168c447355ba82151f1c7305368a95c834    
  
author   : John Naylor <[email protected]>    
date     : Tue, 9 Apr 2024 16:16:01 +0700    
  
committer: John Naylor <[email protected]>    
date     : Tue, 9 Apr 2024 16:16:01 +0700    

This is a C11 feature, and we require C99. While at it, go the further  
step and get rid of the surrounding union (with uintptr_t) entirely,  
as there is currently no use case for this file to access the header of  
BlocktableEntry as a uintptr_t, and there are no additional alignment  
requirements. The least invasive way seems to be to transfer the old  
union name to this struct.  
  
Reported by Pavel Borisov and Andres Freund, per buildfarm member mylodon  
Reviewed by Pavel Borisov  
  
Discussion: https://postgr.es/m/CALT9ZEH11NYV8AOzKb1bWhCf6J0H=H31f0MgT9xX+HdqvcA1rw@mail.gmail.com  

commit   : baa82b78dc97459b6d2a5843cc77fcf755809269    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Tue, 9 Apr 2024 08:06:31 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Tue, 9 Apr 2024 08:06:31 +0300    

Remove stray paren, capitalize SSL and ALPN.  
  
Author: Kyotaro Horiguchi  
Discussion: https://www.postgresql.org/message-id/[email protected]  

commit   : e9f29233fd67bd6b6667b61c88aa1f37f61f353a    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Tue, 9 Apr 2024 08:04:20 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Tue, 9 Apr 2024 08:04:20 +0300    

Author: Erik Rijkers  
Discussion: https://www.postgresql.org/message-id/[email protected]  

commit   : deca6ac136f4cd09280b3385dc5de3e8ec57e9ba    
  
author   : Michael Paquier <[email protected]>    
date     : Tue, 9 Apr 2024 14:01:33 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Tue, 9 Apr 2024 14:01:33 +0900    

These calls are required to make both tools work with NLS.  
  
Author: Kyotaro Horiguchi  
Discussion: https://postgr.es/m/[email protected]  

commit   : f4083c49751018ae2140de8bf752b8d60485a6ca    
  
author   : Michael Paquier <[email protected]>    
date     : Tue, 9 Apr 2024 10:31:12 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Tue, 9 Apr 2024 10:31:12 +0900    

The module relies on a shmem exit callback to clean up any injection  
points linked to a specific process.  One of the tests checks for the  
case of an injection point name reused in a second connection where the  
first connection should clean it up, but it did not count for the fact  
that the shmem exit callback of the first connection may not have run  
when the second connection begins its work.  
  
The regress library includes a wait_pid() that can be used for this  
purpose, instead of a custom wait logic, so let's rely on it to wait for  
the first connection to exit before working with the second connection.  
The module gains a REGRESS_OPTS to be able to look at the regress  
library's dlpath.  
  
This issue could be reproduced with a hardcoded sleep() in the shmem  
exit callback, and the CI has been able to trigger it sporadically.  
  
Oversight in f587338dec87.  
  
Reported-by: Bharath Rupireddy  
Reviewed-by: Andrey Borodin  
Discussion: https://postgr.es/m/[email protected]  

commit   : f463de59d90c10f3d0daf2d5b132ca58e4111a08    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 8 Apr 2024 17:00:07 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 8 Apr 2024 17:00:07 -0400    

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

commit   : c21d4c416ad61b78cf450f11861bbafbdfb7eebc    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 8 Apr 2024 15:49:10 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 8 Apr 2024 15:49:10 -0400    

Alexander Lakhin noted an obsolete comment, which led me to revisit  
some other important comments in the patch, and that study turned up a  
couple of unintended ways in which the chunked-fetch code path didn't  
match the normal code path in ExecQueryAndProcessResults.  The only  
nontrivial problem is that it didn't call PrintQueryStatus, so that  
we'd not print the final status result from DML ... RETURNING  
commands.  To avoid code duplication, move the filter for whether a  
result is from RETURNING from PrintQueryResult to PrintQueryStatus.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 0fe5f64367bc2fc70baa1f0f993638830f8aa6a5    
  
author   : John Naylor <[email protected]>    
date     : Mon, 8 Apr 2024 18:54:35 +0700    
  
committer: John Naylor <[email protected]>    
date     : Mon, 8 Apr 2024 18:54:35 +0700    

Previously, the decision to store values in leaves or within the child  
pointer was made at compile time, with variable length values using  
leaves by necessity. This commit allows introspecting the length of  
variable length values at runtime for that decision. This requires  
the ability to tell whether the last-level child pointer is actually  
a value, so we use a pointer tag in the lowest level bit.  
  
Use this in TID store. This entails adding a byte to the header to  
reserve space for the tag. Commit f35bd9bf3 stores up to three offsets  
within the header with no bitmap, and now the header can be embedded  
as above. This reduces worst-case memory usage when TIDs are sparse.  
  
Reviewed (in an earlier version) by Masahiko Sawada  
  
Discussion: https://postgr.es/m/CANWCAZYw+_KAaUNruhJfE=h6WgtBKeDG32St8vBJBEY82bGVRQ@mail.gmail.com  
Discussion: https://postgr.es/m/CAD21AoBci3Hujzijubomo1tdwH3XtQ9F89cTNQ4bsQijOmqnEw@mail.gmail.com  

commit   : f35bd9bf359d3d740063997e1cbab9b69df7af99    
  
author   : John Naylor <[email protected]>    
date     : Mon, 8 Apr 2024 18:38:11 +0700    
  
committer: John Naylor <[email protected]>    
date     : Mon, 8 Apr 2024 18:38:11 +0700    

The header portion of BlocktableEntry has enough padding space for  
an array of 3 offsets (1 on 32-bit platforms). Use this space instead  
of having a sparse bitmap array. This will take up a constant amount  
of space no matter what the offsets are.  
  
Reviewed (in an earlier version) by Masahiko Sawada  
  
Discussion: https://postgr.es/m/CANWCAZYw+_KAaUNruhJfE=h6WgtBKeDG32St8vBJBEY82bGVRQ@mail.gmail.com  
Discussion: https://postgr.es/m/CAD21AoBci3Hujzijubomo1tdwH3XtQ9F89cTNQ4bsQijOmqnEw@mail.gmail.com  

commit   : dd1f6b0c172a643a73d6b71259fa2d10378b39eb    
  
author   : Alexander Korotkov <[email protected]>    
date     : Mon, 8 Apr 2024 14:30:30 +0300    
  
committer: Alexander Korotkov <[email protected]>    
date     : Mon, 8 Apr 2024 14:30:30 +0300    

While keeping API the same, this commit provides a way for block-level table  
AMs to re-use existing acquire_sample_rows() by providing custom callbacks  
for getting the next block and the next tuple.  
  
Reported-by: Andres Freund  
Discussion: https://postgr.es/m/20240407214001.jgpg5q3yv33ve6y3%40awork3.anarazel.de  
Reviewed-by: Pavel Borisov  

commit   : df64c81ca9cba7b0fcb0ded5f735e99e676671c1    
  
author   : Alexander Korotkov <[email protected]>    
date     : Mon, 8 Apr 2024 14:39:28 +0300    
  
committer: Alexander Korotkov <[email protected]>    
date     : Mon, 8 Apr 2024 14:39:28 +0300    

Discussion: https://postgr.es/m/CAHewXNkGMPU50QG7V6Q60JGFORfo8LfYO1_GCkCa0VWbmB-fEw%40mail.gmail.com  
Author: Tender Wang  

commit   : 422041542f313f23ca66cad26e9b2b99c4d1999a    
  
author   : Alexander Korotkov <[email protected]>    
date     : Mon, 8 Apr 2024 12:11:56 +0300    
  
committer: Alexander Korotkov <[email protected]>    
date     : Mon, 8 Apr 2024 12:11:56 +0300    

Reported-by: Thomas Munro  
Reported-by: Pavel Borisov  
Discussion: https://postgr.es/m/CA%2BhUKGLZzLR50RBvuqOO3MZ%3DF54ETz-rTp1PDX9uDGP_GqyYqA%40mail.gmail.com  

commit   : 3dbd2ff78654b2ac484a8d08ace788c492117894    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Mon, 8 Apr 2024 12:14:20 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Mon, 8 Apr 2024 12:14:20 +0300    

We're not very consistent about this across all the GUCs, but the  
"Logs ..." phrasing is more common than "Log ...", and is used by the  
neighboring "log_connections" and "log_disconnections" GUCs, so switch  
to that.  
  
Author: Kyotaro Horiguchi  
Discussion: https://www.postgresql.org/message-id/[email protected]  

commit   : 9bd99f4c26fe37b8ee2f199aa868a0e2fdba4c43    
  
author   : Alexander Korotkov <[email protected]>    
date     : Mon, 8 Apr 2024 11:23:28 +0300    
  
committer: Alexander Korotkov <[email protected]>    
date     : Mon, 8 Apr 2024 11:23:28 +0300    

Let table AM define custom reloptions for its tables. This allows specifying  
AM-specific parameters by the WITH clause when creating a table.  
  
The reloptions, which could be used outside of table AM, are now extracted  
into the CommonRdOptions data structure.  These options could be by decision  
of table AM directly specified by a user or calculated in some way.  
  
The new test module test_tam_options evaluates the ability to set up custom  
reloptions and calculate fields of CommonRdOptions on their base.  
  
The code may use some parts from prior work by Hao Wu.  
  
Discussion: https://postgr.es/m/CAPpHfdurb9ycV8udYqM%3Do0sPS66PJ4RCBM1g-bBpvzUfogY0EA%40mail.gmail.com  
Discussion: https://postgr.es/m/AMUA1wBBBxfc3tKRLLdU64rb.1.1683276279979.Hmail.wuhao%40hashdata.cn  
Reviewed-by: Reviewed-by: Pavel Borisov, Matthias van de Meent, Jess Davis  

commit   : 6f3d8d5e7cc2f2e2367cd6da6f8affe98d1f5729    
  
author   : Amit Kapila <[email protected]>    
date     : Mon, 8 Apr 2024 13:21:55 +0530    
  
committer: Amit Kapila <[email protected]>    
date     : Mon, 8 Apr 2024 13:21:55 +0530    

It is possible that even if the primary waits for the subscriber to catch  
up and then disables the subscription, the XLOG_RUNNING_XACTS record gets  
inserted between the two steps by bgwriter and walsender processes it.  
This can move the restart_lsn of the corresponding slot in an  
unpredictable way which further leads to slot sync failure.  
  
To ensure predictable behaviour, we drop the subscription and manually  
create the slot before the test. The other idea we discussed to write a  
predictable test is to use injection points to control the bgwriter  
logging XLOG_RUNNING_XACTS but that needs more analysis. We can add a  
separate test using injection points.  
  
Per buildfarm  
  
Author: Hou Zhijie  
Reviewed-by: Amit Kapila, Shveta Malik  
Discussion: https://postgr.es/m/CAA4eK1JD8h_XLRsK_o_Xh=5MhTzm+6d4Cb4_uPgFJ2wSQDah=g@mail.gmail.com