PostgreSQL Weekly News - November 7, 2021

# PostgreSQL Weekly News - November 7, 2021

PG Build 2021 will be held online on 30 November and 1 December 2021 09:00-17:00 GMT.
[Details](https://www.postgresbuild.com/).

# PostgreSQL Product News

PostgresDAC 3.11, a direct access component suite for PostgreSQL, released.
http://microolap.com/products/connectivity/postgresdac/download/

JDBC 42.3.1
[released](https://jdbc.postgresql.org/documentation/changelog.html#version_42.3.1).

ODB C++ ORM version 2.5.0-b.21 [released](https://cppget.org/odb).

DynamoDB FDW 1.0.0 [released](https://github.com/pgspider/dynamodb_fdw).

Babelfish, a MS SQL Server compatibility layer for PostgreSQL,
[released](https://github.com/babelfish-for-postgresql/).

# PostgreSQL Jobs for November

[https://archives.postgresql.org/pgsql-jobs/2021-11/](https://archives.postgresql.org/pgsql-jobs/2021-11/)

# PostgreSQL in the News

Planet PostgreSQL: [https://planet.postgresql.org/](https://planet.postgresql.org/)

PostgreSQL Weekly News is brought to you this week by David Fetter

Submit news and announcements by Sunday at 3:00pm PST8PDT to david(at)fetter(dot)org(dot)

# Applied Patches

Tom Lane pushed:

- plpgsql: report proper line number for errors in variable initialization.
Previously, we pointed at the surrounding block's BEGIN keyword. If there are
multiple variables being initialized in a DECLARE section, this isn't good
enough: it can be quite confusing and unhelpful. We do know where the
variable's declaration started, so it just takes a tiny bit more
error-reporting infrastructure to use that. Discussion:
[https://postgr.es/m/713975.1635530414@sss.pgh.pa.us](https://postgr.es/m/713975.1635530414@sss.pgh.pa.us)
[https://git.postgresql.org/pg/commitdiff/acb2d7d5d2301f07d5857ee252995e62ce9e7055](https://git.postgresql.org/pg/commitdiff/acb2d7d5d2301f07d5857ee252995e62ce9e7055)

- Avoid O(N^2) behavior when the standby process releases many locks. When
replaying a transaction that held many exclusive locks on the primary, a
standby server's startup process would expend O(N^2) effort on manipulating
the list of locks. This code was fine when written, but commit 1cff1b95a made
repetitive list_delete_first() calls inefficient, as explained in its commit
message. Fix by just iterating the list normally, and releasing storage only
when done. (This'd be inadequate if we needed to recover from an error
occurring partway through; but we don't.) Back-patch to v13 where 1cff1b95a
came in. Nathan Bossart Discussion:
[https://postgr.es/m/CD2F0E7F-9822-45EC-A411-AE56F14DEA9F@amazon.com](https://postgr.es/m/CD2F0E7F-9822-45EC-A411-AE56F14DEA9F@amazon.com)
[https://git.postgresql.org/pg/commitdiff/6301c3adabd947394682e37c933b0f3f83353b28](https://git.postgresql.org/pg/commitdiff/6301c3adabd947394682e37c933b0f3f83353b28)

- Doc: improve README files associated with TAP tests. Rearrange
src/test/perl/README so that the first section is more clearly "how to run
these tests", and the rest "how to write new tests". Add some basic info
there about debugging test failures. Then, add cross-refs to that READNE from
other READMEs that describe how to run TAP tests. Per suggestion from Kevin
Burke, though this is not his original patch. Discussion:
[https://postgr.es/m/CAKcy5eiSbwiQnmCfnOnDCVC7B8fYyev3E=6pvvECP9pLE-Fcuw@mail.gmail.com](https://postgr.es/m/CAKcy5eiSbwiQnmCfnOnDCVC7B8fYyev3E=6pvvECP9pLE-Fcuw@mail.gmail.com)
[https://git.postgresql.org/pg/commitdiff/b21415595cace7f3a45cfeb3023359b4b4d56b85](https://git.postgresql.org/pg/commitdiff/b21415595cace7f3a45cfeb3023359b4b4d56b85)

- Don't try to read a multi-GB pg_stat_statements file in one call. 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/17254-a926c89dc03375c2@postgresql.org](https://postgr.es/m/17254-a926c89dc03375c2@postgresql.org)
[https://git.postgresql.org/pg/commitdiff/a667b066837849c5e55e0d626f1f7c93e267b8b7](https://git.postgresql.org/pg/commitdiff/a667b066837849c5e55e0d626f1f7c93e267b8b7)

- Avoid some other O(N^2) hazards in list manipulation. In the same spirit as
6301c3ada, fix some more places where we were using list_delete_first() in a
loop and thereby risking O(N^2) behavior. It's not clear that the lists
manipulated in these spots can get long enough to be really problematic ...
but it's not clear that they can't, either, and the fixes are simple enough.
As before, back-patch to v13. Discussion:
[https://postgr.es/m/CD2F0E7F-9822-45EC-A411-AE56F14DEA9F@amazon.com](https://postgr.es/m/CD2F0E7F-9822-45EC-A411-AE56F14DEA9F@amazon.com)
[https://git.postgresql.org/pg/commitdiff/e9d9ba2a4ddc39e331dd8461b511aa59ec0dc8af](https://git.postgresql.org/pg/commitdiff/e9d9ba2a4ddc39e331dd8461b511aa59ec0dc8af)

- Avoid O(N^2) behavior in SyncPostCheckpoint(). As in commits 6301c3ada and
e9d9ba2a4, avoid doing repetitive list_delete_first() operations, since that
would be expensive when there are many files waiting to be unlinked. This is
a slightly larger change than in those cases. We have to keep the list state
valid for calls to AbsorbSyncRequests(), so it's necessary to invent a
"canceled" field instead of immediately deleting PendingUnlinkEntry entries.
Also, because we might not be able to process all the entries, we need a new
list primitive list_delete_first_n(). list_delete_first_n() is almost
list_copy_tail(), but it modifies the input List instead of making a new copy.
I found a couple of existing uses of the latter that could profitably use the
new function. (There might be more, but the other callers look like they
probably shouldn't overwrite the input List.) As before, back-patch to v13.
Discussion:
[https://postgr.es/m/CD2F0E7F-9822-45EC-A411-AE56F14DEA9F@amazon.com](https://postgr.es/m/CD2F0E7F-9822-45EC-A411-AE56F14DEA9F@amazon.com)
[https://git.postgresql.org/pg/commitdiff/65c6cab1365ac33b11a49a2a193f6b3f9c53e487](https://git.postgresql.org/pg/commitdiff/65c6cab1365ac33b11a49a2a193f6b3f9c53e487)

- Doc: be more precise about conflicts between relation names. Use verbiage like
"The name of the table must be distinct from the name of any other relation
(table, sequence, index, view, materialized view, or foreign table) in the
same schema." in the reference pages for all those object types. The main
change here is to mention materialized views explicitly; although a couple of
these pages failed to say anything at all about name conflicts. Per
suggestion from Daniel Westermann. Discussion:
[https://postgr.es/m/ZR0P278MB0920D0946509233459AF0DEFD2889@ZR0P278MB0920.CHEP278.PROD.OUTLOOK.COM](https://postgr.es/m/ZR0P278MB0920D0946509233459AF0DEFD2889@ZR0P278MB0920.CHEP278.PROD.OUTLOOK.COM)
[https://git.postgresql.org/pg/commitdiff/af8c580e5cf32bb85dde70083a260c93a1f783eb](https://git.postgresql.org/pg/commitdiff/af8c580e5cf32bb85dde70083a260c93a1f783eb)

- Doc: clean up some places that mentioned template1 but not template0. Improve
old text that wasn't updated when we added template0 to the standard database
set. Per suggestion from P. Luzanov. Discussion:
[https://postgr.es/m/163583775122.675.3700595100340939507@wrigleys.postgresql.org](https://postgr.es/m/163583775122.675.3700595100340939507@wrigleys.postgresql.org)
[https://git.postgresql.org/pg/commitdiff/7d9ec0754afeabb9f336c5220ef415c3ea27a0b6](https://git.postgresql.org/pg/commitdiff/7d9ec0754afeabb9f336c5220ef415c3ea27a0b6)

- Fix variable lifespan in ExecInitCoerceToDomain(). This undoes a mistake in
1ec7679f1: domainval and domainnull were meant to live across loop iterations,
but they were incorrectly moved inside the loop. The effect was only to emit
useless extra EEOP_MAKE_READONLY steps, so it's not a big deal; nonetheless,
back-patch to v13 where the mistake was introduced. Ranier Vilela
Discussion:
[https://postgr.es/m/CAEudQAqXuhbkaAp-sGH6dR6Nsq7v28_0TPexHOm6FiDYqwQD-w@mail.gmail.com](https://postgr.es/m/CAEudQAqXuhbkaAp-sGH6dR6Nsq7v28_0TPexHOm6FiDYqwQD-w@mail.gmail.com)
[https://git.postgresql.org/pg/commitdiff/01fc6527034a6f70ed44a078af8f636b1ab64947](https://git.postgresql.org/pg/commitdiff/01fc6527034a6f70ed44a078af8f636b1ab64947)

- Ensure consistent logical replication of datetime and float8 values. In
walreceiver, set the publisher's relevant GUCs (datestyle, intervalstyle,
extra_float_digits) to the same values that pg_dump uses, and for the same
reason: we need the output to be read the same way regardless of the
receiver's settings. Without this, it's possible for subscribers to
misinterpret transmitted values. Although this is clearly a bug fix, it's not
without downsides: subscribers that are storing values into some other
datatype, such as text, could get different results than before, and perhaps
be unhappy about that. Given the lack of previous complaints, it seems best
to change this only in HEAD, and to call it out as an incompatible change in
v15. Japin Li, per report from Sadhuprasad Patro Discussion:
[https://postgr.es/m/CAFF0-CF=D7pc6st-3A9f1JnOt0qmc+BcBPVzD6fLYisKyAjkGA@mail.gmail.com](https://postgr.es/m/CAFF0-CF=D7pc6st-3A9f1JnOt0qmc+BcBPVzD6fLYisKyAjkGA@mail.gmail.com)
[https://git.postgresql.org/pg/commitdiff/f3d4019da5d026f2c3fe5bd258becf6fbb6b4673](https://git.postgresql.org/pg/commitdiff/f3d4019da5d026f2c3fe5bd258becf6fbb6b4673)

- Blind attempt to silence SSL compile failures on hamerkop. Buildfarm member
hamerkop has been failing for the last few days with errors that look like
OpenSSL's X509-related symbols have not been imported into
be-secure-openssl.c. It's unclear why this should be, but let's try adding an
explicit #include of <openssl/x509v3.h>, as there has long been in
fe-secure-openssl.c. Discussion:
[https://postgr.es/m/1051867.1635720347@sss.pgh.pa.us](https://postgr.es/m/1051867.1635720347@sss.pgh.pa.us)
[https://git.postgresql.org/pg/commitdiff/24f9e49e430b4173d75a570e06abef8e3fd12c5e](https://git.postgresql.org/pg/commitdiff/24f9e49e430b4173d75a570e06abef8e3fd12c5e)

- Un-break pg_basebackup's MSVC build. Commit 23a1c6578 thought it'd be cute to
refactor pg_basebackup/Makefile with a new variable BBOBJS, but our MSVC build
system knows nothing of that. Per buildfarm.
[https://git.postgresql.org/pg/commitdiff/d8bf0a1c1d3429cafb3019f2773e2f3aa68f3b65](https://git.postgresql.org/pg/commitdiff/d8bf0a1c1d3429cafb3019f2773e2f3aa68f3b65)

- Second attempt to silence SSL compile failures on hamerkop. After further
investigation, it seems the cause of the problem is our recent decision to
start defining WIN32_LEAN_AND_MEAN. That causes <windows.h> to no longer
include <wincrypt.h>, which means that the OpenSSL headers are unable to
prevent conflicts with that header by #undef'ing the conflicting macros.
Apparently, some other system header that be-secure-openssl.c #includes after
the OpenSSL headers is pulling in <wincrypt.h>. It's obscure just where that
happens and why we're not seeing it on other Windows buildfarm animals.
However, it should work to move the OpenSSL #includes to the end of the list.
For the sake of future-proofing, do likewise in fe-secure-openssl.c. In
passing, remove useless double inclusions of <openssl/ssl.h>. Thanks to
Thomas Munro for running down the relevant information. Discussion:
[https://postgr.es/m/1051867.1635720347@sss.pgh.pa.us](https://postgr.es/m/1051867.1635720347@sss.pgh.pa.us)
[https://git.postgresql.org/pg/commitdiff/1241fcbd7e649414f09f9858ba73e63975dcff64](https://git.postgresql.org/pg/commitdiff/1241fcbd7e649414f09f9858ba73e63975dcff64)

- Disallow making an empty lexeme via array_to_tsvector(). The tsvector data
type has always forbidden lexemes to be empty. However, array_to_tsvector()
didn't get that memo, and would allow an empty-string array element to become
an empty lexeme. This could result in dump/restore failures later, not to
mention whatever semantic issues might be behind the original prohibition.
However, other functions that take a plain text input directly as a lexeme
value do not need a similar restriction, because they only match the string
against existing tsvector entries. In particular it'd be a bad idea to make
ts_delete() reject empty strings, since that is the most convenient way to
clean up any bad data that might have gotten into a tsvector column via this
bug. Reflecting on that, let's also remove the prohibition against NULL array
elements in tsvector_delete_arr and tsvector_setweight_by_filter. It seems
more consistent to ignore them, as an empty-string element would be ignored.
There's a case for back-patching this, since it's clearly a bug fix. On
balance though, it doesn't seem like something to change in a minor release.
Jean-Christophe Arnu Discussion:
[https://postgr.es/m/CAHZmTm1YVndPgUVRoag2WL0w900XcoiivDDj-gTTYBsG25c65A@mail.gmail.com](https://postgr.es/m/CAHZmTm1YVndPgUVRoag2WL0w900XcoiivDDj-gTTYBsG25c65A@mail.gmail.com)
[https://git.postgresql.org/pg/commitdiff/cbe25dcff73a297adbada9dc1d6cad3df18014e9](https://git.postgresql.org/pg/commitdiff/cbe25dcff73a297adbada9dc1d6cad3df18014e9)

- Blind attempt to fix MSVC pgcrypto build. Commit db7d1a7b0 pulled out
Mkvcbuild.pm's custom support for building contrib/pgcrypto, but neglected to
inform it that that module can now be built normally. Or at least I guess it
can now be built normally. But this is definitely causing bowerbird to fail,
since it's trying to test a module it hasn't built.
[https://git.postgresql.org/pg/commitdiff/3c2c391dc9f82fae181508ebcc2f7621ffefd024](https://git.postgresql.org/pg/commitdiff/3c2c391dc9f82fae181508ebcc2f7621ffefd024)

- Doc: add some notes about performance of the List functions. Per suggestion
from Andres Freund. Discussion:
[https://postgr.es/m/20211104221248.pgo4h6wvnjl6uvkb@alap3.anarazel.de](https://postgr.es/m/20211104221248.pgo4h6wvnjl6uvkb@alap3.anarazel.de)
[https://git.postgresql.org/pg/commitdiff/27ef132a805c8633ed8bb94ed70be995c681ab1f](https://git.postgresql.org/pg/commitdiff/27ef132a805c8633ed8bb94ed70be995c681ab1f)

- contrib/sslinfo needs a fix too to make hamerkop happy. Re-ordering the
#include's is a bit problematic here because libpq/libpq-be.h needs to include
<openssl/ssl.h>. Instead, let's #undef the unwanted macro after all the
#includes. This is definitely uglier than the other way, but it should work
despite possible future header rearrangements. (A look at the openssl headers
indicates that X509_NAME is the only conflicting symbol that we use.) In
passing, remove a related but long-incorrect comment in pg_backup_archiver.h.
Discussion:
[https://postgr.es/m/1051867.1635720347@sss.pgh.pa.us](https://postgr.es/m/1051867.1635720347@sss.pgh.pa.us)
[https://git.postgresql.org/pg/commitdiff/568620dfd6912351b4127435eca5309f823abde8](https://git.postgresql.org/pg/commitdiff/568620dfd6912351b4127435eca5309f823abde8)

- Silence uninitialized-variable warning. Quite a few buildfarm animals are
warning about this, and lapwing is actually failing (because -Werror). It's a
false positive AFAICS, so no need to do more than zero the variable to start
with. Discussion:
[https://postgr.es/m/YYXJnUxgw9dZKxlX@paquier.xyz](https://postgr.es/m/YYXJnUxgw9dZKxlX@paquier.xyz)
[https://git.postgresql.org/pg/commitdiff/c3ec4f8fe867807613c08fe16789434ab1a74a15](https://git.postgresql.org/pg/commitdiff/c3ec4f8fe867807613c08fe16789434ab1a74a15)

Michaël Paquier pushed:

- Preserve opclass parameters across REINDEX CONCURRENTLY. The opclass parameter
Datums from the old index are fetched in the same way as for predicates and
expressions, by grabbing them directly from the system catalogs. They are
then copied into the new IndexInfo that will be used for the creation of the
new copy. This caused the new index to be rebuilt with default parameters
rather than the ones pre-defined by a user. The only way to get back a new
index with correct opclass parameters would be to recreate a new index from
scratch. The issue has been introduced by 911e702. Author: Michael Paquier
Reviewed-by: Zhihong Yu Discussion:
[https://postgr.es/m/YX0CG/QpLXcPr8HJ(at)paquier(dot)xyz](https://postgr.es/m/YX0CG/QpLXcPr8HJ(at)paquier(dot)xyz)
Backpatch-through: 13
[https://git.postgresql.org/pg/commitdiff/add5cf28d48149459466b9aff374d78aebf17482](https://git.postgresql.org/pg/commitdiff/add5cf28d48149459466b9aff374d78aebf17482)

- Add TAP test for pg_receivewal with timeline switch. pg_receivewal is able to
follow a timeline switch, but this was not tested. This test uses an empty
archive location with a restart done from a slot, making its implementation a
tad simpler than if we would reuse an existing archive directory. Author:
Ronan Dunklau Reviewed-by: Kyotaro Horiguchi, Michael Paquier Discussion:
[https://postgr.es/m/18708360.4lzOvYHigE@aivenronan](https://postgr.es/m/18708360.4lzOvYHigE@aivenronan)
[https://git.postgresql.org/pg/commitdiff/0f9b9938a0367313fcf6a32fcb7fb5be9e281198](https://git.postgresql.org/pg/commitdiff/0f9b9938a0367313fcf6a32fcb7fb5be9e281198)

- Rework compression options of pg_receivewal. pg_receivewal includes since
cada1af the option --compress, to allow the compression of WAL segments using
gzip, with a value of 0 (the default) meaning that no compression can be used.
This commit introduces a new option, called --compression-method, able to use
as values "none", the default, and "gzip", to make things more extensible.
The case of --compress=0 becomes fuzzy with this option layer, so we have made
the choice to make pg_receivewal return an error when using "none" and a
non-zero compression level, meaning that the authorized values of --compress
are now [1,9] instead of [0,9]. Not specifying --compress with "gzip" as
compression method makes pg_receivewal use the default of zlib instead
(Z_DEFAULT_COMPRESSION). The code in charge of finding the streaming start
LSN when scanning the existing archives is refactored and made more
extensible. While on it, rename "compression" to "compression_level" in
walmethods.c, to reduce the confusion with the introduction of the compression
method, even if the tar method used by pg_basebackup does not rely on the
compression method (yet, at least), but just on the compression level (this
area could be improved more, actually). This is in preparation for an
upcoming patch that adds LZ4 support to pg_receivewal. Author: Georgios
Kokolatos Reviewed-by: Michael Paquier, Jian Guo, Magnus Hagander, Dilip
Kumar, Robert Haas Discussion:
[https://postgr.es/m/ZCm1J5vfyQ2E6dYvXz8si39HQ2gwxSZ3IpYaVgYa3lUwY88SLapx9EEnOf5uEwrddhx2twG7zYKjVeuP5MwZXCNPybtsGouDsAD1o2L_I5E=@pm.me](https://postgr.es/m/ZCm1J5vfyQ2E6dYvXz8si39HQ2gwxSZ3IpYaVgYa3lUwY88SLapx9EEnOf5uEwrddhx2twG7zYKjVeuP5MwZXCNPybtsGouDsAD1o2L_I5E=@pm.me)
[https://git.postgresql.org/pg/commitdiff/d62bcc8b07f921bad105c7a826702c117ea7be58](https://git.postgresql.org/pg/commitdiff/d62bcc8b07f921bad105c7a826702c117ea7be58)

- Fix some thinkos with pg_receivewal --compression-method. The option name was
incorrect in one of the error messages, and the short option 'I' was used in
the code but we did not intend things to be this way. While on it, fix the
documentation to refer to a "method", and not a "level. Oversights in commit
d62bcc8, that I have detected after more review of the LZ4 patch for
pg_receivewal.
[https://git.postgresql.org/pg/commitdiff/9588622945754305836555273a6a3be814db315c](https://git.postgresql.org/pg/commitdiff/9588622945754305836555273a6a3be814db315c)

- Add support for LZ4 compression in pg_receivewal. pg_receivewal gains a new
option, --compression-method=lz4, available when the code is compiled with
--with-lz4. Similarly to gzip, this gives the possibility to compress
archived WAL segments with LZ4. This option is not compatible with
--compress. The implementation uses LZ4 frames, and is compatible with simple
lz4 commands. Like gzip, using --synchronous ensures that any data will be
flushed to disk within the current .partial segment, so as it is possible to
retrieve as much WAL data as possible even from a non-completed segment (this
requires completing the partial file with zeros up to the WAL segment size
supported by the backend after decompression, but this is the same as gzip).
The calculation of the streaming start LSN is able to transparently find and
check LZ4-compressed segments. Contrary to gzip where the uncompressed size
is directly stored in the object read, the LZ4 chunk protocol does not store
the uncompressed data by default. There is contentSize that can be used with
LZ4 frames by that would not help if using an archive that includes segments
compressed with the defaults of a "lz4" command, where this is not stored.
So, this commit has taken the most extensible approach by decompressing the
already-archived segment to check its uncompressed size, through a blank
output buffer in chunks of 64kB (no actual performance difference noticed with
8kB, 16kB or 32kB, and the operation in itself is actually fast). Tests have
been added to verify the creation and correctness of the generated LZ4 files.
The latter is achieved by the use of command "lz4", if found in the
environment. The tar-based WAL method in walmethods.c, used now only by
pg_basebackup, does not know yet about LZ4. Its code could be extended for
this purpose. Author: Georgios Kokolatos Reviewed-by: Michael Paquier, Jian
Guo, Magnus Hagander, Dilip Kumar Discussion:
[https://postgr.es/m/ZCm1J5vfyQ2E6dYvXz8si39HQ2gwxSZ3IpYaVgYa3lUwY88SLapx9EEnOf5uEwrddhx2twG7zYKjVeuP5MwZXCNPybtsGouDsAD1o2L_I5E=@pm.me](https://postgr.es/m/ZCm1J5vfyQ2E6dYvXz8si39HQ2gwxSZ3IpYaVgYa3lUwY88SLapx9EEnOf5uEwrddhx2twG7zYKjVeuP5MwZXCNPybtsGouDsAD1o2L_I5E=@pm.me)
[https://git.postgresql.org/pg/commitdiff/babbbb595d2322da095a1e6703171b3f1f2815cb](https://git.postgresql.org/pg/commitdiff/babbbb595d2322da095a1e6703171b3f1f2815cb)

- Improve psql tab completion for COMMENT. Completion is added for more object
types, like domain constraints, text search-ish objects or policies.
Moreover, the area is reorganized, changing the list of objects supported by
COMMENT to be in the same order as the documentation to ease future additions.
Author: Ken Kato Reviewed-by: Fujii Masao, Shinya Kato, Suraj Khamkar, Michael
Paquier Discussion:
[https://postgr.es/m/6e0c2f3f657b229bea32d098d118f307@oss.nttdata.com](https://postgr.es/m/6e0c2f3f657b229bea32d098d118f307@oss.nttdata.com)
[https://git.postgresql.org/pg/commitdiff/a5b336b8b9e04a93e7c8526302504d2e5201eb80](https://git.postgresql.org/pg/commitdiff/a5b336b8b9e04a93e7c8526302504d2e5201eb80)

Álvaro Herrera pushed:

- Handle XLOG_OVERWRITE_CONTRECORD in DecodeXLogOp. 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
<petr(dot)jelinek(at)enterprisedb(dot)com>
[https://git.postgresql.org/pg/commitdiff/40c516bba864395c77bcfb1bae65ba9562ba8f71](https://git.postgresql.org/pg/commitdiff/40c516bba864395c77bcfb1bae65ba9562ba8f71)

- Reword doc blurb for vacuumdb --analyze-in-stages. Make users aware that using
it in a database with existing stats might cause transient problems. Author:
Nikolai Berkoff <nikolai(dot)berkoff(at)pm(dot)me> Discussion:
[https://postgr.es/m/s-kSljtWXMWgMfGTztPTPcS80R8FHdOrBxDTnrQI6GMZbT7au1A4b0fzaSFtKwCI8nwN0MhgPLfVOTvJ7DwTjkip4P3d0o4VgrMJs4OLN-o=@pm.me](https://postgr.es/m/s-kSljtWXMWgMfGTztPTPcS80R8FHdOrBxDTnrQI6GMZbT7au1A4b0fzaSFtKwCI8nwN0MhgPLfVOTvJ7DwTjkip4P3d0o4VgrMJs4OLN-o=@pm.me)
[https://git.postgresql.org/pg/commitdiff/00a354a13560dc529ac34a303c85c265aaf033b7](https://git.postgresql.org/pg/commitdiff/00a354a13560dc529ac34a303c85c265aaf033b7)

- Document default and changeability of log_startup_progress_interval. Review
for 9ce346eabf35. Author: Álvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
Reviewed-by: Robert Haas <robertmhaas(at)gmail(dot)com> Discussion:
[https://postgr.es/m/202110292123.bnf6axcp27vx@alvherre.pgsql](https://postgr.es/m/202110292123.bnf6axcp27vx@alvherre.pgsql)
[https://git.postgresql.org/pg/commitdiff/e543906e217509ad95c1e341de4e874f027f871b](https://git.postgresql.org/pg/commitdiff/e543906e217509ad95c1e341de4e874f027f871b)

- Pipeline mode disallows multicommand strings. ... so mention that in
appropriate places of the libpq docs. Backpatch to 14. Reported-by: RekGRpth
<rekgrpth(at)gmail(dot)com> Discussion:
[https://postgr.es/m/17235-53bb38fc5be593dc@postgresql.org](https://postgr.es/m/17235-53bb38fc5be593dc@postgresql.org)
[https://git.postgresql.org/pg/commitdiff/105c1de0197473dac8ada55dc8cf773d782224cb](https://git.postgresql.org/pg/commitdiff/105c1de0197473dac8ada55dc8cf773d782224cb)

- Document that ALTER TABLE .. TYPE removes statistics. Co-authored-by: Nikolai
Berkoff <nikolai(dot)berkoff(at)pm(dot)me> Discussion:
[https://postgr.es/m/vCc8XnwDmlP4ZnHBQLIVxzD405BiYHVC9qZlhIF7IsfxK0gC9mZ4PUUOH0-3y6kv5p-87-3_ljqT1KvQVAnb8OoWhPU3kcqWn2ZpmxRBCQg=@pm.me](https://postgr.es/m/vCc8XnwDmlP4ZnHBQLIVxzD405BiYHVC9qZlhIF7IsfxK0gC9mZ4PUUOH0-3y6kv5p-87-3_ljqT1KvQVAnb8OoWhPU3kcqWn2ZpmxRBCQg=@pm.me)
[https://git.postgresql.org/pg/commitdiff/df80f9da5c6541e744eeb20eaca919c7fc189999](https://git.postgresql.org/pg/commitdiff/df80f9da5c6541e744eeb20eaca919c7fc189999)

- Avoid crash in rare case of concurrent DROP. 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
<exclusion(at)gmail(dot)com> Discussion:
[https://postgr.es/m/17126-21887f04508cb5c8@postgresql.org](https://postgr.es/m/17126-21887f04508cb5c8@postgresql.org)
[https://git.postgresql.org/pg/commitdiff/d74b54b3ddf710926a44bf3f9c87c00e6f82d825](https://git.postgresql.org/pg/commitdiff/d74b54b3ddf710926a44bf3f9c87c00e6f82d825)

Daniel Gustafsson pushed:

- Replace unicode characters in comments with ascii. The unicode characters,
while in comments and not code, caused MSVC to emit compiler warning C4819:
The file contains a character that cannot be represented in the current code
page (number). Save the file in Unicode format to prevent data loss. Fix
by replacing the characters in print.c with descriptive comments containing
the codepoints and symbol names, and remove the character in brin_bloom.c
which was a footnote reference copied from the paper citation. Per report
from hamerkop in the buildfarm. Reviewed-by: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Discussion:
[https://postgr.es/m/340E4118-0D0C-4E85-8141-8C40EB22DA3A@yesql.se](https://postgr.es/m/340E4118-0D0C-4E85-8141-8C40EB22DA3A@yesql.se)
[https://git.postgresql.org/pg/commitdiff/43a134f28b350c4b731db9dddf2f53c407a7077f](https://git.postgresql.org/pg/commitdiff/43a134f28b350c4b731db9dddf2f53c407a7077f)

Amit Kapila pushed:

- Replace XLOG_INCLUDE_XID flag with a more localized flag. Commit 0bead9af484c
introduced XLOG_INCLUDE_XID flag to indicate that the WAL record contains
subXID-to-topXID association. It uses that flag later to mark in
CurrentTransactionState that top-xid is logged so that we should not try to
log it again with the next WAL record in the current subtransaction. However,
we can use a localized variable to pass that information. In passing, change
the related function and variable names to make them consistent with what the
code is actually doing. Author: Dilip Kumar Reviewed-by: Alvaro Herrera, Amit
Kapila Discussion:
[https://postgr.es/m/E1mSoYz-0007Fh-D9@gemulon.postgresql.org](https://postgr.es/m/E1mSoYz-0007Fh-D9@gemulon.postgresql.org)
[https://git.postgresql.org/pg/commitdiff/71db6459e6e4ef623e98f3b1e3e9fed1bfb0ae3b](https://git.postgresql.org/pg/commitdiff/71db6459e6e4ef623e98f3b1e3e9fed1bfb0ae3b)

- Move MarkCurrentTransactionIdLoggedIfAny() out of the critical section. We
don't modify any shared state in this function which could cause problems for
any concurrent session. This will make it look similar to the other updates
for the same structure (TransactionState) which avoids confusion for future
readers of code. Author: Dilip Kumar Reviewed-by: Amit Kapila Discussion:
[https://postgr.es/m/E1mSoYz-0007Fh-D9@gemulon.postgresql.org](https://postgr.es/m/E1mSoYz-0007Fh-D9@gemulon.postgresql.org)
[https://git.postgresql.org/pg/commitdiff/335397456b7e3f9f619038cb322fbfc9dd649d4f](https://git.postgresql.org/pg/commitdiff/335397456b7e3f9f619038cb322fbfc9dd649d4f)

Fujii Masao pushed:

- pgbench: Improve error-handling in pgbench. Previously failures of initial
connection and logfile open caused pgbench to proceed the benchmarking, report
the incomplete results and exit with status 2. It didn't make sense to proceed
the benchmarking even when pgbench could not start as prescribed. This commit
improves pgbench so that early errors that occur when starting benchmark such
as those failures should make pgbench exit immediately with status 1. Author:
Yugo Nagata Reviewed-by: Fabien COELHO, Kyotaro Horiguchi, Fujii Masao
Discussion:
[https://postgr.es/m/TYCPR01MB5870057375ACA8A73099C649F5349@TYCPR01MB5870.jpnprd01.prod.outlook.com](https://postgr.es/m/TYCPR01MB5870057375ACA8A73099C649F5349@TYCPR01MB5870.jpnprd01.prod.outlook.com)
[https://git.postgresql.org/pg/commitdiff/cd29be5459f0e138c0f19d49ee588feeda78e3c9](https://git.postgresql.org/pg/commitdiff/cd29be5459f0e138c0f19d49ee588feeda78e3c9)

- pgbench: Fix typo in comment. Discussion:
[https://postgr.es/m/f9041ec2-46b6-1b41-0e84-9c8a1e2d6bda@oss.nttdata.com](https://postgr.es/m/f9041ec2-46b6-1b41-0e84-9c8a1e2d6bda@oss.nttdata.com)
[https://git.postgresql.org/pg/commitdiff/d8dba4d03068eeee1ea3ffc8e7c7b4fa3e35a7f4](https://git.postgresql.org/pg/commitdiff/d8dba4d03068eeee1ea3ffc8e7c7b4fa3e35a7f4)

Peter Geoghegan pushed:

- Don't overlook indexes during parallel VACUUM. Commit b4af70cb, which
simplified state managed by VACUUM, performed refactoring of parallel VACUUM
in passing. Confusion about the exact details of the tasks that the leader
process is responsible for led to code that made it possible for parallel
VACUUM to miss a subset of the table's indexes entirely. Specifically,
indexes that fell under the min_parallel_index_scan_size size cutoff were
missed. These indexes are supposed to be vacuumed by the leader (alongside
any parallel unsafe indexes), but weren't vacuumed at all. Affected indexes
could easily end up with duplicate heap TIDs, once heap TIDs were recycled for
new heap tuples. This had generic symptoms that might be seen with almost any
index corruption involving structural inconsistencies between an index and its
table. To fix, make sure that the parallel VACUUM leader process performs any
required index vacuuming for indexes that happen to be below the size cutoff.
Also document the design of parallel VACUUM with these below-size-cutoff
indexes. It's unclear how many users might be affected by this bug. There
had to be at least three indexes on the table to hit the bug: a smaller index,
plus at least two additional indexes that themselves exceed the size cutoff.
Cases with just one additional index would not run into trouble, since the
parallel VACUUM cost model requires two larger-than-cutoff indexes on the
table to apply any parallel processing. Note also that autovacuum was not
affected, since it never uses parallel processing. Test case based on tests
from a larger patch to test parallel VACUUM by Masahiko Sawada. Many thanks
to Kamigishi Rei for her invaluable help with tracking this problem down.
Author: Peter Geoghegan <pg(at)bowt(dot)ie> Author: Masahiko Sawada
<sawada(dot)mshk(at)gmail(dot)com> Reported-By: Kamigishi Rei <iijima(dot)yun(at)koumakan(dot)jp>
Reported-By: Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> Diagnosed-By: Andres
Freund <andres(at)anarazel(dot)de> Bug: #17245 Discussion:
[https://postgr.es/m/17245-ddf06aaf85735f36@postgresql.org](https://postgr.es/m/17245-ddf06aaf85735f36@postgresql.org)
Discussion:
[https://postgr.es/m/20211030023740.qbnsl2xaoh2grq3d@alap3.anarazel.de](https://postgr.es/m/20211030023740.qbnsl2xaoh2grq3d@alap3.anarazel.de)
Backpatch: 14-, where the refactoring commit appears.
[https://git.postgresql.org/pg/commitdiff/9bacec15b67d1a643915858f054790f36b2b7871](https://git.postgresql.org/pg/commitdiff/9bacec15b67d1a643915858f054790f36b2b7871)

- Fix parallel amvacuumcleanup safety bug. Commit b4af70cb inverted the return
value of the function parallel_processing_is_safe(), but missed the
amvacuumcleanup test. Index AMs that don't support parallel cleanup at all
were affected. The practical consequences of this bug were not very serious.
Hash indexes are affected, but since they just return the number of blocks
during hashvacuumcleanup anyway, it can't have had much impact. Author:
Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> Discussion:
[https://postgr.es/m/CAD21AoA-Em+aeVPmBbL_s1V-ghsJQSxYL-i3JP8nTfPiD1wjKw@mail.gmail.com](https://postgr.es/m/CAD21AoA-Em+aeVPmBbL_s1V-ghsJQSxYL-i3JP8nTfPiD1wjKw@mail.gmail.com)
Backpatch: 14-, where commit b4af70cb appears.
[https://git.postgresql.org/pg/commitdiff/c59278a1aa5ef2ee8a6d5d83bd987a7ce5c89e84](https://git.postgresql.org/pg/commitdiff/c59278a1aa5ef2ee8a6d5d83bd987a7ce5c89e84)

- Add another old commit to git-blame-ignore-revs. Add another historic pgindent
commit that was missed by the initial work done in commit 8e638845.
[https://git.postgresql.org/pg/commitdiff/581055c32fbb5018431265877754cbd8019bc012](https://git.postgresql.org/pg/commitdiff/581055c32fbb5018431265877754cbd8019bc012)

- Add various assertions to heap pruning code. These assertions document (and
verify) our high level assumptions about how pruning can and cannot affect
existing items from target heap pages. For example, one of the new assertions
verifies that pruning does not set a heap-only tuple to LP_DEAD. Author:
Peter Geoghegan <pg(at)bowt(dot)ie> Reviewed-By: Andres Freund <andres(at)anarazel(dot)de>
Discussion:
[https://postgr.es/m/CAH2-Wz=vhvBx1GjF+oueHh8YQcHoQYrMi0F0zFMHEr8yc4sCoA@mail.gmail.com](https://postgr.es/m/CAH2-Wz=vhvBx1GjF+oueHh8YQcHoQYrMi0F0zFMHEr8yc4sCoA@mail.gmail.com)
[https://git.postgresql.org/pg/commitdiff/5cd7eb1f1c32e1b95894f28b277b4e4b89add772](https://git.postgresql.org/pg/commitdiff/5cd7eb1f1c32e1b95894f28b277b4e4b89add772)

- Add hardening to catch invalid TIDs in indexes. Add hardening to the heapam
index tuple deletion path to catch TIDs in index pages that point to a heap
item that index tuples should never point to. The corruption we're trying to
catch here is particularly tricky to detect, since it typically involves
"extra" (corrupt) index tuples, as opposed to the absence of required index
tuples in the index. For example, a heap TID from an index page that turns
out to point to an LP_UNUSED item in the heap page has a good chance of being
caught by one of the new checks. There is a decent chance that the recently
fixed parallel VACUUM bug (see commit 9bacec15) would have been caught had
that particular check been in place for Postgres 14. No backpatch of this
extra hardening for now, though. Author: Peter Geoghegan <pg(at)bowt(dot)ie>
Reviewed-By: Andres Freund <andres(at)anarazel(dot)de> Discussion:
[https://postgr.es/m/CAH2-Wzk-4_raTzawWGaiqNvkpwDXxv3y1AQhQyUeHfkU=tFCeA@mail.gmail.com](https://postgr.es/m/CAH2-Wzk-4_raTzawWGaiqNvkpwDXxv3y1AQhQyUeHfkU=tFCeA@mail.gmail.com)
[https://git.postgresql.org/pg/commitdiff/e7428a99a13f973549aab30c57ec8380ddda1869](https://git.postgresql.org/pg/commitdiff/e7428a99a13f973549aab30c57ec8380ddda1869)

- Update obsolete heap pruning comments. Add new comments that spell out what
VACUUM expects from heap pruning: pruning must never leave behind DEAD tuples
that still have tuple storage. This has at least been the case since commit
8523492d, which established the principle that vacuumlazy.c doesn't have to
deal with DEAD tuples that still have tuple storage directly, except perhaps
by simply retrying pruning (to handle a rare corner case involving concurrent
transaction abort). In passing, update some references to old symbol names
that were missed by the snapshot scalability work (specifically commit
dc7420c2c9).
[https://git.postgresql.org/pg/commitdiff/f214960adde6028a39ba3014b1ab2b224faeefed](https://git.postgresql.org/pg/commitdiff/f214960adde6028a39ba3014b1ab2b224faeefed)

- Update obsolete reference in vacuumlazy.c. Oversight in commit 7ab96cf6.
[https://git.postgresql.org/pg/commitdiff/02f9fd129432cab565b2a3cb9f3b3a5000dfe540](https://git.postgresql.org/pg/commitdiff/02f9fd129432cab565b2a3cb9f3b3a5000dfe540)

Peter Eisentraut pushed:

- Fix incorrect format placeholder.
[https://git.postgresql.org/pg/commitdiff/ef6f047d2c87b91318364341c058dd6b715951b2](https://git.postgresql.org/pg/commitdiff/ef6f047d2c87b91318364341c058dd6b715951b2)

- pgcrypto: Remove non-OpenSSL support. pgcrypto had internal implementations of
some encryption algorithms, as an alternative to calling out to OpenSSL.
These were rarely used, since most production installations are built with
OpenSSL. Moreover, maintaining parallel code paths makes the code more
complex and difficult to maintain. This patch removes these internal
implementations. Now, pgcrypto is only built if OpenSSL support is
configured. Reviewed-by: Daniel Gustafsson <daniel(at)yesql(dot)se> Discussion:
[https://www.postgresql.org/message-id/flat/0b42f1df-8cba-6a30-77d7-acc241cc88c1%40enterprisedb.com](https://www.postgresql.org/message-id/flat/0b42f1df-8cba-6a30-77d7-acc241cc88c1%40enterprisedb.com)
[https://git.postgresql.org/pg/commitdiff/db7d1a7b0530e8cbd045744e1c75b0e63fb6916f](https://git.postgresql.org/pg/commitdiff/db7d1a7b0530e8cbd045744e1c75b0e63fb6916f)

Heikki Linnakangas pushed:

- Fix snapshot reference leak if lo_export fails. 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/32bf767a-2d65-71c4-f170-122f416bab7e@iki.fi](https://www.postgresql.org/message-id/32bf767a-2d65-71c4-f170-122f416bab7e@iki.fi)
[https://git.postgresql.org/pg/commitdiff/6b1b405ebfdce9da47f59d8d4144b1168709fbce](https://git.postgresql.org/pg/commitdiff/6b1b405ebfdce9da47f59d8d4144b1168709fbce)

- Update alternative expected output file. 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/DBA08346-9962-4706-92D1-230EE5201C10@yesql.se](https://www.postgresql.org/message-id/DBA08346-9962-4706-92D1-230EE5201C10@yesql.se)
[https://git.postgresql.org/pg/commitdiff/d5ab0681bf1bbf6c0c2cba9a2d55fe8e080597b6](https://git.postgresql.org/pg/commitdiff/d5ab0681bf1bbf6c0c2cba9a2d55fe8e080597b6)

Robert Haas pushed:

- amcheck: Add additional TOAST pointer checks. Expand the checks of toasted
attributes to complain if the rawsize is overlarge. For compressed
attributes, also complain if compression appears to have expanded the
attribute or if the compression method is invalid. Mark Dilger, reviewed by
Justin Pryzby, Alexander Alekseev, Heikki Linnakangas, Greg Stark, and me.
Discussion:
[http://postgr.es/m/8E42250D-586A-4A27-B317-8B062C3816A8@enterprisedb.com](http://postgr.es/m/8E42250D-586A-4A27-B317-8B062C3816A8@enterprisedb.com)
[https://git.postgresql.org/pg/commitdiff/bd807be6935929bdefe74d1258ca08048f0aafa3](https://git.postgresql.org/pg/commitdiff/bd807be6935929bdefe74d1258ca08048f0aafa3)

- Introduce 'bbsink' abstraction to modularize base backup code. The base backup
code has accumulated a healthy number of new features over the years, but it's
becoming increasingly difficult to maintain and further enhance that code
because there's no real separation of concerns. For example, the code that
understands knows the details of how we send data to the client using the
libpq protocol is scattered throughout basebackup.c, rather than being
centralized in one place. To try to improve this situation, introduce a new
'bbsink' object which acts as a recipient for archives generated during the
base backup progress and also for the backup manifest. This commit introduces
three types of bbsink: a 'copytblspc' bbsink forwards the backup to the client
using one COPY OUT operation per tablespace and another for the manifest, a
'progress' bbsink performs command progress reporting, and a 'throttle' bbsink
performs rate-limiting. The 'progress' and 'throttle' bbsink types also
forward the data to a successor bbsink; at present, the last bbsink in the
chain will always be of type 'copytblspc'. There are plans to add more types
of 'bbsink' in future commits. This abstraction is a bit leaky in the case of
progress reporting, but this still seems cleaner than what we had before.
Patch by me, reviewed and tested by Andres Freund, Sumanta Mukherjee, Dilip
Kumar, Suraj Kharage, Dipesh Pandit, Tushar Ahuja, Mark Dilger, and Jeevan
Ladhe. Discussion:
[https://postgr.es/m/CA+TgmoZGwR=ZVWFeecncubEyPdwghnvfkkdBe9BLccLSiqdf9Q@mail.gmail.com](https://postgr.es/m/CA+TgmoZGwR=ZVWFeecncubEyPdwghnvfkkdBe9BLccLSiqdf9Q@mail.gmail.com)
Discussion:
[https://postgr.es/m/CA+TgmoZvqk7UuzxsX1xjJRmMGkqoUGYTZLDCH8SmU1xTPr1Xig@mail.gmail.com](https://postgr.es/m/CA+TgmoZvqk7UuzxsX1xjJRmMGkqoUGYTZLDCH8SmU1xTPr1Xig@mail.gmail.com)
[https://git.postgresql.org/pg/commitdiff/bef47ff85df18bf4a3a9b13bd2a54820e27f3614](https://git.postgresql.org/pg/commitdiff/bef47ff85df18bf4a3a9b13bd2a54820e27f3614)

- Introduce 'bbstreamer' abstraction to modularize pg_basebackup. pg_basebackup
knows how to do quite a few things with a backup that it gets from the server,
like just write out the files, or compress them first, or even parse the tar
format and inject a modified postgresql.auto.conf file into the archive
generated by the server. Unforatunely, this makes pg_basebackup.c a very large
source file, and also somewhat difficult to enhance, because for example the
knowledge that the server is sending us a 'tar' file rather than some other
sort of archive is spread all over the place rather than centralized. In an
effort to improve this situation, this commit invents a new 'bbstreamer'
abstraction. Each archive received from the server is fed to a bbstreamer
which may choose to dispose of it or pass it along to some other bbstreamer.
Chunks may also be "labelled" according to whether they are part of the
payload data of a file in the archive or part of the archive metadata. So,
for example, if we want to take a tar file, modify the postgresql.auto.conf
file it contains, and the gzip the result and write it out, we can use a
bbstreamer_tar_parser to parse the tar file received from the server, a
bbstreamer_recovery_injector to modify the contents of postgresql.auto.conf, a
bbstreamer_tar_archiver to replace the tar headers for the file modified in
the previous step with newly-built ones that are correct for the modified
file, and a bbstreamer_gzip_writer to gzip and write the resulting data. Only
the objects with "tar" in the name know anything about the tar archive format,
and in theory we could re-archive using some other format rather than "tar" if
somebody wanted to write the code. These chances do add a substantial amount
of code, but I think the result is a lot more maintainable and extensible.
pg_basebackup.c itself shrinks by roughly a third, with a lot of the
complexity previously contained there moving into the newly-added files.
Patch by me. The larger patch series of which this is a part has been reviewed
and tested at various times by Andres Freund, Sumanta Mukherjee, Dilip Kumar,
Suraj Kharage, Dipesh Pandit, Tushar Ahuja, Mark Dilger, Sergei Kornilov, and
Jeevan Ladhe. Discussion:
[https://postgr.es/m/CA+TgmoZGwR=ZVWFeecncubEyPdwghnvfkkdBe9BLccLSiqdf9Q@mail.gmail.com](https://postgr.es/m/CA+TgmoZGwR=ZVWFeecncubEyPdwghnvfkkdBe9BLccLSiqdf9Q@mail.gmail.com)
Discussion:
[https://postgr.es/m/CA+TgmoZvqk7UuzxsX1xjJRmMGkqoUGYTZLDCH8SmU1xTPr1Xig@mail.gmail.com](https://postgr.es/m/CA+TgmoZvqk7UuzxsX1xjJRmMGkqoUGYTZLDCH8SmU1xTPr1Xig@mail.gmail.com)
[https://git.postgresql.org/pg/commitdiff/23a1c6578c87fca0e361c4f5f9a07df5ae1f9858](https://git.postgresql.org/pg/commitdiff/23a1c6578c87fca0e361c4f5f9a07df5ae1f9858)

- Don't set ThisTimeLineID when there's no reason to do so. In slotfuncs.c,
pg_replication_slot_advance() needs to determine the LSN up to which the slot
should be advanced, but that doesn't require us to update ThisTimeLineID,
because none of the code called from here depends on it. If the replication
slot is logical, pg_logical_replication_slot_advance will call
read_local_xlog_page, which does use ThisTimeLineID, but also takes care of
making sure it's up to date. If the replication slot is physical, the timeline
isn't used for anything at all. In logicalfuncs.c,
pg_logical_slot_get_changes_guts() has the same issue: the only code we're
going to run that cares about timelines is in or downstream of
read_local_xlog_page, which already makes sure that the correct value gets
set. Hence, don't do it here. Patch by me, reviewed and tested by Michael
Paquier, Amul Sul, and Álvaro Herrera. Discussion:
[https://postgr.es/m/CA+TgmobfAAqhfWa1kaFBBFvX+5CjM=7TE=n4r4Q1o2bjbGYBpA@mail.gmail.com](https://postgr.es/m/CA+TgmobfAAqhfWa1kaFBBFvX+5CjM=7TE=n4r4Q1o2bjbGYBpA@mail.gmail.com)
[https://git.postgresql.org/pg/commitdiff/caf1f675b88d1aa67ea3fb642e8f38b470cc911e](https://git.postgresql.org/pg/commitdiff/caf1f675b88d1aa67ea3fb642e8f38b470cc911e)

- Remove all use of ThisTimeLineID global variable outside of xlog.c. All such
code deals with this global variable in one of three ways. Sometimes the same
functions use it in more than one of these ways at the same time. First,
sometimes it's an implicit argument to one or more functions being called in
xlog.c or elsewhere, and must be set to the appropriate value before calling
those functions lest they misbehave. In those cases, it is now passed as an
explicit argument instead. Second, sometimes it's used to obtain the current
timeline after the end of recovery, i.e. the timeline to which WAL is being
written and flushed. Such code now calls GetWALInsertionTimeLine() or relies
on the new out parameter added to GetFlushRecPtr(). Third, sometimes it's
used during recovery to store the current replay timeline. That can change, so
such code must generally update the value before each use. It can still do
that, but must now use a local variable instead. The net effect of these
changes is to reduce by a fair amount the amount of code that is directly
accessing this global variable. That's good, because history has shown that we
don't always think clearly about which timeline ID it's supposed to contain at
any given point in time, or indeed, whether it has been or needs to be
initialized at any given point in the code. Patch by me, reviewed and tested
by Michael Paquier, Amul Sul, and Álvaro Herrera. Discussion:
[https://postgr.es/m/CA+TgmobfAAqhfWa1kaFBBFvX+5CjM=7TE=n4r4Q1o2bjbGYBpA@mail.gmail.com](https://postgr.es/m/CA+TgmobfAAqhfWa1kaFBBFvX+5CjM=7TE=n4r4Q1o2bjbGYBpA@mail.gmail.com)
[https://git.postgresql.org/pg/commitdiff/e997a0c642860a96df0151cbeccfecbdf0450d08](https://git.postgresql.org/pg/commitdiff/e997a0c642860a96df0151cbeccfecbdf0450d08)

- Change ThisTimeLineID from a global variable to a local variable.
StartupXLOG() still has ThisTimeLineID as a local variable, but the remaining
code in xlog.c now needs to the relevant TimeLineID by some other means.
Mostly, this means that we now pass it as a function parameter to a bunch of
functions where we didn't previously. However, a few cases require special
handling: - In functions that might be called by outside callers who
wouldn't necessarily know what timeline to specify, we get the timeline ID
from shared memory. XLogCtl->ThisTimeLineID can be used in most cases since
recovery is known to have completed by the time those functions are called.
In xlog_redo(), we can use XLogCtl->replayEndTLI. - XLogFileClose() needs
to know the TLI of the open logfile. Do that with a new global variable
openLogTLI. While someone could argue that this is just trading one global
variable for another, the new one has a far more narrow purposes and is
referenced in just a few places. - read_backup_label() now returns the TLI
that it obtains by parsing the backup_label file. Previously, ReadRecord()
could be called to parse the checkpoint record without ThisTimeLineID having
been initialized. Now, the timeline is passed down, and I didn't want to
pass an uninitialized variable; this change lets us avoid that. The old
coding didn't seem to have any practical consequences that we need to
worry about, but this is cleaner. - In BootstrapXLOG(), it's just a constant.
Patch by me, reviewed and tested by Michael Paquier, Amul Sul, and Álvaro
Herrera. Discussion:
[https://postgr.es/m/CA+TgmobfAAqhfWa1kaFBBFvX+5CjM=7TE=n4r4Q1o2bjbGYBpA@mail.gmail.com](https://postgr.es/m/CA+TgmobfAAqhfWa1kaFBBFvX+5CjM=7TE=n4r4Q1o2bjbGYBpA@mail.gmail.com)
[https://git.postgresql.org/pg/commitdiff/4a92a1c3d1c361ffb031ed05bf65b801241d7cdd](https://git.postgresql.org/pg/commitdiff/4a92a1c3d1c361ffb031ed05bf65b801241d7cdd)

- Remove tests added by bd807be6935929bdefe74d1258ca08048f0aafa3. The buildfarm
is unhappy. It's not obvious why it doesn't like these tests, but let's remove
them until we figure it out. Discussion:
[http://postgr.es/m/462618.1636171009@sss.pgh.pa.us](http://postgr.es/m/462618.1636171009@sss.pgh.pa.us)
[https://git.postgresql.org/pg/commitdiff/ccf289745d3e50360653181dce6a277a1fc79730](https://git.postgresql.org/pg/commitdiff/ccf289745d3e50360653181dce6a277a1fc79730)

Tomáš Vondra pushed:

- Fix handling of NaN values in BRIN minmax multi. When calculating distance
between float4/float8 values, we need to be a bit more careful about NaN
values in order not to trigger assert. We consider NaN values to be equal
(distace 0.0) and in infinite distance from all other values. On builds
without asserts, this issue is mostly harmless - the ranges may be merged in
less efficient order, but the index is still correct. Per report from Andreas
Seltenreich. Backpatch to 14, where this new BRIN opclass was introduced.
Reported-by: Andreas Seltenreich Discussion:
[https://postgr.es/m/87r1bw9ukm.fsf@credativ.de](https://postgr.es/m/87r1bw9ukm.fsf@credativ.de)
[https://git.postgresql.org/pg/commitdiff/d91353f4b21f10417d142e6ac17a0490adae867c](https://git.postgresql.org/pg/commitdiff/d91353f4b21f10417d142e6ac17a0490adae867c)

- Mark mystreamer variable as PG_USED_FOR_ASSERTS_ONLY. Silences warnings about
unused variable, when built without asserts.
[https://git.postgresql.org/pg/commitdiff/dafcf887daa472b0a49bee7e07042372bc37cee4](https://git.postgresql.org/pg/commitdiff/dafcf887daa472b0a49bee7e07042372bc37cee4)

- Add bool GiST opclass to btree_gist. Adds bool opclass to btree_gist
extension, to allow creating GiST indexes on bool columns. GiST indexes on a
single bool column don't seem particularly useful, but this allows defining
exclusion constraings involving a bool column, for example. Author: Emre
Hasegeli Reviewed-by: Andrey Borodin Discussion:
[https://postgr.es/m/CAE2gYzyDKJBZngssR84VGZEN=Ux=V9FV23QfPgo+7-yYnKKg4g@mail.gmail.com](https://postgr.es/m/CAE2gYzyDKJBZngssR84VGZEN=Ux=V9FV23QfPgo+7-yYnKKg4g@mail.gmail.com)
[https://git.postgresql.org/pg/commitdiff/57e3c5160b24e61758f817feb7aac152cd695c6f](https://git.postgresql.org/pg/commitdiff/57e3c5160b24e61758f817feb7aac152cd695c6f)

- Fix gist_bool_ops to use gbtreekey2. Commit 57e3c5160b added a new GiST bool
opclass, but it used gbtreekey4 to store the data, which left two bytes
undefined, as reported by skink, our valgrind animal. There was a bit more
confusion, because the opclass also used gbtreekey8 in the definition. Fix by
defining a new gbtreekey2 struct, and using it in all the places. Discussion:
[https://postgr.es/m/CAE2gYzyDKJBZngssR84VGZEN=Ux=V9FV23QfPgo+7-yYnKKg4g@mail.gmail.com](https://postgr.es/m/CAE2gYzyDKJBZngssR84VGZEN=Ux=V9FV23QfPgo+7-yYnKKg4g@mail.gmail.com)
[https://git.postgresql.org/pg/commitdiff/e2fbb883720aa222f61eb9f3affad1c63bac7cbb](https://git.postgresql.org/pg/commitdiff/e2fbb883720aa222f61eb9f3affad1c63bac7cbb)

Alexander Korotkov pushed:

- Reset lastOverflowedXid on standby when needed. 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](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
[https://git.postgresql.org/pg/commitdiff/05e6e78c1840d07154a4b52092178a2d1ad39445](https://git.postgresql.org/pg/commitdiff/05e6e78c1840d07154a4b52092178a2d1ad39445)

Andres Freund pushed:

- windows: Remove use of WIN32_LEAN_AND_MEAN from crashdump.c. Since 8162464a25e
we do so in win32_port.h. But it likely didn't do much before that either,
because at that point windows.h was already included via win32_port.h.
Reported-By: Tom Lane Discussion:
[https://postgr.es/m/612842.1636237461@sss.pgh.pa.us](https://postgr.es/m/612842.1636237461@sss.pgh.pa.us)
[https://git.postgresql.org/pg/commitdiff/87bb606b20ae4e52fa45eda2d9914c19eb7eea5e](https://git.postgresql.org/pg/commitdiff/87bb606b20ae4e52fa45eda2d9914c19eb7eea5e)