PostgreSQL 9.6.24 commit log

commit   : a4116b8d5a4f68803452d8f1aa3f74f302049a90    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 8 Nov 2021 17:07:24 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 8 Nov 2021 17:07:24 -0500    

commit   : cace98d76cab8882125f6fbbe919f789fe2b9ee3    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 8 Nov 2021 14:02:16 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 8 Nov 2021 14:02:16 -0500    

Security: CVE-2021-23214, CVE-2021-23222  

commit   : d83cdfdca9d918bbbd6bb209139b94c954da7228    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 8 Nov 2021 11:14:57 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 8 Nov 2021 11:14:57 -0500    

libpq collects up to a bufferload of data whenever it reads data from  
the socket.  When SSL or GSS encryption is requested during startup,  
any additional data received with the server's yes-or-no reply  
remained in the buffer, and would be treated as already-decrypted data  
once the encryption handshake completed.  Thus, a man-in-the-middle  
with the ability to inject data into the TCP connection could stuff  
some cleartext data into the start of a supposedly encryption-protected  
database session.  
  
This could probably be abused to inject faked responses to the  
client's first few queries, although other details of libpq's behavior  
make that harder than it sounds.  A different line of attack is to  
exfiltrate the client's password, or other sensitive data that might  
be sent early in the session.  That has been shown to be possible with  
a server vulnerable to CVE-2021-23214.  
  
To fix, throw a protocol-violation error if the internal buffer  
is not empty after the encryption handshake.  
  
Our thanks to Jacob Champion for reporting this problem.  
  
Security: CVE-2021-23222  

commit   : 046c2c846b741a12e7fd61d8d86bf324a20e3dfc    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 8 Nov 2021 11:01:43 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 8 Nov 2021 11:01:43 -0500    

The server collects up to a bufferload of data whenever it reads data  
from the client socket.  When SSL or GSS encryption is requested  
during startup, any additional data received with the initial  
request message remained in the buffer, and would be treated as  
already-decrypted data once the encryption handshake completed.  
Thus, a man-in-the-middle with the ability to inject data into the  
TCP connection could stuff some cleartext data into the start of  
a supposedly encryption-protected database session.  
  
This could be abused to send faked SQL commands to the server,  
although that would only work if the server did not demand any  
authentication data.  (However, a server relying on SSL certificate  
authentication might well not do so.)  
  
To fix, throw a protocol-violation error if the internal buffer  
is not empty after the encryption handshake.  
  
Our thanks to Jacob Champion for reporting this problem.  
  
Security: CVE-2021-23214  

commit   : 9b6194eb0aa5af1bc8ffba5ff95d0d1e5a9649b0    
  
author   : Alvaro Herrera <[email protected]>    
date     : Mon, 8 Nov 2021 08:52:48 -0300    
  
committer: Alvaro Herrera <[email protected]>    
date     : Mon, 8 Nov 2021 08:52:48 -0300    

Introduced in e0eaeafd6646.  
  
Co-authored-by: Alexander Lakhin <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  

commit   : 374a667bdbd870f8264336098f8270f52f03f215    
  
author   : Peter Eisentraut <[email protected]>    
date     : Mon, 8 Nov 2021 10:09:09 +0100    
  
committer: Peter Eisentraut <[email protected]>    
date     : Mon, 8 Nov 2021 10:09:09 +0100    

Source-Git-URL: git://git.postgresql.org/git/pgtranslation/messages.git  
Source-Git-Hash: 2696e7f8ab74ef8b03f4be7595aabe4dfbdd7240  

commit   : 492a1a94bf59f187de2a09fe3ebfedae2bc6cff1    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 7 Nov 2021 14:21:51 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 7 Nov 2021 14:21:51 -0500    

commit   : 7381b79ade479de5038ad924fbff1c584a0d6fee    
  
author   : Alexander Korotkov <[email protected]>    
date     : Sat, 6 Nov 2021 18:31:21 +0300    
  
committer: Alexander Korotkov <[email protected]>    
date     : Sat, 6 Nov 2021 18:31:21 +0300    

Currently, lastOverflowedXid is never reset.  It's just adjusted on new  
transactions known to be overflowed.  But if there are no overflowed  
transactions for a long time, snapshots could be mistakenly marked as  
suboverflowed due to wraparound.  
  
This commit fixes this issue by resetting lastOverflowedXid when needed  
altogether with KnownAssignedXids.  
  
Backpatch to all supported versions.  
  
Reported-by: Stan Hu  
Discussion: https://postgr.es/m/CAMBWrQ%3DFp5UAsU_nATY7EMY7NHczG4-DTDU%3DmCvBQZAQ6wa2xQ%40mail.gmail.com  
Author: Kyotaro Horiguchi, Alexander Korotkov  
Reviewed-by: Stan Hu, Simon Riggs, Nikolay Samokhvalov, Andrey Borodin, Dmitry Dolgov  

commit   : e0eaeafd66462b1a584831f35f10ec1e017c3845    
  
author   : Alvaro Herrera <[email protected]>    
date     : Fri, 5 Nov 2021 12:29:35 -0300    
  
committer: Alvaro Herrera <[email protected]>    
date     : Fri, 5 Nov 2021 12:29:35 -0300    

When a role being dropped contains is referenced by catalog objects that  
are concurrently also being dropped, a crash can result while trying to  
construct the string that describes the objects.  Suppress that by  
ignoring objects whose descriptions are returned as NULL.  
  
The majority of relevant codesites were already cautious about this  
already; we had just missed a couple.  
  
This is an old bug, so backpatch all the way back.  
  
Reported-by: Alexander Lakhin <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  

commit   : 71aeaf245b237bc7c3cfceb4bbbe7a8489da82fb    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Wed, 3 Nov 2021 19:38:17 +0200    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Wed, 3 Nov 2021 19:38:17 +0200    

Previous commit added a test to 'largeobject', but neglected the  
alternative expected output file 'largeobject_1.source'. Per failure  
on buildfarm animal 'hamerkop'.  
  
Discussion: https://www.postgresql.org/message-id/[email protected]  

commit   : 8f32afee0179b2050bb1f84ba16fd1d4fba9a3b8    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Wed, 3 Nov 2021 11:09:08 +0200    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Wed, 3 Nov 2021 11:09:08 +0200    

If lo_export() fails to open the target file or to write to it, it leaks  
the created LargeObjectDesc and its snapshot in the top-transaction  
context and resource owner. That's pretty harmless, it's a small leak  
after all, but it gives the user a "Snapshot reference leak" warning.  
  
Fix by using a short-lived memory context and no resource owner for  
transient LargeObjectDescs that are opened and closed within one function  
call. The leak is easiest to reproduce with lo_export() on a directory  
that doesn't exist, but in principle the other lo_* functions could also  
fail.  
  
Backpatch to all supported versions.  
  
Reported-by: Andrew B  
Reviewed-by: Alvaro Herrera  
Discussion: https://www.postgresql.org/message-id/[email protected]  

commit   : 99197701e57d5444405a0690c49f4712cf99e040    
  
author   : Alvaro Herrera <[email protected]>    
date     : Mon, 1 Nov 2021 13:07:23 -0300    
  
committer: Alvaro Herrera <[email protected]>    
date     : Mon, 1 Nov 2021 13:07:23 -0300    

Failing to do so results in inability of logical decoding to process the  
WAL stream.  Handle it by doing nothing.  
  
Backpatch all the way back.  
  
Reported-by: Petr Jelínek <[email protected]>  

commit   : fdb60ca83d030e77f1e0db4646954d9eb8492ee4    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 31 Oct 2021 19:13:48 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 31 Oct 2021 19:13:48 -0400    

Windows fails on a request to read() more than INT_MAX bytes,  
and perhaps other platforms could have similar issues.  Let's  
adjust this code to read at most 1GB per call.  
  
(One would not have thought the file could get that big, but now  
we have a field report of trouble, so it can.  We likely ought to  
add some mechanism to limit the size of the query-texts file  
separately from the size of the hash table.  That is not this  
patch, though.)  
  
Per bug #17254 from Yusuke Egashira.  It's been like this for  
awhile, so back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 22a498b9b5d9d619c4e6c6396f5c5103b1d42157    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 29 Oct 2021 11:38:18 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 29 Oct 2021 11:38:18 -0400    

DST law changes in Fiji, Jordan, Palestine, and Samoa.  Historical  
corrections for Barbados, Cook Islands, Guyana, Niue, Portugal, and  
Tonga.  
  
Also, the Pacific/Enderbury zone has been renamed to Pacific/Kanton.  
The following zones have been merged into nearby, more-populous zones  
whose clocks have agreed since 1970: Africa/Accra, America/Atikokan,  
America/Blanc-Sablon, America/Creston, America/Curacao,  
America/Nassau, America/Port_of_Spain, Antarctica/DumontDUrville,  
and Antarctica/Syowa.  

commit   : 6315261639e5a81d63082d39f715c2bd9a1bd43a    
  
author   : Daniel Gustafsson <[email protected]>    
date     : Fri, 29 Oct 2021 14:08:35 +0200    
  
committer: Daniel Gustafsson <[email protected]>    
date     : Fri, 29 Oct 2021 14:08:35 +0200    

The SELinux FAQ and User Guide links has been redirecting from the  
URL in our documentation for a very long time (since 2011 according  
to archive.org), but the redirect is no longer maintained and they  
now return a 404 since some time back.  Fix by replacing the links  
with the targets of the redirect.  
  
This is a follow-up to commit cc1853b3 which updated the links in  
version 10 through master, which albeit different from this one  
were also yielding 404.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 162cb0834a9a06ac076d613729447ccf5c2ee21b    
  
author   : Magnus Hagander <[email protected]>    
date     : Wed, 27 Oct 2021 16:20:02 +0200    
  
committer: Magnus Hagander <[email protected]>    
date     : Wed, 27 Oct 2021 16:20:02 +0200    

Make this more clear both in the help message and docs.  
  
Reviewed-By: Michael Paquier  
Backpatch-through: 9.6  
Discussion: https://postgr.es/m/CABUevEw6Je0WUFTLhPKOk4+BoBuDrE-fKw3N4ckqgDBMFu4paA@mail.gmail.com  

commit   : 5184932432b414478edebd74d13d4d16c7ca070c    
  
author   : Noah Misch <[email protected]>    
date     : Sat, 23 Oct 2021 18:36:38 -0700    
  
committer: Noah Misch <[email protected]>    
date     : Sat, 23 Oct 2021 18:36:38 -0700    

The purpose of commit 8a54e12a38d1545d249f1402f66c8cde2837d97c was to  
fix this, and it sufficed when the PREPARE TRANSACTION completed before  
the CIC looked for lock conflicts.  Otherwise, things still broke.  As  
before, in a cluster having used CIC while having enabled prepared  
transactions, queries that use the resulting index can silently fail to  
find rows.  It may be necessary to reindex to recover from past  
occurrences; REINDEX CONCURRENTLY suffices.  Fix this for future index  
builds by making CIC wait for arbitrarily-recent prepared transactions  
and for ordinary transactions that may yet PREPARE TRANSACTION.  As part  
of that, have PREPARE TRANSACTION transfer locks to its dummy PGPROC  
before it calls ProcArrayClearTransaction().  Back-patch to 9.6 (all  
supported versions).  
  
Andrey Borodin, reviewed (in earlier versions) by Andres Freund.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : e428699cb3be0a7abbd5a83bfa5ec3e26c7fea84    
  
author   : Noah Misch <[email protected]>    
date     : Sat, 23 Oct 2021 18:36:38 -0700    
  
committer: Noah Misch <[email protected]>    
date     : Sat, 23 Oct 2021 18:36:38 -0700    

CIC and REINDEX CONCURRENTLY assume backends see their catalog changes  
no later than each backend's next transaction start.  That failed to  
hold when a backend absorbed a relevant invalidation in the middle of  
running RelationBuildDesc() on the CIC index.  Queries that use the  
resulting index can silently fail to find rows.  Fix this for future  
index builds by making RelationBuildDesc() loop until it finishes  
without accepting a relevant invalidation.  It may be necessary to  
reindex to recover from past occurrences; REINDEX CONCURRENTLY suffices.  
Back-patch to 9.6 (all supported versions).  
  
Noah Misch and Andrey Borodin, reviewed (in earlier versions) by Andres  
Freund.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : b1df061f704bcb182d3b71cf9d25b9ef07202396    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 22 Oct 2021 15:22:26 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 22 Oct 2021 15:22:26 -0400    

Non-global default privilege entries should be dumped as-is,  
not made relative to the default ACL for their object type.  
This would typically only matter if one had revoked some  
on-by-default privileges in a global entry, and then wanted  
to grant them again in a non-global entry.  
  
Per report from Boris Korzun.  This is an old bug, so back-patch  
to all supported branches.  
  
Neil Chen, test case by Masahiko Sawada  
  
Discussion: https://postgr.es/m/[email protected]  
Discussion: https://postgr.es/m/CAA3qoJnr2+1dVJObNtfec=qW4Z0nz=A9+r5bZKoTSy5RDjskMw@mail.gmail.com  

commit   : 4d31470705451b7f571ca2f59f133ed482943d3e    
  
author   : Amit Kapila <[email protected]>    
date     : Thu, 21 Oct 2021 10:20:09 +0530    
  
committer: Amit Kapila <[email protected]>    
date     : Thu, 21 Oct 2021 10:20:09 +0530    

This was originally done in commit 5e77625b26 for 15 only, as a  
troubleshooting aid but multiple people showed interest in back-patching  
this.  
  
Author: Jeremy Schneider  
Reviewed-by: Amit Kapila  
Backpatch-through: 9.6  
Discussion: https://postgr.es/m/[email protected]  

commit   : d581960dfbeaea27f1c20f31c7133c9a25a326f6    
  
author   : Michael Paquier <[email protected]>    
date     : Wed, 20 Oct 2021 16:49:14 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Wed, 20 Oct 2021 16:49:14 +0900    

The build scripts of Visual Studio would fail to detect properly a 3.0.0  
build as the check on the second digit was failing.  This is adjusted  
where needed, allowing the builds to complete.  Note that the MSIs of  
OpenSSL mentioned in the documentation have not changed any library  
names for Win32 and Win64, making this change straight-forward.  
  
Reported-by: htalaco, via github  
Reviewed-by: Daniel Gustafsson  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 9.6  

commit   : 1ba3b15bf23255954a355c3237afa1b524ee1827    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 19 Oct 2021 11:35:15 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 19 Oct 2021 11:35:15 -0400    

I think when I added this assertion (in commit 8f889b108), I was only  
thinking of the use of transformExpressionList at top level of INSERT  
and VALUES.  But it's also called by transformRowExpr(), which can  
certainly occur in an UPDATE targetlist, so it's inappropriate to  
suppose that p_multiassign_exprs must be empty.  Besides, since the  
input is not expected to contain ResTargets, there's no reason it  
should contain MultiAssignRefs either.  Hence this code need not  
be concerned about the state of p_multiassign_exprs, and we should  
just drop the assertion.  
  
Per bug #17236 from ocean_li_996.  It's been wrong for years,  
so back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : ef1f15819a389dcb62daa3c60b7af56fbd5695e2    
  
author   : Daniel Gustafsson <[email protected]>    
date     : Tue, 19 Oct 2021 12:59:54 +0200    
  
committer: Daniel Gustafsson <[email protected]>    
date     : Tue, 19 Oct 2021 12:59:54 +0200    

If the blob TOC file cannot be parsed, the error message was failing  
to print the filename as the variable holding it was shadowed by the  
destination buffer for parsing.  When the filename fails to parse,  
the error will print an empty string:  
  
 ./pg_restore -d foo -F d dump  
 pg_restore: error: invalid line in large object TOC file "": ..  
  
..instead of the intended error message:  
  
 ./pg_restore -d foo -F d dump  
 pg_restore: error: invalid line in large object TOC file "dump/blobs.toc": ..  
  
Fix by renaming both variables as the shared name was too generic to  
store either and still convey what the variable held.  
  
Backpatch all the way down to 9.6.  
  
Reviewed-by: Tom Lane  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 9.6  

commit   : 6b96aafc67ac80590a8317ec6a0447e95a2b1f66    
  
author   : Daniel Gustafsson <[email protected]>    
date     : Tue, 19 Oct 2021 12:59:50 +0200    
  
committer: Daniel Gustafsson <[email protected]>    
date     : Tue, 19 Oct 2021 12:59:50 +0200    

Make sure that the string parsing is limited by the size of the  
destination buffer.  
  
The buffer is bounded by MAXPGPATH, and thus the limit must be  
inserted via preprocessor expansion and the buffer increased by  
one to account for the terminator. There is no risk of overflow  
here, since in this case, the buffer scanned is smaller than the  
destination buffer.  
  
Backpatch all the way down to 9.6.  
  
Reviewed-by: Tom Lane  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 9.6  

commit   : f49bf8263459bcaf253ffa33b77648b69fb2bfed    
  
author   : Michael Paquier <[email protected]>    
date     : Mon, 18 Oct 2021 11:57:07 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Mon, 18 Oct 2021 11:57:07 +0900    

During a replication slot creation, an ERROR generated in the same  
transaction as the one creating a to-be-exported snapshot would have  
left the backend in an inconsistent state, as the associated static  
export snapshot state was not being reset on transaction abort, but only  
on the follow-up command received by the WAL sender that created this  
snapshot on replication slot creation.  This would trigger inconsistency  
failures if this session tried to export again a snapshot, like during  
the creation of a replication slot.  
  
Note that a snapshot export cannot happen in a transaction block, so  
there is no need to worry resetting this state for subtransaction  
aborts.  Also, this inconsistent state would very unlikely show up to  
users.  For example, one case where this could happen is an  
out-of-memory error when building the initial snapshot to-be-exported.  
Dilip found this problem while poking at a different patch, that caused  
an error in this code path for reasons unrelated to HEAD.  
  
Author: Dilip Kumar  
Reviewed-by: Michael Paquier, Zhihong Yu  
Discussion: https://postgr.es/m/CAFiTN-s0zA1Kj0ozGHwkYkHwa5U0zUE94RSc_g81WrpcETB5=w@mail.gmail.com  
Backpatch-through: 9.6  

commit   : ae6abeb88047d689e6525a5725cffcd8fc43fe27    
  
author   : Jeff Davis <[email protected]>    
date     : Thu, 14 Oct 2021 12:26:26 -0700    
  
committer: Jeff Davis <[email protected]>    
date     : Thu, 14 Oct 2021 12:26:26 -0700    

An extension may want to call GetSecurityLabel() on a shared object  
before the shared relcaches are fully initialized. For instance, a  
ClientAuthentication_hook might want to retrieve the security label on  
a role.  
  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 9.6  

commit   : 5ec87619bc5d987954475444713672ca733b944a    
  
author   : Alvaro Herrera <[email protected]>    
date     : Wed, 13 Oct 2021 18:49:27 -0300    
  
committer: Alvaro Herrera <[email protected]>    
date     : Wed, 13 Oct 2021 18:49:27 -0300    

The test code added with ff9f111bce24 fails under valgrind, and probably  
other slow cases too, because if (say) autovacuum runs in between and  
produces WAL of its own, the large INSERT fails to account for that in  
the LSN calculations.  Rewrite to use a DO loop.  
  
Per complaint from Andres Freund  
  
Backpatch to all branches.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 7b8237bbecf7aaa537fcccf8a719aab637fd93dc    
  
author   : Etsuro Fujita <[email protected]>    
date     : Wed, 13 Oct 2021 19:00:09 +0900    
  
committer: Etsuro Fujita <[email protected]>    
date     : Wed, 13 Oct 2021 19:00:09 +0900    

The comments were misplaced when adding postgres_fdw.  Fix that by  
moving the comments to more appropriate functions.  
  
Author: Etsuro Fujita  
Backpatch-through: 9.6  
Discussion: https://postgr.es/m/CAPmGK164sAXQtC46mDFyu6d-T25Mzvh5qaRNkit06VMmecYnOA%40mail.gmail.com  

commit   : 36c9f7d96e1c95d45c7286a9355011289ab6c087    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 6 Oct 2021 15:50:24 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 6 Oct 2021 15:50:24 -0400    

Commit c7b7311f6 adjusted conversion_error_callback to always use  
information from the query's rangetable, to avoid doing catalog lookups  
in an already-failed transaction.  However, as a result of the utterly  
inadequate documentation for make_tuple_from_result_row, I failed to  
realize that fsstate could be NULL in some contexts.  That led to a  
crash if we got a conversion error in such a context.  Fix by falling  
back to the previous coding when fsstate is NULL.  Improve the  
commentary, too.  
  
Per report from Andrey Borodin.  Back-patch to 9.6, like the previous  
patch.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 0de8f9bc866a6a54ef891f07890d35455e5e6a00    
  
author   : Dean Rasheed <[email protected]>    
date     : Wed, 6 Oct 2021 13:24:22 +0100    
  
committer: Dean Rasheed <[email protected]>    
date     : Wed, 6 Oct 2021 13:24:22 +0100    

This fixes a loss of precision that occurs when the first input is  
very close to 1, so that its logarithm is very small.  
  
Formerly, during the initial low-precision calculation to estimate the  
result weight, the logarithm was computed to a local rscale that was  
capped to NUMERIC_MAX_DISPLAY_SCALE (1000). However, the base may be  
as close as 1e-16383 to 1, hence its logarithm may be as small as  
1e-16383, and so the local rscale needs to be allowed to exceed 16383,  
otherwise all precision is lost, leading to a poor choice of rscale  
for the full-precision calculation.  
  
Fix this by removing the cap on the local rscale during the initial  
low-precision calculation, as we already do in the full-precision  
calculation. This doesn't change the fact that the initial calculation  
is a low-precision approximation, computing the logarithm to around 8  
significant digits, which is very fast, especially when the base is  
very close to 1.  
  
Patch by me, reviewed by Alvaro Herrera.  
  
Discussion: https://postgr.es/m/CAEZATCV-Ceu%2BHpRMf416yUe4KKFv%3DtdgXQAe5-7S9tD%3D5E-T1g%40mail.gmail.com  

commit   : 086cda1d98238abf4f94c3edb6f4004abc9de705    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 5 Oct 2021 10:24:15 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 5 Oct 2021 10:24:15 -0400    

queries.sgml failed to mention the rather important point that  
INTERSECT binds more tightly than UNION or EXCEPT.  I thought  
it could also use more discussion of the role of parentheses  
in these constructs.  
  
Per gripe from Christopher Painter-Wakefield.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 9e3be5c182d71d7575aa2e63d9604bfa715a432e    
  
author   : Andres Freund <[email protected]>    
date     : Mon, 4 Oct 2021 13:28:06 -0700    
  
committer: Andres Freund <[email protected]>    
date     : Mon, 4 Oct 2021 13:28:06 -0700    

3c5b0685b921 used setFilePointer() to set the position of the filehandle, but  
passed the wrong filehandle, always leaving the position at 0. Instead of just  
fixing that, remove use of setFilePointer(), we have a perl fd at this point,  
so we can just use perl's seek().  
  
Additionally, the perl filehandle wasn't closed, just the windows filehandle.  
  
Reviewed-By: Andrew Dunstan <[email protected]>  
Author: Andres Freund <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  
Backpatch: 9.6-, like 3c5b0685b921  

commit   : b5f34ae08ad2153f66d2463ad008da9e67ec6b03    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 4 Oct 2021 14:52:17 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 4 Oct 2021 14:52:17 -0400    

Per discussion, let's just follow CLDR's default zone mappings  
faithfully.  There are two changes here that are clear improvements:  
  
* Mapping "Greenwich Standard Time" to Atlantic/Reykjavik is actually  
a better fit than using London, because Iceland hasn't observed DST  
since 1968, so this is more nearly what people might expect.  
  
* Since the "Samoa" zone is specified to be UTC+13:00, we must map  
it to Pacific/Apia not Pacific/Samoa; the latter refers to American  
Samoa which is now on the other side of the date line.  
  
The rest of these changes look like they're choosing the most populous  
IANA zone as representative.  Whatever the details, we're just going  
to say "if you don't like this mapping, complain to CLDR".  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : e2b2a9e1c3d51c33f9b4a0d29d8bb7cad05c41ae    
  
author   : Michael Paquier <[email protected]>    
date     : Mon, 4 Oct 2021 14:06:09 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Mon, 4 Oct 2021 14:06:09 +0900    

Some specific logic is done at the end of recovery when involving 2PC  
transactions:  
1) Call RecoverPreparedTransactions(), to recover the state of 2PC  
transactions into memory (re-acquire locks, etc.).  
2) ShutdownRecoveryTransactionEnvironment(), to move back to normal  
operations, mainly cleaning up recovery locks and KnownAssignedXids  
(including any 2PC transaction tracked previously).  
3) Switch XLogCtl->SharedRecoveryState to RECOVERY_STATE_DONE, which is  
the tipping point for any process calling RecoveryInProgress() to check  
if the cluster is still in recovery or not.  
  
Any snapshot taken between steps 2) and 3) would be empty, causing any  
transaction relying on a snapshot at this point to potentially corrupt  
data as there could still be some 2PC transactions to track, with  
RecentXmin moving backwards on successive calls to GetSnapshotData() in  
the same transaction.  
  
As SharedRecoveryState is the point to take into account to know if it  
is safe to discard KnownAssignedXids, this commit moves step 2) after  
step 3), so as we can never finish with empty snapshots.  
  
This exists since the introduction of hot standby, so backpatch all the  
way down.  The window with incorrect snapshots is extremely small, but I  
have seen it when running 023_pitr_prepared_xact.pl, as did buildfarm  
member fairywren.  Thomas Munro also found it independently.  Special  
thanks to Andres Freund for taking the time to analyze this issue.  
  
Reported-by: Thomas Munro, Michael Paquier  
Analyzed-by: Andres Freund  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 9.6  

commit   : dbec5a2fea4d5d6a52136dd169b0abe5b68fe1ec    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 2 Oct 2021 16:05:42 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 2 Oct 2021 16:05:42 -0400    

This corrects a bunch of entries in win32_tzmap[], and adds a few  
new ones, based on the CLDR project's windowsZones.xml file.  
Non-cosmetic changes fall into four main categories:  
  
* Flat-out errors:  
  
US/Aleutan doesn't exist  
America/Salvador doesn't exist  
Asia/Baku is wrong for Yerevan  
Asia/Dhaka (Bangladesh) is wrong for Astana (Kazakhstan)  
Europe/Bucharest is wrong for Chisinau  
America/Mexico_City is wrong for Chetumal  
America/Buenos_Aires is wrong for Cayenne  
America/Caracas has its own zone, so poor fit for La Paz  
US/Eastern is wrong for Haiti  
US/Eastern is wrong for Indiana (East)  
Asia/Karachi is wrong for Tashkent  
Etc/UTC+12 doesn't exist  
Signs of Etc/GMT zones were backwards  
  
* Judgment calls:  
  
(These changes follow CLDR's choices, except for the first one)  
  
Use Europe/London for "Greenwich Standard Time", since that seems much  
more likely than Africa/Casablanca to be what people will think that  
zone name means.  CLDR has Atlantic/Reykjavik here, but that's no better.  
  
Asia/Shanghai seems a better fit than Hong Kong for "China Standard  
Time".  
  
Europe/Sarajevo is now a link to Belgrade, ie "Central Europe Standard  
Time"; so use Warsaw for "Central European Standard Time".  
  
America/Sao_Paulo seems more representative than Araguaina for  
"E. South America Standard Time".  
  
Africa/Johannesburg seems more representative than Harare for  
"South Africa Standard Time".  
  
* New Windows zone names:  
  
"Israel Standard Time"  
"Kaliningrad Standard Time"  
"Russia Time Zone N" for various N  
"Singapore Standard Time"  
"South Sudan Standard Time"  
"W. Central Africa Standard Time"  
"West Bank Standard Time"  
"Yukon Standard Time"  
  
Some of these replace older spellings, but I kept the older spellings  
too in case our code runs on a machine with the older data.  
  
* Replace aliases (tzdb Links) with underlying city-named zones:  
  
(This tracks tzdb's longstanding practice, and reduces inconsistency  
with the rest of the entries, as well as with CLDR.)  
  
US/Alaska  
Asia/Kuwait  
Asia/Muscat  
Canada/Atlantic  
Australia/Canberra  
Canada/Saskatchewan  
US/Central  
US/Eastern  
US/Hawaii  
US/Mountain  
Canada/Newfoundland  
US/Pacific  
  
Back-patch to all supported branches, as is our usual practice for  
time zone data updates.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 37cbe0f791290663a46d7a65330b96a36a109e17    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 2 Oct 2021 16:05:10 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 2 Oct 2021 16:05:10 -0400    

The original intent seems to have been to sort case-insensitively  
by the Windows zone name, but various changes over the years did  
not get that memo.  This commit just moves a few entries to  
restore exact alphabetic order, to ease comparison to the outputs  
of processing scripts.  
  
Back-patch to all supported branches, as is our usual practice for  
time zone data updates.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 148c6ee3be39be61968d580eaafc93795aed1f0c    
  
author   : Alvaro Herrera <[email protected]>    
date     : Wed, 29 Sep 2021 11:21:51 -0300    
  
committer: Alvaro Herrera <[email protected]>    
date     : Wed, 29 Sep 2021 11:21:51 -0300    

Physical replication always ships WAL segment files to replicas once  
they are complete.  This is a problem if one WAL record is split across  
a segment boundary and the primary server crashes before writing down  
the segment with the next portion of the WAL record: WAL writing after  
crash recovery would happily resume at the point where the broken record  
started, overwriting that record ... but any standby or backup may have  
already received a copy of that segment, and they are not rewinding.  
This causes standbys to stop following the primary after the latter  
crashes:  
  LOG:  invalid contrecord length 7262 at A8/D9FFFBC8  
because the standby is still trying to read the continuation record  
(contrecord) for the original long WAL record, but it is not there and  
it will never be.  A workaround is to stop the replica, delete the WAL  
file, and restart it -- at which point a fresh copy is brought over from  
the primary.  But that's pretty labor intensive, and I bet many users  
would just give up and re-clone the standby instead.  
  
A fix for this problem was already attempted in commit 515e3d84a0b5, but  
it only addressed the case for the scenario of WAL archiving, so  
streaming replication would still be a problem (as well as other things  
such as taking a filesystem-level backup while the server is down after  
having crashed), and it had performance scalability problems too; so it  
had to be reverted.  
  
This commit fixes the problem using an approach suggested by Andres  
Freund, whereby the initial portion(s) of the split-up WAL record are  
kept, and a special type of WAL record is written where the contrecord  
was lost, so that WAL replay in the replica knows to skip the broken  
parts.  With this approach, we can continue to stream/archive segment  
files as soon as they are complete, and replay of the broken records  
will proceed across the crash point without a hitch.  
  
Because a new type of WAL record is added, users should be careful to  
upgrade standbys first, primaries later. Otherwise they risk the standby  
being unable to start if the primary happens to write such a record.  
  
A new TAP test that exercises this is added, but the portability of it  
is yet to be seen.  
  
This has been wrong since the introduction of physical replication, so  
backpatch all the way back.  In stable branches, keep the new  
XLogReaderState members at the end of the struct, to avoid an ABI  
break.  
  
Author: Álvaro Herrera <[email protected]>  
Reviewed-by: Kyotaro Horiguchi <[email protected]>  
Reviewed-by: Nathan Bossart <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  

commit   : 55367378d785fba20471b8bbe7f9b3af20bcc77d    
  
author   : Michael Paquier <[email protected]>    
date     : Sun, 26 Sep 2021 19:18:42 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Sun, 26 Sep 2021 19:18:42 +0900    

Author: Justin Pryzby  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 9.6  

commit   : 2aa25558875644b20fd8fcdf6591fa1d49ccef68    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 25 Sep 2021 10:53:55 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 25 Sep 2021 10:53:55 -0400    

Be a little more vocal about the risks of remote collations not  
matching local ones.  Actually fixing these risks seems hard,  
and I've given up on the idea that it might be back-patchable.  
So the best we can do for the back branches is add documentation.  
  
Per discussion of bug #16583 from Jiří Fejfar.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 56dcf00b04b87bd616dfe230323c758eb9c40722    
  
author   : Michael Paquier <[email protected]>    
date     : Sat, 25 Sep 2021 15:12:15 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Sat, 25 Sep 2021 15:12:15 +0900    

Index vacuums may happen multiple times depending on the number of dead  
tuples stored, as of maintenance_work_mem for a manual VACUUM.  For  
autovacuum, this is controlled by autovacuum_work_mem instead, if set.  
The documentation mentioned the former, but not the latter in the  
context of autovacuum.  
  
Reported-by: Nikolai Berkoff  
Author: Laurenz Albe, Euler Taveira  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 9.6  

commit   : d02eb8383edd6be9d701fc74bc6310eb621b3236    
  
author   : Michael Paquier <[email protected]>    
date     : Sat, 25 Sep 2021 14:48:31 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Sat, 25 Sep 2021 14:48:31 +0900    

Reported-by: rir  
Discussion: https://postgr.es/m/20210924183658.3syyitp3yuxjv2fp@localhost  
Backpatch-through: 9.6  

commit   : 404061515cd54a4bbb0447355ca4420411c7bff2    
  
author   : Michael Paquier <[email protected]>    
date     : Wed, 22 Sep 2021 08:43:57 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Wed, 22 Sep 2021 08:43:57 +0900    

Contrary to the output of native perl, Msys perl generates outputs with  
CRLFs characters.  There are already places in the TAP code where CRLFs  
(\r\n) are automatically converted to LF (\n) on Msys, but we missed a  
couple of places when running commands and using their output for  
comparison, that would lead to failures.  
  
This problem has been found thanks to the test added in 5adb067 using  
TestLib::command_checks_all(), but after a closer look more code paths  
were missing a filter.  
  
This is backpatched all the way down to prevent any surprises if a new  
test is introduced in stable branches.  
  
Reviewed-by: Andrew Dunstan, Álvaro Herrera  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 9.6  

commit   : 183b3acedab90390d07036bfd532481acd71cd1d    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 20 Sep 2021 11:48:52 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 20 Sep 2021 11:48:52 -0400    

Casting a value that's already of a type with a specific typmod  
to an unspecified typmod doesn't do anything so far as run-time  
behavior is concerned.  However, it really ought to change the  
exposed type of the expression to match.  Up to now,  
coerce_type_typmod hasn't bothered with that, which creates gotchas  
in contexts such as recursive unions.  If for example one side of  
the union is numeric(18,3), but it needs to be plain numeric to  
match the other side, there's no direct way to express that.  
  
This is easy enough to fix, by inserting a RelabelType to update the  
exposed type of the expression.  However, it's a bit nervous-making  
to change this behavior, because it's stood for a really long time.  
But no complaints have emerged about 14beta3, so go ahead and  
back-patch.  
  
Back-patch of 5c056b0c2 into previous supported branches.  
  
Discussion: https://postgr.es/m/CABNQVagu3bZGqiTjb31a8D5Od3fUMs7Oh3gmZMQZVHZ=uWWWfQ@mail.gmail.com  
Discussion: https://postgr.es/m/[email protected]  

commit   : e5e2e4ee6017dd2404a981864f885d8897356198    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 19 Sep 2021 11:36:53 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 19 Sep 2021 11:36:53 -0400    

"PGcon" should be "PGconn".  Noted by D. Frey.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 9b2cc7856c40f3558b787fb1e170d551860f3b99    
  
author   : Fujii Masao <[email protected]>    
date     : Thu, 16 Sep 2021 13:08:31 +0900    
  
committer: Fujii Masao <[email protected]>    
date     : Thu, 16 Sep 2021 13:08:31 +0900    

ProcArrayGroupClearXid function has a parameter named "proc",  
but the same name was used for its local variables. This commit fixes  
this variable shadowing, to improve code readability.  
  
Back-patch to all supported versions, to make future back-patching  
easy though this patch is classified as refactoring only.  
  
Reported-by: Ranier Vilela  
Author: Ranier Vilela, Aleksander Alekseev  
https://postgr.es/m/CAEudQAqyoTZC670xWi6w-Oe2_Bk1bfu2JzXz6xRfiOUzm7xbyQ@mail.gmail.com  

commit   : a460f7eb3d5ab269fa72f0b4350e561ec158b0e7    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 13 Sep 2021 12:42:04 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 13 Sep 2021 12:42:04 -0400    

Ordinarily, using EXIT this way would draw "control reached end of  
function without RETURN".  However, if the function is one where we  
don't require an explicit RETURN (such as a DO block), that should  
not happen.  It did anyway, because add_dummy_return() neglected to  
account for the case.  
  
Per report from Herwig Goemans.  Back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 3768c468df58ed23588e93c37c94a716116f0cd8    
  
author   : Michael Paquier <[email protected]>    
date     : Mon, 13 Sep 2021 13:24:56 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Mon, 13 Sep 2021 13:24:56 +0900    

An out-of-memory failure happening when allocating the structures to  
store the connection parameter keywords and values would mess up with  
the set of connections saved, as on failure the pthread mutex would  
still be hold with the new connection object listed but free()'d.  
  
Rather than just unlocking the mutex, which would leave the static list  
of connections into an inconsistent state, move the allocation for the  
structures of the connection parameters before beginning the test  
manipulation.  This ensures that the list of connections and the  
connection mutex remain consistent all the time in this code path.  
  
This error is unlikely going to happen, but this could mess up badly  
with ECPG clients in surprising ways, so backpatch all the way down.  
  
Reported-by: ryancaicse  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 9.6  

commit   : ec89d7acedcd84d51d4868f9763183fe9005f46b    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 11 Sep 2021 15:19:31 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 11 Sep 2021 15:19:31 -0400    

If search_start is greater than the length of the string, we should just  
return REG_NOMATCH immediately.  (Note that the equality case should  
*not* be rejected, since the pattern might be able to match zero  
characters.)  This guards various internal assumptions that the min of a  
range of string positions is not more than the max.  Violation of those  
assumptions could allow an attempt to fetch string[search_start-1],  
possibly causing a crash.  
  
Jaime Casanova pointed out that this situation is reachable with the  
new regexp_xxx functions that accept a user-specified start position.  
I don't believe it's reachable via any in-core call site in v14 and  
below.  However, extensions could possibly call pg_regexec with an  
out-of-range search_start, so let's back-patch the fix anyway.  
  
Discussion: https://postgr.es/m/20210911180357.GA6870@ahch-to  

commit   : cc4de2bba02ffcd11caf980fb4c1a500f64bf137    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 9 Sep 2021 11:45:48 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 9 Sep 2021 11:45:48 -0400    

We don't allow relations to exceed 2^32-1 blocks, because block  
numbers are 32 bits and the last possible block number is reserved  
to mean InvalidBlockNumber.  There is a check for this in mdextend,  
but that's really way too late, because the smgr API requires us to  
create a buffer for the block-to-be-added, and we do not want to  
have any buffer with blocknum InvalidBlockNumber.  (Such a case  
can trigger assertions in bufmgr.c, plus I think it might confuse  
ReadBuffer's logic for data-past-EOF later on.)  So put the check  
into ReadBuffer.  
  
Per report from Christoph Berg.  It's been like this forever,  
so back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 61e2aa2dbe55f138b6eea922687747416a4b4f67    
  
author   : Fujii Masao <[email protected]>    
date     : Fri, 10 Sep 2021 00:00:06 +0900    
  
committer: Fujii Masao <[email protected]>    
date     : Fri, 10 Sep 2021 00:00:06 +0900    

Previously, walreceiver always closed the currently-opened WAL segment  
and created its archive notification file, after it finished writing  
the current segment up and received any WAL data that should be  
written into the next segment. If walreceiver exited just before  
any WAL data in the next segment arrived at standby, it did not  
create the archive notification file of the current segment  
even though that's known completed. This behavior could cause  
WAL archiving of the segment to be delayed until subsequent  
restartpoints or checkpoints created its notification file.  
  
To fix the issue, this commit changes walreceiver so that it creates  
an archive notification file of a current WAL segment immediately  
if that's known completed before receiving next WAL data.  
  
Back-patch to all supported branches.  
  
Reported-by: Kyotaro Horiguchi  
Author: Fujii Masao  
Reviewed-by: Kyotaro Horiguchi  
Discussion: https://postgr.es/m/[email protected]  

commit   : dc47f05b553666f57e00f197f0e09962c535a297    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 8 Sep 2021 15:09:43 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 8 Sep 2021 15:09:43 -0400    

Coverity complained that one caller of getFormattedTypeName() failed  
to free the returned string.  Which is true, but rather than fixing  
that one, let's get rid of this tedious and error-prone requirement.  
Now that getFormattedTypeName() caches its result, strdup'ing that  
result and expecting the caller to free it accomplishes little except  
to waste cycles.  We do create a leak in the case where getTypes didn't  
make a TypeInfo for the type, but that basically shouldn't ever happen.  
  
Back-patch, as commit 6c450a861 was.  This isn't a particularly  
interesting bug fix, but the API change seems like a hazard for  
future back-patching activity if we don't back-patch it.  

commit   : 595ab8a5451b00a1ff5a332ad1e1839edbdd771d    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 8 Sep 2021 12:05:43 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 8 Sep 2021 12:05:43 -0400    

If we copy data-modifying CTEs from the original query to a replacement  
query (from a DO INSTEAD rule), we must set hasModifyingCTE properly  
in the replacement query.  Failure to do this can cause various  
unpleasantness, such as unsafe usage of parallel plans.  The code also  
neglected to propagate hasRecursive, though that's only cosmetic at  
the moment.  
  
A difficulty arises if the rule action is an INSERT...SELECT.  We  
attach the original query's RTEs and CTEs to the sub-SELECT Query, but  
data-modifying CTEs are only allowed to appear in the topmost Query.  
For the moment, throw an error in such cases.  It would probably be  
possible to avoid this error by attaching the CTEs to the top INSERT  
Query instead; but that would require a bunch of new code to adjust  
ctelevelsup references.  Given the narrowness of the use-case, and  
the need to back-patch this fix, it does not seem worth the trouble  
for now.  We can revisit this if we get field complaints.  
  
Per report from Greg Nancarrow.  Back-patch to all supported branches.  
(The test case added here does not fail before v10, but there are  
plenty of places checking top-level hasModifyingCTE in 9.6, so I have  
no doubt that this code change is necessary there too.)  
  
Greg Nancarrow and Tom Lane  
  
Discussion: https://postgr.es/m/CAJcOf-f68DT=26YAMz_i0+Au3TcLO5oiHY5=fL6Sfuits6r+_w@mail.gmail.com  
Discussion: https://postgr.es/m/CAJcOf-fAdj=nDKMsRhQzndm-O13NY4dL6xGcEvdX5Xvbbi0V7g@mail.gmail.com  

commit   : 5907c3818c43a1e0b946acc09df6dcbba42f621f    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 6 Sep 2021 11:29:52 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 6 Sep 2021 11:29:52 -0400    

timetz_zone() delivered completely wrong answers if the zone was  
specified by a dynamic TZ abbreviation, because it failed to account  
for the difference between the POSIX conventions for field values in  
struct pg_tm and the conventions used in PG-specific datetime code.  
  
As a stopgap fix, just adjust the tm_year and tm_mon fields to match  
PG conventions.  This is fixed in a different way in HEAD (388e71af8)  
but I don't want to back-patch the change of reference point.  
  
Discussion: https://postgr.es/m/CAJ7c6TOMG8zSNEZtCn5SPe+cCk3Lfxb71ZaQwT2F4T7PJ_t=KA@mail.gmail.com  

commit   : a5e8f7b3798b6fb9a4f3129a5eab98b7087c8a80    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 4 Sep 2021 16:29:08 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 4 Sep 2021 16:29:08 -0400    

Attempting to make hashfloat4() look as much as possible like  
hashfloat8(), I'd figured I could replace NaNs with get_float4_nan()  
before widening to float8.  However, results from protosciurus  
and topminnow show that on some platforms that produces a different  
bit-pattern from get_float8_nan(), breaking the intent of ce773f230.  
Rearrange so that we use the result of get_float8_nan() for all NaN  
cases.  As before, back-patch.  

commit   : 121cdaff10686066a5e03eede8fa9ee562a0ad76    
  
author   : Alvaro Herrera <[email protected]>    
date     : Sat, 4 Sep 2021 12:14:30 -0400    
  
committer: Alvaro Herrera <[email protected]>    
date     : Sat, 4 Sep 2021 12:14:30 -0400    

This reverts commit 515e3d84a0b5 and equivalent commits in back  
branches.  This solution to the problem has a number of problems, so  
we'll try again with a different approach.  
  
Per note from Andres Freund  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 9a070c6589069d94e04cfccc4dc9279478f123ae    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 3 Sep 2021 21:04:45 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 3 Sep 2021 21:04:45 -0400    

Replace fixed-length command buffers with psprintf() calls.  We didn't  
have anything as convenient as psprintf() when this code was written,  
but now that we do, there's little reason for the limitation to  
stand.  Removing it eliminates some corner cases where (for example)  
starting the postmaster with a whole lot of options fails.  
  
Most individual file names that pg_ctl deals with are still restricted  
to MAXPGPATH, but we've seldom had complaints about that limitation  
so long as it only applies to one filename.  
  
Back-patch to all supported branches.  
  
Phil Krylov  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : dea212e245f69fb1cb808e030638b7220311eed9    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 2 Sep 2021 17:24:42 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 2 Sep 2021 17:24:42 -0400    

The IEEE 754 standard allows a wide variety of bit patterns for NaNs,  
of which at least two ("NaN" and "-NaN") are pretty easy to produce  
from SQL on most machines.  This is problematic because our btree  
comparison functions deem all NaNs to be equal, but our float hash  
functions know nothing about NaNs and will happily produce varying  
hash codes for them.  That causes unexpected results from queries  
that hash a column containing different NaN values.  It could also  
produce unexpected lookup failures when using a hash index on a  
float column, i.e. "WHERE x = 'NaN'" will not find all the rows  
it should.  
  
To fix, special-case NaN in the float hash functions, not too much  
unlike the existing special case that forces zero and minus zero  
to hash the same.  I arranged for the most vanilla sort of NaN  
(that coming from the C99 NAN constant) to still have the same  
hash code as before, to reduce the risk to existing hash indexes.  
  
I dithered about whether to back-patch this into stable branches,  
but ultimately decided to do so.  It's a clear improvement for  
queries that hash internally.  If there is anybody who has -NaN  
in a hash index, they'd be well advised to re-index after applying  
this patch ... but the misbehavior if they don't will not be much  
worse than the misbehavior they had before.  
  
Per bug #17172 from Ma Liangzhu.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : e5c1fa6ac1d23d59e9e919195ecda4abea39c87f    
  
author   : Michael Paquier <[email protected]>    
date     : Thu, 2 Sep 2021 11:36:22 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Thu, 2 Sep 2021 11:36:22 +0900    

This makes the documentation more accurate grammatically.  
  
Author: Elena Indrupskaya  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 9.6  

commit   : dd3105286bd8c0ade31961cb5a585692c73bca6f    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 31 Aug 2021 15:04:05 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 31 Aug 2021 15:04:05 -0400    

For no particularly good reason, getPolicies() queried pg_policy  
separately for each table.  We can collect all the policies in  
a single query instead, and attach them to the correct TableInfo  
objects using findTableByOid() lookups.  On the regression  
database, this reduces the number of queries substantially, and  
provides a visible savings even when running against a local  
server.  
  
Per complaint from Hubert Depesz Lubaczewski.  Since this is such  
a simple fix and can have a visible performance benefit, back-patch  
to all supported branches.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 4645997c8ab7fd391df6cd2ff2bfebfc8a135242    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 31 Aug 2021 13:53:33 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 31 Aug 2021 13:53:33 -0400    

There's long been a "TODO: there might be some value in caching  
the results" annotation on pg_dump's getFormattedTypeName function;  
but we hadn't gotten around to checking what it was costing us to  
repetitively look up type names.  It turns out that when dumping the  
current regression database, about 10% of the total number of queries  
issued are duplicative format_type() queries.  However, Hubert Depesz  
Lubaczewski reported a not-unusual case where these account for over  
half of the queries issued by pg_dump.  Individually these queries  
aren't expensive, but when network lag is a factor, they add up to a  
problem.  We can very easily add some caching to getFormattedTypeName  
to solve it.  
  
Since this is such a simple fix and can have a visible performance  
benefit, back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 37e4682520db478d401f423a093bf00fdb8a767c    
  
author   : Alvaro Herrera <[email protected]>    
date     : Mon, 30 Aug 2021 16:29:12 -0400    
  
committer: Alvaro Herrera <[email protected]>    
date     : Mon, 30 Aug 2021 16:29:12 -0400    

Most data-corruption reports mention the location of the problem, but  
this one failed to.  Add it.  
  
Backpatch all the way back.  In 12 and older, also assign the  
ERRCODE_DATA_CORRUPTED error code as was done in commit fd6ec93bf890 for  
13 and later.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 3a19f13cc0a30f47aa64c47c8cda1e50d90ca18f    
  
author   : Amit Kapila <[email protected]>    
date     : Mon, 30 Aug 2021 10:07:26 +0530    
  
committer: Amit Kapila <[email protected]>    
date     : Mon, 30 Aug 2021 10:07:26 +0530    

ERRCODE_CONFIGURATION_LIMIT_EXCEEDED was used for checksum failure, use  
ERRCODE_DATA_CORRUPTED instead.  
  
Reported-by: Tatsuhito Kasahara  
Author: Tatsuhito Kasahara  
Backpatch-through: 9.6, where it was introduced  
Discussion: https://postgr.es/m/CAP0=ZVLHtYffs8SOWcFJWrBGoRzT9QQbk+_aP+E5AHLNXiOorA@mail.gmail.com  

commit   : 978998dbde2aac0e95680a35afcc1911cf1fa93f    
  
author   : Noah Misch <[email protected]>    
date     : Fri, 27 Aug 2021 23:33:23 -0700    
  
committer: Noah Misch <[email protected]>    
date     : Fri, 27 Aug 2021 23:33:23 -0700    

If the system crashed between CREATE TABLESPACE and the next checkpoint,  
the result could be some files in the tablespace unexpectedly containing  
no rows.  Affected files would be those for which the system did not  
write WAL; see the wal_skip_threshold documentation.  Before v13, a  
different set of conditions governed the writing of WAL; see v12's  
<sect2 id="populate-pitr">.  (The v12 conditions were broader in some  
ways and narrower in others.)  Users may want to audit non-default  
tablespaces for unexpected short files.  The bug could have truncated an  
index without affecting the associated table, and reindexing the index  
would fix that particular problem.  
  
This fixes the bug by making create_tablespace_directories() more like  
TablespaceCreateDbspace().  create_tablespace_directories() was  
recursively removing tablespace contents, reasoning that WAL redo would  
recreate everything removed that way.  That assumption holds for other  
wal_level values.  Under wal_level=minimal, the old approach could  
delete files for which no other copy existed.  Back-patch to 9.6 (all  
supported versions).  
  
Reviewed by Robert Haas and Prabhat Sahu.  Reported by Robert Haas.  
  
Discussion: https://postgr.es/m/CA+TgmoaLO9ncuwvr2nN-J4VEP5XyAcy=zKiHxQzBbFRxxGxm0w@mail.gmail.com  

commit   : 9e959f7ed5d5cfcb0852ee56a4c5113a54c52ee1    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 27 Aug 2021 19:42:42 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 27 Aug 2021 19:42:42 -0400    

Somehow, spgist overlooked the need to call pgstat_count_index_scan().  
Hence, pg_stat_all_indexes.idx_scan and equivalent columns never  
became nonzero for an SP-GiST index, although the related per-tuple  
counters worked fine.  
  
This fix works a bit differently from other index AMs, in that the  
counter increment occurs in spgrescan not spggettuple/spggetbitmap.  
It looks like this won't make the user-visible semantics noticeably  
different, so I won't go to the trouble of introducing an is-this-  
the-first-call flag just to make the counter bumps happen in the  
same places.  
  
Per bug #17163 from Christian Quest.  Back-patch to all supported  
versions.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : b96c1a23dc97cb860b1e436b78636de35b6214c5    
  
author   : Daniel Gustafsson <[email protected]>    
date     : Fri, 27 Aug 2021 22:50:19 +0200    
  
committer: Daniel Gustafsson <[email protected]>    
date     : Fri, 27 Aug 2021 22:50:19 +0200    

Author: Dave Cramer <[email protected]>  
Reviewed-by: Tom Lane <[email protected]>  
Discussion: https://postgr.es/m/CADK3HHLZmqAQZ2ByPDQQ9yhGqax36kksq6sDkV0yYzsxw6ipvQ@mail.gmail.com  

commit   : 5d1c36fd204bc680745263c3f9f41978b368fa0a    
  
author   : Fujii Masao <[email protected]>    
date     : Wed, 25 Aug 2021 11:43:56 +0900    
  
committer: Fujii Masao <[email protected]>    
date     : Wed, 25 Aug 2021 11:43:56 +0900    

The distance in phrase operator must be an integer value between zero  
and MAXENTRYPOS inclusive. But previously the error message about  
its valid value included the information about its upper limit  
but not lower limit (i.e., zero). This commit improves the error message  
so that it also includes the information about its lower limit.  
  
Back-patch to v9.6 where full-text phrase search was supported.  
  
Author: Kyotaro Horiguchi  
Reviewed-by: Fujii Masao  
Discussion: https://postgr.es/m/[email protected]  

commit   : 7e75fe390b68f7ed6d3feb38d228f3d798b553c8    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 24 Aug 2021 16:37:27 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 24 Aug 2021 16:37:27 -0400    

Regexps like "(.){0}...\1" drew an "invalid backreference number".  
That's not unreasonable on its face, since the capture group will  
never be matched if it's iterated zero times.  However, other engines  
such as Perl's don't complain about this, nor do we throw an error for  
related cases such as "(.)|\1", even though that backref can never  
succeed either.  Also, if the zero-iterations case happens at runtime  
rather than compile time --- say, "(x)*...\1" when there's no "x" to  
be found --- that's not an error, we just deem the backref to not  
match.  Making this even less defensible, no error was thrown for  
nested cases such as "((.)){0}...\2"; and to add insult to injury,  
those cases could result in assertion failures instead.  (It seems  
that nothing especially bad happened in non-assert builds, though.)  
  
Let's just fix it so that no error is thrown and instead the backref  
is deemed to never match, so that compile-time detection of no  
iterations behaves the same as run-time detection.  
  
Per report from Mark Dilger.  This appears to be an aboriginal error  
in Spencer's library, so back-patch to all supported versions.  
  
Pre-v14, it turns out to also be necessary to back-patch one aspect of  
commits cb76fbd7e/00116dee5, namely to create capture-node subREs with  
the begin/end states of their subexpressions, not the current lp/rp  
of the outer parseqatom invocation.  Otherwise delsub complains that  
we're trying to disconnect a state from itself.  This is a bit scary  
but code examination shows that it's safe: in the pre-v14 code, if we  
want to wrap iteration around the subexpression, the first thing we do  
is overwrite the atom's begin/end fields with new states.  So the  
bogus values didn't survive long enough to be used for anything, except  
if no iteration is required, in which case it doesn't matter.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : d90e144148885767e2d0a82ccfef75480d39cb8d    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 23 Aug 2021 17:41:07 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 23 Aug 2021 17:41:07 -0400    

The recursion in cdissect() was careless about clearing match data  
for capturing parentheses after rejecting a partial match.  This  
could allow a later back-reference to succeed when by rights it  
should fail for lack of a defined referent.  
  
To fix, think a little more rigorously about what the contract  
between different levels of cdissect's recursion needs to be.  
With the right spec, we can fix this using fewer rather than more  
resets of the match data; the key decision being that a failed  
sub-match is now explicitly responsible for clearing any matches  
it may have set.  
  
There are enough other cross-checks and optimizations in the code  
that it's not especially easy to exhibit this problem; usually, the  
match will fail as-expected.  Plus, regexps that are even potentially  
vulnerable are most likely user errors, since there's just not much  
point in writing a back-ref that doesn't always have a referent.  
These facts perhaps explain why the issue hasn't been detected,  
even though it's almost certainly a couple of decades old.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : e85f00501e16f39f32d48c83d38634e93b69d7cd    
  
author   : Alvaro Herrera <[email protected]>    
date     : Mon, 23 Aug 2021 15:50:35 -0400    
  
committer: Alvaro Herrera <[email protected]>    
date     : Mon, 23 Aug 2021 15:50:35 -0400    

WAL records may span multiple segments, but XLogWrite() does not  
wait for the entire record to be written out to disk before  
creating archive status files.  Instead, as soon as the last WAL page of  
the segment is written, the archive status file is created, and the  
archiver may process it.  If PostgreSQL crashes before it is able to  
write and flush the rest of the record (in the next WAL segment), the  
wrong version of the first segment file lingers in the archive, which  
causes operations such as point-in-time restores to fail.  
  
To fix this, keep track of records that span across segments and ensure  
that segments are only marked ready-for-archival once such records have  
been completely written to disk.  
  
This has always been wrong, so backpatch all the way back.  
  
Author: Nathan Bossart <[email protected]>  
Reviewed-by: Kyotaro Horiguchi <[email protected]>  
Reviewed-by: Ryo Matsumura <[email protected]>  
Reviewed-by: Andrey Borodin <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  

commit   : cafebd6638d026a9340847e875148e5026c3ff45    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 20 Aug 2021 14:19:04 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 20 Aug 2021 14:19:04 -0400    

After detecting a sub-match "dissect" failure (i.e., a backref match  
failure) in the i'th sub-match of an iteration node, we should proceed  
by adjusting the attempted length of the i'th submatch.  As coded,  
though, these functions changed the attempted length of the *last*  
sub-match, and only after exhausting all possibilities for that would  
they back up to adjust the next-to-last sub-match, and then the  
second-from-last, etc; all of which is wasted effort, since only  
changing the start or length of the i'th sub-match can possibly make  
it succeed.  This oversight creates the possibility for exponentially  
bad performance.  Fortunately the problem is masked in most cases by  
optimizations or constraints applied elsewhere; which explains why  
we'd not noticed it before.  But it is possible to reach the problem  
with fairly simple, if contrived, regexps.  
  
Oversight in my commit 173e29aa5.  That's pretty ancient now,  
so back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : cc7fae5c2d9effad8a907ffacb4190aca136f87b    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 19 Aug 2021 12:12:36 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 19 Aug 2021 12:12:36 -0400    

transformLockingClause neglected to exclude the pseudo-RTEs for  
OLD/NEW when processing a rule's query.  This led to odd errors  
or even crashes later on.  This bug is very ancient, but it's  
not terribly surprising that nobody noticed, since the use-case  
for SELECT FOR UPDATE in a non-view rule is somewhere between  
thin and non-existent.  Still, crashing is not OK.  
  
Per bug #17151 from Zhiyong Wu.  Thanks to Masahiko Sawada  
for analysis of the problem.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : c09f56fedc73d66758d202f6c40fb3b70c80751e    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 18 Aug 2021 18:12:51 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 18 Aug 2021 18:12:51 -0400    

Recursion into the FILTER clause was mis-implemented, such that a  
relevant Var or Aggref at the very top of the FILTER clause would  
be ignored.  (Of course, that'd have to be a plain boolean Var or  
boolean-returning aggregate.)  The consequence would be  
mis-identification of the correct semantic level of the aggregate,  
which could lead to not-per-spec query behavior.  If the FILTER  
expression is an aggregate, this could also lead to failure to issue  
an expected "aggregate function calls cannot be nested" error, which  
would likely result in a core dump later on, since the planner and  
executor aren't expecting such cases to appear.  
  
The root cause is that commit b560ec1b0 blindly copied some code  
that assumed it's recursing into a List, and thus didn't examine the  
top-level node.  To forestall questions about why this call doesn't  
look like the others, as well as possible future copy-and-paste  
mistakes, let's change all three check_agg_arguments_walker calls in  
check_agg_arguments, even though only the one for the filter clause  
is really broken.  
  
Per bug #17152 from Zhiyong Wu.  This has been wrong since we  
implemented FILTER, so back-patch to all supported versions.  
(Testing suggests that pre-v11 branches manage to avoid crashing  
in the bad-Aggref case, thanks to "redundant" checks in ExecInitAgg.  
But I'm not sure how thorough that protection is, and anyway the  
wrong-behavior issue remains, so fix 9.6 and 10 too.)  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 0a88d4ece83cc20f0d64be7930666e8900991cdc    
  
author   : Daniel Gustafsson <[email protected]>    
date     : Tue, 17 Aug 2021 14:27:37 +0200    
  
committer: Daniel Gustafsson <[email protected]>    
date     : Tue, 17 Aug 2021 14:27:37 +0200    

In OpenSSL there are two types of BIO's (I/O abstractions):  
source/sink and filters. A source/sink BIO is a source and/or  
sink of data, ie one acting on a socket or a file. A filter  
BIO takes a stream of input from another BIO and transforms it.  
In order for BIO_find_type() to be able to traverse the chain  
of BIO's and correctly find all BIO's of a certain type they  
shall have the type bit set accordingly, source/sink BIO's  
(what PostgreSQL implements) use BIO_TYPE_SOURCE_SINK and  
filter BIO's use BIO_TYPE_FILTER. In addition to these, file  
descriptor based BIO's should have the descriptor bit set,  
BIO_TYPE_DESCRIPTOR.  
  
The PostgreSQL implementation didn't set the type bits, which  
went unnoticed for a long time as it's only really relevant  
for code auditing the OpenSSL installation, or doing similar  
tasks. It is required by the API though, so this fixes it.  
  
Backpatch through 9.6 as this has been wrong for a long time.  
  
Author: Itamar Gafni  
Discussion: https://postgr.es/m/SN6PR06MB39665EC10C34BB20956AE4578AF39@SN6PR06MB3966.namprd06.prod.outlook.com  
Backpatch-through: 9.6  

commit   : 087c1a2f119b3e27ef989d414750709f7bef3cb8    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Tue, 17 Aug 2021 10:00:06 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Tue, 17 Aug 2021 10:00:06 +0300    

The backslash sequences, including \123 and \x12 escapes, are interpreted  
after encoding conversion. The docs failed to mention that.  
  
Backpatch to all supported versions.  
  
Reported-by: Andreas Grob  
Discussion: https://www.postgresql.org/message-id/17142-9181542ca1df75ab%40postgresql.org  

commit   : 942416f4bdb056c2b12a97ef7fb2d21b565df3cb    
  
author   : Michael Paquier <[email protected]>    
date     : Mon, 16 Aug 2021 12:12:09 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Mon, 16 Aug 2021 12:12:09 +0900    

This commit ensures that the wait interval in the replay delay loop  
waiting for an amount of time defined by recovery_min_apply_delay is  
correctly handled on reload, recalculating the delay if this GUC value  
is updated, based on the timestamp of the commit record being replayed.  
  
The previous behavior would be problematic for example with replay  
still waiting even if the delay got reduced or just cancelled.  If the  
apply delay was increased to a larger value, the wait would have just  
respected the old value set, finishing earlier.  
  
Author: Soumyadeep Chakraborty, Ashwin Agrawal  
Reviewed-by: Kyotaro Horiguchi, Michael Paquier  
Discussion: https://postgr.es/m/CAE-ML+93zfr-HLN8OuxF0BjpWJ17O5dv1eMvSE5jsj9jpnAXZA@mail.gmail.com  
Backpatch-through: 9.6  

commit   : 582a2affa4a945f5b9c8c233e71372ee9a7aa923    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 13 Aug 2021 13:58:47 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 13 Aug 2021 13:58:47 -0400    

Like the ARM case, just use gcc's __sync_lock_test_and_set();  
that will compile into AMOSWAP.W.AQ which does what we need.  
  
At some point it might be worth doing some work on atomic ops  
for RISC-V, but this should be enough for a creditable port.  
  
Back-patch to all supported branches, just in case somebody  
wants to try them on RISC-V.  
  
Marek Szuba  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 715a8668a5f703f00b8f6cdc126381eb87205d90    
  
author   : Thomas Munro <[email protected]>    
date     : Fri, 13 Aug 2021 10:38:22 +1200    
  
committer: Thomas Munro <[email protected]>    
date     : Fri, 13 Aug 2021 10:38:22 +1200    

It's hard to disable ASLR on current macOS releases, for testing with  
-DEXEC_BACKEND.  You could already set the environment variable  
PG_SHMEM_ADDR to something not likely to collide with mappings created  
earlier in process startup.  Let's also provide a default value that  
works on current releases and architectures, for developer convenience.  
  
As noted in the pre-existing comment, this is a horrible hack, but  
-DEXEC_BACKEND is only used by Unix-based PostgreSQL developers for  
testing some otherwise Windows-only code paths, so it seems excusable.  
  
Back-patch to all supported branches.  
  
Reviewed-by: Tom Lane <[email protected]>  
Discussion: https://postgr.es/m/20210806032944.m4tz7j2w47mant26%40alap3.anarazel.de  

commit   : 5a9df5d509305bab7f21b8d188f618e0a1906087    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 10 Aug 2021 18:10:30 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 10 Aug 2021 18:10:30 -0400    

As a result of confusion about whether the "char" type is signed or  
unsigned, scans for index searches like "col < 'x'" or "col <= 'x'"  
would start at the middle of the index not the left end, thus missing  
many or all of the entries they should find.  Fortunately, this  
is not a symptom of index corruption.  It's only the search logic  
that is broken, and we can fix it without unpleasant side-effects.  
  
Per report from Jason Kim.  This has been wrong since btree_gin's  
beginning, so back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/[email protected]