PostgreSQL 18.0 (upcoming) commit log

commit   : adbb27ac89e07cfbd94ea07a53930addfc3895ee    
  
author   : Thomas Munro <[email protected]>    
date     : Sat, 5 Oct 2024 13:48:33 +1300    
  
committer: Thomas Munro <[email protected]>    
date     : Sat, 5 Oct 2024 13:48:33 +1300    

Commit bf03cfd1 started scanning all available BCP 47 locale names on  
Windows.  This caused an abort/crash in the Windows runtime library if  
the default locale name contained non-ASCII characters, because of our  
use of the setlocale() save/restore pattern with "char" strings.  After  
switching to another locale with a different encoding, the saved name  
could no longer be understood, and setlocale() would abort.  
  
"Turkish_Türkiye.1254" is the example from recent reports, but there are  
other examples of countries and languages with non-ASCII characters in  
their names, and they appear in Windows' (old style) locale names.  
  
To defend against this:  
  
1.  In initdb, reject non-ASCII locale names given explicity on the  
command line, or returned by the operating system environment with  
setlocale(..., ""), or "canonicalized" by the operating system when we  
set it.  
  
2.  In initdb only, perform the save-and-restore with Windows'  
non-standard wchar_t variant of setlocale(), so that it is not subject  
to round trip failures stemming from char string encoding confusion.  
  
3.  In the backend, we don't have to worry about the save-and-restore  
problem because we have already vetted the defaults, so we just have to  
make sure that CREATE DATABASE also rejects non-ASCII names in any new  
databases.  SET lc_XXX doesn't suffer from the problem, but the ban  
applies to it too because it uses check_locale().  CREATE COLLATION  
doesn't suffer from the problem either, but it doesn't use  
check_locale() so it is not included in the new ban for now, to minimize  
the change.  
  
Anyone who encounters the new error message should either create a new  
duplicated locale with an ASCII-only name using Windows Locale Builder,  
or consider using BCP 47 names like "tr-TR".  Users already couldn't  
initialize a cluster with "Turkish_Türkiye.1254" on PostgreSQL 16+, but  
the new failure mode is an error message that explains why, instead of a  
crash.  
  
Back-patch to 16, where bf03cfd1 landed.  Older versions are affected  
in theory too, but only 16 and later are causing crash reports.  
  
Reviewed-by: Andrew Dunstan <[email protected]> (the idea, not the patch)  
Reported-by: Haifang Wang (Centific Technologies Inc) <[email protected]>  
Discussion: https://postgr.es/m/PH8PR21MB3902F334A3174C54058F792CE5182%40PH8PR21MB3902.namprd21.prod.outlook.com  

commit   : f22e84df1dea96c8f4b0f7369ea60607fbb9ce10    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 4 Oct 2024 12:01:50 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 4 Oct 2024 12:01:50 -0400    

The preprocessor really should not have done this to begin with.  
The space after '&' was masked by ECPGconnect's skipping spaces  
before option keywords, and the space before by dint of libpq  
being (mostly) insensitive to trailing space in option values.  
We fixed the one known problem with that in 920d51979.  Hence  
this patch is mostly cosmetic, and we'll just change it in HEAD.  
  
Discussion: https://postgr.es/m/TY2PR01MB36286A7B97B9A15793335D18C1772@TY2PR01MB3628.jpnprd01.prod.outlook.com  

commit   : ddbba3aac868132137782b02a4e81218cfd3b4b9    
  
author   : Peter Eisentraut <[email protected]>    
date     : Fri, 4 Oct 2024 12:47:35 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Fri, 4 Oct 2024 12:47:35 +0200    

In the PostgreSQL C type naming schema, the type PageData should be  
what the pointer of type Page points to.  But in this case it's  
actually an unrelated type local to generic_xlog.c.  Rename that to a  
more specific name.  This makes room to possible add a PageData type  
with the mentioned meaning, but this is not done here.  
  
Reviewed-by: Heikki Linnakangas <[email protected]>  
Reviewed-by: Michael Paquier <[email protected]>  
Discussion: https://www.postgresql.org/message-id/flat/001d457e-c118-4219-8132-e1846c2ae3c9%40eisentraut.org  

commit   : 9428c001f67540e6206b7a76adfc5377d9207777    
  
author   : Dean Rasheed <[email protected]>    
date     : Fri, 4 Oct 2024 09:49:24 +0100    
  
committer: Dean Rasheed <[email protected]>    
date     : Fri, 4 Oct 2024 09:49:24 +0100    

Formerly there were two internal functions in numeric.c to perform  
numeric division, div_var() and div_var_fast(). div_var() performed  
division exactly to a specified rscale using Knuth's long division  
algorithm, while div_var_fast() used the algorithm from the "FM"  
library, which approximates each quotient digit using floating-point  
arithmetic, and computes a truncated quotient with DIV_GUARD_DIGITS  
extra digits. div_var_fast() could be many times faster than  
div_var(), but did not guarantee correct results in all cases, and was  
therefore only suitable for use in transcendental functions, where  
small errors are acceptable.  
  
This commit merges div_var() and div_var_fast() together into a single  
function with an extra "exact" boolean parameter, which can be set to  
false if the caller is OK with an approximate result. The new function  
uses the faster algorithm from the "FM" library, except that when  
"exact" is true, it does not truncate the computation with  
DIV_GUARD_DIGITS extra digits, but instead performs the full-precision  
computation, subtracting off complete multiples of the divisor for  
each quotient digit. However, it is able to retain most of the  
performance benefits of div_var_fast(), by delaying the propagation of  
carries, allowing the inner loop to be auto-vectorized.  
  
Since this may still lead to an inaccurate result, when "exact" is  
true, it then inspects the remainder and uses that to adjust the  
quotient, if necessary, to make it correct. In practice, the quotient  
rarely needs to be adjusted, and never by more than one in the final  
digit, though it's difficult to prove that, so the code allows for  
larger adjustments, just in case.  
  
In addition, use base-NBASE^2 arithmetic and a 64-bit dividend array,  
similar to mul_var(), so that the number of iterations of the outer  
loop is roughly halved. Together with the faster algorithm, this makes  
div_var() up to around 20 times as fast as the old Knuth algorithm  
when "exact" is true, and up to 2 or 3 times as fast as the old  
div_var_fast() function when "exact" is false.  
  
Dean Rasheed, reviewed by Joel Jacobson.  
  
Discussion: https://postgr.es/m/CAEZATCVHR10BPDJSANh0u2+Sg6atO3mD0G+CjKDNRMD-C8hKzQ@mail.gmail.com  

commit   : 4dd308730029f5d90bd188f181c2dd9d7630ea69    
  
author   : Michael Paquier <[email protected]>    
date     : Fri, 4 Oct 2024 12:51:17 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Fri, 4 Oct 2024 12:51:17 +0900    

This assertion has been added by 24f520594809, but Alexander Lakhin has  
proved that the ExecutorRun() one can be broken by using a PL function  
that manipulates compute_query_id and track_activities, while the ones  
in ExecutorFinish() and ExecutorEnd() could be triggered when cleaning  
up portals at the beginning of a new query execution.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 259a0a99fe3d45dcf624788c1724d9989f3382dc    
  
author   : Dean Rasheed <[email protected]>    
date     : Thu, 3 Oct 2024 13:48:32 +0100    
  
committer: Dean Rasheed <[email protected]>    
date     : Thu, 3 Oct 2024 13:48:32 +0100    

If a MERGE command contains WHEN NOT MATCHED BY SOURCE actions, the  
source relation appears on the outer side of the join. Thus, any Vars  
referring to the source in the merge join condition, actions, and  
RETURNING list should be marked as nullable by the join, since they  
are used in the ModifyTable node above the join. Note that this only  
applies to the copy of join condition used in the executor to  
distinguish MATCHED from NOT MATCHED BY SOURCE cases. Vars in the  
original join condition, inside the join node itself, should not be  
marked.  
  
Failure to correctly mark these Vars led to a "wrong varnullingrels"  
error in the final stage of query planning, in some circumstances. We  
happened to get away without this in all previous tests, since they  
all involved a ModifyTable node directly on top of the join node, so  
that the top plan targetlist coincided with the output of the join,  
and the varnullingrels check was more lax. However, if another plan  
node, such as a one-time filter Result node, gets inserted between the  
ModifyTable node and the join node, then a stricter check is applied,  
which fails.  
  
Per bug #18634 from Alexander Lakhin. Thanks to Tom Lane and Richard  
Guo for review and analysis.  
  
Back-patch to v17, where WHEN NOT MATCHED BY SOURCE support was added  
to MERGE.  
  
Discussion: https://postgr.es/m/18634-db5299c937877f2b%40postgresql.org  

commit   : dddb5640c6d32f3d48994dac0f4e80d0f4567262    
  
author   : Dean Rasheed <[email protected]>    
date     : Thu, 3 Oct 2024 12:53:03 +0100    
  
committer: Dean Rasheed <[email protected]>    
date     : Thu, 3 Oct 2024 12:53:03 +0100    

If a MERGE command contains WHEN NOT MATCHED BY SOURCE actions, the  
merge join condition is used by the executor to distinguish MATCHED  
from NOT MATCHED BY SOURCE cases. However, this qual is executed using  
the output from the join subplan node, which nulls the output from the  
source relation in the not matched case, and so the result may be  
incorrect if the join condition is "non-strict" -- for example,  
something like "src.col IS NOT DISTINCT FROM tgt.col".  
  
Fix this by enhancing the join recheck condition with an additional  
"src IS NOT NULL" check, so that it does the right thing when  
evaluated using the output from the join subplan.  
  
Noted by Tom Lane while investigating bug #18634 from Alexander  
Lakhin.  
  
Back-patch to v17, where WHEN NOT MATCHED BY SOURCE support was added  
to MERGE.  
  
Discussion: https://postgr.es/m/18634-db5299c937877f2b%40postgresql.org  

commit   : 19531968e84557693576928b3184ccc549aa44c8    
  
author   : Amit Langote <[email protected]>    
date     : Thu, 3 Oct 2024 19:51:38 +0900    
  
committer: Amit Langote <[email protected]>    
date     : Thu, 3 Oct 2024 19:51:38 +0900    

In commit babb3993dbe9, I accidentally introduced a Unicode  
apostrophe (U+2019). This commit replaces it with the ASCII  
apostrophe (U+0027) for consistency.  
  
Reported-by: Alexander Korotkov <[email protected]>  
Discussion: https://postgr.es/m/CAPpHfduNWMBjkJFtqXJremk6b6YQYO2s3_VEpnj-T_CaUNUYYQ@mail.gmail.com  

commit   : e55f025b059fb02b659f12f3003c160ed4674dc8    
  
author   : Fujii Masao <[email protected]>    
date     : Thu, 3 Oct 2024 15:59:16 +0900    
  
committer: Fujii Masao <[email protected]>    
date     : Thu, 3 Oct 2024 15:59:16 +0900    

This commit simplifies CopyFrom() by removing the unnecessary local variable  
'skipped', which tracked the number of rows skipped due to on_error = 'ignore'.  
That count is already handled by cstate->num_errors, so the 'skipped' variable  
was redundant.  
  
Additionally, the condition on_error != COPY_ON_ERROR_STOP is removed.  
Since on_error == COPY_ON_ERROR_IGNORE is already checked, and on_error  
only has two values (ignore and stop), the additional check was redundant  
and made the logic harder to read. Seemingly this was introduced  
in preparation for a future patch, but the current checks don’t offer  
clear value and have been removed to improve readability.  
  
Author: Atsushi Torikoshi  
Reviewed-by: Masahiko Sawada, Fujii Masao  
Discussion: https://postgr.es/m/[email protected]  

commit   : a1c4c8a9e1e3a53996dafa1f4ee6d4f7de2c58b2    
  
author   : Fujii Masao <[email protected]>    
date     : Thu, 3 Oct 2024 15:57:32 +0900    
  
committer: Fujii Masao <[email protected]>    
date     : Thu, 3 Oct 2024 15:57:32 +0900    

In v17, the on_error and log_verbosity options were introduced for  
the COPY command. This commit extends support for these options  
to file_fdw.  
  
Setting on_error = 'ignore' for a file_fdw foreign table allows users  
to query it without errors, even when the input file contains  
malformed rows, by skipping the problematic rows.  
  
Both on_error and log_verbosity options apply to SELECT and ANALYZE  
operations on file_fdw foreign tables.  
  
Author: Atsushi Torikoshi  
Reviewed-by: Masahiko Sawada, Fujii Masao  
Discussion: https://postgr.es/m/[email protected]  

commit   : e7834a1a251d4a28245377f383ff20a657ba8262    
  
author   : Fujii Masao <[email protected]>    
date     : Thu, 3 Oct 2024 15:55:37 +0900    
  
committer: Fujii Masao <[email protected]>    
date     : Thu, 3 Oct 2024 15:55:37 +0900    

Previously, when the on_error option was set to ignore, the COPY command  
would always log NOTICE messages for input rows discarded due to  
data type incompatibility. Users had no way to suppress these messages.  
  
This commit introduces a new log_verbosity setting, 'silent',  
which prevents the COPY command from emitting NOTICE messages  
when on_error = 'ignore' is used, even if rows are discarded.  
This feature is particularly useful when processing malformed files  
frequently, where a flood of NOTICE messages can be undesirable.  
  
For example, when frequently loading malformed files via the COPY command  
or querying foreign tables using file_fdw (with an upcoming patch to  
add on_error support for file_fdw), users may prefer to suppress  
these messages to reduce log noise and improve clarity.  
  
Author: Atsushi Torikoshi  
Reviewed-by: Masahiko Sawada, Fujii Masao  
Discussion: https://postgr.es/m/[email protected]  

commit   : babb3993dbe9c805c1d29fa275a5e8f4c2b40922    
  
author   : Amit Langote <[email protected]>    
date     : Thu, 3 Oct 2024 11:59:09 +0900    
  
committer: Amit Langote <[email protected]>    
date     : Thu, 3 Oct 2024 11:59:09 +0900    

This commit addresses two issues related to the manipulation of the  
partition constraint expression list in ATExecAttachPartition().  
  
First, the current use of list_concat() to combine the partition's  
constraint (retrieved via get_qual_from_partbound()) with the parent  
table’s partition constraint can lead to memory safety issues. After  
calling list_concat(), the original constraint (partBoundConstraint)  
might no longer be safe to access, as list_concat() may free or modify  
it.  
  
Second, there's a logical error in constructing the constraint for  
validating against the default partition. The current approach  
incorrectly includes a negated version of the parent table's partition  
constraint, which is redundant, as it always evaluates to false for  
rows in the default partition.  
  
To resolve these issues, list_concat() is replaced with  
list_concat_copy(), ensuring that partBoundConstraint remains unchanged  
and can be safely reused when constructing the validation constraint  
for the default partition.  
  
This fix is not applied to back-branches, as there is no live bug and  
the issue has not caused any reported problems in practice.  
  
Nitin Jadhav posted a patch to address the memory safety issue, but I  
decided to follow Alvaro Herrera's suggestion from the initial  
discussion, as it allows us to fix both the memory safety and logical  
issues.  
  
Reported-by: Andres Freund <[email protected]>  
Reported-by: Nitin Jadhav <[email protected]>  
Reviewed-by: Junwang Zhao <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  
Discussion: https://postgr.es/m/CAMm1aWbmYHM3bqtjyMQ-a+4Ub=dgsb_2E3_up2cn=UGdHNrGTg@mail.gmail.com  

commit   : e2bab2d792044b55dd092bf1c2be0d570ccb9401    
  
author   : Michael Paquier <[email protected]>    
date     : Thu, 3 Oct 2024 10:55:02 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Thu, 3 Oct 2024 10:55:02 +0900    

The following commands were allowed on partitioned tables, with  
different effects:  
1) ALTER TABLE SET [UN]LOGGED did not issue an error, and did not update  
pg_class.relpersistence.  
2) CREATE UNLOGGED TABLE was working with pg_class.relpersistence marked  
as initially defined, but partitions did not inherit the UNLOGGED  
property, which was confusing.  
  
This commit causes the commands mentioned above to fail for partitioned  
tables, instead.  
  
pg_dump is tweaked so as partitioned tables marked as UNLOGGED ignore  
the option when dumped from older server versions.  pgbench needs a  
tweak for --unlogged and --partitions=N to ignore the UNLOGGED option on  
the partitioned tables created, its partitions still being unlogged.  
  
Author: Michael Paquier  
Reviewed-by: Nathan Bossart  
Discussion: https://postgr.es/m/[email protected]  

commit   : 554d3a18f36264eeb1333655b8ddcd929befa6ec    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 2 Oct 2024 20:27:45 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 2 Oct 2024 20:27:45 -0400    

Oversight in commit d94cf5ca7 (and in my testing of same).  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 920d51979a99df29112396b2c75da7921ba7a7b0    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 2 Oct 2024 17:30:36 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 2 Oct 2024 17:30:36 -0400    

Use pqParseIntParam (nee parse_int_param) instead of using strtol  
directly.  This allows trailing whitespace, which the previous coding  
didn't, and makes the spelling of the error message consistent with  
other similar cases.  
  
This seems to be an oversight in commit e7a221797, which introduced  
parse_int_param.  That fixed places that were using atoi(), but missed  
this place which was randomly using strtol() instead.  
  
Ordinarily I'd consider this minor cleanup not worth back-patching.  
However, it seems that ecpg assumes it can add trailing whitespace  
to URL parameters, so that use of the keepalives option fails in  
that context.  Perhaps that's worth improving as a separate matter.  
In the meantime, back-patch this to all supported branches.  
  
Yuto Sasaki (some further cleanup by me)  
  
Discussion: https://postgr.es/m/TY2PR01MB36286A7B97B9A15793335D18C1772@TY2PR01MB3628.jpnprd01.prod.outlook.com  

commit   : d94cf5ca7fad9cd81af5eac491bfbaf0facb9f6f    
  
author   : Robert Haas <[email protected]>    
date     : Wed, 2 Oct 2024 09:59:04 -0400    
  
committer: Robert Haas <[email protected]>    
date     : Wed, 2 Oct 2024 09:59:04 -0400    

size_t is the size of an object in memory, not the size of a file on disk.  
  
Thanks to Tom Lane for noting the error.  
  
Discussion: http://postgr.es/m/[email protected]  

commit   : 7b2822ecf944a6aa429c05cc7f070001c3817934    
  
author   : Daniel Gustafsson <[email protected]>    
date     : Wed, 2 Oct 2024 14:50:56 +0200    
  
committer: Daniel Gustafsson <[email protected]>    
date     : Wed, 2 Oct 2024 14:50:56 +0200    

Various improvements to the documentation like adding missing  
markup, improving punctuation, ensuring consistent spelling of  
words and minor wordsmithing.  
  
Author: Oleg Sibiryakov <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  

commit   : 9c733951049bf3993c886d7f2c7459e7439a9793    
  
author   : Daniel Gustafsson <[email protected]>    
date     : Wed, 2 Oct 2024 13:08:55 +0200    
  
committer: Daniel Gustafsson <[email protected]>    
date     : Wed, 2 Oct 2024 13:08:55 +0200    

If there are no objects found, there is no reason to inspect the  
result columns and mallocing a zero-sized  (which will be 1 byte  
in reality) heap buffer for it.  Add a fast-path for immediately  
returning like how other object inspection functions are already  
doing it.  
  
Reviewed-by: Ranier Vilela <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  

commit   : 1a123e3b136bf38ebf5f7a97b358306998f8a61f    
  
author   : Daniel Gustafsson <[email protected]>    
date     : Wed, 2 Oct 2024 13:07:31 +0200    
  
committer: Daniel Gustafsson <[email protected]>    
date     : Wed, 2 Oct 2024 13:07:31 +0200    

Since the buffer was just created, there is no reason to immediately  
reset it.  
  
Reviewed-by: Ranier Vilela <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  

commit   : 94902b146fae024c03f80d496a0da5ba9751c9b5    
  
author   : Daniel Gustafsson <[email protected]>    
date     : Wed, 2 Oct 2024 12:24:39 +0200    
  
committer: Daniel Gustafsson <[email protected]>    
date     : Wed, 2 Oct 2024 12:24:39 +0200    

The login event trigger is not listed on the trigger firing matrix  
since it's not fired by a command.  Add a link to the example code  
page similar to how the other event triggers link to the matrix.  
  
Reported-by: Marcos Pegoraro <[email protected]>  
Discussion: https://postgr.es/m/CAB-JLwYS+78rX02BZ3wJ9ykVrd2i3O1K+7jzvZKQ0evquyQiLQ@mail.gmail.com  

commit   : 17cc5f666f6aada21eb3237974c50681ba4814ea    
  
author   : Fujii Masao <[email protected]>    
date     : Wed, 2 Oct 2024 11:17:47 +0900    
  
committer: Fujii Masao <[email protected]>    
date     : Wed, 2 Oct 2024 11:17:47 +0900    

Previously, the pg_stat_checkpointer view and the checkpoint completion  
log message could show different numbers for buffers written  
during checkpoints. The view only counted shared buffers,  
while the log message included both shared and SLRU buffers,  
causing inconsistencies.  
  
This commit resolves the issue by updating both the view and the log message  
to separately report shared and SLRU buffers written during checkpoints.  
A new slru_written column is added to the pg_stat_checkpointer view  
to track SLRU buffers, while the existing buffers_written column now  
tracks only shared buffers. This change would help users distinguish  
between the two types of buffers, in the pg_stat_checkpointer view and  
the checkpoint complete log message, respectively.  
  
Bump catalog version.  
  
Author: Nitin Jadhav  
Reviewed-by: Bharath Rupireddy, Michael Paquier, Kyotaro Horiguchi, Robert Haas  
Reviewed-by: Andres Freund, vignesh C, Fujii Masao  
Discussion: https://postgr.es/m/CAMm1aWb18EpT0whJrjG+-nyhNouXET6ZUw0pNYYAe+NezpvsAA@mail.gmail.com  

commit   : 506eede7111ae7c88bd3c21f653bbb65846bd4a5    
  
author   : Michael Paquier <[email protected]>    
date     : Wed, 2 Oct 2024 11:12:40 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Wed, 2 Oct 2024 11:12:40 +0900    

The fork name is always separated with the block number by an underscore  
in the names of the files generated, but the docs stuck them together  
without a separator, which was confusing.  
  
Author: Christoph Berg  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 16  

commit   : da8a4c1666476648659dc5fb6fc01ba5cd5d16a1    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 1 Oct 2024 16:53:54 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 1 Oct 2024 16:53:54 -0400    

We have always documented that a copy EOF marker (\.) must appear  
by itself on a line, and that is how psql interprets the rule.  
However, the backend's actual COPY FROM logic only insists that  
there not be data between the \. and the following newline.  
Any data ahead of the \. is parsed as a final line of input.  
It's hard to interpret this as anything but an ancient mistake  
that we've faithfully carried forward.  Continuing to allow it  
is not cost-free, since it could mask client-side bugs that  
unnecessarily backslash-escape periods (and thereby risk  
accidentally creating an EOF marker).  So, let's remove that  
provision and throw error if the EOF marker isn't alone on its  
line, matching what the documentation has said right along.  
Adjust the relevant error messages to be clearer, too.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 983a588e0b864d5c016d5902217ba4b11fc82b4f    
  
author   : Peter Eisentraut <[email protected]>    
date     : Tue, 1 Oct 2024 10:27:39 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Tue, 1 Oct 2024 10:27:39 -0400    

Right now this does nothing except override any earlier  
--data-checksums option.  But the idea is that --data-checksums could  
become the default, and then this option would allow forcing it off  
instead.  
  
Author: Greg Sabino Mullane <[email protected]>  
Discussion: https://www.postgresql.org/message-id/flat/CAKAnmmKwiMHik5AHmBEdf5vqzbOBbcwEPHo4-PioWeAbzwcTOQ@mail.gmail.com  

commit   : efd72a3d422b591bfec941d625df6fad820e021b    
  
author   : Peter Eisentraut <[email protected]>    
date     : Tue, 1 Oct 2024 09:58:20 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Tue, 1 Oct 2024 09:58:20 -0400    

Author: Greg Sabino Mullane <[email protected]>  
Discussion: https://www.postgresql.org/message-id/flat/CAKAnmmKwiMHik5AHmBEdf5vqzbOBbcwEPHo4-PioWeAbzwcTOQ@mail.gmail.com  

commit   : 10b721821d6d6e27e594549cf105476dc28514c8    
  
author   : Peter Eisentraut <[email protected]>    
date     : Tue, 1 Oct 2024 09:30:24 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Tue, 1 Oct 2024 09:30:24 -0400    

Refactoring in the interest of code consistency, a follow-up to 2e068db56e31.  
  
The argument against inserting a special enum value at the end of the enum  
definition is that a switch statement might generate a compiler warning unless  
it has a default clause.  
  
Aleksander Alekseev, reviewed by Michael Paquier, Dean Rasheed, Peter Eisentraut  
  
Discussion: https://postgr.es/m/CAJ7c6TMsiaV5urU_Pq6zJ2tXPDwk69-NKVh4AMN5XrRiM7N%2BGA%40mail.gmail.com  

commit   : fc1b2ce0ee9c9745c5c562b692e021344a3f719a    
  
author   : Robert Haas <[email protected]>    
date     : Tue, 1 Oct 2024 08:31:33 -0400    
  
committer: Robert Haas <[email protected]>    
date     : Tue, 1 Oct 2024 08:31:33 -0400    

Commit 8dfd3129027969fdd2d9d294220c867d2efd84aa introduced a few  
problems. verify_tar_file() forgot to free a buffer; the leak can't  
add up to anything material, but might as well fix it.  
precheck_tar_backup_file() intended to return after reporting an  
error but didn't actually do so. member_copy_control_data() could  
try to copy zero bytes (and maybe Coverity thinks it can even be  
trying to copy a negative number of bytes).  
  
Per discussion with Tom Lane.  
  
Discussion: http://postgr.es/m/[email protected]  

commit   : 9c2a6c5a5f4b94a93120009e623ae8bd153e6dbb    
  
author   : Peter Eisentraut <[email protected]>    
date     : Tue, 1 Oct 2024 07:16:04 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Tue, 1 Oct 2024 07:16:04 -0400    

Instead of XXX_IN_XLOCALE_H for several features XXX, let's just  
include <xlocale.h> if HAVE_XLOCALE_H.  The reason for the extra  
complication was apparently that some old glibc systems also had an  
<xlocale.h>, and you weren't supposed to include it directly, but it's  
gone now (as far as I can tell it was harmless to do so anyway).  
  
Author: Thomas Munro <[email protected]>  
Discussion: https://postgr.es/m/CWZBBRR6YA8D.8EHMDRGLCKCD%40neon.tech  

commit   : ee4859123e3d47aef8cfe078f7faee2ebcecb613    
  
author   : Peter Eisentraut <[email protected]>    
date     : Tue, 1 Oct 2024 05:05:51 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Tue, 1 Oct 2024 05:05:51 -0400    

LLVM's opaque pointer change began in LLVM 14, but remained optional  
until LLVM 16.  When commit 37d5babb added opaque pointer support, we  
didn't turn it on for LLVM 14 and 15 yet because we didn't want to risk  
weird bitcode incompatibility problems in released branches of  
PostgreSQL.  (That might have been overly cautious, I don't know.)  
  
Now that PostgreSQL 18 has dropped support for LLVM versions < 14, and  
since it hasn't been released yet and no extensions or bitcode have been  
built against it in the wild yet, we can be more aggressive.  We can rip  
out the support code and build system clutter that made opaque pointer  
use optional.  
  
Author: Thomas Munro <[email protected]>  
Reviewed-by: Peter Eisentraut <[email protected]>  
Discussions: https://postgr.es/m/CA%2BhUKGLhNs5geZaVNj2EJ79Dx9W8fyWUU3HxcpZy55sMGcY%3DiA%40mail.gmail.com  

commit   : 972c2cd2882b6dd7a2059d030d03e89dae47ede7    
  
author   : Peter Eisentraut <[email protected]>    
date     : Tue, 1 Oct 2024 04:49:11 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Tue, 1 Oct 2024 04:49:11 -0400    

Remove support for LLVM versions 10-13.  The default on all non-EOL'd  
OSes represented in our build farm will be at least LLVM 14 when  
PostgreSQL 18 ships.  
  
Author: Thomas Munro <[email protected]>  
Reviewed-by: Peter Eisentraut <[email protected]>  
Discussion: https://postgr.es/m/CA%2BhUKGLhNs5geZaVNj2EJ79Dx9W8fyWUU3HxcpZy55sMGcY%3DiA%40mail.gmail.com  

commit   : 1b4d52c3556b9abad10165ce7298062cf7eb7005    
  
author   : Daniel Gustafsson <[email protected]>    
date     : Tue, 1 Oct 2024 10:20:14 +0200    
  
committer: Daniel Gustafsson <[email protected]>    
date     : Tue, 1 Oct 2024 10:20:14 +0200    

The documentation for the connection service file was mentioning  
the environment variable early but not the connection string key  
word until the last sentence and only then in an example.  This  
adds the keyword in the first paragraph to make it clearer  
  
Author: Dagfinn Ilmari Mannsåker <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  

commit   : cf4401fe6cf56811343edcad29c96086c2c66481    
  
author   : Michael Paquier <[email protected]>    
date     : Tue, 1 Oct 2024 15:44:03 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Tue, 1 Oct 2024 15:44:03 +0900    

COMMIT PREPARED removes on-disk 2PC files near its end, but the state  
checked if a file is on-disk or not gets read from shared memory while  
not holding the two-phase state lock.  
  
Because of that, there was a small window where a second backend doing a  
PREPARE TRANSACTION could reuse the GlobalTransaction put back into the  
2PC free list by the COMMIT PREPARED, overwriting the "ondisk" flag read  
afterwards by the COMMIT PREPARED to decide if its on-disk two-phase  
state file should be removed, preventing the file deletion.  
  
This commit fixes this issue so as the "ondisk" flag in the  
GlobalTransaction is read while holding the two-phase state lock, not  
from shared memory after its entry has been added to the free list.  
  
Orphaned two-phase state files flushed to disk after a checkpoint are  
discarded at the beginning of recovery.  However, a truncation of  
pg_xact/ would make the startup process issue a FATAL when it cannot  
read the SLRU page holding the state of the transaction whose 2PC file  
was orphaned, which is a necessary step to decide if the 2PC file should  
be removed or not.  Removing manually the file would be necessary in  
this case.  
  
Issue introduced by effe7d9552dd, so backpatch all the way down.  
  
Mea culpa.  
  
Author: wuchengwen  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 12  

commit   : 3b1a377defcfc01d8a3f964e39aa652766ffc188    
  
author   : Tatsuo Ishii <[email protected]>    
date     : Tue, 1 Oct 2024 11:34:34 +0900    
  
committer: Tatsuo Ishii <[email protected]>    
date     : Tue, 1 Oct 2024 11:34:34 +0900    

There were unnecessary non-breaking spaces (nbsp, U+00A0, 0xc2a0 in  
UTF-8) in the docs.  This commit replaces them with ASCII spaces  
(0x20).  
  
config.sgml is backpatched through 17.  
ref/drop_extension.sgml is backpatched through 13.  
  
Discussion: https://postgr.es/m/20240930.153404.202479334310259810.ishii%40postgresql.org  
Reviewed-by: Yugo Nagata, Daniel Gustafsson  
Backpatch-through: 17, 13  

commit   : 5deb56387e3a1d08e1e62bed031258db267a0ab5    
  
author   : Michael Paquier <[email protected]>    
date     : Tue, 1 Oct 2024 08:56:21 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Tue, 1 Oct 2024 08:56:21 +0900    

As formulated, the assertion added in the executor by 24f520594809 to  
check that a query ID is set had two problems:  
- track_activities may be disabled while compute_query_id is enabled,  
causing the query ID to not be reported to pg_stat_activity.  
- debug_query_string may not be set in some context.  The only path  
where this would matter is visibly autovacuum, should parallel workers  
be enabled there at some point.  This is not the case currently.  
  
There was no test showing the interactions between the query ID and  
track_activities, so let's add one based on a scan of pg_stat_activity.  
This assertion is still an experimentation at this stage, but let's see  
if this shows more paths where query IDs are not properly set while they  
should.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 102de3be73345a8de443355e055c10762b08cc4c    
  
author   : Daniel Gustafsson <[email protected]>    
date     : Tue, 1 Oct 2024 00:01:32 +0200    
  
committer: Daniel Gustafsson <[email protected]>    
date     : Tue, 1 Oct 2024 00:01:32 +0200    

The comment in pg_class_aclmask_ext() which lists the allowed commands  
for the pg_maintain role lacked LOCK TABLE.  
  
Reported-by: Yusuke Sugie <[email protected]>  
Reviewed-by: Yugo Nagata <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  

commit   : 7702337489810f645b3501d99215c2b525c5abca    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 30 Sep 2024 17:57:12 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 30 Sep 2024 17:57:12 -0400    

Since backslash is (typically) not special in CSV data, we should  
not be treating \. as special either.  The server historically did  
this to keep CSV and TEXT modes more alike and to support V2 protocol;  
but V2 protocol is long dead, and the inconsistency with CSV standards  
is annoying.  Remove that behavior in CopyReadLineText, and make some  
minor consequent code simplifications.  
  
On the client side, we need to fix psql so that it does not check  
for \. except when reading data from STDIN (that is, the script  
source).  We must do that regardless of TEXT/CSV mode or there is  
no way to end the COPY short of script EOF.  Also, be careful  
not to send the \. to the server in that case.  
  
This is a small compatibility break in that other applications  
beside psql may need similar adjustment.  Also, using an older  
version of psql with a v18 server may result in misbehavior  
during CSV-mode COPY IN.  
  
Daniel Vérité, reviewed by vignesh C, Robert Haas, and myself  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : a19f83f87966f763991cc76404f8e42a36e7e842    
  
author   : Fujii Masao <[email protected]>    
date     : Tue, 1 Oct 2024 01:55:45 +0900    
  
committer: Fujii Masao <[email protected]>    
date     : Tue, 1 Oct 2024 01:55:45 +0900    

This commit updates the documentation for the pg_stat_checkpointer view  
to clarify what kind of checkpoints or restartpoints each counter tracks.  
This makes it easier to understand the meaning of each counter.  
  
Previously, the num_requested description included "backend,"  
which could be misleading since requests come from other sources as well.  
This commit also removes "backend" from the description of num_requested,  
to avoid confusion.  
  
Author: Fujii Masao  
Reviewed-by: Anton A. Melnikov  
Discussion: https://postgr.es/m/[email protected]  

commit   : 04c64e3fb35af090c249303b9df0a311f2a07593    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 30 Sep 2024 12:06:54 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 30 Sep 2024 12:06:54 -0400    

For some reason this listed "-f" and "-w" as valid switches, though  
the code doesn't implement any such thing nor do the docs mention  
them.  The effect of this was that if you tried to use one of these  
switches, you'd get an unhelpful error message.  
  
Yusuke Sugie  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 4dea33ce765d65d8807d343ca6535a3d067a63da    
  
author   : Alvaro Herrera <[email protected]>    
date     : Mon, 30 Sep 2024 11:58:13 +0200    
  
committer: Alvaro Herrera <[email protected]>    
date     : Mon, 30 Sep 2024 11:58:13 +0200    

This restriction seems to have come about due to some fuzzy thinking: in  
commit 9139aa19423b we were adding a restriction against ADD constraint  
ONLY on partitioned tables (which is sensible) and apparently we thought  
the DROP case had to be symmetrical.  However, it isn't, and the  
comments about it are mistaken about the effect it would have.  Remove  
this limitation.  
  
There have been no reports of users bothered by this limitation, so I'm  
not backpatching it just yet.  We can revisit this decision later, as needed.  
  
Reviewed-by: Amit Langote <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  
Discussion: https://postgr.es/m/[email protected]  
	(about commit 9139aa19423b, previously not registered)  

commit   : 4c7cd07aa62abc29e6885e95b5307e5e08bb3bf7    
  
author   : Michael Paquier <[email protected]>    
date     : Mon, 30 Sep 2024 14:52:03 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Mon, 30 Sep 2024 14:52:03 +0900    

Oversight in dc68515968e8, as this breaks SQL functions with a SET  
command.  
  
Reported-by: Tom Lane  
Discussion: https://postgr.es/m/[email protected]  

commit   : dc68515968e80d75f8106d0df05da346be537628    
  
author   : Michael Paquier <[email protected]>    
date     : Mon, 30 Sep 2024 14:02:00 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Mon, 30 Sep 2024 14:02:00 +0900    

This is a continuation of work like 11c34b342bd7, done to reduce the  
bloat of pg_stat_statements by applying more normalization to query  
entries.  This commit is able to detect and normalize values in  
VariableSetStmt, resulting in:  
SET conf_param = $1  
  
Compared to other parse nodes, VariableSetStmt is embedded in much more  
places in the parser, impacting many query patterns in  
pg_stat_statements.  A custom jumble function is used, with an extra  
field in the node to decide if arguments should be included in the  
jumbling or not, a location field being not enough for this purpose.  
This approach allows for a finer tuning.  
  
Clauses relying on one or more keywords are not normalized, for example:  
* DEFAULT  
* FROM CURRENT  
* List of keywords.  SET SESSION CHARACTERISTICS AS TRANSACTION,  
where it is critical to differentiate different sets of options, is a  
good example of why normalization should not happen.  
  
Some queries use VariableSetStmt for some subclauses with SET, that also  
have their values normalized:  
- ALTER DATABASE  
- ALTER ROLE  
- ALTER SYSTEM  
- CREATE/ALTER FUNCTION  
  
ba90eac7a995 has added test coverage for most of the existing SET  
patterns.  The expected output of these tests shows the difference this  
commit creates.  Normalization could be perhaps applied to more portions  
of the grammar but what is done here is conservative, and good enough as  
a starting point.  
  
Author: Greg Sabino Mullane, Michael Paquier  
Discussion: https://postgr.es/m/[email protected]  
Discussion: https://postgr.es/m/[email protected]  
Discussion: https://postgr.es/m/CAKAnmmJtJY2jzQN91=2QAD2eAJAA-Per61eyO48-TyxEg-q0Rg@mail.gmail.com  

commit   : 559efce1d684069acf234a5cb032acba84e70938    
  
author   : Fujii Masao <[email protected]>    
date     : Mon, 30 Sep 2024 11:56:05 +0900    
  
committer: Fujii Masao <[email protected]>    
date     : Mon, 30 Sep 2024 11:56:05 +0900    

Checkpoints can be skipped when the server is idle. The existing num_timed and  
num_requested counters in pg_stat_checkpointer track both completed and  
skipped checkpoints, but there was no way to count only the completed ones.  
  
This commit introduces the num_done counter, which tracks only completed  
checkpoints, making it easier to see how many were actually performed.  
  
Bump catalog version.  
  
Author: Anton A. Melnikov  
Reviewed-by: Fujii Masao  
Discussion: https://postgr.es/m/[email protected]  

commit   : 20cfec896c6a20ca436f634b0ffa3582d7b9425c    
  
author   : Fujii Masao <[email protected]>    
date     : Mon, 30 Sep 2024 11:13:55 +0900    
  
committer: Fujii Masao <[email protected]>    
date     : Mon, 30 Sep 2024 11:13:55 +0900    

Reindexing temp tables or indexes of other sessions is not allowed.  
However, reindexdb in parallel mode previously listed them as  
the objects to process, leading to failures.  
  
This commit ensures reindexdb in parallel mode skips temporary tables  
and indexes by adding a condition based on the relpersistence column  
in pg_class to the object listing queries, preventing these issues.  
  
Note that this commit does not affect reindexdb when temporary tables  
or indexes are explicitly specified using the -t or -j options;  
reindexdb in that case still does not skip them and can cause an error.  
  
Back-patch to v13 where parallel mode was introduced in reindexdb.  
  
Author: Fujii Masao  
Reviewed-by: Michael Paquier  
Discussion: https://postgr.es/m/[email protected]  

commit   : 6fd5071909a2886c499871e61127f815fd9bb6a2    
  
author   : Michael Paquier <[email protected]>    
date     : Mon, 30 Sep 2024 08:43:28 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Mon, 30 Sep 2024 08:43:28 +0900    

All these code paths use their own entry point when starting parallel  
workers, but failed to set a query ID, even if they set a text query.  
Hence, this data would be missed in pg_stat_activity for the worker  
processes.  The main entry point for parallel query processing,  
ParallelQueryMain(), is already doing that by saving its query ID in a  
dummy PlannedStmt, but not the others.  The code is changed so as the  
query ID of these queries is set in their shared state, and reported  
back once the parallel workers start.  
  
Some tests are added to show how the failures can happen for btree and  
BRIN with a parallel build enforced, which are able to trigger a failure  
in an assertion added by 24f520594809 in the recovery TAP test  
027_stream_regress.pl where pg_stat_statements is always loaded.  In  
this case, the executor path was taken because the index expression  
needs to be flattened when building its IndexInfo.  
  
Alexander Lakhin has noticed the problem in btree, and I have noticed  
that the issue was more spread.  This is arguably a bug, but nobody has  
complained about that until now, so no backpatch is done out of caution.  
If folks would like to see a backpatch, well, let me know.  
  
Reported-by: Alexander Lakhin  
Reviewed-by: Sami Imseih  
Discussion: https://postgr.es/m/[email protected]  

commit   : 0d5a3d7574f8dabcbc229c2a06a9cb2d9a43c7c5    
  
author   : Noah Misch <[email protected]>    
date     : Sun, 29 Sep 2024 15:54:25 -0700    
  
committer: Noah Misch <[email protected]>    
date     : Sun, 29 Sep 2024 15:54:25 -0700    

Defect in last week's commit aac2c9b4fde889d13f859c233c2523345e72d32b,  
per Coverity.  Reaching this would need catalog corruption.  Back-patch  
to v12, like that commit.  

commit   : e9339782a631eeef01281bc7e1633dd6b970106e    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 29 Sep 2024 13:40:03 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 29 Sep 2024 13:40:03 -0400    

Oversight in e882bcae0.  Per Coverity.  

commit   : c1ff2d8bc5be55e302731a16aaff563b7f03ed7c    
  
author   : Noah Misch <[email protected]>    
date     : Fri, 27 Sep 2024 15:28:56 -0700    
  
committer: Noah Misch <[email protected]>    
date     : Fri, 27 Sep 2024 15:28:56 -0700    

Back-patch to v12 (all supported versions).  

commit   : d8ebcac547d7c25c1378e0fc5810528f343ab8d5    
  
author   : Nathan Bossart <[email protected]>    
date     : Fri, 27 Sep 2024 16:21:21 -0500    
  
committer: Nathan Bossart <[email protected]>    
date     : Fri, 27 Sep 2024 16:21:21 -0500    

Since v17, CREATE MATERIALIZED VIEW has set search_path to  
"pg_catalog, pg_temp" while running the query.  The docs for the  
other commands that restrict search_path mention it, but the page  
for CREATE MATERIALIZED VIEW does not.  Fix that.  
  
Oversight in commit 4b74ebf726.  
  
Author: Yugo Nagata  
Reviewed-by: Jeff Davis  
Discussion: https://postgr.es/m/20240805160502.d2a4975802a832b1e04afb80%40sraoss.co.jp  
Backpatch-through: 17  

commit   : a3179ab692be4314d5ee5cd56598976c487d5ef2    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 27 Sep 2024 16:04:04 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 27 Sep 2024 16:04:04 -0400    

Up to now, remove_rel_from_query() has done a pretty shoddy job  
of updating our where-needed bitmaps (per-Var attr_needed and  
per-PlaceHolderVar ph_needed relid sets).  It removed direct mentions  
of the to-be-removed baserel and outer join, which is the minimum  
amount of effort needed to keep the data structures self-consistent.  
But it didn't account for the fact that the removed join ON clause  
probably mentioned Vars of other relations, and those Vars might now  
not be needed as high up in the join tree as before.  It's easy to  
show cases where this results in failing to remove a lower outer join  
that could also have been removed.  
  
To fix, recalculate the where-needed bitmaps from scratch after  
each successful join removal.  This sounds expensive, but it seems  
to add only negligible planner runtime.  (We cheat a little bit  
by preserving "relation 0" entries in the bitmaps, allowing us to  
skip re-scanning the targetlist and HAVING qual.)  
  
The submitted test case drew attention because we had successfully  
optimized away the lower join prior to v16.  I suspect that that's  
somewhat accidental and there are related cases that were never  
optimized before and now can be.  I've not tried to come up with  
one, though.  
  
Perhaps we should back-patch this into v16 and v17 to repair the  
performance regression.  However, since it took a year for anyone  
to notice the problem, it can't be affecting too many people.  Let's  
let the patch bake awhile in HEAD, and see if we get more complaints.  
  
Per bug #18627 from Mikaël Gourlaouen.  No back-patch for now.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 7f7474a8e4002ac9fd4979cc7b16b50b70b70c28    
  
author   : Robert Haas <[email protected]>    
date     : Fri, 27 Sep 2024 11:14:31 -0400    
  
committer: Robert Haas <[email protected]>    
date     : Fri, 27 Sep 2024 11:14:31 -0400    

commit   : 8dfd3129027969fdd2d9d294220c867d2efd84aa    
  
author   : Robert Haas <[email protected]>    
date     : Fri, 27 Sep 2024 08:40:24 -0400    
  
committer: Robert Haas <[email protected]>    
date     : Fri, 27 Sep 2024 08:40:24 -0400    

This also works for compressed tar-format backups. However, -n must be  
used, because we use pg_waldump to verify WAL, and it doesn't yet know  
how to verify WAL that is stored inside of a tarfile.  
  
Amul Sul, reviewed by Sravan Kumar and by me, and revised by me.  

commit   : 8410f738ad2fd94fc068ce0189e1ae04ef3c12e3    
  
author   : Fujii Masao <[email protected]>    
date     : Fri, 27 Sep 2024 10:20:22 +0900    
  
committer: Fujii Masao <[email protected]>    
date     : Fri, 27 Sep 2024 10:20:22 +0900    

Author: Koki Nakamura  
Discussion: https://postgr.es/m/[email protected]  

commit   : 09620ea09121b66e9372e8e9244d8bb6b19b89d7    
  
author   : Michael Paquier <[email protected]>    
date     : Fri, 27 Sep 2024 09:40:09 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Fri, 27 Sep 2024 09:40:09 +0900    

An invalid toast index is skipped in reindex_relation().  These would be  
remnants of a failed REINDEX CONCURRENTLY and they should never been  
rebuilt as there can only be one valid toast index at a time.  
  
REINDEX_REL_SUPPRESS_INDEX_USE, used by CLUSTER and VACUUM FULL, needs  
to maintain a list of the indexes being processed.  The list of indexes  
is retrieved from the relation cache, and includes invalid indexes.  The  
code has missed that invalid toast indexes are ignored in  
reindex_relation() as this leads to a hard failure in reindex_index(),  
and they were left in the reindex pending list, making the list  
inconsistent when rechecked.  The incorrect memory access was happening  
when scanning pg_class for the refresh of pg_database.datfrozenxid, when  
doing a scan of pg_class.  
  
This issue exists since REINDEX CONCURRENTLY exists, where invalid toast  
indexes can exist, so backpatch all the way down.  
  
Reported-by: Alexander Lakhin  
Author: Tender Wang  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 12  

commit   : f762d99c8783f5ca99d5a6ab0f8245e164a954ce    
  
author   : Michael Paquier <[email protected]>    
date     : Fri, 27 Sep 2024 07:26:29 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Fri, 27 Sep 2024 07:26:29 +0900    

This commit improves the catalog data in pg_proc for the three functions  
for has_largeobject_privilege(), introduced in 4eada203a5a8:  
- Fix their descriptions (typos and consistency).  
- Reallocate OIDs to be within the 8000-9999 range as required by  
a6417078c414.  
  
Bump catalog version.  
  
Reviewed-by: Fujii Masao  
Discussion: https://postgr.es/m/[email protected]  

commit   : b52adbad46740524cbfbffaeb202b01a2c16202a    
  
author   : Nathan Bossart <[email protected]>    
date     : Thu, 26 Sep 2024 15:51:23 -0500    
  
committer: Nathan Bossart <[email protected]>    
date     : Thu, 26 Sep 2024 15:51:23 -0500    

Creating, reindexing, and dropping an index concurrently could  
entail accessing pg_index's TOAST table, which was recently added  
in commit b52c4fc3c0.  These code paths start and commit their own  
transactions, but they do not always set an active snapshot.  This  
rightfully leads to assertion failures and ERRORs when trying to  
access pg_index's TOAST table, such as the following:  
  
	ERROR:  cannot fetch toast data without an active snapshot  
  
To fix, push an active snapshot just before each section of code  
that might require accessing pg_index's TOAST table, and pop it  
shortly afterwards.  
  
Reported-by: Alexander Lakhin  
Reviewed-by: Michael Paquier  
Discussion: https://postgr.es/m/a97d7401-e7c9-f771-6a00-037379f0a8bb%40gmail.com  

commit   : 9726653185de62f2f8bf42a25e961bc56895a41b    
  
author   : Nathan Bossart <[email protected]>    
date     : Thu, 26 Sep 2024 13:54:37 -0500    
  
committer: Nathan Bossart <[email protected]>    
date     : Thu, 26 Sep 2024 13:54:37 -0500    

I wanted to avoid adjusting this code too much when converting  
these tasks to use the new parallelization framework (see commit  
40e2e5e92b), which is why this is being done as a follow-up commit.  
These stylistic adjustments result in fewer lines of code and fewer  
levels of indentation in some places.  
  
While at it, add names to the UpgradeTaskSlotState enum and the  
UpgradeTaskSlot struct.  I'm not aware of any established project  
policy in this area, but let's at least be consistent within the  
same file.  
  
Reviewed-by: Daniel Gustafsson  
Discussion: https://postgr.es/m/ZunW7XHLd2uTts4f%40nathan  

commit   : 147bbc90f75794e5522dcbadaf2bbe1af3ce574a    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 26 Sep 2024 11:02:31 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 26 Sep 2024 11:02:31 -0400    

int_to_roman() only accepts plain "int" input, which is fine since  
we're going to produce '###############' for any value above 3999  
anyway.  However, the numeric and int8 variants of to_char() would  
throw an error if the given input exceeded the integer range, while  
the float-input variants invoked undefined-per-C-standard behavior.  
Fix things so that you uniformly get '###############' for out of  
range input.  
  
Also add test cases covering this code, plus the equally-untested  
EEEE, V, and PL format codes.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : e3a92ab0708aa8ac0c8466312cef316ea6d03c63    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 26 Sep 2024 10:37:51 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 26 Sep 2024 10:37:51 -0400    

Commit e08d74ca1 removed that restriction, but missed updating  
the documentation about it.  Noted by Egor Rogov.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : d66572d9fedb632af5df65ce513d04dc2a1682a3    
  
author   : Amit Kapila <[email protected]>    
date     : Thu, 26 Sep 2024 16:14:07 +0530    
  
committer: Amit Kapila <[email protected]>    
date     : Thu, 26 Sep 2024 16:14:07 +0530    

The steps used to upgrade the cluster first upgraded the publisher node  
but ideally, any node could be upgraded first.  
  
Author: Vignesh C  
Discussion: https://postgr.es/m/CALDaNm1_iDO6srWzntqTr0ZDVkk2whVhNKEWAvtgZBfSmuBeZQ@mail.gmail.com  
Discussion: https://postgr.es/m/CALDaNm3Y-M+kAqr_mf=_C1kNwAB-cS6S5hTHnKMEqDw4sGEh4Q@mail.gmail.com  

commit   : e658038772f59588c8be8b016c8a7e28e7705ab4    
  
author   : Alexander Korotkov <[email protected]>    
date     : Thu, 26 Sep 2024 11:48:23 +0300    
  
committer: Alexander Korotkov <[email protected]>    
date     : Thu, 26 Sep 2024 11:48:23 +0300    

Use an oid from 8000-9999 range, as required by 98eab30b93d5.  
  
Reported-by: Michael Paquier  
Discussion: https://postgr.es/m/ZvUY6bfTwB0GsyzP%40paquier.xyz  

commit   : 2ceeb638b7b27da156c10cb9d5ea4f81cabda0d1    
  
author   : Nathan Bossart <[email protected]>    
date     : Wed, 25 Sep 2024 11:18:56 -0500    
  
committer: Nathan Bossart <[email protected]>    
date     : Wed, 25 Sep 2024 11:18:56 -0500    

There's no need to add another level of indentation to this status  
message.  pg_log() will put it in the right place.  
  
Oversight in commit 347758b120.  
  
Reviewed-by: Daniel Gustafsson  
Discussion: https://postgr.es/m/ZunW7XHLd2uTts4f%40nathan  
Backpatch-through: 17  

commit   : dce507356a4ab7d548dca9d7abf1800a0fc0a18e    
  
author   : Alvaro Herrera <[email protected]>    
date     : Wed, 25 Sep 2024 16:42:02 +0200    
  
committer: Alvaro Herrera <[email protected]>    
date     : Wed, 25 Sep 2024 16:42:02 +0200    

The unwritten assumption of this code is that both events->head and  
events->tail are NULL together (an empty list) or they aren't.  So the  
code was testing events->head for nullness and using that as a cue to  
deference events->tail, which annoys the Svace static code analyzer.  
We can silence it by testing events->tail member instead, and add an  
assertion about events->head to ensure it's all consistent.  
  
This code is very old and as far as we know, there's never been a bug  
report related to this, so there's no need to backpatch.  
  
This was found by the ALT Linux Team using Svace.  
  
Author: Alexander Kuznetsov <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  

commit   : 1ab67c9dfaadda86059f405e5746efb6ddb9fe21    
  
author   : Michael Paquier <[email protected]>    
date     : Wed, 25 Sep 2024 14:43:16 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Wed, 25 Sep 2024 14:43:16 +0900    

Running vacuumdb with a non-superuser while another user has created a  
temporary table would lead to a mid-flight permission failure,  
interrupting the operation.  vacuum_rel() skips temporary relations of  
other backends, and it makes no sense for vacuumdb to know about these  
relations, so let's switch it to ignore temporary relations entirely.  
  
Adding a qual in the query based on relpersistence simplifies the  
generation of its WHERE clause in vacuum_one_database(), per se the  
removal of "has_where".  
  
Author: VaibhaveS, Michael Paquier  
Reviewed-by: Fujii Masao  
Discussion: https://postgr.es/m/CAM_eQjwfAR=y3G1fGyS1U9FTmc+FyJm9amNfY2QCZBnDDbNPZg@mail.gmail.com  
Backpatch-through: 12  

commit   : 7fdeaf5774d05245e82632e763665ff62db5598e    
  
author   : Amit Kapila <[email protected]>    
date     : Wed, 25 Sep 2024 10:06:10 +0530    
  
committer: Amit Kapila <[email protected]>    
date     : Wed, 25 Sep 2024 10:06:10 +0530    

Author: Vignesh C  
Reviewed-by: Peter Smith, Amit Kapila, Hayato Kuroda, Bharath Rupireddy  
Discussion: https://postgr.es/m/CALDaNm1_iDO6srWzntqTr0ZDVkk2whVhNKEWAvtgZBfSmuBeZQ@mail.gmail.com  

commit   : ba90eac7a9953f6f6fa5e0a0cc7441d09778f8b9    
  
author   : Michael Paquier <[email protected]>    
date     : Wed, 25 Sep 2024 10:04:44 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Wed, 25 Sep 2024 10:04:44 +0900    

There are many grammar flavors that depend on the parse node  
VariableSetStmt.  This closes the gap in pg_stat_statements by providing  
test coverage for what should be a large majority of them, improving more  
the work begun in de2aca288569.  This will be used to ease the  
evaluation of a path towards more normalization of SET queries with  
query jumbling.  
  
Note that SET NAMES (grammar from the standard, synonym of SET  
client_encoding) is omitted on purpose, this could use UTF8 with a  
conditional script where UTF8 is supported, but that does not seem worth  
the maintenance cost for the sake of these tests.  
  
The author has submitted most of these in a TAP test (filled in any  
holes I could spot), still queries in a SQL file of pg_stat_statements  
is able to achieve the same goal while being easier to look at when  
testing normalization patterns.  
  
Author: Greg Sabino Mullane, Michael Paquier  
Discussion: https://postgr.es/m/CAKAnmmJtJY2jzQN91=2QAD2eAJAA-Per61eyO48-TyxEg-q0Rg@mail.gmail.com  

commit   : aac2c9b4fde889d13f859c233c2523345e72d32b    
  
author   : Noah Misch <[email protected]>    
date     : Tue, 24 Sep 2024 15:25:18 -0700    
  
committer: Noah Misch <[email protected]>    
date     : Tue, 24 Sep 2024 15:25:18 -0700    

The previous commit fixed some ways of losing an inplace update.  It  
remained possible to lose one when a backend working toward a  
heap_update() copied a tuple into memory just before inplace update of  
that tuple.  In catalogs eligible for inplace update, use LOCKTAG_TUPLE  
to govern admission to the steps of copying an old tuple, modifying it,  
and issuing heap_update().  This includes MERGE commands.  To avoid  
changing most of the pg_class DDL, don't require LOCKTAG_TUPLE when  
holding a relation lock sufficient to exclude inplace updaters.  
Back-patch to v12 (all supported versions).  In v13 and v12, "UPDATE  
pg_class" or "UPDATE pg_database" can still lose an inplace update.  The  
v14+ UPDATE fix needs commit 86dc90056dfdbd9d1b891718d2e5614e3e432f35,  
and it wasn't worth reimplementing that fix without such infrastructure.  
  
Reviewed by Nitin Motiani and (in earlier versions) Heikki Linnakangas.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : a07e03fd8fa7daf4d1356f7cb501ffe784ea6257    
  
author   : Noah Misch <[email protected]>    
date     : Tue, 24 Sep 2024 15:25:18 -0700    
  
committer: Noah Misch <[email protected]>    
date     : Tue, 24 Sep 2024 15:25:18 -0700    

As previously-added tests demonstrated, heap_inplace_update() could  
instead update an unrelated tuple of the same catalog.  It could lose  
the update.  Losing relhasindex=t was a source of index corruption.  
Inplace-updating commands like VACUUM will now wait for heap_update()  
commands like GRANT TABLE and GRANT DATABASE.  That isn't ideal, but a  
long-running GRANT already hurts VACUUM progress more just by keeping an  
XID running.  The VACUUM will behave like a DELETE or UPDATE waiting for  
the uncommitted change.  
  
For implementation details, start at the systable_inplace_update_begin()  
header comment and README.tuplock.  Back-patch to v12 (all supported  
versions).  In back branches, retain a deprecated heap_inplace_update(),  
for extensions.  
  
Reported by Smolkin Grigory.  Reviewed by Nitin Motiani, (in earlier  
versions) Heikki Linnakangas, and (in earlier versions) Alexander  
Lakhin.  
  
Discussion: https://postgr.es/m/CAMp+ueZQz3yDk7qg42hk6-9gxniYbp-=bG2mgqecErqR5gGGOA@mail.gmail.com  

commit   : dbf3f974ee04d24547690268b1fc2b7eb12b4ebc    
  
author   : Noah Misch <[email protected]>    
date     : Tue, 24 Sep 2024 15:25:18 -0700    
  
committer: Noah Misch <[email protected]>    
date     : Tue, 24 Sep 2024 15:25:18 -0700    

The current use always releases this locktag.  A planned use will  
continue that intent.  It will involve more areas of code, making unlock  
omissions easier.  Warn under debug_assertions, like we do for various  
resource leaks.  Back-patch to v12 (all supported versions), the plan  
for the commit of the new use.  
  
Reviewed by Heikki Linnakangas.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : ac30021356e7aa05a069741d17c3db3e8d520933    
  
author   : Jeff Davis <[email protected]>    
date     : Tue, 24 Sep 2024 15:15:03 -0700    
  
committer: Jeff Davis <[email protected]>    
date     : Tue, 24 Sep 2024 15:15:03 -0700    

Like ICU, allow a length of -1 to be specified for NUL-terminated  
arguments to pg_strncoll(), pg_strnxfrm(), and pg_strnxfrm_prefix().  
  
Simplifies the code and comments.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 1591b38d17c55015403f6e3c9461538ffcf704e7    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 24 Sep 2024 17:21:38 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 24 Sep 2024 17:21:38 -0400    

Commit d1379ebf4 carelessly broke printACLColumn for pre-9.4 servers,  
by using the cardinality() function which we introduced in 9.4.  
We expect psql's describe-related commands to work back to 9.2, so  
this is bad.  Use the longstanding array_length() function instead.  
  
Per report from Christoph Berg.  Back-patch to v17.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : ceeaaed87aa39425f1f2c2409f927c76efb8de89    
  
author   : Jeff Davis <[email protected]>    
date     : Tue, 24 Sep 2024 12:01:45 -0700    
  
committer: Jeff Davis <[email protected]>    
date     : Tue, 24 Sep 2024 12:01:45 -0700    

Ensure that error paths within these functions do not leak a collator,  
and return the result rather than using an out parameter. (Error paths  
in the caller may still result in a leaked collator, which will be  
addressed separately.)  
  
In make_libc_collator(), if the first newlocale() succeeds and the  
second one fails, close the first locale_t object.  
  
The function make_icu_collator() doesn't have any external callers, so  
change it to be static.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 59f0eea7b001e3f5d38fd84a9ee5482a23be56e2    
  
author   : Peter Eisentraut <[email protected]>    
date     : Tue, 24 Sep 2024 20:41:47 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Tue, 24 Sep 2024 20:41:47 +0200    

Some header files under contrib/isn/ are not meant to be included  
independently, and they fail -Wmissing-variable-declarations when  
doing so.  
  
Reported-by: Thomas Munro <[email protected]>  
Discussion: https://www.postgresql.org/message-id/flat/CA%2BhUKG%2BYVt5MBD-w0HyHpsGb4U8RNge3DvAbDmOFy_epGhZ2Mg%40mail.gmail.com#aba3226c6dd493923bd6ce95d25a2d77  

commit   : cd838e200880c6f52c5b5e30887e5ff584876bef    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 24 Sep 2024 12:59:43 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 24 Sep 2024 12:59:43 -0400    

When our XML-handling modules were first written, the SQL standard  
lacked any error codes that were particularly intended for XML  
error conditions.  Unsurprisingly, this led to some rather random  
choices of errcodes in those modules.  Now the standard has a whole  
SQLSTATE class, "Class 10 - XQuery Error", with a reasonably large  
selection of relevant-looking errcodes.  
  
In this patch I've chosen one fairly generic code defined by the  
standard, 10608 = invalid_argument_for_xquery, and used it where  
it seemed appropriate.  I've also made an effort to replace  
ERRCODE_INTERNAL_ERROR everywhere it was not clearly reporting  
a coding problem; in particular, many of the existing uses look  
like they can fairly be reported as ERRCODE_OUT_OF_MEMORY.  
  
It might be interesting to try to map libxml2's error codes into  
the standard's new collection, but I've not undertaken that here.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 3da436ec09ae2f1a0167d4b74b30449f0292f581    
  
author   : Peter Geoghegan <[email protected]>    
date     : Tue, 24 Sep 2024 12:58:55 -0400    
  
committer: Peter Geoghegan <[email protected]>    
date     : Tue, 24 Sep 2024 12:58:55 -0400    

The array->scan_key references fixed up at the end of preprocessing  
start out as offsets into the arrayKeyData[] array (the array returned  
by _bt_preprocess_array_keys at the start of preprocessing that involves  
array scan keys).  Offsets into the arrayKeyData[] array are no longer  
guaranteed to be valid offsets into our original scan->keyData[] input  
scan key array, but comments describing the array->scan_key references  
still talked about scan->keyData[].  Update those comments.  
  
Oversight in commit b5249741.  

commit   : 62ddf7ee9a399e0b9624412fc482ed7365e38958    
  
author   : David Rowley <[email protected]>    
date     : Tue, 24 Sep 2024 18:03:40 +1200    
  
committer: David Rowley <[email protected]>    
date     : Tue, 24 Sep 2024 18:03:40 +1200    

Since autovacuum does not trigger an ANALYZE for partitioned tables,  
users must perform these manually.  However, performing a manual ANALYZE  
on a partitioned table would always result in recursively analyzing each  
partition and that could be undesirable as autovacuum takes care of that.  
For partitioned tables that contain a large number of partitions, having  
to analyze each partition could take an unreasonably long time, especially  
so for tables with a large number of columns.  
  
Here we allow the ONLY keyword to prefix the name of the table to allow  
users to have ANALYZE skip processing partitions.  This option can also  
be used with VACUUM, but there is no work to do if VACUUM ONLY is used on  
a partitioned table.  
  
This commit also changes the behavior of VACUUM	and ANALYZE for  
inheritance parents.  Previously inheritance child tables would not be  
processed when operating on the parent.  Now, by default we *do* operate  
on the child tables.  ONLY can be used to obtain the old behavior.  
The release notes should note this as an incompatibility.  The default  
behavior has not changed for partitioned tables as these always  
recursively processed the partitions.  
  
Author: Michael Harris <[email protected]>  
Discussion: https://postgr.es/m/CADofcAWATx_haD=QkSxHbnTsAe6+e0Aw8Eh4H8cXyogGvn_kOg@mail.gmail.com  
Discussion: https://postgr.es/m/CADofcAXVbD0yGp_EaC9chmzsOoSai3jcfBCnyva3j0RRdRvMVA@mail.gmail.com  
Reviewed-by: Jelte Fennema-Nio <[email protected]>  
Reviewed-by: Melih Mutlu <[email protected]>  
Reviewed-by: Atsushi Torikoshi <[email protected]>  
Reviewed-by: jian he <[email protected]>  
Reviewed-by: David Rowley <[email protected]>  

commit   : bbba59e69a56e1622e270f5e47b402c3a904cefc    
  
author   : Michael Paquier <[email protected]>    
date     : Tue, 24 Sep 2024 08:59:08 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Tue, 24 Sep 2024 08:59:08 +0900    

Attempting these commands for a non-partitioned table would result in a  
failure when creating the relation in transformPartitionCmd().  This  
gives the possibility to throw an error earlier with a much better error  
message, thanks to d69a3f4d70b7.  
  
The extra test cases are from me.  Note that FINALIZE uses a different  
subcommand and it had no coverage for its failure path with  
non-partitioned tables.  
  
Author: Álvaro Herrera, Michael Paquier  
Reviewed-by: Nathan Bossart  
Discussion: https://postgr.es/m/[email protected]  

commit   : 75240f65e700d7d157be27653c70fe75108f25c1    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 23 Sep 2024 12:30:51 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 23 Sep 2024 12:30:51 -0400    

Coverity pointed out that inc_lex_level() would leak memory  
(not to mention corrupt the pstack data structure) if some  
but not all of its three REALLOC's failed.  To fix, store  
successfully-updated pointers back into the pstack struct  
immediately.  
  
Oversight in 0785d1b8b, so no need for back-patch.  

commit   : a7e5237f268ea378c514635d65a55aa47621958a    
  
author   : Tomas Vondra <[email protected]>    
date     : Mon, 23 Sep 2024 11:37:12 +0200    
  
committer: Tomas Vondra <[email protected]>    
date     : Mon, 23 Sep 2024 11:37:12 +0200    

Commit c4d5cb71d229 introduced a couple asserts in the fast-path locking  
code, upsetting Coverity.  
  
The assert in InitProcGlobal() is clearly wrong, as it assigns instead  
of checking the value. This is harmless, but doesn't check anything.  
  
The asserts in FAST_PATH_ macros are written as if for signed values,  
but the macros are only called for unsigned ones. That makes the check  
for (val >= 0) useless. Checks written as ((uint32) x < max) work for  
both signed and unsigned values. Negative values should wrap to values  
greater than INT32_MAX.  
  
Per Coverity, report by Tom Lane.  
  
Reported-by: Tom Lane  
Discussion: https://postgr.es/m/[email protected]  

commit   : 40708acd65c112149493d7159ca5c5a9391c9d35    
  
author   : Tatsuo Ishii <[email protected]>    
date     : Mon, 23 Sep 2024 16:34:24 +0900    
  
committer: Tatsuo Ishii <[email protected]>    
date     : Mon, 23 Sep 2024 16:34:24 +0900    

This commit is similar to 95d6e9af07, expanding the idea to CTE scan,  
table function scan and recursive union scan nodes so that the maximum  
tuplestore memory or disk usage is shown with EXPLAIN ANALYZE command.  
  
Also adjust show_storage_info() so that it accepts storage type and  
storage size arguments instead of Tuplestorestate. This allows the  
node types to share the formatting code using show_storage_info(). Due  
to this show_material_info() and show_windowagg_info() are also  
modified.  
  
Reviewed-by: David Rowley  
Discussion: https://postgr.es/m/20240918.211246.1127161704188186085.ishii%40postgresql.org  

commit   : 6aa44060a3c94ee10273bb8a89e98a5bb2fbbacb    
  
author   : Nathan Bossart <[email protected]>    
date     : Sat, 21 Sep 2024 15:17:46 -0500    
  
committer: Nathan Bossart <[email protected]>    
date     : Sat, 21 Sep 2024 15:17:46 -0500    

pg_authid's only varlena column is rolpassword, which unfortunately  
cannot be de-TOASTed during authentication because we haven't  
selected a database yet and cannot read pg_class.  By removing  
pg_authid's TOAST table, attempts to set password hashes that  
require out-of-line storage will fail with a "row is too big"  
error instead.  We may want to provide a more user-friendly error  
in the future, but for now let's just remove the useless TOAST  
table.  
  
Bumps catversion.  
  
Reported-by: Alexander Lakhin  
Reviewed-by: Tom Lane, Michael Paquier  
Discussion: https://postgr.es/m/89e8649c-eb74-db25-7945-6d6b23992394%40gmail.com  

commit   : c4d5cb71d229095a39fda1121a75ee40e6069a2a    
  
author   : Tomas Vondra <[email protected]>    
date     : Sat, 21 Sep 2024 20:06:49 +0200    
  
committer: Tomas Vondra <[email protected]>    
date     : Sat, 21 Sep 2024 20:06:49 +0200    

Replace the fixed-size array of fast-path locks with arrays, sized on  
startup based on max_locks_per_transaction. This allows using fast-path  
locking for workloads that need more locks.  
  
The fast-path locking introduced in 9.2 allowed each backend to acquire  
a small number (16) of weak relation locks cheaply. If a backend needs  
to hold more locks, it has to insert them into the shared lock table.  
This is considerably more expensive, and may be subject to contention  
(especially on many-core systems).  
  
The limit of 16 fast-path locks was always rather low, because we have  
to lock all relations - not just tables, but also indexes, views, etc.  
For planning we need to lock all relations that might be used in the  
plan, not just those that actually get used in the final plan. So even  
with rather simple queries and schemas, we often need significantly more  
than 16 locks.  
  
As partitioning gets used more widely, and the number of partitions  
increases, this limit is trivial to hit. Complex queries may easily use  
hundreds or even thousands of locks. For workloads doing a lot of I/O  
this is not noticeable, but for workloads accessing only data in RAM,  
the access to the shared lock table may be a serious issue.  
  
This commit removes the hard-coded limit of the number of fast-path  
locks. Instead, the size of the fast-path arrays is calculated at  
startup, and can be set much higher than the original 16-lock limit.  
The overall fast-path locking protocol remains unchanged.  
  
The variable-sized fast-path arrays can no longer be part of PGPROC, but  
are allocated as a separate chunk of shared memory and then references  
from the PGPROC entries.  
  
The fast-path slots are organized as a 16-way set associative cache. You  
can imagine it as a hash table of 16-slot "groups". Each relation is  
mapped to exactly one group using hash(relid), and the group is then  
processed using linear search, just like the original fast-path cache.  
With only 16 entries this is cheap, with good locality.  
  
Treating this as a simple hash table with open addressing would not be  
efficient, especially once the hash table gets almost full. The usual  
remedy is to grow the table, but we can't do that here easily. The  
access would also be more random, with worse locality.  
  
The fast-path arrays are sized using the max_locks_per_transaction GUC.  
We try to have enough capacity for the number of locks specified in the  
GUC, using the traditional 2^n formula, with an upper limit of 1024 lock  
groups (i.e. 16k locks). The default value of max_locks_per_transaction  
is 64, which means those instances will have 64 fast-path slots.  
  
The main purpose of the max_locks_per_transaction GUC is to size the  
shared lock table. It is often set to the "average" number of locks  
needed by backends, with some backends using significantly more locks.  
This should not be a major issue, however. Some backens may have to  
insert locks into the shared lock table, but there can't be too many of  
them, limiting the contention.  
  
The only solution is to increase the GUC, even if the shared lock table  
already has sufficient capacity. That is not free, especially in terms  
of memory usage (the shared lock table entries are fairly large). It  
should only happen on machines with plenty of memory, though.  
  
In the future we may consider a separate GUC for the number of fast-path  
slots, but let's try without one first.  
  
Reviewed-by: Robert Haas, Jakub Wartak  
Discussion: https://postgr.es/m/[email protected]  

commit   : b524974106acb05ae4f9c2178153c3ead72eaf04    
  
author   : Peter Geoghegan <[email protected]>    
date     : Sat, 21 Sep 2024 13:25:49 -0400    
  
committer: Peter Geoghegan <[email protected]>    
date     : Sat, 21 Sep 2024 13:25:49 -0400    

Teach _bt_preprocess_array_keys to eliminate redundant array equality  
scan keys directly, rather than just marking them as redundant.  Its  
_bt_preprocess_keys caller is no longer required to ignore input scan  
keys that were marked redundant in this way.  Oversights like the one  
fixed by commit f22e17f7 are no longer possible.  
  
The new scheme also makes it easier for _bt_preprocess_keys to output a  
so.keyData[] scan key array with _more_ scan keys than it was passed in  
its scan.keyData[] input scan key array.  An upcoming patch that adds  
skip scan optimizations to nbtree will take advantage of this.  
  
In passing, remove and rename certain _bt_preprocess_keys variables to  
make the difference between our input scan key array and our output scan  
key array clearer.  
  
Author: Peter Geoghegan <[email protected]>  
Reviewed-By: Tomas Vondra <[email protected]>  
Discussion: https://postgr.es/m/CAH2-Wz=9A_UtM7HzUThSkQ+BcrQsQZuNhWOvQWK06PRkEp=SKQ@mail.gmail.com  

commit   : 54562c9cfa2281b6303cdea1aff9596c4a5de4b2    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 20 Sep 2024 16:37:55 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 20 Sep 2024 16:37:55 -0400    

table_beginscan_parallel and index_beginscan_parallel contain  
Asserts checking that the relation a worker will use in  
a parallel scan is the same one the leader intended.  However,  
they were checking for relation OID match, which was not strong  
enough to detect the mismatch problem fixed in 126ec0bc7.  
What would be strong enough is to compare relfilenodes instead.  
Arguably, that's a saner definition anyway, since a scan surely  
operates on a physical relation not a logical one.  Hence,  
store and compare RelFileLocators not relation OIDs.  Also  
ensure that index_beginscan_parallel checks the index identity  
not just the table identity.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : afb03e2ebf595c057db0372f543f9f796effaadf    
  
author   : Nathan Bossart <[email protected]>    
date     : Fri, 20 Sep 2024 15:18:42 -0500    
  
committer: Nathan Bossart <[email protected]>    
date     : Fri, 20 Sep 2024 15:18:42 -0500    

Author: Michael Banck  
Discussion: https://postgr.es/m/66edaed0.050a0220.32a9ba.42c8%40mx.google.com  

commit   : a2ebf3274a43acf7ae36d608fc26090b803ab6e1    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 20 Sep 2024 15:56:34 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 20 Sep 2024 15:56:34 -0400    

This has always been possible, but the syntax is a bit obscure,  
and our user-facing docs were not very helpful.  Spell it out  
more clearly.  
  
Per complaint from Dominique Devienne.  Back-patch to  
all supported branches.  
  
Discussion: https://postgr.es/m/CAFCRh-8JNEy+dV4SXFOrWca50u+d=--TO4cq=+ac1oBtfJy4AA@mail.gmail.com  

commit   : c00c54a9ac1e0c52ace8051a30805ca74ae53212    
  
author   : Peter Geoghegan <[email protected]>    
date     : Fri, 20 Sep 2024 14:06:32 -0400    
  
committer: Peter Geoghegan <[email protected]>    
date     : Fri, 20 Sep 2024 14:06:32 -0400    

Commit 5bf748b8, which enhanced nbtree ScalarArrayOp execution, made  
parallel index scans work with the new design for arrays via explicit  
scheduling of primitive index scans.  Under this scheme a parallel index  
scan with array keys will perform the same number of index descents as  
an equivalent serial index scan (barring corner cases where an  
individual parallel worker discovers that it can advance the scan's  
array keys without anybody needing to perform another descent of the  
index to get to the relevant page on the leaf level).  
  
Despite all this, the pgstats accounting wasn't updated; it continued to  
increment the total number of index scans for the rel once per _bt_first  
call, no matter the details.  As a result, the number of (primitive)  
index scans could be over-counted during parallel scans.  
  
To fix, delay incrementing the count of index scans until after we've  
established that another descent of the index (using either _bt_search  
or _bt_endpoint) is required.  That way pg_stat_user_tables.idx_scan  
always advances in the same way, regardless of whether or not the scan  
makes use of parallelism.  
  
Oversight in commit 5bf748b8, which enhanced nbtree ScalarArrayOp  
execution.  
  
Author: Peter Geoghegan <[email protected]>  
Reviewed-By: Tomas Vondra <[email protected]>  
Discussion: https://postgr.es/m/CAH2-Wz=E7XrkvscBN0U6V81NK3Q-dQOmivvbEsjG-zwEfDdFpg@mail.gmail.com  
Discussion: https://postgr.es/m/CAH2-WzkRqvaqR2CTNqTZP0z6FuL4-3ED6eQB0yx38XBNj1v-4Q@mail.gmail.com  
Backpatch: 17-, where nbtree SAOP execution was enhanced.  

commit   : d35e29387870fecfdb52ffd4c93c651f0c7c1b43    
  
author   : Michael Paquier <[email protected]>    
date     : Fri, 20 Sep 2024 09:49:43 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Fri, 20 Sep 2024 09:49:43 +0900    

Like for Cluster::psql, this can be handy to force the use of a  
connection string with some values overriden, like a "host".  
  
Author: Aidar Imamov  
Discussion: https://postgr.es/m/[email protected]  

commit   : 126ec0bc76d044d3a9eb86538b61242bf7da6db4    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 19 Sep 2024 20:58:17 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 19 Sep 2024 20:58:17 -0400    

We need to do RestoreRelationMap before loading catalog-derived  
state, else the worker may end up with catalog relcache entries  
containing stale relfilenode data.  Move up RestoreReindexState  
too, on the principle that that should also happen before we  
do much of any catalog access.  
  
I think ideally these things would happen even before InitPostgres,  
but there are various problems standing in the way of that, notably  
that the relmapper thinks "active" mappings should be discarded at  
transaction end.  The implication of this is that InitPostgres and  
RestoreLibraryState will see the same catalog state as an independent  
backend would see, which is probably fine; at least, it's been like  
that all along.  
  
Per report from Justin Pryzby.  There is a case to be made that  
this should be back-patched.  But given the lack of complaints  
before 6e086fa2e and the short amount of time remaining before  
17.0 wraps, I'll just put it in HEAD for now.  
  
Discussion: https://postgr.es/m/ZuoU_8EbSTE14o1U@pryzbyj2023  

commit   : 91287b5f5da324ac24678f556962e1b95e52240c    
  
author   : Michael Paquier <[email protected]>    
date     : Fri, 20 Sep 2024 08:59:20 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Fri, 20 Sep 2024 08:59:20 +0900    

The implementation assumes that on multiple calls of these meta-commands  
the last one wins.  Multiple \g calls in-between mean multiple  
executions.  
  
There were no tests to check these properties, hence let's add  
something.  
  
Author: Jelte Fennema-Nio, Michael Paquier  
Discussion: https://postgr.es/m/CAGECzQSTE7CoM=Gst56Xj8pOvjaPr09+7jjtWqTC40pGETyAuA@mail.gmail.com  

commit   : 658fc6c6af4fa209af6ddadc0182cdb69e2b70ae    
  
author   : Bruce Momjian <[email protected]>    
date     : Thu, 19 Sep 2024 18:05:22 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Thu, 19 Sep 2024 18:05:22 -0400    

Make paragraph empty instead of removing it.  
  
Discussion: https://postgr.es/m/[email protected]  
  
Backpatch-through: 12  

commit   : c6b1506f71324d0bacfab17c6688e8fc2a79b1dc    
  
author   : Bruce Momjian <[email protected]>    
date     : Thu, 19 Sep 2024 12:01:59 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Thu, 19 Sep 2024 12:01:59 -0400    

Backpatch-through: 12  

commit   : 25f8cf19ab3a0246ef252203410b84169124eaaf    
  
author   : Bruce Momjian <[email protected]>    
date     : Thu, 19 Sep 2024 09:47:22 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Thu, 19 Sep 2024 09:47:22 -0400    

FYI, during PDF builds, this link type generates a "Unresolved ID  
reference found" warning because it is suppressed from the PDF output.  
  
Backpatch-through: 12  

commit   : f0577816865dc9e6fab1537b2a112545535a5d51    
  
author   : Bruce Momjian <[email protected]>    
date     : Thu, 19 Sep 2024 08:45:33 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Thu, 19 Sep 2024 08:45:33 -0400    

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

commit   : 4c57facbb16ec5f7002f0b87427897f6f9fa49ae    
  
author   : Alexander Korotkov <[email protected]>    
date     : Thu, 19 Sep 2024 14:34:52 +0300    
  
committer: Alexander Korotkov <[email protected]>    
date     : Thu, 19 Sep 2024 14:34:52 +0300    

While it doesn't directly influence indentation right now, add it for  
uniformity.  

commit   : a094e8b9e43e350798ea0c95b8967b8caf64bcbd    
  
author   : Alexander Korotkov <[email protected]>    
date     : Thu, 19 Sep 2024 14:34:00 +0300    
  
committer: Alexander Korotkov <[email protected]>    
date     : Thu, 19 Sep 2024 14:34:00 +0300    

commit   : 014f9f34d2527c14cdf4150863c053d2a117c1c7    
  
author   : Alexander Korotkov <[email protected]>    
date     : Thu, 19 Sep 2024 14:26:03 +0300    
  
committer: Alexander Korotkov <[email protected]>    
date     : Thu, 19 Sep 2024 14:26:03 +0300    

This commit moves pg_wal_replay_wait() procedure to be a neighbor of  
WAL-related functions in xlogfuncs.c.  The implementation of LSN waiting  
continues to reside in the same place.  
  
By proposal from Michael Paquier.  
  
Reported-by: Peter Eisentraut  
Discussion: https://postgr.es/m/18c0fa64-0475-415e-a1bd-665d922c5201%40eisentraut.org  

commit   : 87eeadaea1439693f6108ff599d750842ca6f338    
  
author   : Michael Paquier <[email protected]>    
date     : Thu, 19 Sep 2024 15:39:01 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Thu, 19 Sep 2024 15:39:01 +0900    

This fixes a couple of issues with the psql meta-commands mentioned  
above when called repeatedly:  
- The statement name is reset for each call.  If a command errors out,  
its send_mode would still be set, causing an incorrect path to be taken  
when processing a query.  For \bind_named, this could trigger an  
assertion failure as a statement name is always expected for this  
meta-command.  This issue has been introduced by d55322b0da60.  
- The memory allocated for bind parameters can be leaked.  This is a bug  
enlarged by d55322b0da60 that exists since 5b66de3433e2, as it is also  
possible to leak memory with \bind in v16 and v17.  This requires a fix  
that will be done on the affected branches separately.  This issue is  
taken care of here for HEAD.  
  
This patch tightens the cleanup of the state used for the extended  
protocol meta-commands (bind parameters, send mode, statement name) by  
doing it before running each meta-command on top of doing it once a  
query has been processed, avoiding any leaks and the inconsistencies  
when mixing calls, by refactoring the cleanup in a single routine used  
in all the code paths where this step is required.  
  
Reported-by: Alexander Lakhin  
Author: Anthonin Bonnefoy  
Discussion: https://postgr.es/m/[email protected]  

commit   : d69a3f4d70b7cab328ba5d0944450d87f39c2eb4    
  
author   : Michael Paquier <[email protected]>    
date     : Thu, 19 Sep 2024 12:22:56 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Thu, 19 Sep 2024 12:22:56 +0900    

Partitioned tables and normal tables have been relying on ATT_TABLE in  
ATSimplePermissions() to produce error messages that depend on the  
relation's relkind, because both relkinds currently support the same set  
of ALTER TABLE subcommands.  
  
A patch to restrict SET LOGGED/UNLOGGED for partitioned tables is under  
discussion, and introducing ATT_PARTITIONED_TABLE makes subcommand  
restrictions for partitioned tables easier to deal with, so let's add  
one.  There is no functional change.  
  
Author: Michael Paquier  
Reviewed-by: Nathan Bossart  
Discussion: https://postgr.es/m/[email protected]  

commit   : 5d56d07ca343a467ce74a042c22c963ea2690eaf    
  
author   : David Rowley <[email protected]>    
date     : Thu, 19 Sep 2024 15:20:35 +1200    
  
committer: David Rowley <[email protected]>    
date     : Thu, 19 Sep 2024 15:20:35 +1200    

nodeRecursiveunion.c makes use of two tuplestores and, until now, would  
delete and recreate one of these tuplestores after every recursive  
iteration.  
  
Here we adjust that behavior and instead reuse one of the existing  
tuplestores and just empty it of all tuples using tuplestore_clear().  
  
This saves some free/malloc roundtrips and has shown a 25-30% performance  
improvement for queries that perform very little work between recursive  
iterations.  
  
This also paves the way to add some EXPLAIN ANALYZE telemetry output for  
recursive common table expressions, similar to what was done in 1eff8279d  
and 95d6e9af0.  Previously calling tuplestore_end() would have caused  
the maximum storage space used to be lost.  
  
Reviewed-by: Tatsuo Ishii  
Discussion: https://postgr.es/m/CAApHDvr9yW0YRiK8A2J7nvyT8g17YzbSfOviEWrghazKZbHbig@mail.gmail.com  

commit   : 8a6e85b46e0ff1a49b1b2303149ec010e5e0b30e    
  
author   : Bruce Momjian <[email protected]>    
date     : Wed, 18 Sep 2024 17:13:19 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Wed, 18 Sep 2024 17:13:19 -0400    

And suppress the symbol in print mode, where the section symbol does not  
appear.  
  
Discussion: https://postgr.es/m/[email protected]  
  
Backpatch-through: 12  

commit   : f986882ffd67a4a2560b5cbd9056fc70d0c69209    
  
author   : Bruce Momjian <[email protected]>    
date     : Wed, 18 Sep 2024 16:34:52 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Wed, 18 Sep 2024 16:34:52 -0400    

In print output, there are too many commit links for footnotes in the  
release notes to be useful.  
  
Reported-by: Tom Lane  
  
Discussion: https://postgr.es/m/[email protected]  
  
Backpatch-through: 12  

commit   : b52c4fc3c09ec0ec9c1f9aa676f6d74304cc2f6f    
  
author   : Nathan Bossart <[email protected]>    
date     : Wed, 18 Sep 2024 14:42:57 -0500    
  
committer: Nathan Bossart <[email protected]>    
date     : Wed, 18 Sep 2024 14:42:57 -0500    

This change allows pg_index rows to use out-of-line storage for the  
"indexprs" and "indpred" columns, which enables use-cases such as  
very large index expressions.  
  
This system catalog was previously not given a TOAST table due to a  
fear of circularity issues (see commit 96cdeae07f).  Testing has  
not revealed any such problems, and it seems unlikely that the  
entries for system indexes could ever need out-of-line storage.  In  
any case, it is still early in the v18 development cycle, so  
committing this now will hopefully increase the chances of finding  
any unexpected problems prior to release.  
  
Bumps catversion.  
  
Reported-by: Jonathan Katz  
Reviewed-by: Tom Lane  
Discussion: https://postgr.es/m/b611015f-b423-458c-aa2d-be0e655cc1b4%40postgresql.org  

commit   : a7c39db5eb342dd491dacf39546486c6a539ea43    
  
author   : Fujii Masao <[email protected]>    
date     : Thu, 19 Sep 2024 02:14:10 +0900    
  
committer: Fujii Masao <[email protected]>    
date     : Thu, 19 Sep 2024 02:14:10 +0900    

The previous documentation stated that num_timed reflects the number of  
scheduled checkpoints performed. However, checkpoints may be skipped  
if the server has been idle, and num_timed counts both skipped and completed  
checkpoints. This commit clarifies the description to make it clear that  
the counter includes both skipped and completed checkpoints.  
  
Back-patch to v17 where pg_stat_checkpointer was added.  
  
Author: Fujii Masao  
Reviewed-by: Alexander Korotkov  
Discussion: https://postgr.es/m/[email protected]  

commit   : 24f5205948093a96edf8213294b3d585ac3fe1fb    
  
author   : Michael Paquier <[email protected]>    
date     : Wed, 18 Sep 2024 14:43:37 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Wed, 18 Sep 2024 14:43:37 +0900    

This commit adds three sanity checks in code paths of the executor where  
it is possible to use hooks, checking that a query ID is reported in  
pg_stat_activity if compute_query_id is enabled:  
- ExecutorRun()  
- ExecutorFinish()  
- ExecutorEnd()  
  
This causes the test in pg_stat_statements added in 933848d16dc9 to  
complain immediately in ExecutorRun().  The idea behind this commit is  
to help extensions to detect if they are missing query ID reports when a  
query goes through the executor.  Perhaps this will prove to be a bad  
idea, but let's see where this experience goes in v18 and newer  
versions.  
  
Reviewed-by: Sami Imseih  
Discussion: https://postgr.es/m/[email protected]  

commit   : 4f08ab55457751308ffd8d33e82155758cd0e304    
  
author   : Fujii Masao <[email protected]>    
date     : Wed, 18 Sep 2024 12:51:48 +0900    
  
committer: Fujii Masao <[email protected]>    
date     : Wed, 18 Sep 2024 12:51:48 +0900    

This commit adds a "user_name" output column to  
the postgres_fdw_get_connections function, returning the name  
of the local user mapped to the foreign server for each connection.  
If a public mapping is used, it returns "public."  
  
This helps identify postgres_fdw connections more easily,  
such as determining which connections are invalid, closed,  
or used within the current transaction.  
  
No extension version bump is needed, as commit c297a47c5f  
already handled it for v18~.  
  
Author: Hayato Kuroda  
Reviewed-by: Fujii Masao  
Discussion: https://postgr.es/m/[email protected]  

commit   : b14e9ce7d55c75ffa160b07765eb9dffde70b5fa    
  
author   : Michael Paquier <[email protected]>    
date     : Wed, 18 Sep 2024 12:44:15 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Wed, 18 Sep 2024 12:44:15 +0900    

This opens the possibility to define keys for more types of statistics  
kinds in PgStat_HashKey, the first case being 8-byte query IDs for  
statistics like pg_stat_statements.  
  
This increases the size of PgStat_HashKey from 12 to 16 bytes, while  
PgStatShared_HashEntry, entry stored in the dshash for pgstats, keeps  
the same size due to alignment.  
  
xl_xact_stats_item, that tracks the stats items to drop in commit WAL  
records, is increased from 12 to 16 bytes.  Note that individual chunks  
in commit WAL records should be multiples of sizeof(int), hence 8-byte  
object IDs are stored as two uint32, based on a suggestion from Heikki  
Linnakangas.  
  
While on it, the field of PgStat_HashKey is renamed from "objoid" to  
"objid", as for some stats kinds this field does not refer to OIDs but  
just IDs, like for replication slot stats.  
  
This commit bumps the following format variables:  
- PGSTAT_FILE_FORMAT_ID, as PgStat_HashKey is written to the stats file  
for non-serialized stats kinds in the dshash table.  
- XLOG_PAGE_MAGIC for the changes in xl_xact_stats_item.  
- Catalog version, for the SQL function pg_stat_have_stats().  
  
Reviewed-by: Bertrand Drouvot  
Discussion: https://postgr.es/m/[email protected]  

commit   : ac04aa84a7f06635748278e6ff4bd74751bb3e8e    
  
author   : Noah Misch <[email protected]>    
date     : Tue, 17 Sep 2024 19:53:11 -0700    
  
committer: Noah Misch <[email protected]>    
date     : Tue, 17 Sep 2024 19:53:11 -0700    

Doing so caused the leader to hang in wait_event=ParallelFinish, which  
required an immediate shutdown to resolve.  Back-patch to v12 (all  
supported versions).  
  
Francesco Degrassi  
  
Discussion: https://postgr.es/m/CAC-SaSzHUKT=vZJ8MPxYdC_URPfax+yoA1hKTcF4ROz_Q6z0_Q@mail.gmail.com  

commit   : 933848d16dc9d9d838c1bc15ed7e48c2f2eed69c    
  
author   : Michael Paquier <[email protected]>    
date     : Wed, 18 Sep 2024 09:59:09 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Wed, 18 Sep 2024 09:59:09 +0900    

This commit adds query ID reports for two code paths when processing  
extended query protocol messages:  
- When receiving a bind message, setting it to the first Query retrieved  
from a cached cache.  
- When receiving an execute message, setting it to the first PlannedStmt  
stored in a portal.  
  
An advantage of this method is that this is able to cover all the types  
of portals handled in the extended query protocol, particularly these  
two when the report done in ExecutorStart() is not enough (neither is an  
addition in ExecutorRun(), actually, for the second point):  
- Multiple execute messages, with multiple ExecutorRun().  
- Portal with execute/fetch messages, like a query with a RETURNING  
clause and a fetch size that stores the tuples in a first execute  
message going though ExecutorStart() and ExecuteRun(), followed by one  
or more execute messages doing only fetches from the tuplestore created  
in the first message.  This corresponds to the case where  
execute_is_fetch is set, for example.  
  
Note that the query ID reporting done in ExecutorStart() is still  
necessary, as an EXECUTE requires it.  Query ID reporting is optimistic  
and more calls to pgstat_report_query_id() don't matter as the first  
report takes priority except if the report is forced.  The comment in  
ExecutorStart() is adjusted to reflect better the reality with the  
extended query protocol.  
  
The test added in pg_stat_statements is a courtesy of Robert Haas.  This  
uses psql's \bind metacommand, hence this part is backpatched down to  
v16.  
  
Reported-by:  Kaido Vaikla, Erik Wienhold  
Author: Sami Imseih  
Reviewed-by: Jian He, Andrei Lepikhov, Michael Paquier  
Discussion: https://postgr.es/m/CA+427g8DiW3aZ6pOpVgkPbqK97ouBdf18VLiHFesea2jUk3XoQ@mail.gmail.com  
Discussion: https://postgr.es/m/CA+TgmoZxtnf_jZ=VqBSyaU8hfUkkwoJCJ6ufy4LGpXaunKrjrg@mail.gmail.com  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 14  

commit   : 70d38e3d8a2d2cb88e3add2b90a122dacc941aa4    
  
author   : Thomas Munro <[email protected]>    
date     : Wed, 18 Sep 2024 09:20:59 +1200    
  
committer: Thomas Munro <[email protected]>    
date     : Wed, 18 Sep 2024 09:20:59 +1200    

Commits 041b9680 and 6377e12a changed the interface of  
scan_analyze_next_block() to take a ReadStream instead of a BlockNumber  
and a BufferAccessStrategy, and to return a value to indicate when the  
stream has run out of blocks.  
  
This caused integration problems for at least one known extension that  
uses specially encoded BlockNumber values that map to different  
underlying storage, because acquire_sample_rows() sets up the stream so  
that read_stream_next_buffer() reads blocks from the main fork of the  
relation's SMgrRelation.  
  
Provide read_stream_next_block(), as a way for such an extension to  
access the stream of raw BlockNumbers directly and forward them to its  
own ReadBuffer() calls after decoding, as it could in earlier releases.  
The new function returns the BlockNumber and BufferAccessStrategy that  
were previously passed directly to scan_analyze_next_block().  
Alternatively, an extension could wrap the stream of BlockNumbers in  
another ReadStream with a callback that performs any decoding required  
to arrive at real storage manager BlockNumber values, so that it could  
benefit from the I/O combining and concurrency provided by  
read_stream.c.  
  
Another class of table access method that does nothing in  
scan_analyze_next_block() because it is not block-oriented could use  
this function to control the number of block sampling loops.  It could  
match the previous behavior with "return read_stream_next_block(stream,  
&bas) != InvalidBlockNumber".  
  
Ongoing work is expected to provide better ANALYZE support for table  
access methods that don't behave like heapam with respect to storage  
blocks, but that will be for future releases.  
  
Back-patch to 17.  
  
Reported-by: Mats Kindahl <[email protected]>  
Reviewed-by: Mats Kindahl <[email protected]>  
Discussion: https://postgr.es/m/CA%2B14425%2BCcm07ocG97Fp%2BFrD9xUXqmBKFvecp0p%2BgV2YYR258Q%40mail.gmail.com  

commit   : 918e21d25178c8ae09808c581a782002f702ed9e    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 17 Sep 2024 15:53:26 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 17 Sep 2024 15:53:26 -0400    

Since we introduced unlogged sequences in v15, identity sequences  
have defaulted to having the same persistence as their owning table.  
However, it is possible to change that with ALTER SEQUENCE, and  
pg_dump tries to preserve the logged-ness of sequences when it doesn't  
match (as indeed it wouldn't for an unlogged table from before v15).  
  
The fly in the ointment is that ALTER SEQUENCE SET [UN]LOGGED fails  
in binary-upgrade mode, because it needs to assign a new relfilenode  
which we cannot permit in that mode.  Thus, trying to pg_upgrade a  
database containing a mismatching identity sequence failed.  
  
To fix, add syntax to ADD/ALTER COLUMN GENERATED AS IDENTITY to allow  
the sequence's persistence to be set correctly at creation, and use  
that instead of ALTER SEQUENCE SET [UN]LOGGED in pg_dump.  (I tried to  
make SET [UN]LOGGED work without any pg_dump modifications, but that  
seems too fragile to be a desirable answer.  This way should be  
markedly faster anyhow.)  
  
In passing, document the previously-undocumented SEQUENCE NAME option  
that pg_dump also relies on for identity sequences; I see no value  
in trying to pretend it doesn't exist.  
  
Per bug #18618 from Anthony Hsu.  
Back-patch to v15 where we invented this stuff.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 2520226c953c0b443791a185a8d1fb8b71d9fe9e    
  
author   : Alexander Korotkov <[email protected]>    
date     : Tue, 17 Sep 2024 22:51:06 +0300    
  
committer: Alexander Korotkov <[email protected]>    
date     : Tue, 17 Sep 2024 22:51:06 +0300    

This commit ensures standby will be promoted at least at the primary insert  
LSN we have just observed.  We use pg_switch_wal() to force the insert LSN  
to be written then wait for standby to catchup.  
  
Reported-by: Alexander Lakhin  
Discussion: https://postgr.es/m/1d7b08f2-64a2-77fb-c666-c9a74c68eeda%40gmail.com  

commit   : 85b98b8d5a48092acd03db76a8bf02d9c38c1d79    
  
author   : Alexander Korotkov <[email protected]>    
date     : Tue, 17 Sep 2024 22:50:43 +0300    
  
committer: Alexander Korotkov <[email protected]>    
date     : Tue, 17 Sep 2024 22:50:43 +0300    

 * Rename $node_standby1 to $node_standby in 043_wal_replay_wait.pl as there  
   is only one standby.  
 * Remove useless debug printing in 043_wal_replay_wait.pl.  
 * Fix typo in one check description in 043_wal_replay_wait.pl.  
 * Fix some wording in comments and documentation.  
  
Reported-by: Alexander Lakhin  
Discussion: https://postgr.es/m/1d7b08f2-64a2-77fb-c666-c9a74c68eeda%40gmail.com  
Reviewed-by: Alexander Lakhin  

commit   : d8adfc18bebfb1b69b456a00e67453775a77f594    
  
author   : Peter Geoghegan <[email protected]>    
date     : Tue, 17 Sep 2024 11:10:35 -0400    
  
committer: Peter Geoghegan <[email protected]>    
date     : Tue, 17 Sep 2024 11:10:35 -0400    

Commit 5bf748b8, which enhanced nbtree ScalarArrayOp execution, made  
parallel index scans work with the new design for arrays via explicit  
scheduling of primitive index scans.  A backend that successfully  
scheduled the scan's next primitive index scan saved its backend local  
array keys in shared memory.  Any backend could pick up the scheduled  
primitive scan within _bt_first.  This scheme decouples scheduling a  
primitive scan from starting the scan (by performing another descent of  
the index via a _bt_search call from _bt_first) to make things robust.  
  
The scheme had a deadlock hazard, at least when the leader process  
participated in the scan.  _bt_parallel_seize had a code path that made  
backends that were not in an immediate position to start a scheduled  
primitive index scan wait for some other backend to do so instead.  
Under the right circumstances, the leader process could wait here  
forever: the leader would wait for any other backend to start the  
primitive scan, while every worker was busy waiting on the leader to  
consume tuples from the scan's tuple queue.  
  
To fix, don't wait for a scheduled primitive index scan to be started by  
some other eligible backend from within _bt_parallel_seize (when the  
calling backend isn't in a position to do so itself).  Return false  
instead, while recording that the scan has a scheduled primitive index  
scan in backend local state.  This leaves the backend in the same state  
as the existing case where a backend schedules (or tries to schedule)  
another primitive index scan from within _bt_advance_array_keys, before  
calling _bt_parallel_seize.  _bt_parallel_seize already handles that  
case by returning false without waiting, and without unsetting the  
backend local state.  Leaving the backend in this state enables it to  
start a previously scheduled primitive index scan once it gets back to  
_bt_first.  
  
Oversight in commit 5bf748b8, which enhanced nbtree ScalarArrayOp  
execution.  
  
Matthias van de Meent, with tweaks by me.  
  
Author: Matthias van de Meent <[email protected]>  
Reported-By: Tomas Vondra <[email protected]>  
Reviewed-By: Peter Geoghegan <[email protected]>  
Discussion: https://postgr.es/m/CAH2-WzmMGaPa32u9x_FvEbPTUkP5e95i=QxR8054nvCRydP-sw@mail.gmail.com  
Backpatch: 17-, where nbtree SAOP execution was enhanced.  

commit   : 89f908a6d0ac1337c868625008c9598487d184e7    
  
author   : Peter Eisentraut <[email protected]>    
date     : Tue, 17 Sep 2024 10:41:07 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Tue, 17 Sep 2024 10:41:07 +0200    

Add PERIOD clause to foreign key constraint definitions.  This is  
supported for range and multirange types.  Temporal foreign keys check  
for range containment instead of equality.  
  
This feature matches the behavior of the SQL standard temporal foreign  
keys, but it works on PostgreSQL's native ranges instead of SQL's  
"periods", which don't exist in PostgreSQL (yet).  
  
Reference actions ON {UPDATE,DELETE} {CASCADE,SET NULL,SET DEFAULT}  
are not supported yet.  
  
(previously committed as 34768ee3616, reverted by 8aee330af55; this is  
essentially unchanged from those)  
  
Author: Paul A. Jungwirth <[email protected]>  
Reviewed-by: Peter Eisentraut <[email protected]>  
Reviewed-by: jian he <[email protected]>  
Discussion: https://www.postgresql.org/message-id/flat/CA+renyUApHgSZF9-nd-a0+OPGharLQLO=mDHcY4_qQ0+noCUVg@mail.gmail.com  

commit   : fc0438b4e80535419a4e54dba87642cdf84defda    
  
author   : Peter Eisentraut <[email protected]>    
date     : Tue, 17 Sep 2024 10:36:09 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Tue, 17 Sep 2024 10:36:09 +0200    

Add WITHOUT OVERLAPS clause to PRIMARY KEY and UNIQUE constraints.  
These are backed by GiST indexes instead of B-tree indexes, since they  
are essentially exclusion constraints with = for the scalar parts of  
the key and && for the temporal part.  
  
(previously committed as 46a0cd4cefb, reverted by 46a0cd4cefb; the new  
part is this:)  
  
Because 'empty' && 'empty' is false, the temporal PK/UQ constraint  
allowed duplicates, which is confusing to users and breaks internal  
expectations.  For instance, when GROUP BY checks functional  
dependencies on the PK, it allows selecting other columns from the  
table, but in the presence of duplicate keys you could get the value  
from any of their rows.  So we need to forbid empties.  
  
This all means that at the moment we can only support ranges and  
multiranges for temporal PK/UQs, unlike the original patch (above).  
Documentation and tests for this are added.  But this could  
conceivably be extended by introducing some more general support for  
the notion of "empty" for other types.  
  
Author: Paul A. Jungwirth <[email protected]>  
Reviewed-by: Peter Eisentraut <[email protected]>  
Reviewed-by: jian he <[email protected]>  
Discussion: https://www.postgresql.org/message-id/flat/CA+renyUApHgSZF9-nd-a0+OPGharLQLO=mDHcY4_qQ0+noCUVg@mail.gmail.com  

commit   : 7406ab623fee1addcb21c881afecbe638a0d56e9    
  
author   : Peter Eisentraut <[email protected]>    
date     : Tue, 17 Sep 2024 10:19:26 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Tue, 17 Sep 2024 10:19:26 +0200    

This is support function 12 for the GiST AM and translates  
"well-known" RT*StrategyNumber values into whatever strategy number is  
used by the opclass (since no particular numbers are actually  
required).  We will use this to support temporal PRIMARY  
KEY/UNIQUE/FOREIGN KEY/FOR PORTION OF functionality.  
  
This commit adds two implementations, one for internal GiST opclasses  
(just an identity function) and another for btree_gist opclasses.  It  
updates btree_gist from 1.7 to 1.8, adding the support function for  
all its opclasses.  
  
(previously committed as 6db4598fcb8, reverted by 8aee330af55; this is  
essentially unchanged from those)  
  
Author: Paul A. Jungwirth <[email protected]>  
Reviewed-by: Peter Eisentraut <[email protected]>  
Reviewed-by: jian he <[email protected]>  
Discussion: https://www.postgresql.org/message-id/flat/CA+renyUApHgSZF9-nd-a0+OPGharLQLO=mDHcY4_qQ0+noCUVg@mail.gmail.com  

commit   : 95d6e9af07d2e5af2fdd272e72b5b552bad3ea0a    
  
author   : Tatsuo Ishii <[email protected]>    
date     : Tue, 17 Sep 2024 14:38:53 +0900    
  
committer: Tatsuo Ishii <[email protected]>    
date     : Tue, 17 Sep 2024 14:38:53 +0900    

This commit is similar to 1eff8279d and expands the idea to Window  
aggregate nodes so that users can know how much memory or disk the  
tuplestore used.  
  
This commit uses newly introduced tuplestore_get_stats() to inquire this  
information and add some additional output in EXPLAIN ANALYZE to  
display the information for the Window aggregate node.  
  
Reviewed-by: David Rowley, Ashutosh Bapat, Maxim Orlov, Jian He  
Discussion: https://postgr.es/m/20240706.202254.89740021795421286.ishii%40postgresql.org  

commit   : 1bbf1e2f1a077905037272cd4767e952f34c02b3    
  
author   : Nathan Bossart <[email protected]>    
date     : Mon, 16 Sep 2024 16:33:50 -0500    
  
committer: Nathan Bossart <[email protected]>    
date     : Mon, 16 Sep 2024 16:33:50 -0500    

Per buildfarm members sifaka and longfin, clang with  
-Wtypedef-redefinition warns of a duplicate typedef unless building  
with C11.  
  
Oversight in commit 40e2e5e92b.  

commit   : c880cf258864cdb355ce28438ec31a2405c20941    
  
author   : Nathan Bossart <[email protected]>    
date     : Mon, 16 Sep 2024 16:10:33 -0500    
  
committer: Nathan Bossart <[email protected]>    
date     : Mon, 16 Sep 2024 16:10:33 -0500    

This commit makes use of the new task framework in pg_upgrade to  
parallelize the check for incompatible user-defined encoding  
conversions, i.e., those defined on servers older than v14.  This  
step will now process multiple databases concurrently when  
pg_upgrade's --jobs option is provided a value greater than 1.  
  
Reviewed-by: Daniel Gustafsson, Ilya Gladyshev  
Discussion: https://postgr.es/m/20240516211638.GA1688936%40nathanxps13  

commit   : f93f5f7b984edd85f3f515cd454a6160e574b2d0    
  
author   : Nathan Bossart <[email protected]>    
date     : Mon, 16 Sep 2024 16:10:33 -0500    
  
committer: Nathan Bossart <[email protected]>    
date     : Mon, 16 Sep 2024 16:10:33 -0500    

This commit makes use of the new task framework in pg_upgrade to  
parallelize the check for tables declared WITH OIDS.  This step  
will now process multiple databases concurrently when pg_upgrade's  
--jobs option is provided a value greater than 1.  
  
Reviewed-by: Daniel Gustafsson, Ilya Gladyshev  
Discussion: https://postgr.es/m/20240516211638.GA1688936%40nathanxps13  

commit   : cf2f82a37cc35895b67c83dd2b33d2fcf4688a55    
  
author   : Nathan Bossart <[email protected]>    
date     : Mon, 16 Sep 2024 16:10:33 -0500    
  
committer: Nathan Bossart <[email protected]>    
date     : Mon, 16 Sep 2024 16:10:33 -0500    

This commit makes use of the new task framework in pg_upgrade to  
parallelize the check for usage of incompatible polymorphic  
functions, i.e., those with arguments of type anyarray/anyelement  
rather than the newer anycompatible variants.  This step will now  
process multiple databases concurrently when pg_upgrade's --jobs  
option is provided a value greater than 1.  
  
Reviewed-by: Daniel Gustafsson, Ilya Gladyshev  
Discussion: https://postgr.es/m/20240516211638.GA1688936%40nathanxps13  

commit   : c34eabfbbfd3d3799bc7bc61f22b1fe730c53fe8    
  
author   : Nathan Bossart <[email protected]>    
date     : Mon, 16 Sep 2024 16:10:33 -0500    
  
committer: Nathan Bossart <[email protected]>    
date     : Mon, 16 Sep 2024 16:10:33 -0500    

This commit makes use of the new task framework in pg_upgrade to  
parallelize the check for user-defined postfix operators.  This  
step will now process multiple databases concurrently when  
pg_upgrade's --jobs option is provided a value greater than 1.  
  
Reviewed-by: Daniel Gustafsson, Ilya Gladyshev  
Discussion: https://postgr.es/m/20240516211638.GA1688936%40nathanxps13  

commit   : 9db3018cf83b4be1dbcdca8274e97ea8645df49c    
  
author   : Nathan Bossart <[email protected]>    
date     : Mon, 16 Sep 2024 16:10:33 -0500    
  
committer: Nathan Bossart <[email protected]>    
date     : Mon, 16 Sep 2024 16:10:33 -0500    

This commit makes use of the new task framework in pg_upgrade to  
parallelize the check for contrib/isn functions that rely on the  
bigint data type.  This step will now process multiple databases  
concurrently when pg_upgrade's --jobs option is provided a value  
greater than 1.  
  
Reviewed-by: Daniel Gustafsson, Ilya Gladyshev  
Discussion: https://postgr.es/m/20240516211638.GA1688936%40nathanxps13  

commit   : bbf83cab98f2c018d6d394decaa9b03212f96983    
  
author   : Nathan Bossart <[email protected]>    
date     : Mon, 16 Sep 2024 16:10:33 -0500    
  
committer: Nathan Bossart <[email protected]>    
date     : Mon, 16 Sep 2024 16:10:33 -0500    

This commit makes use of the new task framework in pg_upgrade to  
parallelize the checks for incompatible data types, i.e., data  
types whose on-disk format has changed, data types that have been  
removed, etc.  This step will now process multiple databases  
concurrently when pg_upgrade's --jobs option is provided a value  
greater than 1.  
  
Reviewed-by: Daniel Gustafsson, Ilya Gladyshev  
Discussion: https://postgr.es/m/20240516211638.GA1688936%40nathanxps13  

commit   : 6ab8f27bc7163ab534543e32504e47ed924b6737    
  
author   : Nathan Bossart <[email protected]>    
date     : Mon, 16 Sep 2024 16:10:33 -0500    
  
committer: Nathan Bossart <[email protected]>    
date     : Mon, 16 Sep 2024 16:10:33 -0500    

This commit makes use of the new task framework in pg_upgrade to  
parallelize retrieving the set of extensions that should be updated  
with the ALTER EXTENSION command after upgrade.  This step will now  
process multiple databases concurrently when pg_upgrade's --jobs  
option is provided a value greater than 1.  
  
Reviewed-by: Daniel Gustafsson, Ilya Gladyshev  
Discussion: https://postgr.es/m/20240516211638.GA1688936%40nathanxps13  

commit   : 46cad8b31927410a99894279ca9af4e0d5c185b6    
  
author   : Nathan Bossart <[email protected]>    
date     : Mon, 16 Sep 2024 16:10:33 -0500    
  
committer: Nathan Bossart <[email protected]>    
date     : Mon, 16 Sep 2024 16:10:33 -0500    

This commit makes use of the new task framework in pg_upgrade to  
parallelize retrieving the names of all libraries referenced by  
non-built-in C functions.  This step will now process multiple  
databases concurrently when pg_upgrade's --jobs option is provided  
a value greater than 1.  
  
Reviewed-by: Daniel Gustafsson, Ilya Gladyshev  
Discussion: https://postgr.es/m/20240516211638.GA1688936%40nathanxps13  

commit   : 7baa36de58bdaeb4797d592aeb9ef1db08320853    
  
author   : Nathan Bossart <[email protected]>    
date     : Mon, 16 Sep 2024 16:10:33 -0500    
  
committer: Nathan Bossart <[email protected]>    
date     : Mon, 16 Sep 2024 16:10:33 -0500    

This commit makes use of the new task framework in pg_upgrade to  
parallelize the part of check_old_cluster_subscription_state() that  
verifies each of the subscribed tables is in the 'i' (initialize)  
or 'r' (ready) state.  This check will now process multiple  
databases concurrently when pg_upgrade's --jobs option is provided  
a value greater than 1.  
  
Reviewed-by: Daniel Gustafsson, Ilya Gladyshev  
Discussion: https://postgr.es/m/20240516211638.GA1688936%40nathanxps13  

commit   : 6d3d2e8e541f07dafb6a42a105b3ca78b2a09437    
  
author   : Nathan Bossart <[email protected]>    
date     : Mon, 16 Sep 2024 16:10:33 -0500    
  
committer: Nathan Bossart <[email protected]>    
date     : Mon, 16 Sep 2024 16:10:33 -0500    

This commit makes use of the new task framework in pg_upgrade to  
parallelize retrieving relation and logical slot information.  This  
step will now process multiple databases concurrently when  
pg_upgrade's --jobs option is provided a value greater than 1.  
  
Reviewed-by: Daniel Gustafsson, Ilya Gladyshev  
Discussion: https://postgr.es/m/20240516211638.GA1688936%40nathanxps13  

commit   : 40e2e5e92b7da358fb45802b53c735d25a51d23a    
  
author   : Nathan Bossart <[email protected]>    
date     : Mon, 16 Sep 2024 16:10:33 -0500    
  
committer: Nathan Bossart <[email protected]>    
date     : Mon, 16 Sep 2024 16:10:33 -0500    

A number of pg_upgrade steps require connecting to every database  
in the cluster and running the same query in each one.  When there  
are many databases, these steps are particularly time-consuming,  
especially since they are performed sequentially, i.e., we connect  
to a database, run the query, and process the results before moving  
on to the next database.  
  
This commit introduces a new framework that makes it easy to  
parallelize most of these once-in-each-database tasks by processing  
multiple databases concurrently.  This framework manages a set of  
slots that follow a simple state machine, and it uses libpq's  
asynchronous APIs to establish the connections and run the queries.  
The --jobs option is used to determine the number of slots to use.  
To use this new task framework, callers simply need to provide the  
query and a callback function to process its results, and the  
framework takes care of the rest.  A more complete description is  
provided at the top of the new task.c file.  
  
None of the eligible once-in-each-database tasks are converted to  
use this new framework in this commit.  That will be done via  
several follow-up commits.  
  
Reviewed-by: Jeff Davis, Robert Haas, Daniel Gustafsson, Ilya Gladyshev, Corey Huinker  
Discussion: https://postgr.es/m/20240516211638.GA1688936%40nathanxps13  

commit   : d891c49286bb138dcd70df1dff83e22fa757fc84    
  
author   : Bruce Momjian <[email protected]>    
date     : Mon, 16 Sep 2024 14:23:39 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Mon, 16 Sep 2024 14:23:39 -0400    

Backpatch-through: 12  

commit   : 257210455257aaac30001914886d422cbf34c215    
  
author   : Bruce Momjian <[email protected]>    
date     : Mon, 16 Sep 2024 13:26:37 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Mon, 16 Sep 2024 13:26:37 -0400    

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

commit   : 4632e5cf4bc5c496f41dfc6a89533e7afa7262dd    
  
author   : Bruce Momjian <[email protected]>    
date     : Sun, 15 Sep 2024 21:25:00 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Sun, 15 Sep 2024 21:25:00 -0400    

Small improvement not worth the code churn.  
  
Reported-by: Andrew Dunstan  
  
Discussion: https://postgr.es/m/[email protected]  
  
Backpatch-through: master  

commit   : d5622acb32b3c11a27b323138fbee9c715742b38    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 15 Sep 2024 13:33:09 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 15 Sep 2024 13:33:09 -0400    

In existing releases of libxml2, xmlXPathCompile can be driven  
to stack overflow because it fails to protect itself against  
too-deeply-nested input.  While there is an upstream fix as of  
yesterday, it will take years for that to propagate into all  
shipping versions.  In the meantime, we can protect our own  
usages basically for free by calling xmlXPathCtxtCompile instead.  
  
(The actual bug is that libxml2 keeps its nesting counter in the  
xmlXPathContext, and its parsing code was willing to just skip  
counting nesting levels if it didn't have a context.  So if we supply  
a context, all is well.  It seems odd actually that it works at all  
to not supply a context, because this means that XPath parsing does  
not have access to XML namespace info.  Apparently libxml2 never  
checks namespaces until runtime?  Anyway, this seems like good  
future-proofing even if its only immediate effect is to dodge a bug.)  
  
Sadly, this hack only offers protection with libxml2 2.9.11 and newer.  
Before that there are multiple similar problems, so if you are  
processing untrusted XML it behooves you to get a newer version.  
But we have some pretty old libxml2 in the buildfarm, so it seems  
impractical to add a regression test to verify this fix.  
  
Per bug #18617 from Jingzhou Fu.  Back-patch to all supported  
versions.  
  
Discussion: https://postgr.es/m/[email protected]  
Discussion: https://gitlab.gnome.org/GNOME/libxml2/-/issues/799  

commit   : 43ce181059d4ecbb1b14b75e7f38a7dda9f80225    
  
author   : Bruce Momjian <[email protected]>    
date     : Sun, 15 Sep 2024 10:55:37 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Sun, 15 Sep 2024 10:55:37 -0400    

Eliminate warnings of Perl Critic from src/tools.  
  
Backpatch-through: master  

commit   : b8ea0f675f35c3f0c2cf62175517ba0dacad4abd    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 14 Sep 2024 17:55:02 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 14 Sep 2024 17:55:02 -0400    

Historically we've used timezone "PST8PDT", but the recent release  
2024b of tzdb changes the definition of that zone in a way that  
breaks many test cases concerned with dates before 1970.  Although  
we've not yet adopted 2024b into our own tree, this is already  
problematic for people using --with-system-tzdata if their platform  
has already adopted 2024b.  To work with both older and newer  
versions of tzdb, switch to using "America/Los_Angeles", accepting  
the ensuing changes in regression test results.  
  
Back-patch to all supported branches.  
  
Per report and patch from Wolfgang Walther.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : f64074c88c067b4733ae439afae46ad61e45474b    
  
author   : Alvaro Herrera <[email protected]>    
date     : Sat, 14 Sep 2024 20:17:30 +0200    
  
committer: Alvaro Herrera <[email protected]>    
date     : Sat, 14 Sep 2024 20:17:30 +0200    

commit   : 94537982ec6b4c6b7957d084f0c50eba14924baf    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 14 Sep 2024 11:42:31 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 14 Sep 2024 11:42:31 -0400    

Commit 76db9cb63 removed the use of multiple nesting counters,  
but missed one comment describing that arrangement.  
  
Back-patch to v17 where 76db9cb63 came in, just to avoid confusion.  
  
Julien Rouhaud  
  
Discussion: https://postgr.es/m/gfcwh3zjxc2vygltapgo7g6yacdor5s4ynr234b6v2ohhuvt7m@gr42joxalenw  

commit   : 76f2a0e5479618d48161549a148a37251b4b3d4b    
  
author   : Andrew Dunstan <[email protected]>    
date     : Sat, 14 Sep 2024 10:26:25 -0400    
  
committer: Andrew Dunstan <[email protected]>    
date     : Sat, 14 Sep 2024 10:26:25 -0400    

The current method of detecting perl build flags breaks if the path to  
perl contains a space. This change makes two improvements. First,  
instead of getting a list of ldflags and ccdlflags and then trying to  
filter those out of the reported ldopts, we tell perl to suppress  
reporting those in the first instance. Second, it tells perl to parse  
those and output them, one per line. Thus any space on the option in a  
file name, for example, is preserved.  
  
Issue reported off-list by Muralikrishna Bandaru  
  
Discussion: https://postgr.es/[email protected]  
  
Backpatch to release 16.  

commit   : bc46104fc9aa5254f98250cf2756552f92095ae9    
  
author   : Andrew Dunstan <[email protected]>    
date     : Sat, 14 Sep 2024 08:37:08 -0400    
  
committer: Andrew Dunstan <[email protected]>    
date     : Sat, 14 Sep 2024 08:37:08 -0400    

Latest versions of Strawberry Perl define USE_THREAD_SAFE_LOCALE, and we  
therefore get a handshake error when building against such instances.  
The solution is to perform a test to see if USE_THREAD_SAFE_LOCALE is  
defined and only define NO_THREAD_SAFE_LOCALE if it isn't.  
  
Backpatch the meson.build fix back to release 16 and apply the same  
logic to Mkvcbuild.pm in releases 12 through 16.  
  
Original report of the issue from Muralikrishna Bandaru.  

commit   : fae55f0bb38504b3774fa50152d3c14d2f09aa15    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 13 Sep 2024 16:16:47 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 13 Sep 2024 16:16:47 -0400    

When we are building a hash index that is large enough to need  
pre-sorting (larger than either maintenance_work_mem or NBuffers),  
the initial sorting phase is interruptible, but the insertion  
phase wasn't.  Add the missing CHECK_FOR_INTERRUPTS().  
  
Per bug #18616 from Alexander Lakhin.  Back-patch to all  
supported branches.  
  
Pavel Borisov  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 9a23967063b1b36c620a753f72c7cdb56dc0a4c4    
  
author   : Nathan Bossart <[email protected]>    
date     : Fri, 13 Sep 2024 13:06:06 -0500    
  
committer: Nathan Bossart <[email protected]>    
date     : Fri, 13 Sep 2024 13:06:06 -0500    

commit   : 70d1c664f4376fd3499e3b0c6888cf39b65d722b    
  
author   : Nathan Bossart <[email protected]>    
date     : Fri, 13 Sep 2024 10:16:40 -0500    
  
committer: Nathan Bossart <[email protected]>    
date     : Fri, 13 Sep 2024 10:16:40 -0500    

I managed to break this test in two different ways in commit  
05036a3155.  
  
First, the output of the new call to tuple_data_split() on the test  
sequence is dependent on endianness.  This is fixed by setting a  
special start value for the test sequence that produces the same  
output regardless of the endianness of the machine.  
  
Second, on versions older than v15, the new test case fails under  
"force_parallel_mode = regress" with the following error:  
  
	ERROR:  cannot access temporary tables during a parallel operation  
  
This is because pageinspect's disk-accessing functions are  
incorrectly marked PARALLEL SAFE on versions older than v15 (see  
commit aeaaf520f4 for details).  This one is fixed by changing the  
test sequence to be permanent.  The only reason it was previously  
marked temporary was to avoid needing a DROP SEQUENCE command at  
the end of the test.  Unlike some other tests in this file, the use  
of a permanent sequence here shouldn't result in any test  
instability like what was fixed by commit e2933a6e11.  
  
Reviewed-by: Tom Lane  
Discussion: https://postgr.es/m/ZuOKOut5hhDlf_bP%40nathan  
Backpatch-through: 12