PostgreSQL 11.20 commit log

commit   : f96e531b1c079ae148b927a204845c7150a573f8    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 8 May 2023 17:21:16 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 8 May 2023 17:21:16 -0400    

commit   : 8dec3e375380dcdffea20d95ce3993c1bf79b045    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 8 May 2023 12:38:08 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 8 May 2023 12:38:08 -0400    

Security: CVE-2023-2454, CVE-2023-2455  

commit   : 766e061404c2159dccebad4d19e496d8ced8b2c4    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 8 May 2023 11:24:47 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 8 May 2023 11:24:47 -0400    

Security: CVE-2023-2454  

commit   : 473626cf00babd829eb15c36b51dfb358d32bc95    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 8 May 2023 10:12:45 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 8 May 2023 10:12:45 -0400    

If an SRF in the FROM clause references a table having row-level  
security policies, and we inline that SRF into the calling query,  
we neglected to mark the plan as potentially dependent on which  
role is executing it.  This could lead to later executions in the  
same session returning or hiding rows that should have been hidden  
or returned instead.  
  
Our thanks to Wolfgang Walther for reporting this problem.  
  
Stephen Frost and Tom Lane  
  
Security: CVE-2023-2455  

commit   : 23cb8eaeb97df350273cb8902e55842a955339c8    
  
author   : Noah Misch <[email protected]>    
date     : Mon, 8 May 2023 06:14:07 -0700    
  
committer: Noah Misch <[email protected]>    
date     : Mon, 8 May 2023 06:14:07 -0700    

The two methods don't cooperate, so set_config_option("search_path",  
...) has been ineffective under non-empty overrideStack.  This defect  
enabled an attacker having database-level CREATE privilege to execute  
arbitrary code as the bootstrap superuser.  While that particular attack  
requires v13+ for the trusted extension attribute, other attacks are  
feasible in all supported versions.  
  
Standardize on the combination of NewGUCNestLevel() and  
set_config_option("search_path", ...).  It is newer than  
PushOverrideSearchPath(), more-prevalent, and has no known  
disadvantages.  The "override" mechanism remains for now, for  
compatibility with out-of-tree code.  Users should update such code,  
which likely suffers from the same sort of vulnerability closed here.  
Back-patch to v11 (all supported versions).  
  
Alexander Lakhin.  Reported by Alexander Lakhin.  
  
Security: CVE-2023-2454  

commit   : 625acd098b98fb955473bf87c78f49afd20eb7c9    
  
author   : Peter Eisentraut <[email protected]>    
date     : Mon, 8 May 2023 14:44:53 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Mon, 8 May 2023 14:44:53 +0200    

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

commit   : 5cf42239e5ba220d24bb998c7599618162f43662    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 7 May 2023 12:36:12 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 7 May 2023 12:36:12 -0400    

commit   : b189f71e549fe0885c9fdff233d3d7b95cc77fd4    
  
author   : Peter Eisentraut <[email protected]>    
date     : Fri, 5 May 2023 06:29:49 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Fri, 5 May 2023 06:29:49 +0200    

Commit 153e215677 added the portlock directory.  This is created in  
$ENV{top_builddir} if it is set.  Under PGXS, top_builddir points into  
the installation directory, which is not necessarily writable and in  
any case inappropriate to use by a test suite.  The cause of the  
problem is that the prove_installcheck target in Makefile.global  
exports top_builddir, which isn't useful (since no other Perl code  
actually reads it) and breaks this use case.  The reason this code is  
there is probably that is has been dragged around with various other  
changes, in particular a0fc813266, but without a real purpose of its  
own.  By just removing the exporting of top_builddir in  
prove_installcheck, the portlock directory then ends up under  
tmp_check in the build directory, which is more suitable.  
  
Reviewed-by: Andrew Dunstan <[email protected]>  
Discussion: https://www.postgresql.org/message-id/[email protected]  

commit   : 0af386b0f4b81393aa7b1fe2118bd31ef06ef64c    
  
author   : Nathan Bossart <[email protected]>    
date     : Wed, 3 May 2023 11:32:43 -0700    
  
committer: Nathan Bossart <[email protected]>    
date     : Wed, 3 May 2023 11:32:43 -0700    

If we exit a PG_TRY block early via "continue", "break", "goto", or  
"return", we'll skip unwinding its exception stack.  This change  
moves a couple of such "return" statements in PL/Python out of  
PG_TRY blocks.  This was introduced in d0aa965c0a and affects all  
supported versions.  
  
We might also be able to add compile-time checks to prevent  
recurrence, but that is left as a future exercise.  
  
Reported-by: Mikhail Gribkov, Xing Guo  
Author: Xing Guo  
Reviewed-by: Michael Paquier, Andres Freund, Tom Lane  
Discussion: https://postgr.es/m/CAMEv5_v5Y%2B-D%3DCO1%2Bqoe16sAmgC4sbbQjz%2BUtcHmB6zcgS%2B5Ew%40mail.gmail.com  
Discussion: https://postgr.es/m/CACpMh%2BCMsGMRKFzFMm3bYTzQmMU5nfEEoEDU2apJcc4hid36AQ%40mail.gmail.com  
Backpatch-through: 11 (all supported versions)  

commit   : 4624aad61a313520d6542a210680088cec644dca    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 4 May 2023 11:48:23 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 4 May 2023 11:48:23 -0400    

These functions incautiously fetched the array's first lower bound  
even when the array is zero-dimensional, thus fetching the word  
after the allocated array space.  While almost always harmless,  
with very bad luck this could result in SIGSEGV.  Fix by adding  
an early exit for empty input.  
  
Per bug #17920 from Alexander Lakhin.  
  
Discussion: https://postgr.es/m/17920-f7c228c627b6d02e%40postgresql.org  

commit   : aa7e5e404324ebddb71bac891361f72fc0098cbb    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 4 May 2023 11:00:33 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 4 May 2023 11:00:33 -0400    

Like plperl before f47004add, plpython wasn't being sufficiently  
careful about checking that list-of-list structures represent  
rectangular arrays, so that it would accept some cases in which  
different parts of the "array" are nested to different depths.  
This was exacerbated by Python's weak distinction between  
sequences and lists, so that in some cases strings could get  
treated as though they are lists (and burst into individual  
characters) even though a different ordering of the upper-level  
list would give a different result.  
  
Some of this behavior was unreachable (without risking a crash)  
before 81eaaf65e.  It seems like a good idea to clean it all up  
in the same releases, rather than shipping a non-crashing but  
nonetheless visibly buggy behavior in the name of minimal change.  
Hence, back-patch.  
  
Per bug #17912 and further testing by Alexander Lakhin.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 0e0463fc590c6fe55083ed941e28655bbbb700b4    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 2 May 2023 17:55:01 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 2 May 2023 17:55:01 -0400    

plperl, plpython, and pltcl all provide query-execution functions  
that are thin wrappers around SPI_execute() or its variants.  
The SPI functions document their row-count limit arguments clearly,  
as "maximum number of rows to return, or 0 for no limit".  However  
the PLs' documentation failed to explain this special behavior of  
zero, so that a reader might well assume it means "fetch zero  
rows".  Improve that.  
  
Daniel Gustafsson and Tom Lane, per report from Kieran McCusker  
  
Discussion: https://postgr.es/m/CAGgUQ6H6qYScctOhktQ9HLFDDoafBKHyUgJbZ6q_dOApnzNTXg@mail.gmail.com  

commit   : ea96fbe772a7c441ba5b6c3aae024562157ddb9c    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 29 Apr 2023 13:06:44 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 29 Apr 2023 13:06:44 -0400    

plperl_array_to_datum() wasn't sufficiently careful about checking  
that nested lists represent a rectangular array structure; it would  
accept inputs such as "[1, []]".  This is a bit related to the  
PL/Python bug fixed in commit 81eaaf65e, but it doesn't seem to  
provide any direct route to a memory stomp.  Instead the likely  
failure mode is for makeMdArrayResult to be passed fewer Datums than  
the claimed array dimensionality requires, possibly leading to a wild  
pointer dereference and SIGSEGV.  
  
Per report from Alexander Lakhin.  It's been broken for a long  
time, so back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : b7c6af375da6fe75458233892fe57571348c2be0    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 28 Apr 2023 12:24:29 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 28 Apr 2023 12:24:29 -0400    

If PLySequence_ToArray came across a zero-length sublist, it'd compute  
the overall array size as zero, possibly leading to a memory clobber.  
(This would likely qualify as a security bug, were it not that plpython  
is an untrusted language already.)  
  
I think there are other corner-case issues in this code as well, notably  
that the error messages don't match the core code and for some ranges  
of array sizes you'd get "invalid memory alloc request size" rather than  
the intended message about array size.  
  
Really this code has no business doing its own array size calculation  
at all, so remove the faulty code in favor of using ArrayGetNItems().  
  
Per bug #17912 from Alexander Lakhin.  Bug seems to have come in with  
commit 94aceed31, so back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : a9212716b3bfb8fa83032e5e2e11658f067d7aaf    
  
author   : Michael Paquier <[email protected]>    
date     : Fri, 28 Apr 2023 19:29:44 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Fri, 28 Apr 2023 19:29:44 +0900    

CREATE SCHEMA AUTHORIZATION with appended schema elements can lead to  
crashes when comparing the schema name of the query with the schemas  
used in the qualification of some clauses in the elements' queries.  
  
The origin of the problem is that the transformation routine for the  
elements listed in a CREATE SCHEMA query uses as new, expected, schema  
name the one listed in CreateSchemaStmt itself.  However, depending on  
the query, CreateSchemaStmt.schemaname may be NULL, being computed  
instead from the role specification of the query given by the  
AUTHORIZATION clause, that could be either:  
- A user name string, with the new schema name being set to the same  
value as the role given.  
- Guessed from CURRENT_ROLE, SESSION_ROLE or CURRENT_ROLE, with a new  
schema name computed from the security context where CREATE SCHEMA is  
running.  
  
Regression tests are added for CREATE SCHEMA with some appended elements  
(some of them with schema qualifications), covering also some role  
specification patterns.  
  
While on it, this simplifies the context structure used during the  
transformation of the elements listed in a CREATE SCHEMA query by  
removing the fields for the role specification and the role type.  They  
were not used, and for the role specification this could be confusing as  
the schema name may by extracted from that at the beginning of  
CreateSchemaCommand().  
  
This issue exists for a long time, so backpatch down to all the versions  
supported.  
  
Reported-by: Song Hongyu  
Author: Michael Paquier  
Reviewed-by: Richard Guo  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 11  

commit   : c3c1097dc54328b95270dee59bd5709bbf6be8aa    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 27 Apr 2023 11:55:06 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 27 Apr 2023 11:55:06 -0400    

Python 3 changed the behavior of PyMapping_Check(), breaking the  
test in plpython_to_hstore() that verifies whether a function result  
to be transformed is acceptable.  A backwards-compatible fix is to  
first verify that the object doesn't pass PySequence_Check().  
  
Perhaps accidentally, our other uses of PyMapping_Check() already  
follow uses of PySequence_Check(), so that no other bugs were  
created by this change.  
  
Per bug #17908 from Alexander Lakhin.  Back-patch to all supported  
branches.  
  
Dmitry Dolgov and Tom Lane  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 0151d2c5f256063c6143778062d4685bb08b2db7    
  
author   : Daniel Gustafsson <[email protected]>    
date     : Tue, 25 Apr 2023 13:54:10 +0200    
  
committer: Daniel Gustafsson <[email protected]>    
date     : Tue, 25 Apr 2023 13:54:10 +0200    

Commit 1021bd6a89 excluded autovacuum workers from cost-limit balance  
calculations when per-relation options were set.  The code checks for  
limit and cost_delay being greater than zero, but since cost_delay can  
be set to -1 the test needs to check for greater than or zero.  
  
Backpatch to all supported branches since 1021bd6a89 was backpatched  
all the way at the time.  
  
Author: Masahiko Sawada <[email protected]>  
Reviewed-by: Melanie Plageman <[email protected]>  
Reviewed-by: Daniel Gustafsson <[email protected]>  
Discussion: https://postgr.es/m/CAD21AoBS7o6Ljt_vfqPQPf67AhzKu3fR0iqk8B=vVYczMugKMQ@mail.gmail.com  
Backpatch-through: v11 (all supported branches)  

commit   : 082b59335dbba2da64d77d4f55c8e2559fe548e2    
  
author   : Daniel Gustafsson <[email protected]>    
date     : Mon, 24 Apr 2023 11:16:17 +0200    
  
committer: Daniel Gustafsson <[email protected]>    
date     : Mon, 24 Apr 2023 11:16:17 +0200    

Commit 6df7a9698bb accidentally included two identical prototypes for  
default_multirange_selectivi() and commit 086cf1458c6 added a break;  
statement where one was already present, thus duplicating it.  While  
there is no bug caused by this, fix by removing the duplicated lines  
as they provide no value.  
  
Backpatch the fix for duplicate prototypes to v14 and the duplicate  
break statement fix to all supported branches to avoid backpatching  
hazards due to the removal.  
  
Reported-by: Anton Voloshin <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  

commit   : 106a1bf824ce80c434dbd4cee94e8b66e07e1231    
  
author   : Jeff Davis <[email protected]>    
date     : Fri, 21 Apr 2023 08:19:41 -0700    
  
committer: Jeff Davis <[email protected]>    
date     : Fri, 21 Apr 2023 08:19:41 -0700    

For regex escape sequences, just test directly for the relevant ASCII  
characters rather than using locale-sensitive character  
classification.  
  
This fixes an assertion failure when a locale considers a non-ASCII  
character, such as "൧", to be a digit.  
  
Reported-by: Richard Guo  
Discussion: https://postgr.es/m/CAMbWs49Q6UoKGeT8pBkMtJGJd+16CBFZaaWUk9Du+2ERE5g_YA@mail.gmail.com  
Backpatch-through: 11  

commit   : c976ccc9e5578a6999f1848d34b869add1525cb5    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 20 Apr 2023 18:12:32 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 20 Apr 2023 18:12:32 -0400    

We've long used "--strip-unneeded" for shared libraries but plain  
"-x" for static libraries when stripping symbols with GNU strip.  
There doesn't seem to be any really good reason for that though,  
since --strip-unneeded produces smaller output (as "-x" alone  
does not remove debug symbols).  Moreover it seems that  
llvm-strip, although it identifies as GNU strip, misbehaves when  
given "-x" for this purpose.  It's unclear whether that's  
intentional or a bug in llvm-strip, but in any case it seems like  
changing to use --strip-unneeded in all cases should be a win.  
  
Note that this doesn't change our behavior when dealing with  
non-GNU strip.  
  
Per gripes from Ed Maste and Palle Girgensohn.  Back-patch,  
in case anyone wants to use llvm-strip with stable branches.  
  
Discussion: https://postgr.es/m/[email protected]  
Discussion: https://postgr.es/m/[email protected]  

commit   : 7228f2f812f58627465fc00dbfbec5f6d15d8b5b    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 18 Apr 2023 14:46:39 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 18 Apr 2023 14:46:39 -0400    

DST law changes in Egypt, Greenland, Morocco, and Palestine.  
  
When observing Moscow time, Europe/Kirov and Europe/Volgograd now  
use the abbreviations MSK/MSD instead of numeric abbreviations,  
for consistency with other timezones observing Moscow time.  
  
Also, America/Yellowknife is no longer distinct from America/Edmonton;  
this affects some pre-1948 timestamps in that area.  

commit   : dbd25dd0b59c649981e0a26cc0f367b8c0368473    
  
author   : Michael Paquier <[email protected]>    
date     : Tue, 18 Apr 2023 12:00:31 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Tue, 18 Apr 2023 12:00:31 +0900    

Per buildfarm member mylodon.  As C99 declarations are allowed in v12~,  
this is adjusted only on REL_11_STABLE.  Introduced by 9eb44bb.  

commit   : 9eb44bb043af924d9fe567145a3c6510d584399b    
  
author   : Michael Paquier <[email protected]>    
date     : Tue, 18 Apr 2023 11:20:55 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Tue, 18 Apr 2023 11:20:55 +0900    

When compiled with -C ORACLE, ecpg_get_data() had a one-off issue where  
it would incorrectly store the null terminator byte to str[-1] when  
varcharsize is 0, which is something that can happen when using SQLDA.  
This would eat 1 byte from the previous field stored, corrupting the  
results generated.  
  
All the callers of ecpg_get_data() estimate and allocate enough storage  
for the data received, and the fix of this commit relies on this  
assumption.  Note that this maps to the case where no padding or  
truncation is required.  
  
This issue has been introduced by 3b7ab43 with the Oracle compatibility  
option, so backpatch down to v11.  
  
Author: Kyotaro Horiguchi  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 11  

commit   : c796d7296978e1ac09bcbb41c9230b6cc32b7d44    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 17 Apr 2023 14:22:06 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 17 Apr 2023 14:22:06 -0400    

If the last few pages in the specified range are empty (all zero),  
then log_newpage_range() could try to emit an empty WAL record  
containing no FPIs.  This at least upsets an Assert in  
ReserveXLogInsertLocation, and might perhaps have bad real-world  
consequences in non-assert builds.  
  
This has been broken since log_newpage_range() was introduced,  
but the case was hard if not impossible to hit before commit 3d6a98457  
decided it was okay to leave VM and FSM pages intentionally zero.  
Nonetheless, it seems prudent to back-patch.  log_newpage_range()  
was added in v12 but later back-patched, so this affects all  
supported branches.  
  
Matthias van de Meent, per report from Justin Pryzby  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : ea7894d33d174c2fb76ad838cf9a7a17d604a950    
  
author   : Daniel Gustafsson <[email protected]>    
date     : Fri, 14 Apr 2023 10:15:50 +0200    
  
committer: Daniel Gustafsson <[email protected]>    
date     : Fri, 14 Apr 2023 10:15:50 +0200    

Starting with OpenSSL 1.1.0 there is no need to call PQinitOpenSSL  
or PQinitSSL to avoid duplicate initialization of OpenSSL.  Add a  
note to the documentation to explain this.  
  
Backpatch to all supported versions as older OpenSSL versions are  
equally likely to be used for all branches.  
  
Reported-by: Sebastien Flaesch <[email protected]>  
Reviewed-by: Tom Lane <[email protected]>  
Discussion: https://postgr.es/m/DBAP191MB12895BFFEC4B5FE0460D0F2FB0459@DBAP191MB1289.EURP191.PROD.OUTLOOK.COM  
Backpatch-through: 11, all supported versions  

commit   : 1c19e2863994ec15e496d21a9320aff95a389d0b    
  
author   : David Rowley <[email protected]>    
date     : Fri, 14 Apr 2023 16:23:11 +1200    
  
committer: David Rowley <[email protected]>    
date     : Fri, 14 Apr 2023 16:23:11 +1200    

The partition pruning logic assumed that "b IS NOT true" was exactly the  
same as "b IS FALSE".  This is not the case when considering NULL values.  
Fix this so we correctly include any partition which could hold NULL  
values for the NOT case.  
  
Additionally, this fixes a bug in the partition pruning code which handles  
partitioned tables partitioned like ((NOT boolcol)).  This is a seemingly  
unlikely schema design, and it was untested and also broken.  
  
Here we add tests for the ((NOT boolcol)) case and insert some actual data  
into those tables and verify we do get the correct rows back when running  
queries.  I've also adjusted the existing boolpart tests to include some  
data and verify we get the correct results too.  
  
Both the bugs being fixed here could lead to incorrect query results with  
fewer rows being returned than expected.  No additional rows could have  
been returned accidentally.  
  
In passing, remove needless ternary expression.  It's more simple just to  
pass !is_not_clause to makeBoolConst().  It makes sense to do this so the  
code is consistent with the bug fix in the "else if" condition just below.  
  
David Kimura did submit a patch to fix the first of the issues here, but  
that's not what's being committed here.  
  
Reported-by: David Kimura  
Reviewed-by: Richard Guo, David Kimura  
Discussion: https://postgr.es/m/CAHnPFjQ5qxs6J_p+g8=ww7GQvfn71_JE+Tygj0S7RdRci1uwPw@mail.gmail.com  
Backpatch-through: 11, all supported versions  

commit   : 9517e6e1dd60f38d55f3941d8b5182555c165ede    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 13 Apr 2023 10:32:51 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 13 Apr 2023 10:32:51 -0400    

Previously the test knew how to find an OpenLDAP installation at the  
paths used by Homebrew.  Add the MacPorts paths too.  
  
This back-patches the v12-era commit aa1419e63 into v11, in  
preparation for spinning up a buildfarm animal that requires it.  
  
Author: Thomas Munro  
Reviewed-by: Tom Lane  
Discussion: https://postgr.es/m/CA%2BhUKGKrjGS7sO4jc53gp3qipCtEvThtdP_%3DzoixgX5ZBq4Nbw%40mail.gmail.com  
Discussion: https://postgr.es/m/[email protected]  

commit   : 60c8aeaf6745fa51cc893c48c626bc14c1009fde    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 12 Apr 2023 10:46:30 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 12 Apr 2023 10:46:30 -0400    

Our policy since commit ab77a5a45 has been that a plan node having  
any initplans is automatically not parallel-safe.  (This could be  
relaxed, but not today.)  clean_up_removed_plan_level neglected  
this, and could attach initplans to a parallel-safe child plan  
node without clearing the plan's parallel-safe flag.  That could  
lead to "subplan was not initialized" errors at runtime, in case  
an initplan referenced another one and only the referencing one  
got transmitted to parallel workers.  
  
The fix in clean_up_removed_plan_level is trivial enough.  
materialize_finished_plan also moves initplans from one node  
to another, but it's okay because it already copies the source  
node's parallel_safe flag.  The other place that does this kind  
of thing is standard_planner's hack to inject a top-level Gather  
when debug_parallel_query is active.  But that's actually dead  
code given that we're correctly enforcing the "initplans aren't  
parallel safe" rule, so just replace it with an Assert that  
there are no initplans.  
  
Also improve some related comments.  
  
Normally we'd add a regression test case for this sort of bug.  
The mistake itself is already reached by existing tests, but there  
is accidentally no visible problem.  The only known test case that  
creates an actual failure seems too indirect and fragile to justify  
keeping it as a regression test (not least because it fails to fail  
in v11, though the bug is clearly present there too).  
  
Per report from Justin Pryzby.  Back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 52d83e927015ddfc7fdbc5bb65d555cdd0355522    
  
author   : Stephen Frost <[email protected]>    
date     : Fri, 7 Apr 2023 19:36:03 -0400    
  
committer: Stephen Frost <[email protected]>    
date     : Fri, 7 Apr 2023 19:36:03 -0400    

Similar to 8dff2f224, this disables DNS lookups by the Kerberos library  
to look up the KDC and the realm while the Kerberos tests are running.  
In some environments, these lookups can take a long time and end up  
timing out and causing tests to fail.  Further, since this isn't really  
our domain, we shouldn't be sending out these DNS requests during our  
tests.  

commit   : f0bd3361e09d206c47c0dc439c6642f96f67fab9    
  
author   : Stephen Frost <[email protected]>    
date     : Fri, 7 Apr 2023 19:36:03 -0400    
  
committer: Stephen Frost <[email protected]>    
date     : Fri, 7 Apr 2023 19:36:03 -0400    

In our Kerberos test suite, there isn't much need to worry about the  
normal canonicalization that Kerberos provides by looking up the reverse  
DNS for the IP address connected to, and in some cases it can actively  
cause problems (eg: a captive portal wifi where the normally not  
resolvable localhost address used ends up being resolved anyway, and  
not to the domain we are using for testing, causing the entire  
regression test to fail with errors about not being able to get a TGT  
for the remote realm for cross-realm trust).  
  
Therefore, disable it by adding rdns = false into the krb5.conf that's  
generated for the test.  
  
Reviewed-By: Heikki Linnakangas  
Discussion: https://postgr.es/m/Y/[email protected]  

commit   : 83965ef0bd2345f83d728f0ca80779b8fd1c264c    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 6 Apr 2023 18:13:49 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 6 Apr 2023 18:13:49 -0400    

The tests added by commits 029dea882 et al turn out to produce  
different output under -DRANDOMIZE_ALLOCATED_MEMORY.  This is  
not a bug exactly: that flag causes coerce_type() to invoke  
the input function twice when coercing an unknown-type literal  
to a specific type.  So you get tsqueryin's bleat about an empty  
tsquery twice.  Revise the test query to avoid that.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : bc428b12ac3ac7f4444b5d6f792cdbc3ee3c9388    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 6 Apr 2023 15:52:37 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 6 Apr 2023 15:52:37 -0400    

tsquery's GETQUERY() macro is only safe to apply to a tsquery  
that is known non-empty; otherwise it gives a pointer to garbage.  
Before commit 5a617d75d, ts_headline() avoided this pitfall, but  
only in a very indirect, nonobvious way.  (hlCover could not reach  
its TS_execute call, because if the query contains no lexemes  
then hlFirstIndex would surely return -1.)  After that commit,  
it fell into the trap, resulting in weird errors such as  
"unrecognized operator" and/or valgrind complaints.  In HEAD,  
fix this by not calling TS_execute_locations() at all for an  
empty query.  In the back branches, add a defensive check to  
hlCover() --- that's not fixing any live bug, but I judge the  
code a bit too fragile as-is.  
  
Also, both mark_hl_fragments() and mark_hl_words() were careless  
about the possibility of empty search text: in the cases where  
no match has been found, they'd end up telling mark_fragment() to  
mark from word indexes 0 to 0 inclusive, even when there is no  
word 0.  This is harmless since we over-allocated the prs->words  
array, but it does annoy valgrind.  Fix so that the end index is -1  
and thus mark_fragment() will do nothing in such cases.  
  
Bottom line is that this fixes a live bug in HEAD, but in the  
back branches it's only getting rid of a valgrind nitpick.  
Back-patch anyway.  
  
Per report from Alexander Lakhin.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : eac34f7eb3153e716401c9a88b518c33a20c01e5    
  
author   : John Naylor <[email protected]>    
date     : Wed, 5 Apr 2023 14:16:19 +0700    
  
committer: John Naylor <[email protected]>    
date     : Wed, 5 Apr 2023 14:16:19 +0700    

Since 8b9e9644d, the messages for failed permissions checks report  
"table" where appropriate, rather than "relation".  
  
Backpatch to all supported branches  

commit   : ea406250d9c77be9dc83f7d41662379319d1ffd5    
  
author   : Michael Paquier <[email protected]>    
date     : Wed, 5 Apr 2023 07:59:57 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Wed, 5 Apr 2023 07:59:57 +0900    

The explanation describing the dependency to system read() calls for  
these two functions has been removed in ddfc2d9.  And after more  
discussion about d69c404, we have concluded that adding more details  
makes them easier to understand.  
  
While on it, use the term "block read requests" (maybe found in cache)  
rather than "buffers fetched" and "buffer hits".  
  
Per discussion with Melanie Plageman, Kyotaro Horiguchi, Bertrand  
Drouvot and myself.  
  
Discussion: https://postgr.es/m/CAAKRu_ZmdiScT4q83OAbfmR5AH-L5zWya3SXjaxiJvhCob-e2A@mail.gmail.com  
Backpatch-through: 11  

commit   : e46a309bd8b257642ebe406188e79cce22db43f7    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 31 Mar 2023 10:08:40 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 31 Mar 2023 10:08:40 -0400    

The totalrows/totaldeadrows outputs were left uninitialized in cases  
where we find no analyzable child tables of a partitioned table.  This  
could lead to setting the partitioned table's pg_class.reltuples value  
to garbage.  It's not clear that that would have any very bad effects  
in practice, but fix it anyway because it's making valgrind unhappy.  
  
Reported and diagnosed by Alexander Lakhin (bug #17880).  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 07554c99dfdbba7809b73e8028cf8a9f5cbfa36f    
  
author   : David Rowley <[email protected]>    
date     : Fri, 31 Mar 2023 12:15:39 +1300    
  
committer: David Rowley <[email protected]>    
date     : Fri, 31 Mar 2023 12:15:39 +1300    

When calling generateSerialExtraStmts(), we would pass in the  
constraint->options.  In some cases, generateSerialExtraStmts() would  
modify the referenced List to remove elements from it, but doing so is  
invalid without assigning the list back to all variables that point to it.  
In the particular reported problem case, the List became empty, in which  
cases it became NIL, but the passed in constraint->options didn't get to  
find out about that and was left pointing to free'd memory.  
  
To fix this, just perform a list_copy() inside generateSerialExtraStmts().  
We could just do a list_copy() just before we perform the delete from the  
list, however, that seems less robust.  Let's make sure the generated  
CreateSeqStmt gets a completely different copy of the list to be safe.  
  
Bug: #17879  
Reported-by: Fei Changhong  
Diagnosed-by: Fei Changhong  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 11, all supported versions  

commit   : b5c6776c11279f4afe6c92b2a25831c0eb35a45c    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 29 Mar 2023 11:31:30 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 29 Mar 2023 11:31:30 -0400    

gistBuildCallback tried to fetch the size of an index tuple that  
might have already been freed by gistProcessEmptyingQueue.  
While this seems to usually be harmless in production builds,  
in principle it could result in a SIGSEGV, or more likely a bogus  
value for indtuplesSize leading to poor page-split decisions later  
in the build.  
  
The memory management here is confusing and could stand to be  
refactored, but for the moment it seems to be enough to fetch  
the tuple size sooner.  AFAICT the indtuples[Size] totals aren't  
used in between these places; even if they were, the updated  
values shouldn't be any worse to use.  So just move the  
incrementing of the totals up.  
  
It's not very clear why our valgrind-using buildfarm animals  
haven't noticed this problem, because the relevant code path  
does seem to be exercised according to the code coverage report.  
I think the reason that we didn't fix this bug after the first  
report is that I'd wanted to try to understand that better.  
However, now that it's been re-discovered let's just be pragmatic  
and fix it already.  
  
Original report by Alexander Lakhin (bug #16329),  
later rediscovered by Egor Chindyaskin (bug #17874).  
  
Patch by Alexander Lakhin (commentary by Pavel Borisov and me).  
Back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/[email protected]  
Discussion: https://postgr.es/m/[email protected]  

commit   : 4257d34e310be2e16c782f9e9339907a34f708ce    
  
author   : Daniel Gustafsson <[email protected]>    
date     : Mon, 27 Mar 2023 21:35:34 +0200    
  
committer: Daniel Gustafsson <[email protected]>    
date     : Mon, 27 Mar 2023 21:35:34 +0200    

Homebrew changed the prefix for Apple Silicon based machines, so  
our advice for XML_CATALOG_FILES needs to mention both.  More info  
on the Homebrew change can be found at:  
  
https://github.com/Homebrew/brew/issues/9177  
  
This is backpatch of commits 4c8d65408 and 5a91c7975, the latter  
which contained a small fix based on a report from Dagfinn Ilmari  
Mannsåker.  
  
Author: Julien Rouhaud <[email protected]>  
Discussion: https://postgr.es/m/20230327082441.h7pa2vqiobbyo7rd@jrouhaud  

commit   : 78838bc3d43d3557f1027b95b1961b943d8c0980    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 27 Mar 2023 15:04:02 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 27 Mar 2023 15:04:02 -0400    

find_composite_type_dependencies() ignored indexes, which is a poor  
decision because an expression index could have a stored column of  
a composite (or other container) type even when the underlying table  
does not.  Teach it to detect such cases and error out.  We have to  
work a bit harder than for other relations because the pg_depend entry  
won't identify the specific index column of concern, but it's not much  
new code.  
  
This does not address bug #17872's original complaint that dropping  
a column in such a type might lead to violations of the uniqueness  
property that a unique index is supposed to ensure.  That seems of  
much less concern to me because it won't lead to crashes.  
  
Per bug #17872 from Alexander Lakhin.  Back-patch to all supported  
branches.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : ae320fc216863e675505877a844d5a31516362d8    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 26 Mar 2023 13:41:06 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 26 Mar 2023 13:41:06 -0400    

The nested-arrays code path in ExecEvalArrayExpr() used palloc to  
allocate the result array, whereas every other array-creating function  
has used palloc0 since 18c0b4ecc.  This mostly works, but unused bits  
past the end of the nulls bitmap may end up undefined.  That causes  
valgrind complaints with -DWRITE_READ_PARSE_PLAN_TREES, and could  
cause planner misbehavior as cited in 18c0b4ecc.  There seems no very  
good reason why we should strive to avoid palloc0 in just this one case,  
so fix it the easy way with s/palloc/palloc0/.  
  
While looking at that I noted that we also failed to check for overflow  
of "nbytes" and "nitems" while summing the sizes of the sub-arrays,  
potentially allowing a crash due to undersized output allocation.  
For "nbytes", follow the policy used by other array-munging code of  
checking for overflow after each addition.  (As elsewhere, the last  
addition of the array's overhead space doesn't need an extra check,  
since palloc itself will catch a value between 1Gb and 2Gb.)  
For "nitems", there's no very good reason to sum the inputs at all,  
since we can perfectly well use ArrayGetNItems' result instead of  
ignoring it.  
  
Per discussion of this bug, also remove redundant zeroing of the  
nulls bitmap in array_set_element and array_set_slice.  
  
Patch by Alexander Lakhin and myself, per bug #17858 from Alexander  
Lakhin; thanks also to Richard Guo.  These bugs are a dozen years old,  
so back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : e09fb8a7588d89c9654b21e81d181ef9abf6e77c    
  
author   : Michael Paquier <[email protected]>    
date     : Wed, 22 Mar 2023 18:32:11 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Wed, 22 Mar 2023 18:32:11 +0900    

This commit adds some documentation about two monitoring functions:  
- pg_stat_get_xact_blocks_fetched()  
- pg_stat_get_xact_blocks_hit()  
  
The description of these functions has been removed in ddfc2d9, later  
simplified by 5f2b089, assuming that all the functions whose  
descriptions were removed are used in system views.  Unfortunately, some  
of them were are not used in any system views, so they lacked  
documentation.  
  
This gap exists in the docs for a long time, so backpatch all the way  
down.  
  
Reported-by: Michael Paquier  
Author: Bertrand Drouvot  
Reviewed-by: Kyotaro Horiguchi  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 11  

commit   : 4cdaea7a211938a2471a8481f5efb61e7a88ad36    
  
author   : Amit Kapila <[email protected]>    
date     : Tue, 21 Mar 2023 08:39:00 +0530    
  
committer: Amit Kapila <[email protected]>    
date     : Tue, 21 Mar 2023 08:39:00 +0530    

We fail to apply updates and deletes when the REPLICA IDENTITY FULL is  
used for the table having dropped columns. We didn't use to ignore dropped  
columns while doing tuple comparison among the tuples from the publisher  
and subscriber during apply of updates and deletes.  
  
Author: Onder Kalaci, Shi yu  
Reviewed-by: Amit Kapila  
Discussion: https://postgr.es/m/CACawEhVQC9WoofunvXg12aXtbqKnEgWxoRx3+v8q32AWYsdpGg@mail.gmail.com  

commit   : ef16d27245f6167acd878bea49cdde0a8dcec49c    
  
author   : Thomas Munro <[email protected]>    
date     : Tue, 21 Mar 2023 14:29:34 +1300    
  
committer: Thomas Munro <[email protected]>    
date     : Tue, 21 Mar 2023 14:29:34 +1300    

With unlucky timing and parallel_leader_participation=off (not the  
default), PHJ could attempt to access per-batch shared state just as it  
was being freed.  There was code intended to prevent that by checking  
for a cleared pointer, but it was racy.  Fix, by introducing an extra  
barrier phase.  The new phase PHJ_BUILD_RUNNING means that it's safe to  
access the per-batch state to find a batch to help with, and  
PHJ_BUILD_DONE means that it is too late.  The last to detach will free  
the array of per-batch state as before, but now it will also atomically  
advance the phase, so that late attachers can avoid the hazard.  This  
mirrors the way per-batch hash tables are freed (see phases  
PHJ_BATCH_PROBING and PHJ_BATCH_DONE).  
  
An earlier attempt to fix this (commit 3b8981b6, later reverted) missed  
one special case.  When the inner side is empty (the "empty inner  
optimization), the build barrier would only make it to  
PHJ_BUILD_HASHING_INNER phase before workers attempted to detach from  
the hashtable.  In that case, fast-forward the build barrier to  
PHJ_BUILD_RUNNING before proceeding, so that our later assertions hold  
and we can still negotiate who is cleaning up.  
  
Revealed by build farm failures, where BarrierAttach() failed a sanity  
check assertion, because the memory had been clobbered by dsa_free().  
In non-assert builds, the result could be a segmentation fault.  
  
Back-patch to all supported releases.  
  
Author: Thomas Munro <[email protected]>  
Author: Melanie Plageman <[email protected]>  
Reported-by: Michael Paquier <[email protected]>  
Reported-by: David Geier <[email protected]>  
Tested-by: David Geier <[email protected]>  
Discussion: https://postgr.es/m/20200929061142.GA29096%40paquier.xyz  

commit   : 4af259543b1581deeaedd6a983223d44b2db98b7    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 18 Mar 2023 16:11:22 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 18 Mar 2023 16:11:22 -0400    

Per report from rsindlin  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 012ffb365a05694e392bf96c8363d119bd19534c    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 17 Mar 2023 13:31:40 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 17 Mar 2023 13:31:40 -0400    

Hash partitioning on an enum is problematic because the hash codes are  
derived from the OIDs assigned to the enum values, which will almost  
certainly be different after a dump-and-reload than they were before.  
This means that some rows probably end up in different partitions than  
before, causing restore to fail because of partition constraint  
violations.  (pg_upgrade dodges this problem by using hacks to force  
the enum values to keep the same OIDs, but that's not possible nor  
desirable for pg_dump.)  
  
Users can work around that by specifying --load-via-partition-root,  
but since that's a dump-time not restore-time decision, one might  
find out the need for it far too late.  Instead, teach pg_dump to  
apply that option automatically when dealing with a partitioned  
table that has hash-on-enum partitioning.  
  
Also deal with a pre-existing issue for --load-via-partition-root  
mode: in a parallel restore, we try to TRUNCATE target tables just  
before loading them, in order to enable some backend optimizations.  
This is bad when using --load-via-partition-root because (a) we're  
likely to suffer deadlocks from restore jobs trying to restore rows  
into other partitions than they came from, and (b) if we miss getting  
a deadlock we might still lose data due to a TRUNCATE removing rows  
from some already-completed restore job.  
  
The fix for this is conceptually simple: just don't TRUNCATE if we're  
dealing with a --load-via-partition-root case.  The tricky bit is for  
pg_restore to identify those cases.  In dumps using COPY commands we  
can inspect each COPY command to see if it targets the nominal target  
table or some ancestor.  However, in dumps using INSERT commands it's  
pretty impractical to examine the INSERTs in advance.  To provide a  
solution for that going forward, modify pg_dump to mark TABLE DATA  
items that are using --load-via-partition-root with a comment.  
(This change also responds to a complaint from Robert Haas that  
the dump output for --load-via-partition-root is pretty confusing.)  
pg_restore checks for the special comment as well as checking the  
COPY command if present.  This will fail to identify the combination  
of --load-via-partition-root and --inserts in pre-existing dump files,  
but that should be a pretty rare case in the field.  If it does  
happen you will probably get a deadlock failure that you can work  
around by not using parallel restore, which is the same as before  
this bug fix.  
  
Having done this, there seems no remaining reason for the alarmism  
in the pg_dump man page about combining --load-via-partition-root  
with parallel restore, so remove that warning.  
  
Patch by me; thanks to Julien Rouhaud for review.  Back-patch to  
v11 where hash partitioning was introduced.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : b520129bdca4a787973b71bdd61519686be12715    
  
author   : Andres Freund <[email protected]>    
date     : Thu, 16 Mar 2023 23:03:31 -0700    
  
committer: Andres Freund <[email protected]>    
date     : Thu, 16 Mar 2023 23:03:31 -0700    

Unfortunately it turns out that the logfile-only option added in b9f8d1cbad7  
is only available in openldap starting in 2.6.  
  
Luckily the option to control the log level (loglevel/-s) have been around for  
much longer. As it turns out loglevel/-s only control what goes into syslog,  
not what ends up in the file specified with 'logfile' and stderr.  
  
While we currently are specifying 'logfile', nothing ends up in it, as the  
option only controls debug messages, and we didn't set a debug level. The  
debug level can only be configured on the commandline and also prevents  
forking. That'd require larger changes, so this commit doesn't tackle that  
issue.  
  
Specify the syslog level when starting slapd using -s, as that allows to  
prevent all syslog messages if one uses '0' instead of 'none', while loglevel  
doesn't prevent the first message.  
  
Discussion: https://postgr.es/m/[email protected]  
Backpatch: 11-  

commit   : b43d8e76ddfabfb710f80dd3095cd62c593e5ca8    
  
author   : Andres Freund <[email protected]>    
date     : Thu, 16 Mar 2023 17:48:47 -0700    
  
committer: Andres Freund <[email protected]>    
date     : Thu, 16 Mar 2023 17:48:47 -0700    

Until now the tests using slapd spammed syslog for every connection /  
query. Use logfile-only to prevent syslog activity. Unfortunately that only  
takes effect after logging the first message, but that's still much better  
than the prior situation.  
  
Discussion: https://postgr.es/m/[email protected]  
Backpatch: 11-  

commit   : b23f2a729c9e9b028091717df2fed11c95f98cd9    
  
author   : Thomas Munro <[email protected]>    
date     : Fri, 17 Mar 2023 14:44:12 +1300    
  
committer: Thomas Munro <[email protected]>    
date     : Fri, 17 Mar 2023 14:44:12 +1300    

Further to commit 6a9229da, checking for NULL is now redundant.  An "out  
of memory" error would have been thrown already by palloc() and treated  
as FATAL, so we can delete a few more lines.  
  
Back-patch to all releases, like those other commits.  
  
Reported-by: Tom Lane <[email protected]>  
Discussion: https://postgr.es/m/4040668.1679013388%40sss.pgh.pa.us  

commit   : 25ae3bba79221ceacf8a6ec0313a039ecd18e528    
  
author   : Andres Freund <[email protected]>    
date     : Thu, 16 Mar 2023 14:08:44 -0700    
  
committer: Andres Freund <[email protected]>    
date     : Thu, 16 Mar 2023 14:08:44 -0700    

gcc 12+ has complaints like the following:  
  
../../../../../pgsql/src/backend/utils/adt/network.c: In function 'inetnot':  
../../../../../pgsql/src/backend/utils/adt/network.c:1893:34: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=]  
 1893 |                         pdst[nb] = ~pip[nb];  
      |                         ~~~~~~~~~^~~~~~~~~~  
../../../../../pgsql/src/include/utils/inet.h:27:23: note: at offset -1 into destination object 'ipaddr' of size 16  
   27 |         unsigned char ipaddr[16];       /* up to 128 bits of address */  
      |                       ^~~~~~  
../../../../../pgsql/src/include/utils/inet.h:27:23: note: at offset -1 into destination object 'ipaddr' of size 16  
  
This is due to a compiler bug:  
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104986  
  
It has been a year since the bug has been reported without getting fixed. As  
the warnings are verbose and use of gcc 12 is becoming more common, it seems  
worth working around the bug. Particularly because a simple reformulation of  
the loop condition fixes the issue and isn't any less readable.  
  
Author: Tom Lane <[email protected]>  
Author: Andres Freund <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  
Backpatch: 11-  

commit   : 9d6c3439716f04e1dea92376e794ddde98624e3b    
  
author   : Thomas Munro <[email protected]>    
date     : Fri, 17 Mar 2023 09:44:42 +1300    
  
committer: Thomas Munro <[email protected]>    
date     : Fri, 17 Mar 2023 09:44:42 +1300    

A comment was left behind claiming that we needed to use malloc() rather  
than palloc() because the corresponding free would run in another  
thread, but that's not true anymore.  Remove that comment.  And, with  
the reason being gone, we might as well actually use palloc().  
  
Back-patch to supported releases, like d41a178b.  
  
Discussion: https://postgr.es/m/CA%2BhUKG%2BpdM9v3Jv4tc2BFx2jh_daY3uzUyAGBhtDkotEQDNPYw%40mail.gmail.com  

commit   : 5ff8e69d8ea594075e435bb42e95b605e08afc2f    
  
author   : Thomas Munro <[email protected]>    
date     : Wed, 15 Mar 2023 13:17:18 +1300    
  
committer: Thomas Munro <[email protected]>    
date     : Wed, 15 Mar 2023 13:17:18 +1300    

Our waitpid() emulation didn't prevent a PID from being recycled by the  
OS before the call to waitpid().  The postmaster could finish up  
tracking more than one child process with the same PID, and confuse  
them.  
  
Fix, by moving the guts of pgwin32_deadchild_callback() into waitpid(),  
so that resources are released synchronously.  The process and PID  
continue to exist until we close the process handle, which only happens  
once we're ready to adjust our book-keeping of running children.  
  
This seems to explain a couple of failures on CI.  It had never been  
reported before, despite the code being as old as the Windows port.  
Perhaps Windows started recycling PIDs more rapidly, or perhaps timing  
changes due to commit 7389aad6 made it more likely to break.  
  
Thanks to Alexander Lakhin for analysis and Andres Freund for tracking  
down the root cause.  
  
Back-patch to all supported branches.  
  
Reported-by: Andres Freund <[email protected]>  
Discussion: https://postgr.es/m/20230208012852.bvkn2am4h4iqjogq%40awork3.anarazel.de  

commit   : 8e33fb9ef1df7f1a1e7ef2fe0dbddfff2520f161    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 14 Mar 2023 19:17:31 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 14 Mar 2023 19:17:31 -0400    

The band-aid applied in commit f0bedf3e4 turns out to still need  
some work: it made sure we didn't set Np->last_relevant too small  
(to the left of the decimal point), but it didn't prevent setting  
it too large (off the end of the partially-converted string).  
This could result in fetching data beyond the end of the allocated  
space, which with very bad luck could cause a SIGSEGV, though  
I don't see any hazard of interesting memory disclosure.  
  
Per bug #17839 from Thiago Nunes.  The bug's pretty ancient,  
so back-patch to all supported versions.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 234941a3bbf32266e9e2d3d9bc7648aec850d8c4    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 13 Mar 2023 15:19:00 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 13 Mar 2023 15:19:00 -0400    

The majority of error exit cases in json_lex_string() failed to  
set lex->token_terminator, causing problems for the error context  
reporting code: it would see token_terminator less than token_start  
and do something more or less nuts.  In v14 and up the end result  
could be as bad as a crash in report_json_context().  Older  
versions accidentally avoided that fate; but all versions produce  
error context lines that are far less useful than intended,  
because they'd stop at the end of the prior token instead of  
continuing to where the actually-bad input is.  
  
To fix, invent some macros that make it less notationally painful  
to do the right thing.  Also add documentation about what the  
function is actually required to do; and in >= v14, add an assertion  
in report_json_context about token_terminator being sufficiently  
far advanced.  
  
Per report from Nikolay Shaplov.  Back-patch to all supported  
versions.  
  
Discussion: https://postgr.es/m/7332649.x5DLKWyVIX@thinkpad-pgpro  

commit   : 0736b11318daaa38f808197f707fabed79b3aef8    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 13 Mar 2023 12:40:28 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 13 Mar 2023 12:40:28 -0400    

check_agg_arguments_walker() supposed that it needn't descend into  
the arguments of a lower-level aggregate function, but this is  
just wrong in the presence of multiple levels of sub-select.  The  
oversight would lead to executor failures on queries that should  
be rejected.  (Prior to v11, they actually were rejected, thanks  
to a "redundant" execution-time check.)  
  
Per bug #17835 from Anban Company.  Back-patch to all supported  
branches.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : b18327489b3be5c30ae51eaf24479da7c0af1aaa    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 11 Mar 2023 12:15:41 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 11 Mar 2023 12:15:41 -0500    

If the regex compiler can see that a regex is unsatisfiable  
(for example, '$foo') then it may emit an NFA having no arcs.  
pg_trgm's packGraph function did the wrong thing in this case;  
it would access off the end of a work array, and with bad luck  
could produce a corrupted output data structure causing more  
problems later.  This could end with wrong answers or crashes  
in queries using a pg_trgm GIN or GiST index with such a regex.  
  
Fix by not trying to de-duplicate if there aren't at least 2 arcs.  
  
Per bug #17830 from Alexander Lakhin.  Back-patch to all supported  
branches.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 6e2674d772b017f4ad4e36394aa1cf64c05b46e5    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 10 Mar 2023 13:52:28 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 10 Mar 2023 13:52:28 -0500    

The COPY documentation is quite clear that "COPY relation TO" copies  
rows from only the named table, not any inheritance children it may  
have.  However, if you enabled row-level security on the table then  
this stopped being true, because the code forgot to apply the ONLY  
modifier in the "SELECT ... FROM relation" query that it constructs  
in order to allow RLS predicates to be attached.  Fix that.  
  
Report and patch by Antonin Houska (comment adjustments and test case  
by me).  Back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/3472.1675251957@antos  

commit   : d1c0f81e72738bcd1b5abc86be7f5a90d659f7bc    
  
author   : Thomas Munro <[email protected]>    
date     : Thu, 9 Mar 2023 16:33:24 +1300    
  
committer: Thomas Munro <[email protected]>    
date     : Thu, 9 Mar 2023 16:33:24 +1300    

Commit bdaabb9b started skipping doomed transactions when building the  
list of possible conflicts for SERIALIZABLE READ ONLY.  That makes  
sense, because doomed transactions won't commit, but a couple of subtle  
things broke:  
  
1.  If all uncommitted r/w transactions are doomed, a READ ONLY  
transaction would arbitrarily not benefit from the safe snapshot  
optimization.  It would not be taken immediately, and yet no other  
transaction would set SXACT_FLAG_RO_SAFE later.  
  
2.  In the same circumstances but with DEFERRABLE, GetSafeSnapshot()  
would correctly exit its wait loop without sleeping and then take the  
optimization in non-assert builds, but assert builds would fail a sanity  
check that SXACT_FLAG_RO_SAFE had been set by another transaction.  
  
This is similar to the case for PredXact->WritableSxactCount == 0.  We  
should opt out immediately if our possibleUnsafeConflicts list is empty  
after filtering.  
  
The code to maintain the serializable global xmin is moved down below  
the new opt out site, because otherwise we'd have to reverse its effects  
before returning.  
  
Back-patch to all supported releases.  Bug #17368.  
  
Reported-by: Alexander Lakhin <[email protected]>  
Discussion: https://postgr.es/m/17116-d6ca217acc180e30%40postgresql.org  
Discussion: https://postgr.es/m/20110707212159.GF76634%40csail.mit.edu  

commit   : 721626cb57c023a957397a81564439560f0f155f    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 7 Mar 2023 18:21:37 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 7 Mar 2023 18:21:37 -0500    

If a view is defined atop another view, and then CREATE OR REPLACE  
VIEW is used to add columns to the lower view, then when the upper  
view's referencing RTE is expanded by ApplyRetrieveRule we will have  
a subquery RTE with fewer eref->colnames than output columns.  This  
confuses various code that assumes those lists are always in sync,  
as they are in plain parser output.  
  
We have seen such problems before (cf commit d5b760ecb), and now  
I think the time has come to do what was speculated about in that  
commit: let's make ApplyRetrieveRule synthesize some column names to  
preserve the invariant that holds in parser output.  Otherwise we'll  
be chasing this class of bugs indefinitely.  Moreover, it appears from  
testing that this actually gives us better results in the test case  
d5b760ecb added, and likely in other corner cases that we lack  
coverage for.  
  
In HEAD, I replaced d5b760ecb's hack to make expandRTE exit early with  
an elog(ERROR) call, since the case is now presumably unreachable.  
But it seems like changing that in back branches would bring more risk  
than benefit, so there I just updated the comment.  
  
Per bug #17811 from Alexander Lakhin.  Back-patch to all supported  
branches.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : b1a9d8ef254fab59c35a504490e14b2d9e1bbb92    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 1 Mar 2023 11:30:17 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 1 Mar 2023 11:30:17 -0500    

This is usually harmless, but if you were very unlucky it could  
provoke a segfault due to the "to" string being right up against  
the end of memory.  Found via valgrind testing (so we might've  
found it earlier, except that our regression tests lacked any  
exercise of translate()'s deletion feature).  
  
Fix by switching the order of the test-for-end-of-string and  
advance-pointer steps.  While here, compute "to_ptr + tolen"  
just once.  (Smarter compilers might figure that out for  
themselves, but let's just make sure.)  
  
Report and fix by Daniil Anisimov, in bug #17816.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 73e779b3807dedb9b0bc20d4ce12a350033aa646    
  
author   : Andrew Dunstan <[email protected]>    
date     : Sun, 26 Feb 2023 06:48:41 -0500    
  
committer: Andrew Dunstan <[email protected]>    
date     : Sun, 26 Feb 2023 06:48:41 -0500    

It's been this way for a very long time, but it appears to have been  
masking an issue that only manifests with different settings. Therefore,  
run the tests in the installation's default encoding/locale.  
  
Backpatch to all live branches.  

commit   : ffec64ba86c40a31e5a1d0c9a53bf923624db51f    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 25 Feb 2023 14:44:14 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 25 Feb 2023 14:44:14 -0500    

We already tried to fix this in commits 3f7323cbb et al (and follow-on  
fixes), but now it emerges that there are still unfixed cases;  
moreover, these cases affect all branches not only pre-v14.  I thought  
we had eliminated all cases of making multiple clones of an UPDATE's  
target list when we nuked inheritance_planner.  But it turns out we  
still do that in some partitioned-UPDATE cases, notably including  
INSERT ... ON CONFLICT UPDATE, because ExecInitPartitionInfo thinks  
it's okay to clone and modify the parent's targetlist.  
  
This fix is based on a suggestion from Andres Freund: let's stop  
abusing the ParamExecData.execPlan mechanism, which was only ever  
meant to handle initplans, and instead solve the execution timing  
problem by having the expression compiler move MULTIEXPR_SUBLINK steps  
to the front of their expression step lists.  This is feasible because  
(a) all branches still in support compile the entire targetlist of  
an UPDATE into a single ExprState, and (b) we know that all  
MULTIEXPR_SUBLINKs do need to be evaluated --- none could be buried  
inside a CASE, for example.  There is a minor semantics change  
concerning the order of execution of the MULTIEXPR's subquery versus  
other parts of the parent targetlist, but that seems like something  
we can get away with.  By doing that, we no longer need to worry  
about whether different clones of a MULTIEXPR_SUBLINK share output  
Params; their usage of that data structure won't overlap.  
  
Per bug #17800 from Alexander Lakhin.  Back-patch to all supported  
branches.  In v13 and earlier, we can revert 3f7323cbb and follow-on  
fixes; however, I chose to keep the SubPlan.subLinkId field added  
in ccbb54c72.  We don't need that anymore in the core code, but it's  
cheap enough to fill, and removing a plan node field in a minor  
release seems like it'd be asking for trouble.  
  
Andres Freund and Tom Lane  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 79f194cc0144fad07fa18c4b2a5f32bce9035ee0    
  
author   : Dean Rasheed <[email protected]>    
date     : Sat, 25 Feb 2023 14:48:08 +0000    
  
committer: Dean Rasheed <[email protected]>    
date     : Sat, 25 Feb 2023 14:48:08 +0000    

If a rule action contains a subquery that refers to columns from OLD  
or NEW, then those are really lateral references, and the planner will  
complain if it sees such things in a subquery that isn't marked as  
lateral. However, at rule-definition time, the user isn't required to  
mark the subquery with LATERAL, and so it can fail when the rule is  
used.  
  
Fix this by marking such subqueries as lateral in the rewriter, at the  
point where they're used.  
  
Dean Rasheed and Tom Lane, per report from Alexander Lakhin.  
Back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/5e09da43-aaba-7ea7-0a51-a2eb981b058b%40gmail.com  

commit   : 44dbc960f6711e32118a8da71f251d65e0630caa    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 23 Feb 2023 15:40:28 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 23 Feb 2023 15:40:28 -0500    

Multiple cycles of starting up and shutting down the plugin within a  
single session would eventually lead to "out of relcache_callback_list  
slots", because pgoutput_startup blindly re-registered its cache  
callbacks each time.  Fix it to register them only once, as all other  
users of cache callbacks already take care to do.  
  
This has been broken all along, so back-patch to all supported branches.  
  
Shi Yu  
  
Discussion: https://postgr.es/m/OSZPR01MB631004A78D743D68921FFAD3FDA79@OSZPR01MB6310.jpnprd01.prod.outlook.com  

commit   : e68b133c30e2146b51c15be702f8954bc8fdb63b    
  
author   : Dean Rasheed <[email protected]>    
date     : Thu, 23 Feb 2023 10:58:43 +0000    
  
committer: Dean Rasheed <[email protected]>    
date     : Thu, 23 Feb 2023 10:58:43 +0000    

Given an updatable view with a DO ALSO INSERT ... SELECT rule, a  
multi-row INSERT ... VALUES query on the view fails if the VALUES list  
contains any DEFAULTs that are not replaced by view defaults. This  
manifests as an "unrecognized node type" error, or an Assert failure,  
in an assert-enabled build.  
  
The reason is that when RewriteQuery() attempts to replace the  
remaining DEFAULT items with NULLs in any product queries, using  
rewriteValuesRTEToNulls(), it assumes that the VALUES RTE is located  
at the same rangetable index in each product query. However, if the  
product query is an INSERT ... SELECT, then the VALUES RTE is actually  
in the SELECT part of that query (at the same index), rather than the  
top-level product query itself.  
  
Fix, by descending to the SELECT in such cases. Note that we can't  
simply use getInsertSelectQuery() for this, since that expects to be  
given a raw rule action with OLD and NEW placeholder entries, so we  
duplicate its logic instead.  
  
While at it, beef up the checks in getInsertSelectQuery() by checking  
that the jointree->fromlist node is indeed a RangeTblRef, and that the  
RTE it points to has rtekind == RTE_SUBQUERY.  
  
Per bug #17803, from Alexander Lakhin. Back-patch to all supported  
branches.  
  
Dean Rasheed, reviewed by Tom Lane.  
  
Discussion: https://postgr.es/m/17803-53c63ed4ecb4eac6%40postgresql.org  

commit   : 8de91ebf2ac1e9922214bf2976a2fcc5c045c169    
  
author   : Tomas Vondra <[email protected]>    
date     : Wed, 22 Feb 2023 15:24:09 +0100    
  
committer: Tomas Vondra <[email protected]>    
date     : Wed, 22 Feb 2023 15:24:09 +0100    

Whe decoding a transactional logical message, logicalmsg_decode called  
SnapBuildGetOrBuildSnapshot. But we may not have a consistent snapshot  
yet at that point. We don't actually need the snapshot in this case  
(during replay we'll have the snapshot from the transaction), so in  
practice this is harmless. But in assert-enabled build this crashes.  
  
Fixed by requesting the snapshot only in non-transactional case, where  
we are guaranteed to have SNAPBUILD_CONSISTENT.  
  
Backpatch to 11. The issue exists since 9.6.  
  
Backpatch-through: 11  
Reviewed-by: Andres Freund  
Discussion: https://postgr.es/m/[email protected]  

commit   : 83a54d9661027cbb0a97e543ce7440d55812c87c    
  
author   : Dean Rasheed <[email protected]>    
date     : Wed, 22 Feb 2023 13:29:39 +0000    
  
committer: Dean Rasheed <[email protected]>    
date     : Wed, 22 Feb 2023 13:29:39 +0000    

SPI_result_code_string() was missing support for SPI_OK_TD_REGISTER,  
and in v15 and later, it was missing support for SPI_OK_MERGE, as was  
pltcl_process_SPI_result().  
  
The last of those would trigger an error if a MERGE was executed from  
PL/Tcl. The others seem fairly innocuous, but worth fixing.  
  
Back-patch to all supported branches. Before v15, this is just adding  
SPI_OK_TD_REGISTER to SPI_result_code_string(), which is unlikely to  
be seen by anyone, but seems worth doing for completeness.  
  
Reviewed by Tom Lane.  
  
Discussion:  
  https://postgr.es/m/CAEZATCUg8V%2BK%2BGcafOPqymxk84Y_prXgfe64PDoopjLFH6Z0Aw%40mail.gmail.com  
  https://postgr.es/m/CAEZATCUMe%2B_KedPMM9AxKqm%3DSZogSxjUcrMe%2BsakusZh3BFcQw%40mail.gmail.com  

commit   : 21bd818d05fb24c6e48de95734acf5e572d18392    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 21 Feb 2023 18:47:47 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 21 Feb 2023 18:47:47 -0500    

If asked to decrease the size of a large (>8K) palloc chunk,  
AllocSetRealloc could improperly change the Valgrind state of memory  
beyond the new end of the chunk: it would mark data UNDEFINED as far  
as the old end of the chunk after having done the realloc(3) call,  
thus tromping on the state of memory that no longer belongs to it.  
One would normally expect that memory to now be marked NOACCESS,  
so that this mislabeling might prevent detection of later errors.  
If realloc() had chosen to move the chunk someplace else (unlikely,  
but well within its rights) we could also mismark perfectly-valid  
DEFINED data as UNDEFINED, causing false-positive valgrind reports  
later.  Also, any malloc bookkeeping data placed within this area  
might now be wrongly marked, causing additional problems.  
  
Fix by replacing relevant uses of "oldsize" with "Min(size, oldsize)".  
It's sufficient to mark as far as "size" when that's smaller, because  
whatever remains in the new chunk size will be marked NOACCESS below,  
and we expect realloc() to have taken care of marking the memory  
beyond the new official end of the chunk.  
  
While we're here, also rename the function's "oldsize" variable  
to "oldchksize" to more clearly explain what it actually holds,  
namely the distance to the end of the chunk (that is, requested size  
plus trailing padding).  This is more consistent with the use of  
"size" and "chksize" to hold the new requested size and chunk size.  
Add a new variable "oldsize" in the one stanza where we're actually  
talking about the old requested size.  
  
Oversight in commit c477f3e44.  Back-patch to all supported branches,  
as that was, just in case anybody wants to do valgrind testing on back  
branches.  
  
Karina Litskevich  
  
Discussion: https://postgr.es/m/CACiT8iaAET-fmzjjZLjaJC4zwSJmrFyL7LAdHwaYyjjQOQ4hcg@mail.gmail.com  

commit   : df931e9ab35bae8902035eac60e0edcbd8db8b3d    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 17 Feb 2023 16:40:34 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 17 Feb 2023 16:40:34 -0500    

ruleutils.c blindly printed the user-given alias (or nothing if there  
hadn't been one) for the target table of INSERT/UPDATE/DELETE queries.  
That works a large percentage of the time, but not always: for queries  
appearing in WITH, it's possible that we chose a different alias to  
avoid conflict with outer-scope names.  Since the chosen alias would  
be used in any Var references to the target table, this'd lead to an  
inconsistent printout with consequences such as dump/restore failures.  
  
The correct logic for printing (or not) a relation alias was embedded  
in get_from_clause_item.  Factor it out to a separate function so that  
we don't need a jointree node to use it.  (Only a limited part of that  
function can be reached from these new call sites, but this seems like  
the cleanest non-duplicative factorization.)  
  
In passing, I got rid of a redundant "\d+ rules_src" step in rules.sql.  
  
Initial report from Jonathan Katz; thanks to Vignesh C for analysis.  
This has been broken for a long time, so back-patch to all supported  
branches.  
  
Discussion: https://postgr.es/m/[email protected]  
Discussion: https://postgr.es/m/CALDaNm1MMntjmT_NJGp-Z=xbF02qHGAyuSHfYHias3TqQbPF2w@mail.gmail.com  

commit   : 88d606f7cc68aa753868ca92b0e065d77c5915d2    
  
author   : Michael Paquier <[email protected]>    
date     : Wed, 15 Feb 2023 10:12:40 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Wed, 15 Feb 2023 10:12:40 +0900    

OpenSSL 1.1.1 and newer versions have added support for RSA-PSS  
certificates, which requires the use of a specific routine in OpenSSL to  
determine which hash function to use when compiling it when using  
channel binding in SCRAM-SHA-256.  X509_get_signature_nid(), that is the  
original routine the channel binding code has relied on, is not able to  
determine which hash algorithm to use for such certificates.  However,  
X509_get_signature_info(), new to OpenSSL 1.1.1, is able to do it.  This  
commit switches the channel binding logic to rely on  
X509_get_signature_info() over X509_get_signature_nid(), which would be  
the choice when building with 1.1.1 or newer.  
  
The error could have been triggered on the client or the server, hence  
libpq and the backend need to have their related code paths patched.  
Note that attempting to load an RSA-PSS certificate with OpenSSL 1.1.0  
or older leads to a failure due to an unsupported algorithm.  
  
The discovery of relying on X509_get_signature_info() comes from Jacob,  
the tests have been written by Heikki (with few tweaks from me), while I  
have bundled the whole together while adding the bits needed for MSVC  
and meson.  
  
This issue exists since channel binding exists, so backpatch all the way  
down.  Some tests are added in 15~, triggered if compiling with OpenSSL  
1.1.1 or newer, where the certificate and key files can easily be  
generated for RSA-PSS.  
  
Reported-by: Gunnar "Nick" Bluth  
Author: Jacob Champion, Heikki Linnakangas  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 11  

commit   : 8d2a8581b6d67cfa05c1f47fa13de9815cdf91f6    
  
author   : David Rowley <[email protected]>    
date     : Mon, 13 Feb 2023 17:07:04 +1300    
  
committer: David Rowley <[email protected]>    
date     : Mon, 13 Feb 2023 17:07:04 +1300    

When an aggregate function is used as a WindowFunc and a tuple transitions  
out of the window frame, we ordinarily try to make use of the aggregate  
function's inverse transition function to "unaggregate" the exiting tuple.  
  
This optimization is disabled for various cases, including when the  
aggregate contains a volatile function.  In such a case we'd be unable to  
ensure that the transition value was calculated to the same value during  
transitions and inverse transitions.  Unfortunately, we did this check by  
calling contain_volatile_functions() which does not recursively search  
SubPlans for volatile functions.  If the aggregate function's arguments or  
its FILTER clause contained a subplan with volatile functions then we'd  
fail to notice this.  
  
Here we fix this by just disabling the optimization when the WindowFunc  
contains any subplans.  Volatile functions are not the only reason that a  
subplan may have nonrepeatable results.  
  
Bug: #17777  
Reported-by: Anban Company  
Discussion: https://postgr.es/m/17777-860b739b6efde977%40postgresql.org  
Reviewed-by: Tom Lane  
Backpatch-through: 11  

commit   : 36a646d99c3fb5262aff00fe7d3d40c2cdbb6d34    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 8 Feb 2023 17:15:23 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 8 Feb 2023 17:15:23 -0500    

It appears no longer possible to build the SGML docs without a local  
installation of the DocBook DTD, because sourceforge.net now only  
permits HTTPS access, and no common version of xsltproc supports that.  
Hence, remove the bits of our documentation suggesting that that's  
possible or useful.  
  
In fact, we might as well add the --nonet option to the build recipes  
automatically, for a bit of extra security.  
  
Also fix our documentation-tool-installation recipes for macOS to  
ensure that xmllint and xsltproc are pulled in from MacPorts or  
Homebrew.  The previous recipes assumed you could use the  
Apple-supplied versions of these tools; which still works, except that  
you'd need to set an environment variable to ensure that they would  
find DTD files provided by those package managers.  Simpler and easier  
to just recommend pulling in the additional packages.  
  
In HEAD, also document how to build docs using Meson, and adjust  
"ninja docs" to just build the HTML docs, for consistency with the  
default behavior of doc/src/sgml/Makefile.  
  
In a fit of neatnik-ism, I also made the ordering of the package  
lists match the order in which the tools are described at the head  
of the appendix.  
  
Aleksander Alekseev, Peter Eisentraut, Tom Lane  
  
Discussion: https://postgr.es/m/CAJ7c6TO8Aro2nxg=EQsVGiSDe-TstP4EsSvDHd7DSRsP40PgGA@mail.gmail.com  

commit   : cab553a08e2d7ba8be52a1871977fa6653ba5924    
  
author   : Peter Eisentraut <[email protected]>    
date     : Fri, 5 Jun 2020 11:18:11 +0200    
  
committer: Andrew Dunstan <[email protected]>    
date     : Fri, 5 Jun 2020 11:18:11 +0200    

backport of commit f0d2c65f17 to releases 11 and 12  
  
This means the SSL tests will fail on machines with extremely old  
versions of OpenSSL, but we don't know of anything trying to run such  
tests. The ability to build is not affected.  
  
Discussion: https://postgr.es/m/[email protected]