PostgreSQL 14.4 commit log

commit   : 164d174bbf9a3aba719c845497863cd3c49a3ad0    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 13 Jun 2022 16:04:05 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 13 Jun 2022 16:04:05 -0400    

commit   : cb31fc24b7283a663d1cfc760bb655a86a48b571    
  
author   : Peter Eisentraut <[email protected]>    
date     : Mon, 13 Jun 2022 07:32:39 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Mon, 13 Jun 2022 07:32:39 +0200    

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

commit   : 18f66a1a91bdc44dce2823faec9530dc14223234    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 10 Jun 2022 16:38:15 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 10 Jun 2022 16:38:15 -0400    

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

commit   : f25b5519c99a68324b147dad15b68b1a3bd378ad    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 10 Jun 2022 16:34:25 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 10 Jun 2022 16:34:25 -0400    

This reverts commits a04ccf6df et al. in the back branches only.  
There was some disagreement already over whether to back-patch  
157f8739a, on the grounds that it is the sort of behavioral  
change that we don't like to back-patch.  Furthermore, it now  
looks like the logic needs some more work, which we don't have  
time for before the upcoming 14.4 release.  Revert for now, and  
perhaps reconsider later.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 03fa84ac7c9239a18b7953d49acedd80f6aaccee    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 10 Jun 2022 13:47:19 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 10 Jun 2022 13:47:19 -0400    

commit   : 77c1d92cbac15f3c9c02f9a5b1ef551842659de6    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 10 Jun 2022 10:35:57 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 10 Jun 2022 10:35:57 -0400    

In commit ec62cb0aa, I foolishly replaced ExecEvalWholeRowVar's  
lookup_rowtype_tupdesc_domain call with just lookup_rowtype_tupdesc,  
because I didn't see how a domain could be involved there, and  
there were no regression test cases to jog my memory.  But the  
existing code was correct, so revert that change and add a test  
case showing why it's necessary.  (Note: per comment in struct  
DatumTupleFields, it is correct to produce an output tuple that's  
labeled with the base composite type, not the domain; hence just  
blindly looking through the domain is correct here.)  
  
Per bug #17515 from Dan Kubb.  Back-patch to v11 where domains over  
composites became a thing.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 0ccef410e4c35fd6a742091736b6fe1997eec6d3    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 8 Jun 2022 12:01:51 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 8 Jun 2022 12:01:51 -0400    

The patch introducing jsonpath dropped a para about that between  
two related examples, and didn't bother updating the introductory  
sentences that it falsified.  The grammar was pretty shaky as well.  

commit   : 804a5079220d48598ce15a16f76c5d2d0df923d1    
  
author   : Peter Eisentraut <[email protected]>    
date     : Wed, 8 Jun 2022 14:27:42 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Wed, 8 Jun 2022 14:27:42 +0200    

commit   : cbcea3b91dcd242473dfdc5464dcfb53dae2bdf4    
  
author   : David Rowley <[email protected]>    
date     : Wed, 8 Jun 2022 12:39:44 +1200    
  
committer: David Rowley <[email protected]>    
date     : Wed, 8 Jun 2022 12:39:44 +1200    

Bug #17512 highlighted that a suitably broken data type could cause the  
backend to crash if either the hash function or equality function were in  
someway non-deterministic based on their input values.  Such a data type  
could cause a crash of the backend due to some code which assumes that  
we'll always find a hash table entry corresponding to an item in the  
Memoize LRU list.  
  
Here we remove the assumption that we'll always find the entry  
corresponding to the given LRU list item and add run-time checks to verify  
we have found the given item in the cache.  
  
This is not a fix for bug #17512, but it will turn the crash reported by  
that bug report into an internal ERROR.  
  
Reported-by: Ales Zeleny  
Reviewed-by: Tom Lane  
Discussion: https://postgr.es/m/CAApHDvpxFSTwvoYWT7kmFVSZ9zLAeHb=S9vrz=RExMgSkQNWqw@mail.gmail.com  
Backpatch-through: 14, where Memoize was added.  

commit   : 5c3b5f7db6cee574488dfbb9462f0eb6090315b9    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 7 Jun 2022 15:34:30 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 7 Jun 2022 15:34:30 -0400    

pg_stat_get_subscription scanned one more LogicalRepWorker array entry  
than is really allocated.  In the worst case this could lead to SIGSEGV,  
if the LogicalRepCtx data structure is near the end of shared memory.  
That seems quite unlikely though (thanks to the ordering of calls in  
CreateSharedMemoryAndSemaphores) and we've heard no field reports of it.  
A more likely misbehavior is one row of garbage data in the function's  
result, but even that is not real likely because of the check that the  
pid field matches some live backend.  
  
Report and fix by Kuntal Ghosh.  This bug is old, so back-patch  
to all supported branches.  
  
Discussion: https://postgr.es/m/CAGz5QCJykEDzW6jQK6Yz7Qh_PMtD=95de_7QoocbVR2Qy8hWZA@mail.gmail.com  

commit   : 32a85ee46b034be7b8bf8f31b24cf6fe3684fe7f    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 6 Jun 2022 11:26:57 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 6 Jun 2022 11:26:57 -0400    

An error PGresult generated by libpq itself, such as a report of  
connection loss, won't have broken-down error fields.  
should_processing_continue() blithely assumed that  
PG_DIAG_SEVERITY_NONLOCALIZED would always be present, and would  
dump core if it wasn't.  
  
Per grepping to see if 6d157e7cb's mistake was repeated elsewhere.  

commit   : a5dbca460ace7e89a607d43e206973efaee0ed19    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 6 Jun 2022 11:20:21 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 6 Jun 2022 11:20:21 -0400    

An error PGresult generated by libpq itself, such as a report of  
connection loss, won't have broken-down error fields.  
ecpg_raise_backend() blithely assumed that PG_DIAG_MESSAGE_PRIMARY  
would always be present, and would end up passing a NULL string  
pointer to snprintf when it isn't.  That would typically crash  
before 3779ac62d, and it would fail to provide a useful error report  
in any case.  Best practice is to substitute PQerrorMessage(conn)  
in such cases, so do that.  
  
Per bug #17421 from Masayuki Hirose.  Back-patch to all supported  
branches.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : a04ccf6dfb4a15b9c279154b3366f8051de8b5d1    
  
author   : Michael Paquier <[email protected]>    
date     : Mon, 6 Jun 2022 11:07:22 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Mon, 6 Jun 2022 11:07:22 +0900    

psql --single-transaction is able to handle multiple -c and -f switches  
in a single transaction since d5563d7d, but this had the surprising  
behavior of forcing a transaction COMMIT even if psql failed with an  
error in the client (for example incorrect path given to \copy), which  
would generate an error, but still commit any changes that were already  
applied in the backend.  This commit makes the behavior more consistent,  
by enforcing a transaction ROLLBACK if any commands fail, both  
client-side and backend-side, so as no changes are applied if one error  
happens in any of them.  
  
Some tests are added on HEAD to provide some coverage about all that.  
Backend-side errors are unreliable as IPC::Run can complain on SIGPIPE  
if psql quits before reading a query result, but that should work  
properly in the case where any errors come from psql itself, which is  
what the original report is about.  
  
Reported-by: Christoph Berg  
Author: Kyotaro Horiguchi, Michael Paquier  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 10  

commit   : c1ad8047a2c22f841e4e3df39696febeb7167e6c    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 3 Jun 2022 13:54:53 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 3 Jun 2022 13:54:53 -0400    

The previous entry invited confusion between what uniq() does  
by itself and what it does when combined with sort().  The latter  
usage is pretty useful so we should show it, but add an additional  
example to clarify the results of uniq() alone.  
  
Per suggestion from Martin Kalcher.  Back-patch to v13, where  
we switched to formatting that supports multiple examples.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 2223c2a7c4403e71c2553c313e958503084077f3    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 3 Jun 2022 11:51:37 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 3 Jun 2022 11:51:37 -0400    

Will Mortensen (minor additional copy-editing by me)  
  
Discussion: https://postgr.es/m/CAMpnoC5Y6jiZHSA82FG+e_AqkwMg-i94EYqs1C_9kXXFc3_3Yw@mail.gmail.com  

commit   : 18e3b197bc6a4d957a92b3540b7afcc07a9e7f29    
  
author   : Etsuro Fujita <[email protected]>    
date     : Thu, 2 Jun 2022 18:00:02 +0900    
  
committer: Etsuro Fujita <[email protected]>    
date     : Thu, 2 Jun 2022 18:00:02 +0900    

This patch fixes the partitioning synopsis in the Parameters section in  
the CREATE FOREIGN TABLE documentation.  Follow-up for commit ce21a36cf.  
  
Back-patch to v11 where default partition was introduced.  
  
Reviewed by Amit Langote and Robert Haas.  
  
Discussion: https://postgr.es/m/CAPmGK17U5jEqVZuo3r38wB0VFWomEtJCBGn_h92HQzQ2sP-49Q%40mail.gmail.com  

commit   : 4e467261560f087e0c75452646695a4edbb09de7    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 1 Jun 2022 17:21:45 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 1 Jun 2022 17:21:45 -0400    

Since a117cebd6, some older gcc versions issue "variable may be used  
uninitialized in this function" complaints for brin_summarize_range.  
Silence that using the same coding pattern as in bt_index_check_internal;  
arguably, a117cebd6 had too narrow a view of which compilers might give  
trouble.  
  
Nathan Bossart and Tom Lane.  Back-patch as the previous commit was.  
  
Discussion: https://postgr.es/m/20220601163537.GA2331988@nathanxps13  

commit   : 1072e4c45dc3e4a9a62b34087414627b307e10f6    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 1 Jun 2022 16:15:47 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 1 Jun 2022 16:15:47 -0400    

Perl 5.36 has reclassified the warning condition that this test  
case used, so that the expected error fails to appear.  Tweak  
the test so it instead exercises a case that's handled the same  
way in all Perl versions of interest.  
  
This appears to meet our standards for back-patching into  
out-of-support branches: it changes no user-visible behavior  
but enables testing of old branches with newer tools.  
Hence, back-patch as far as 9.2.  
  
Dagfinn Ilmari Mannsåker, per report from Jitka Plesníková.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 80cd99c55802d4e4517049dea341ccb356cfa3ba    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 1 Jun 2022 10:39:46 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 1 Jun 2022 10:39:46 -0400    

The example given for anyelement <@ anymultirange didn't return  
true as claimed; adjust it so it does.  
  
In passing, change a couple of sample results where the modern  
numeric-based logic produces a different number of trailing zeroes  
than before.  
  
Erik Rijkers  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : f2a0060a9bfb7a6f257a536de5ea2d4f7cedff03    
  
author   : David Rowley <[email protected]>    
date     : Wed, 1 Jun 2022 12:46:18 +1200    
  
committer: David Rowley <[email protected]>    
date     : Wed, 1 Jun 2022 12:46:18 +1200    

The PostgreSQL limitations section of the documents mentioned the limit  
on the number of columns that can exist in a table.  Users might be  
surprised to find that there's also a limit on the number of columns that  
can exist in a targetlist.  Users may experience restrictions which  
surprise them if they happened to select a large number of columns from  
several tables with many columns.  Here we document that there is a  
limitation on this and mention what that limit actually is.  
  
Wording proposal by Alvaro Herrera  
  
Reported-by: Vladimir Sitnikov  
Author: Dave Crammer  
Reviewed-by: Tom Lane  
Discussion: https://postgr.es/m/CAB=Je-E18aTYpNqje4mT0iEADpeGLSzwUvo3H9kRRuDdsNo4aQ@mail.gmail.com  
Backpatch-through: 12, where the limitations section was added  

commit   : a694cf4ca496a7db66a61f6ec2a15a9af6493cef    
  
author   : Magnus Hagander <[email protected]>    
date     : Tue, 31 May 2022 21:59:47 +0200    
  
committer: Magnus Hagander <[email protected]>    
date     : Tue, 31 May 2022 21:59:47 +0200    

PostgreSQL 14 changed the default to be scram-sha-256, so we should stop  
recommending the user to use md5 or even worse password.  
  
Suggested-By: Daniel Westermann  
Author: Jonathan S. Katz  
Backpatch-through: 14  
Discussion: https://postgr.es/m/GV0P278MB0419A8BAC0B0B84AFA5263D9D2DC9@GV0P278MB0419.CHEP278.PROD.OUTLOOK.COM  

commit   : 042b584c7f7d6216c54359c0ee0f613ba3b3d9c2    
  
author   : Alvaro Herrera <[email protected]>    
date     : Tue, 31 May 2022 21:24:59 +0200    
  
committer: Alvaro Herrera <[email protected]>    
date     : Tue, 31 May 2022 21:24:59 +0200    

This reverts commit d9d076222f5b "VACUUM: ignore indexing operations  
with CONCURRENTLY".  
  
These changes caused indexes created with the CONCURRENTLY option to  
miss heap tuples that were HOT-updated and HOT-pruned during the index  
creation.  Before these changes, HOT pruning would have been prevented  
by the Xmin of the transaction creating the index, but because this  
change was precisely to allow the Xmin to move forward ignoring that  
backend, now other backends scanning the table can prune them.  This is  
not a problem for VACUUM (which requires a lock that conflicts with a  
CREATE INDEX CONCURRENTLY operation), but HOT-prune can definitely  
occur.  In other words, Xmin advancement was sped up, but at the cost of  
corrupting the resulting index.  
  
Regrettably, this means that the new feature in PG14 that RIC/CIC on  
very large tables no longer force VACUUM to retain very old tuples goes  
away.  We might try to implement it again in a later release, but for  
now the risk of indexes missing tuples is too high and there's no easy  
fix.  
  
Backpatch to 14, where this change appeared.  
  
Reported-by: Peter Slavov <[email protected]>  
Diagnosys-by: Andrey Borodin <[email protected]>  
Diagnosys-by: Michael Paquier <[email protected]>  
Diagnosys-by: Andres Freund <[email protected]>  
Discussion: https://postgr.es/m/17485-396609c6925b982d%40postgresql.org  

commit   : c47a558528dd79fe76c698cde7e23f38610b05ed    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 31 May 2022 14:47:44 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 31 May 2022 14:47:44 -0400    

We hadn't noticed this because (a) few people feed invalid  
timezone abbreviation files to the server, and (b) in typical  
scenarios guc.c would throw ereport(ERROR) and then transaction  
abort handling would silently clean up the leaked file reference.  
However, it was possible to observe file leakage warnings if one  
breaks an already-active abbreviation file, because guc.c does  
not throw ERROR when loading supposedly-validated settings during  
session start or SIGHUP processing.  
  
Report and fix by Kyotaro Horiguchi (cosmetic adjustments by me)  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : a18b2a3fbcf16998faeb35fc2341708983769841    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 31 May 2022 12:14:02 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 31 May 2022 12:14:02 -0400    

runtime.sgml contains a passing reference to the minimum server  
version that pg_dump[all] can dump from.  That was 7.0 for many  
years, but when 64f3524e2 raised it to 8.0, we missed updating this  
bit.  Then when 30e7c175b raised it to 9.2, we missed it again.  
  
Given that track record, I'm not too hopeful that we'll remember  
to fix this in future changes ... but for now, make the docs match  
reality in each branch.  
  
Noted by Daniel Westermann.  
  
Discussion: https://postgr.es/m/GV0P278MB041917EB3E2FE8704B5AE2C6D2DC9@GV0P278MB0419.CHEP278.PROD.OUTLOOK.COM  

commit   : 0adff38da4bc88bcbcc07641ddc04180fe183188    
  
author   : Michael Paquier <[email protected]>    
date     : Mon, 30 May 2022 10:50:32 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Mon, 30 May 2022 10:50:32 +0900    

The information generated when track_activities is accessible to  
superusers, roles with the privileges of pg_read_all_stats, as well as  
roles one has the privileges of.  The original text did not outline the  
last point, while the change done in ac1ae47 was unclear about the  
second point.  
  
Per discussion with Nathan Bossart.  
  
Discussion: https://postgr.es/m/20220521185743.GA886636@nathanxps13  
Backpatch-through: 10  

commit   : f82595ac903e4e4062d909e73693dd809c6845c0    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Sun, 29 May 2022 23:53:45 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Sun, 29 May 2022 23:53:45 +0300    

In the codepath when no encoding conversion is required, the check for  
incomplete character at the end of input incorrectly used server  
encoding's max character length, instead of the client's. Usually the  
server and client encodings are the same when we're not performing  
encoding conversion, but SQL_ASCII is an exception.  
  
In the passing, also fix some outdated comments that still talked about  
the old COPY protocol. It was removed in v14.  
  
Per bug #17501 from Vitaly Voronov. Backpatch to v14 where this was  
introduced.  
  
Discussion: https://www.postgresql.org/message-id/[email protected]  

commit   : 9f2d1946d4b41a27cb5b62da7a5f070acc62cd4e    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 29 May 2022 13:25:21 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 29 May 2022 13:25:21 -0400    

The form taking anymultirange had not been documented.  This was  
fixed in HEAD in b21c4cf95, but that should have been back-patched  
to v14 since the function was added there.  Do so now.  
  
Also, the form taking anyrange was incorrectly documented as  
returning anymultirange, when it returns anyrange.  
  
Remove b21c4cf95 from the v15 release notes, since it no longer  
qualifies as new-in-v15.  
  
Noted by Shay Rojansky.  
  
Discussion: https://postgr.es/m/CADT4RqAktzP7t6SFf0Xqm9YhahzvsmxFbzXe-gFOd=+_CHm0JA@mail.gmail.com  

commit   : fe441a0319405a52e773e8f3750e925ecc5d86eb    
  
author   : Michael Paquier <[email protected]>    
date     : Sat, 28 May 2022 12:12:46 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Sat, 28 May 2022 12:12:46 +0900    

If a short description is specified as NULL in one of the various  
DefineCustomXXXVariable() functions available to external modules to  
define a custom parameter, SHOW ALL would crash.  This change teaches  
SHOW ALL to properly handle NULL short descriptions, as well as any code  
paths that manipulate it, to gain in flexibility.  Note that  
help_config.c was already able to do that, when describing a set of GUCs  
for postgres --describe-config.  
  
Author: Steve Chavez  
Reviewed by: Nathan Bossart, Andres Freund, Michael Paquier, Tom Lane  
Discussion: https://postgr.es/m/CAGRrpzY6hO-Kmykna_XvsTv8P2DshGiU6G3j8yGao4mk0CqjHA%40mail.gmail.com  
Backpatch-through: 10  

commit   : b4be4a082bde8b4f3caca6fa3127af005720f2d8    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 26 May 2022 14:14:05 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 26 May 2022 14:14:05 -0400    

Commits a59c79564 et al. tried to sync libpq's SSL key file  
permissions checks with what we've used for years in the backend.  
We did not intend to create any new failure cases, but it turns out  
we did: restricting the key file's ownership breaks cases where the  
client is allowed to read a key file despite not having the identical  
UID.  In particular a client running as root used to be able to read  
someone else's key file; and having seen that I suspect that there are  
other, less-dubious use cases that this restriction breaks on some  
platforms.  
  
We don't really need an ownership check, since if we can read the key  
file despite its having restricted permissions, it must have the right  
ownership --- under normal conditions anyway, and the point of this  
patch is that any additional corner cases where that works should be  
deemed allowable, as they have been historically.  Hence, just drop  
the ownership check, and rearrange the permissions check to get rid  
of its faulty assumption that geteuid() can't be zero.  (Note that the  
comparable backend-side code doesn't have to cater for geteuid() == 0,  
since the server rejects that very early on.)  
  
This does have the end result that the permissions safety check used  
for a root user's private key file is weaker than that used for  
anyone else's.  While odd, root really ought to know what she's doing  
with file permissions, so I think this is acceptable.  
  
Per report from Yogendra Suralkar.  Like the previous patch,  
back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/MW3PR15MB3931DF96896DC36D21AFD47CA3D39@MW3PR15MB3931.namprd15.prod.outlook.com  

commit   : a5fc06bf31352fc57cb34ccbf2ca18214118ab9b    
  
author   : Robert Haas <[email protected]>    
date     : Thu, 26 May 2022 12:54:57 -0400    
  
committer: Robert Haas <[email protected]>    
date     : Thu, 26 May 2022 12:54:57 -0400    

Foreign tables can be partitioned, but previous documentation commits  
left the syntax synopsis both incomplete and incorrect.  
  
Justin Pryzby and Amit Langote  
  
Discussion: http://postgr.es/m/[email protected]  

commit   : 6f7eec1193f8ddafb6d7ff495d3ce2eb01202a86    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 21 May 2022 14:45:58 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 21 May 2022 14:45:58 -0400    

ruleutils.c was coded to suppress the AS label for a SELECT output  
expression if the column name is "?column?", which is the parser's  
fallback if it can't think of something better.  This is fine, and  
avoids ugly clutter, so long as (1) nothing further up in the parse  
tree relies on that column name or (2) the same fallback would be  
assigned when the rule or view definition is reloaded.  Unfortunately  
(2) is far from certain, both because ruleutils.c might print the  
expression in a different form from how it was originally written  
and because FigureColname's rules might change in future releases.  
So we shouldn't rely on that.  
  
Detecting exactly whether there is any outer-level use of a SELECT  
column name would be rather expensive.  This patch takes the simpler  
approach of just passing down a flag indicating whether there *could*  
be any outer use; for example, the output column names of a SubLink  
are not referenceable, and we also do not care about the names exposed  
by the right-hand side of a setop.  This is sufficient to suppress  
unwanted clutter in all but one case in the regression tests.  That  
seems like reasonable evidence that it won't be too much in users'  
faces, while still fixing the cases we need to fix.  
  
Per bug #17486 from Nicolas Lutic.  This issue is ancient, so  
back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 7f798e89367878c0637d6152365b7452b052f3d5    
  
author   : Michael Paquier <[email protected]>    
date     : Sat, 21 May 2022 19:05:54 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Sat, 21 May 2022 19:05:54 +0900    

The description of track_activities mentioned that it is visible to  
superusers and that the information related to the current session can  
be seen, without telling about pg_read_all_stats.  Roles that are  
granted the privileges of pg_read_all_stats can also see this  
information, so mention it in the docs.  
  
Author: Ian Barwick  
Reviewed-by: Nathan Bossart  
Discussion: https://postgr.es/m/CAB8KJ=jhPyYFu-A5r-ZGP+Ax715mUKsMxAGcEQ9Cx_mBAmrPow@mail.gmail.com  
Backpatch-through: 10  

commit   : 58b088a9b3c2ec19998a3822190afdd6af847efe    
  
author   : Alvaro Herrera <[email protected]>    
date     : Fri, 20 May 2022 18:52:55 +0200    
  
committer: Alvaro Herrera <[email protected]>    
date     : Fri, 20 May 2022 18:52:55 +0200    

When an implicit operator family is created, it wasn't getting reported.  
Make it do so.  
  
This has always been missing.  Backpatch to 10.  
  
Author: Masahiko Sawada <[email protected]>  
Reported-by: Leslie LEMAIRE <[email protected]>  
Reviewed-by: Amit Kapila <[email protected]>  
Reviewed-by: Michael Paquiër <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  

commit   : aa783575294f6e3579b9c78a75d54a693f010213    
  
author   : Alvaro Herrera <[email protected]>    
date     : Fri, 20 May 2022 10:05:31 +0200    
  
committer: Alvaro Herrera <[email protected]>    
date     : Fri, 20 May 2022 10:05:31 +0200    

It wasn't previously mentioned that the index is created as invalid,  
which is confusing to new users.  
  
Backpatch to 14 (only because of a conflict in 13).  
  
Author: Laurenz Albe <[email protected]>  
Reported-by: Lauren Fliksteen <[email protected]>  
Reviewed-by: Rajakavitha Kodhandapani <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  

commit   : 3a8d83cae35e887be0011fa6139c83423037bc67    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 19 May 2022 18:36:07 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 19 May 2022 18:36:07 -0400    

The documentation didn't specify the name of the per-user service file  
on Windows, and extrapolating from the pattern used for other config  
files gave the wrong answer.  The fact that it isn't consistent with the  
others sure seems like a bug, but it's far too late to change that now;  
we'd just penalize people who worked it out in the past.  So, simply  
document the true state of affairs.  
  
In passing, fix some gratuitous differences between the discussions  
of the service file and the password file.  
  
Julien Rouhaud, per question from Dominique Devienne.  
  
Backpatch to all supported branches.  I (tgl) also chose to back-patch  
the part of commit ba356a397 that touched libpq.sgml's description of  
the service file --- in hindsight, I'm not sure why I didn't do so at  
the time, as it includes some fairly essential information.  
  
Discussion: https://postgr.es/m/CAFCRh-_mdLrh8eYVzhRzu4c8bAFEBn=rwoHOmFJcQOTsCy5nig@mail.gmail.com  

commit   : 8d9d1286acf9f209243cbcddc53cc4c875a90e20    
  
author   : Alvaro Herrera <[email protected]>    
date     : Thu, 19 May 2022 16:20:32 +0200    
  
committer: Alvaro Herrera <[email protected]>    
date     : Thu, 19 May 2022 16:20:32 +0200    

This is a slight, convenient semantics change from what commit  
0f0cfb494004 ("Fix parallel operations that prevent oldest xmin from  
advancing") introduced that lets us simplify the coding in the one place  
where it is used.  
  
Backpatch to 13.  This is related to commit 6fea65508a1a ("Tighten  
ComputeXidHorizons' handling of walsenders") rewriting the code site  
where this is used, which has not yet been backpatched, but it may well  
be in the future.  
  
Reviewed-by: Masahiko Sawada <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  

commit   : 3f712ea6dc40a0c9d5cf96907655343039601473    
  
author   : David Rowley <[email protected]>    
date     : Thu, 19 May 2022 17:14:56 +1200    
  
committer: David Rowley <[email protected]>    
date     : Thu, 19 May 2022 17:14:56 +1200    

Reported-by: Peter Eisentraut  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 14, where Memoize was added  

commit   : e8b93c6e2810306887dc8477aab88ae08cf335f9    
  
author   : Alvaro Herrera <[email protected]>    
date     : Wed, 18 May 2022 23:19:53 +0200    
  
committer: Alvaro Herrera <[email protected]>    
date     : Wed, 18 May 2022 23:19:53 +0200    

Commit 0fbf01120023 should have updated them but didn't.  

commit   : 94edb85d253e5ae066481e4e369ad9e35dea41b5    
  
author   : Alvaro Herrera <[email protected]>    
date     : Wed, 18 May 2022 20:28:31 +0200    
  
committer: Alvaro Herrera <[email protected]>    
date     : Wed, 18 May 2022 20:28:31 +0200    

We weren't checking the length of the column list in the alias clause of  
an XMLTABLE or JSON_TABLE function (a "tablefunc" RTE), and it was  
possible to make the server crash by passing an overly long one.  Fix it  
by throwing an error in that case, like the other places that deal with  
alias lists.  
  
In passing, modify the equivalent test used for join RTEs to look like  
the other ones, which was different for no apparent reason.  
  
This bug came in when XMLTABLE was born in version 10; backpatch to all  
stable versions.  
  
Reported-by: Wang Ke <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  

commit   : 23c2b76a8322233ce0b2c135c10ad52d48a4a22b    
  
author   : David Rowley <[email protected]>    
date     : Mon, 16 May 2022 16:08:37 +1200    
  
committer: David Rowley <[email protected]>    
date     : Mon, 16 May 2022 16:08:37 +1200    

In order to estimate the cache hit ratio of a Memoize node, one of the  
inputs we require is the estimated number of times the Memoize node will  
be rescanned.  The higher this number, the large the cache hit ratio is  
likely to become.  Unfortunately, the value being passed as the number of  
"calls" to the Memoize was incorrectly using the Nested Loop's  
outer_path->parent->rows instead of outer_path->rows.  This failed to  
account for the fact that the outer_path might be parameterized by some  
upper-level Nested Loop.  
  
This problem could lead to Memoize plans appearing more favorable than  
they might actually be.  It could also lead to extended executor startup  
times when work_mem values were large due to the planner setting overly  
large MemoizePath->est_entries resulting in the Memoize hash table being  
initially made much larger than might be required.  
  
Fix this simply by passing outer_path->rows rather than  
outer_path->parent->rows.  Also, adjust the expected regression test  
output for a plan change.  
  
Reported-by: Pavel Stehule  
Author: David Rowley  
Discussion: https://postgr.es/m/CAFj8pRAMp%3DQsMi6sPQJ4W3hczoFJRvyXHJV3AZAZaMyTVM312Q%40mail.gmail.com  
Backpatch-through: 14, where Memoize was introduced  

commit   : 6dced63b411b920f7d0296337e4b3c8cba3e2e30    
  
author   : Michael Paquier <[email protected]>    
date     : Mon, 16 May 2022 11:26:22 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Mon, 16 May 2022 11:26:22 +0900    

If a cluster is promoted (aka the control file shows a state different  
than DB_IN_ARCHIVE_RECOVERY) while CreateRestartPoint() is still  
processing, this function could miss an update of the control file for  
"checkPoint" and "checkPointCopy" but still do the recycling and/or  
removal of the past WAL segments, assuming that the to-be-updated LSN  
values should be used as reference points for the cleanup.  This causes  
a follow-up restart attempting crash recovery to fail with a PANIC on a  
missing checkpoint record if the end-of-recovery checkpoint triggered by  
the promotion did not complete while the cluster abruptly stopped or  
crashed before the completion of this checkpoint.  The PANIC would be  
caused by the redo LSN referred in the control file as located in a  
segment already gone, recycled by the previous restartpoint with  
"checkPoint" out-of-sync in the control file.  
  
This commit fixes the update of the control file during restartpoints so  
as "checkPoint" and "checkPointCopy" are updated even if the cluster has  
been promoted while a restartpoint is running, to be on par with the set  
of WAL segments actually recycled in the end of CreateRestartPoint().  
  
7863ee4 has fixed this problem already on master, but the release timing  
of the latest point versions did not let me enough time to study and fix  
that on all the stable branches.  
  
Reported-by: Fujii Masao, Rui Zhao  
Author: Kyotaro Horiguchi  
Reviewed-by: Nathan Bossart, Michael Paquier  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 10  

commit   : ac51c9fba5a796ff434c0a7e05a5fd081690b21c    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 12 May 2022 11:31:46 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 12 May 2022 11:31:46 -0400    

This follows in the footsteps of commit 2591ee8ec by removing one more  
ill-advised shortcut from planning of GroupingFuncs.  It's true that  
we don't intend to execute the argument expression(s) at runtime, but  
we still have to process any Vars appearing within them, or we risk  
failure at setrefs.c time (or more fundamentally, in EXPLAIN trying  
to print such an expression).  Vars in upper plan nodes have to have  
referents in the next plan level, whether we ever execute 'em or not.  
  
Per bug #17479 from Michael J. Sullivan.  Back-patch to all supported  
branches.  
  
Richard Guo  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : d6da71fa8f28faa68823e163f318ffb38a7a9a54    
  
author   : Amit Kapila <[email protected]>    
date     : Wed, 11 May 2022 10:51:04 +0530    
  
committer: Amit Kapila <[email protected]>    
date     : Wed, 11 May 2022 10:51:04 +0530    

The problem is that we don't send keep-alive messages for a long time  
while processing large transactions during logical replication where we  
don't send any data of such transactions. This can happen when the table  
modified in the transaction is not published or because all the changes  
got filtered. We do try to send the keep_alive if necessary at the end of  
the transaction (via WalSndWriteData()) but by that time the  
subscriber-side can timeout and exit.  
  
To fix this we try to send the keepalive message if required after  
processing certain threshold of changes.  
  
Reported-by: Fabrice Chapuis  
Author: Wang wei and Amit Kapila  
Reviewed By: Masahiko Sawada, Euler Taveira, Hou Zhijie, Hayato Kuroda  
Backpatch-through: 10  
Discussion: https://postgr.es/m/CAA5-nLARN7-3SLU_QUxfy510pmrYK6JJb=bk3hcgemAM_pAv+w@mail.gmail.com  

commit   : ca9e9b08e453523314a3b8e87d1894edb23b6e8d    
  
author   : Michael Paquier <[email protected]>    
date     : Wed, 11 May 2022 10:22:29 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Wed, 11 May 2022 10:22:29 +0900    

The current setup assumes that commands for lz4, zstd and gzip always  
exist by default if not enforced by a user's environment.  However,  
vcpkg, as one example, installs libraries but no binaries, so this  
default setup to assume that a command should always be present would  
cause failures.  This commit improves the detection of such external  
commands as follows:  
* If a ENV value is available, trust the environment/user and use it.  
* If a ENV value is not available, check its execution by looking in the  
current PATH, by launching a simple "$command --version" (that should be  
portable enough).  
** On execution failure, ignore ENV{command}.  
** On execution success, set ENV{command} = "$command".  
  
Note that this new rule applies to gzip, lz4 and zstd but not tar that  
we assume will always exist.  Those commands are set up in the  
environment only when using bincheck and taptest.  The CI includes all  
those commands and I have checked that their setup is correct there.  I  
have also tested this change in a MSVC environment where we have none of  
those commands.  
  
While on it, remove the references to lz4 from the documentation and  
vcregress.pl in ~v13.  --with-lz4 has been added in v14~ so there is no  
point to have this information in these older branches.  
  
Reported-by: Andrew Dunstan  
Reviewed-by: Andrew Dunstan  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 10  

commit   : 12736e7dc326c404ae0f12ebdf5d1dbb954ec5f6    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 10 May 2022 18:42:02 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 10 May 2022 18:42:02 -0400    

In OpenLDAP 2.5 and later, libldap itself is always thread-safe and  
there's never a libldap_r.  Our existing coding dealt with that  
by assuming it wouldn't find libldap_r if libldap is thread-safe.  
But that rule fails to cope if there are multiple OpenLDAP versions  
visible, as is likely to be the case on macOS in particular.  We'd  
end up using shiny new libldap in the backend and a hoary libldap_r  
in libpq.  
  
Instead, once we've found libldap, check if it's >= 2.5 (by  
probing for a function introduced then) and don't bother looking  
for libldap_r if so.  While one can imagine library setups that  
this'd still give the wrong answer for, they seem unlikely to  
occur in practice.  
  
Per report from Peter Eisentraut.  Back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/[email protected]