PostgreSQL Weekly News - February 21, 2021

# PostgreSQL Weekly News - February 21, 2021

Person of the week: [https://postgresql.life/post/valeria_kaplan/](https://postgresql.life/post/valeria_kaplan/)

# PostgreSQL Product News

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

Pgpool-II 4.2.2, 4.1.6, 4.0.13, 3.7.18 and 3.6.25, a connection pooler and
statement replication system for PostgreSQL, released.
[https://www.pgpool.net/docs/42/en/html/release-4-2-2.html](https://www.pgpool.net/docs/42/en/html/release-4-2-2.html)

pgBadger v11.5, a PostgreSQL log analyzer and graph tool written in
Perl, released.
[https://github.com/darold/pgbadger/releases](https://github.com/darold/pgbadger/releases)

pg_probackup 2.4.10, a utility to manage backup and recovery of PostgreSQL
database clusters, released.
[https://github.com/postgrespro/pg_probackup/releases/tag/2.4.10](https://github.com/postgrespro/pg_probackup/releases/tag/2.4.10)

pgFormatter 5.0, a formatter/beautifier for SQL code, released.
[https://github.com/darold/pgFormatter/blob/master/ChangeLog](https://github.com/darold/pgFormatter/blob/master/ChangeLog)

# PostgreSQL Jobs for February

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

# 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

Thomas Munro pushed:

- ReadNewTransactionId() -> ReadNextTransactionId(). The new name conveys the
effect better, is more consistent with similar functions
ReadNextMultiXactId(), ReadNextFullTransactionId(), and matches the name of
the variable that it reads. Reported-by: Peter Geoghegan <pg(at)bowt(dot)ie>
Discussion:
[https://postgr.es/m/CAH2-WzmVR4SakBXQUdhhPpMf1aYvZCnna5%3DHKa7DAgEmBAg%2B8g%40mail.gmail.com](https://postgr.es/m/CAH2-WzmVR4SakBXQUdhhPpMf1aYvZCnna5%3DHKa7DAgEmBAg%2B8g%40mail.gmail.com)
[https://git.postgresql.org/pg/commitdiff/c7ecd6af010e2ac8c5530f3985e97f24531bfa5f](https://git.postgresql.org/pg/commitdiff/c7ecd6af010e2ac8c5530f3985e97f24531bfa5f)

- Hold interrupts while running dsm_detach() callbacks. While cleaning up after
a parallel query or parallel index creation that created temporary files, we
could be interrupted by a statement timeout. The error handling path would
then fail to clean up the files when it ran dsm_detach() again, because the
callback was already popped off the list. Prevent this hazard by holding
interrupts while the cleanup code runs. Thanks to Heikki Linnakangas for this
suggestion, and also to Kyotaro Horiguchi, Masahiko Sawada, Justin Pryzby and
Tom Lane for discussion of this and earlier ideas on how to fix the problem.
Back-patch to all supported releases. Reported-by: Justin Pryzby
<pryzby(at)telsasoft(dot)com> Discussion:
[https://postgr.es/m/20191212180506.GR2082@telsasoft.com](https://postgr.es/m/20191212180506.GR2082@telsasoft.com)
[https://git.postgresql.org/pg/commitdiff/637668fb1d17ad789e392a40ff09694ff1aabffb](https://git.postgresql.org/pg/commitdiff/637668fb1d17ad789e392a40ff09694ff1aabffb)

- Use pg_pwrite() in pg_test_fsync. For consistency with the PostgreSQL behavior
this test program is intended to simulate, use pwrite() instead of lseek() +
write(). Also fix the final "non-sync" test, which was opening and closing
the file for every write. Discussion:
[https://postgr.es/m/CA%2BhUKGJjjid2BJsvjMALBTduo1ogdx2SPYaTQL3wAy8y2hc4nw%40mail.gmail.com](https://postgr.es/m/CA%2BhUKGJjjid2BJsvjMALBTduo1ogdx2SPYaTQL3wAy8y2hc4nw%40mail.gmail.com)
[https://git.postgresql.org/pg/commitdiff/2c8b42b50df6cc5ba6987c400a857d6bbfdf0300](https://git.postgresql.org/pg/commitdiff/2c8b42b50df6cc5ba6987c400a857d6bbfdf0300)

- Default to wal_sync_method=fdatasync on FreeBSD. FreeBSD 13 gained O_DSYNC,
which would normally cause wal_sync_method to choose open_datasync as its
default value. That may not be a good choice for all systems, and performs
worse than fdatasync in some scenarios. Let's preserve the existing default
behavior for now. Like commit 576477e73c4, which did the same for Linux,
back-patch to all supported releases. Discussion:
[https://postgr.es/m/CA%2BhUKGLsAMXBQrCxCXoW-JsUYmdOL8ALYvaX%3DCrHqWxm-nWbGA%40mail.gmail.com](https://postgr.es/m/CA%2BhUKGLsAMXBQrCxCXoW-JsUYmdOL8ALYvaX%3DCrHqWxm-nWbGA%40mail.gmail.com)
[https://git.postgresql.org/pg/commitdiff/f900a79ecdc1864a6ead72c97c34a41012227eaf](https://git.postgresql.org/pg/commitdiff/f900a79ecdc1864a6ead72c97c34a41012227eaf)

Tom Lane pushed:

- Minor fixes to improve regex debugging code. When REG_DEBUG is defined, ensure
that an un-filled "struct cnfa" is all-zeroes, not just that it has nstates ==
0. This is mainly so that looking at "struct subre" structs in gdb doesn't
distract one with a lot of garbage fields during regex compilation. Adjust
some places that print debug output to have suitable fflush calls afterwards.
In passing, correct an erroneous ancient comment: the concatenation subre-s
created by parsebranch() have op == '.' not ','. Noted while fooling around
with some regex performance improvements.
[https://git.postgresql.org/pg/commitdiff/2dd6733108f2bea07b0a3469e768bd900c0808b3](https://git.postgresql.org/pg/commitdiff/2dd6733108f2bea07b0a3469e768bd900c0808b3)

- Simplify loop logic in nodeIncrementalSort.c. The inner loop in
switchToPresortedPrefixMode() can be implemented as a conventional
integer-counter for() loop, removing a couple of redundant boolean state
variables. The old logic here was a remnant of earlier development, but as
things now stand there's no reason for extra complexity. Also, annotate the
test case added by 82e0e2930 to explain why it manages to hit the corner case
fixed in that commit, and add an EXPLAIN to verify that it's creating an
incremental-sort plan. Back-patch to v13, like the previous patch. James
Coleman and Tom Lane Discussion:
[https://postgr.es/m/16846-ae49f51ac379a4cb@postgresql.org](https://postgr.es/m/16846-ae49f51ac379a4cb@postgresql.org)
[https://git.postgresql.org/pg/commitdiff/0e5290312851557ee24e3d6103baf14d6066695c](https://git.postgresql.org/pg/commitdiff/0e5290312851557ee24e3d6103baf14d6066695c)

- Convert tsginidx.c's GIN indexing logic to fully ternary operation. Commit
2f2007fbb did this partially, but there were two remaining warts.
checkcondition_gin handled some uncertain cases by setting the out-of-band
recheck flag, some by returning TS_MAYBE, and some by doing both. Meanwhile,
TS_execute arbitrarily converted a TS_MAYBE result to TS_YES. Thus, if
checkcondition_gin chose to only return TS_MAYBE, the outcome would be TS_YES
with no recheck flag, potentially resulting in wrong query outputs. The case
where this'd happen is if there were GIN_MAYBE entries in the indexscan
results passed to gin_tsquery_[tri]consistent, which so far as I can see would
only happen if the tidbitmap used to accumulate indexscan results grew large
enough to become lossy. I initially thought of fixing this by ensuring we
always set the recheck flag as well as returning TS_MAYBE in uncertain cases.
But that errs in the other direction, potentially forcing rechecks of rows
that provably match the query (since the recheck flag remains set even if
TS_execute later finds that the answer must be TS_YES). Instead, let's get
rid of the out-of-band recheck flag altogether and rely on returning TS_MAYBE.
This requires exporting a version of TS_execute that will actually return the
full ternary result of the evaluation ... but we likely should have done that
to start with. Unfortunately it doesn't seem practical to add a regression
test case that covers this: the amount of data needed to cause the GIN bitmap
to become lossy results in a longer runtime than I think we want to have in
the tests. (I'm wondering about allowing smaller work_mem settings to
ameliorate that, but it'd be a matter for a separate patch.) Per bug #16865
from Dimitri Nüscheler. Back-patch to v13 where the faulty commit came in.
Discussion:
[https://postgr.es/m/16865-4ffdc3e682e6d75b@postgresql.org](https://postgr.es/m/16865-4ffdc3e682e6d75b@postgresql.org)
[https://git.postgresql.org/pg/commitdiff/38bb3aef354ca98ff88cb37337995039a3b5135f](https://git.postgresql.org/pg/commitdiff/38bb3aef354ca98ff88cb37337995039a3b5135f)

- Make some minor improvements in the regex code. Push some
hopefully-uncontroversial bits extracted from an upcoming patch series, to
remove non-relevant clutter from the main patches. In compact(), return
immediately after setting REG_ASSERT error; continuing the loop would just
lead to assertion failure below. (Ask me how I know.) In parseqatom(), remove
assertion that moresubs() did its job. When moresubs actually did its job,
this is redundant with that function's final assert; but when it failed on
OOM, this is an assertion crash. We could avoid the crash by adding a NOERR()
check before the assertion, but it seems better to subtract code than add it.
(Note that there's a NOERR exit a few lines further down, and nothing else
between here and there requires moresubs to have succeeded. So we don't
really need an extra error exit.) This is a live bug in assert-enabled builds,
but given the very low likelihood of OOM in moresub's tiny allocation, I don't
think it's worth back-patching. On the other hand, it seems worthwhile to add
an assertion that our intended v->subs[subno] target is still null by the time
we are ready to insert into it, since there's a recursion in between. In
pg_regexec, ensure we fflush any debug output on the way out, and try to make
MDEBUG messages more uniform and helpful. (In particular, ensure that all of
them are prefixed with the subre's id number, so one can match up entry and
exit reports.) Add some test cases in test_regex to improve coverage of
lookahead and lookbehind constraints. Adding these now is mainly to establish
that this is indeed the existing behavior. Discussion:
[https://postgr.es/m/1340281.1613018383@sss.pgh.pa.us](https://postgr.es/m/1340281.1613018383@sss.pgh.pa.us)
[https://git.postgresql.org/pg/commitdiff/4e703d67193df0431c0740044d662d1feade73aa](https://git.postgresql.org/pg/commitdiff/4e703d67193df0431c0740044d662d1feade73aa)

- Fix another ancient bug in parsing of BRE-mode regular expressions. While
poking at the regex code, I happened to notice that the bug squashed in commit
afcc8772e had a sibling: next() failed to return a specific value associated
with the '}' token for a "\{m,n\}" quantifier when parsing in basic RE mode.
Again, this could result in treating the quantifier as non-greedy, which it
never should be in basic mode. For that to happen, the last character before
"\}" that sets "nextvalue" would have to set it to zero, or it'd have to have
accidentally been zero from the start. The failure can be provoked repeatably
with, for example, a bound ending in digit "0". Like the previous patch,
back-patch all the way.
[https://git.postgresql.org/pg/commitdiff/b5a66e7353ba65c11c5fc6a79b72213bde8dbe44](https://git.postgresql.org/pg/commitdiff/b5a66e7353ba65c11c5fc6a79b72213bde8dbe44)

- Invent "rainbow" arcs within the regex engine. Some regular expression
constructs, most notably the "." match-anything metacharacter, produce a sheaf
of parallel NFA arcs covering all possible colors (that is, character
equivalence classes). We can make a noticeable improvement in the space and
time needed to process large regexes by replacing such cases with a single arc
bearing the special color code "RAINBOW". This requires only minor additional
complication in places such as pull() and push(). Callers of
pg_reg_getoutarcs() must now be prepared for the possibility of seeing a
RAINBOW arc. For the one known user, contrib/pg_trgm, that's a net benefit
since it cuts the number of arcs to be dealt with, and the handling isn't any
different than for other colors that contain too many characters to be dealt
with individually. This is part of a patch series that in total reduces the
regex engine's runtime by about a factor of four on a large corpus of
real-world regexes. Patch by me, reviewed by Joel Jacobson Discussion:
[https://postgr.es/m/1340281.1613018383@sss.pgh.pa.us](https://postgr.es/m/1340281.1613018383@sss.pgh.pa.us)
[https://git.postgresql.org/pg/commitdiff/08c0d6ad65f7c161add82ae906efb90dbd7f653d](https://git.postgresql.org/pg/commitdiff/08c0d6ad65f7c161add82ae906efb90dbd7f653d)

- Recognize "match-all" NFAs within the regex engine. This builds on the
previous "rainbow" patch to detect NFAs that will match any string, though
possibly with constraints on the string length. This definition is chosen to
match constructs such as `".*"`, `".+"`, and `".{1,100}"`. Recognizing such an NFA
after the optimization pass is fairly cheap, since we basically just have to
verify that all arcs are RAINBOW arcs and count the number of steps to the end
state. (Well, there's a bit of complication with pseudo-color arcs for string
boundary conditions, but not much.) Once we have these markings, the regex
executor functions longest(), shortest(), and matchuntil() don't have to
expend per-character work to determine whether a given substring satisfies
such an NFA; they just need to check its length against the bounds. Since
some matching problems require O(N) invocations of these functions, we've
reduced the runtime for an N-character string from O(N^2) to O(N). Of course,
this is no help for non-matchall sub-patterns, but those usually have
constraints that allow us to avoid needing O(N) substring checks in the first
place. It's precisely the unconstrained "match-all" cases that cause the most
headaches. This is part of a patch series that in total reduces the regex
engine's runtime by about a factor of four on a large corpus of real-world
regexes. Patch by me, reviewed by Joel Jacobson Discussion:
[https://postgr.es/m/1340281.1613018383@sss.pgh.pa.us](https://postgr.es/m/1340281.1613018383@sss.pgh.pa.us)
[https://git.postgresql.org/pg/commitdiff/824bf71902db4a2067b8d64583c9d88bb264c44b](https://git.postgresql.org/pg/commitdiff/824bf71902db4a2067b8d64583c9d88bb264c44b)

- Fix regex engine to suppress useless concatenation sub-REs. The comment for
parsebranch() claims that it avoids generating unnecessary concatenation nodes
in the "subre" tree, but it missed some significant cases. Once we've decided
that a given atom is "messy" and can't be bundled with the preceding atom(s)
of the current regex branch, parseqatom() always generated two new concat
nodes, one to concat the messy atom to what follows it in the branch, and an
upper node to concatenate the preceding part of the branch to that one. But
one or both of these could be unnecessary, if the messy atom is the first,
last, or only one in the branch. Improve the code to suppress such useless
concat nodes, along with the no-op child nodes representing empty chunks of a
branch. Reducing the number of subre tree nodes offers significant savings
not only at execution but during compilation, because each subre node has its
own NFA that has to be separately optimized. (Maybe someday we'll figure out
how to share the optimization work across multiple tree nodes, but it doesn't
look easy.) Eliminating upper tree nodes is especially useful because they
tend to have larger NFAs. This is part of a patch series that in total
reduces the regex engine's runtime by about a factor of four on a large corpus
of real-world regexes. Patch by me, reviewed by Joel Jacobson Discussion:
[https://postgr.es/m/1340281.1613018383@sss.pgh.pa.us](https://postgr.es/m/1340281.1613018383@sss.pgh.pa.us)
[https://git.postgresql.org/pg/commitdiff/cebc1d34e5207c37871708f91be65dd839760b5f](https://git.postgresql.org/pg/commitdiff/cebc1d34e5207c37871708f91be65dd839760b5f)

- Convert regex engine's subre tree from binary to N-ary style. Instead of
having left and right child links in subre structs, have a single child link
plus a sibling link. Multiple children of a tree node are now reached by
chasing the sibling chain. The beneficiary of this is alternation tree nodes.
A regular expression with N (>1) branches is now represented by one
alternation node with N children, rather than a tree that includes N
alternation nodes as well as N children. While the old representation didn't
really cost anything extra at execution time, it was pretty horrid for
compilation purposes, because each of the alternation nodes had its own NFA,
which we were too stupid not to separately optimize. (To make matters worse,
all of those NFAs described the entire alternation pattern, not just the
portion of it that one might expect from the tree structure.) We continue to
require concatenation nodes to have exactly two children. This data structure
is now prepared to support more, but the executor's logic would need some
careful redesign, and it's not clear that a lot of benefit could be had. This
is part of a patch series that in total reduces the regex engine's runtime by
about a factor of four on a large corpus of real-world regexes. Patch by me,
reviewed by Joel Jacobson Discussion:
[https://postgr.es/m/1340281.1613018383@sss.pgh.pa.us](https://postgr.es/m/1340281.1613018383@sss.pgh.pa.us)
[https://git.postgresql.org/pg/commitdiff/581043089472816061a7fd381f40572191dfa48f](https://git.postgresql.org/pg/commitdiff/581043089472816061a7fd381f40572191dfa48f)

- Avoid generating extra subre tree nodes for capturing parentheses. Previously,
each pair of capturing parentheses gave rise to a separate subre tree node,
whose only function was to identify that we ought to capture the match details
for this particular sub-expression. In most cases we don't really need that,
since we can perfectly well put a "capture this" annotation on the child node
that does the real matching work. As with the two preceding commits, the main
value of this is to avoid generating and optimizing an NFA for a tree node
that's not really pulling its weight. The chosen data representation only
allows one capture annotation per subre node. In the legal-per-spec, but
seemingly not very useful, case where there are multiple capturing parens
around the exact same bit of the regex (i.e. "((xyz))"), wrap the child node
in N-1 capture nodes that act the same as before. We could work harder at
that but I'll refrain, pending some evidence that such cases are worth
troubling over. In passing, improve the comments in regex.h to say what all
the different re_info bits mean. Some of them were pretty obvious but others
not so much, so reverse-engineer some documentation. This is part of a patch
series that in total reduces the regex engine's runtime by about a factor of
four on a large corpus of real-world regexes. Patch by me, reviewed by Joel
Jacobson Discussion:
[https://postgr.es/m/1340281.1613018383@sss.pgh.pa.us](https://postgr.es/m/1340281.1613018383@sss.pgh.pa.us)
[https://git.postgresql.org/pg/commitdiff/ea1268f6301cc7adce571cc9c5ebe8d9342a2ef4](https://git.postgresql.org/pg/commitdiff/ea1268f6301cc7adce571cc9c5ebe8d9342a2ef4)

Michaël Paquier pushed:

- Add result size as argument of pg_cryptohash_final() for overflow checks. With
its current design, a careless use of pg_cryptohash_final() could would result
in an out-of-bound write in memory as the size of the destination buffer to
store the result digest is not known to the cryptohash internals, without the
caller knowing about that. This commit adds a new argument to
pg_cryptohash_final() to allow such sanity checks, and implements such
defenses. The internals of SCRAM for HMAC could be tightened a bit more, but
as everything is based on SCRAM_KEY_LEN with uses particular to this code
there is no need to complicate its interface more than necessary, and this
comes back to the refactoring of HMAC in core. Except that, this minimizes
the uses of the existing DIGEST_LENGTH variables, relying instead on sizeof()
for the result sizes. In ossp-uuid, this also makes the code more defensive,
as it already relied on dce_uuid_t being at least the size of a MD5 digest.
This is in philosophy similar to cfc40d3 for base64.c and aef8948 for hex.c.
Reported-by: Ranier Vilela Author: Michael Paquier, Ranier Vilela Reviewed-by:
Kyotaro Horiguchi Discussion:
[https://postgr.es/m/CAEudQAoqEGmcff3J4sTSV-R_16Monuz-UpJFbf_dnVH=APr02Q@mail.gmail.com](https://postgr.es/m/CAEudQAoqEGmcff3J4sTSV-R_16Monuz-UpJFbf_dnVH=APr02Q@mail.gmail.com)
[https://git.postgresql.org/pg/commitdiff/b83dcf792869fb4a9270d17c961eab75f51c44e4](https://git.postgresql.org/pg/commitdiff/b83dcf792869fb4a9270d17c961eab75f51c44e4)

- Add psql completion for [ NO ] DEPENDS ON EXTENSION. ALTER INDEX was able to
handle that already. This adds tab completion for all the remaining commands
that support this grammar: - ALTER FUNCTION - ALTER PROCEDURE - ALTER ROUTINE
- ALTER TRIGGER - ALTER MATERIALIZED VIEW Author: Ian Lawrence Barwick
Discussion:
[https://postgr.es/m/CAB8KJ=iypYudXuMOAMOP4BpkaYbXxk=a2cdJppX0e9mJXWtuig@mail.gmail.com](https://postgr.es/m/CAB8KJ=iypYudXuMOAMOP4BpkaYbXxk=a2cdJppX0e9mJXWtuig@mail.gmail.com)
[https://git.postgresql.org/pg/commitdiff/e6b8e83b9f012cfbb3a2f96a7d2e74aebd299d4e](https://git.postgresql.org/pg/commitdiff/e6b8e83b9f012cfbb3a2f96a7d2e74aebd299d4e)

- Fix inconsistent configure data for --with-ssl. This inconsistency was showing
up after an autoreconf. Reported-by: Antonin Houska Reviewed-by: Tom Lane
Discussion:
[https://postgr.es/m/47255.1613716807@antos](https://postgr.es/m/47255.1613716807@antos)
[https://git.postgresql.org/pg/commitdiff/a899ec1cb23eb3c4a94648f18a9408e5316d32a4](https://git.postgresql.org/pg/commitdiff/a899ec1cb23eb3c4a94648f18a9408e5316d32a4)

- doc: Mention that partitions_{done,total} is 0 for REINDEX progress reports.
REINDEX has recently gained support for partitions, so it can be confusing to
see those fields not being set. Making useful reports for for such relations
is more complicated than it looks with the current set of columns available in
pg_stat_progress_create_index, and this touches equally REINDEX
DATABASE/SYSTEM/SCHEMA. This commit documents that those two columns are not
touched during a REINDEX. Reported-by: Justin Pryzby Discussion:
[https://postgr.es/m/20210216064214.GI28165@telsasoft.com](https://postgr.es/m/20210216064214.GI28165@telsasoft.com)
[https://git.postgresql.org/pg/commitdiff/17661188336c8cbb1783808912096932c57893a3](https://git.postgresql.org/pg/commitdiff/17661188336c8cbb1783808912096932c57893a3)

Amit Kapila pushed:

- Fix the warnings introduced in commit ce0fdbfe97. Author: Amit Kapila
Reviewed-by: Tom Lane Discussion:
[https://postgr.es/m/1610789.1613170207@sss.pgh.pa.us](https://postgr.es/m/1610789.1613170207@sss.pgh.pa.us)
[https://git.postgresql.org/pg/commitdiff/d9b0767becf5f41e4f001d8381e6a89941efa5b2](https://git.postgresql.org/pg/commitdiff/d9b0767becf5f41e4f001d8381e6a89941efa5b2)

- Remove the unnecessary PrepareWrite in pgoutput. This issue exists from the
inception of this code (PG-10) but got exposed by the recent commit ce0fdbfe97
where we are using origins in tablesync workers. The problem was that we were
sometimes sending the prepare_write ('w') message but then the actual message
was not being sent and on the subscriber side, we always expect a message
after prepare_write message which led to this bug. I refrained from
backpatching this because there is no way in the core code to hit this prior
to commit ce0fdbfe97 and we haven't received any complaints so far.
Reported-by: Erik Rijkers Author: Amit Kapila and Vignesh C Tested-by: Erik
Rijkers Discussion:
[https://postgr.es/m/1295168140.139428.1613133237154@webmailclassic.xs4all.nl](https://postgr.es/m/1295168140.139428.1613133237154@webmailclassic.xs4all.nl)
[https://git.postgresql.org/pg/commitdiff/f672df5fdd22dac14c98d0a0bf5bbaa6ab17f8a5](https://git.postgresql.org/pg/commitdiff/f672df5fdd22dac14c98d0a0bf5bbaa6ab17f8a5)

Peter Geoghegan pushed:

- Adjust lazy_scan_heap() accounting comments. Explain which particular LP_DEAD
line pointers get accounted for by the tups_vacuumed variable.
[https://git.postgresql.org/pg/commitdiff/7cde6b13a9b630e2f04d91e2f17dedc2afee21c6](https://git.postgresql.org/pg/commitdiff/7cde6b13a9b630e2f04d91e2f17dedc2afee21c6)

- Avoid misinterpreting GiST pages in pageinspect. GistPageSetDeleted() sets
pd_lower when deleting a page, and sets the page contents to a
GISTDeletedPageContents. Avoid treating deleted GiST pages as regular slotted
pages within pageinspect. Oversight in commit 756ab291. Author: Andrey
Borodin <x4mmm(at)yandex-team(dot)ru>
[https://git.postgresql.org/pg/commitdiff/fa41cf8f183ac5d702e91da567e9b3375c632081](https://git.postgresql.org/pg/commitdiff/fa41cf8f183ac5d702e91da567e9b3375c632081)

- Add "LP_DEAD item?" column to GiST pageinspect functions. This brings
gist_page_items() and gist_page_items_bytea() in line with nbtree's
bt_page_items() function. Minor follow-up to commit 756ab291, which added the
GiST functions. Author: Andrey Borodin <x4mmm(at)yandex-team(dot)ru> Discussion:
[https://postgr.es/m/E0794687-7315-4C29-A9C7-EC54D448596D@yandex-team.ru](https://postgr.es/m/E0794687-7315-4C29-A9C7-EC54D448596D@yandex-team.ru)
[https://git.postgresql.org/pg/commitdiff/9e596b65f430fcb942685b41860b323398a88873](https://git.postgresql.org/pg/commitdiff/9e596b65f430fcb942685b41860b323398a88873)

- nbtree README: move VACUUM linear scan section. Discuss VACUUM's linear scan
after discussion of tuple deletion by VACUUM, but before discussion of page
deletion by VACUUM. This progression is a lot more natural. Also tweak the
wording a little. It seems unnecessary to talk about how it worked prior to
PostgreSQL 8.2.
[https://git.postgresql.org/pg/commitdiff/128dd901a5c87e11c6a8cbe227a806cdc3afd10d](https://git.postgresql.org/pg/commitdiff/128dd901a5c87e11c6a8cbe227a806cdc3afd10d)

- Add nbtree README section on page recycling. Consolidate discussion of how
VACUUM places pages in the FSM for recycling by adding a new section that
comes after discussion of page deletion. This structure reflects the fact
that page recycling is explicitly decoupled from page deletion in Lanin &
Shasha's paper. Page recycling in nbtree is an implementation of what the
paper calls "the drain technique". This decoupling is an important concept
for nbtree VACUUM. Searchers have to detect and recover from concurrent page
deletions, but they will never have to reason about concurrent page recycling.
Recycling can almost always be thought of as a low level garbage collection
operation that asynchronously frees the physical space that backs a logical
tree node. Almost all code need only concern itself with logical tree nodes.
(Note that "logical tree node" is not currently a term of art in the nbtree
code -- this all works implicitly.) This is preparation for an upcoming patch
that teaches nbtree VACUUM to remember the details of pages that it deletes on
the fly, in local memory. This enables the same VACUUM operation to consider
placing its own deleted pages in the FSM later on, when it reaches the end of
btvacuumscan().
[https://git.postgresql.org/pg/commitdiff/b071a311495bbf42ddf2466a556d033df8f0f5e7](https://git.postgresql.org/pg/commitdiff/b071a311495bbf42ddf2466a556d033df8f0f5e7)

Fujii Masao pushed:

- Display the time when the process started waiting for the lock, in pg_locks,
take 2. This commit adds new column "waitstart" into pg_locks view. This
column reports the time when the server process started waiting for the lock
if the lock is not held. This information is useful, for example, when
examining the amount of time to wait on a lock by subtracting "waitstart" in
pg_locks from the current time, and identify the lock that the processes are
waiting for very long. This feature uses the current time obtained for the
deadlock timeout timer as "waitstart" (i.e., the time when this process
started waiting for the lock). Since getting the current time newly can cause
overhead, we reuse the already-obtained time to avoid that overhead. Note
that "waitstart" is updated without holding the lock table's partition lock,
to avoid the overhead by additional lock acquisition. This can cause
"waitstart" in pg_locks to become NULL for a very short period of time after
the wait started even though "granted" is false. This is OK in practice
because we can assume that users are likely to look at "waitstart" when
waiting for the lock for a long time. The first attempt of this patch (commit
3b733fcd04) caused the buildfarm member "rorqual" (built with
--disable-atomics --disable-spinlocks) to report the failure of the regression
test. It was reverted by commit 890d2182a2. The cause of this failure was that
the atomic variable for "waitstart" in the dummy process entry created at the
end of prepare transaction was not initialized. This second attempt fixes that
issue. Bump catalog version. Author: Atsushi Torikoshi Reviewed-by: Ian
Lawrence Barwick, Robert Haas, Justin Pryzby, Fujii Masao Discussion:
[https://postgr.es/m/a96013dc51cdc56b2a2b84fa8a16a993@oss.nttdata.com](https://postgr.es/m/a96013dc51cdc56b2a2b84fa8a16a993@oss.nttdata.com)
[https://git.postgresql.org/pg/commitdiff/46d6e5f567906389c31c4fb3a2653da1885c18ee](https://git.postgresql.org/pg/commitdiff/46d6e5f567906389c31c4fb3a2653da1885c18ee)

- Fix "invalid spinlock number: 0" error in pg_stat_wal_receiver. Commit
2c8dd05d6c added the atomic variable writtenUpto into walreceiver's shared
memory information. It's initialized only when walreceiver started up but
could be read via pg_stat_wal_receiver view anytime, i.e., even before it's
initialized. In the server built with --disable-atomics and
--disable-spinlocks, this uninitialized atomic variable read could cause
"invalid spinlock number: 0" error. This commit changed writtenUpto so that
it's initialized at the postmaster startup, to avoid the uninitialized
variable read via pg_stat_wal_receiver and fix the error. Also this commit
moved the read of writtenUpto after the release of spinlock protecting
walreceiver's shared variables. This is necessary to prevent new spinlock from
being taken by atomic variable read while holding another spinlock, and to
shorten the spinlock duration. This change leads writtenUpto not to be
consistent with the other walreceiver's shared variables protected by a
spinlock. But this is OK because writtenUpto should not be used for data
integrity checks. Back-patch to v13 where commit 2c8dd05d6c introduced the
bug. Author: Fujii Masao Reviewed-by: Michael Paquier, Thomas Munro, Andres
Freund Discussion:
[https://postgr.es/m/7ef8708c-5b6b-edd3-2cf2-7783f1c7c175@oss.nttdata.com](https://postgr.es/m/7ef8708c-5b6b-edd3-2cf2-7783f1c7c175@oss.nttdata.com)
[https://git.postgresql.org/pg/commitdiff/614b7f18b3bda738f352a8732cf749eb5fa56dae](https://git.postgresql.org/pg/commitdiff/614b7f18b3bda738f352a8732cf749eb5fa56dae)

- Fix bug in COMMIT AND CHAIN command. This commit fixes COMMIT AND CHAIN
command so that it starts new transaction immediately even if savepoints are
defined within the transaction to commit. Previously COMMIT AND CHAIN command
did not in that case because commit 280a408b48 forgot to make
CommitTransactionCommand() handle a transaction chaining when the transaction
state was TBLOCK_SUBCOMMIT. Also this commit adds the regression test for
COMMIT AND CHAIN command when savepoints are defined. Back-patch to v12 where
transaction chaining was added. Reported-by: Arthur Nascimento Author: Fujii
Masao Reviewed-by: Arthur Nascimento, Vik Fearing Discussion:
[https://postgr.es/m/16867-3475744069228158@postgresql.org](https://postgr.es/m/16867-3475744069228158@postgresql.org)
[https://git.postgresql.org/pg/commitdiff/8a55cb5ba9655ffb1cf0a3042aaa6f5eef8c5a85](https://git.postgresql.org/pg/commitdiff/8a55cb5ba9655ffb1cf0a3042aaa6f5eef8c5a85)

- Fix psql's ON_ERROR_ROLLBACK so that it handles COMMIT AND CHAIN. When
ON_ERROR_ROLLBACK is enabled, psql releases a temporary savepoint if it's idle
in a valid transaction block after executing a query. But psql doesn't do that
after RELEASE or ROLLBACK is executed because a temporary savepoint has
already been destroyed in that case. This commit changes psql's
ON_ERROR_ROLLBACK so that it doesn't release a temporary savepoint also when
COMMIT AND CHAIN is executed. A temporary savepoint doesn't need to be
released in that case because COMMIT AND CHAIN also destroys any savepoints
defined within the transaction to commit. Otherwise psql tries to release the
savepoint that COMMIT AND CHAIN has already destroyed and cause an error
"ERROR: savepoint "pg_psql_temporary_savepoint" does not exist". Back-patch
to v12 where transaction chaining was added. Reported-by: Arthur Nascimento
Author: Arthur Nascimento Reviewed-by: Fujii Masao, Vik Fearing Discussion:
[https://postgr.es/m/16867-3475744069228158@postgresql.org](https://postgr.es/m/16867-3475744069228158@postgresql.org)
[https://git.postgresql.org/pg/commitdiff/fe06819f105ccea52c12d418c8dbaaaa54377e96](https://git.postgresql.org/pg/commitdiff/fe06819f105ccea52c12d418c8dbaaaa54377e96)

Heikki Linnakangas pushed:

- Make ExecGetInsertedCols() and friends more robust and improve comments. If
ExecGetInsertedCols(), ExecGetUpdatedCols() or ExecGetExtraUpdatedCols() were
called with a ResultRelInfo that's not in the range table and isn't a
partition routing target, the functions would dereference a NULL pointer,
relinfo->ri_RootResultRelInfo. Such ResultRelInfos are created when firing RI
triggers in tables that are not modified directly. None of the current callers
of these functions pass such relations, so this isn't a live bug, but let's
make them more robust. Also update comment in ResultRelInfo; after commit
6214e2b228, ri_RangeTableIndex is zero for ResultRelInfos created for
partition tuple routing. Noted by Coverity. Backpatch down to v11, like
commit 6214e2b228. Reviewed-by: Tom Lane, Amit Langote
[https://git.postgresql.org/pg/commitdiff/54e51dcde03e5c746e8de6243c69fafdc8d0ec7a](https://git.postgresql.org/pg/commitdiff/54e51dcde03e5c746e8de6243c69fafdc8d0ec7a)

Andres Freund pushed:

- Remove backwards compat ugliness in snapbuild.c. In 955a684e040 we fixed a bug
in initial snapshot creation. In the course of which several members of struct
SnapBuild were obsoleted. As SnapBuild is serialized to disk we couldn't
change the memory layout. Unfortunately I subsequently forgot about removing
the backward compat gunk, but luckily Heikki just reminded me. This commit
bumps SNAPBUILD_VERSION, therefore breaking existing slots (which is fine in a
major release). Author: Andres Freund Reminded-By: Heikki Linnakangas
<hlinnaka(at)iki(dot)fi> Discussion:
[https://postgr.es/m/c94be044-818f-15e3-1ad3-7a7ae2dfed0a@iki.fi](https://postgr.es/m/c94be044-818f-15e3-1ad3-7a7ae2dfed0a@iki.fi)
[https://git.postgresql.org/pg/commitdiff/a975ff4980d60f8cbd8d8cbcff70182ea53e787a](https://git.postgresql.org/pg/commitdiff/a975ff4980d60f8cbd8d8cbcff70182ea53e787a)

- Fix heap_page_prune() parameter order confusion introduced in dc7420c2c92.
Both luckily and unluckily the passed values meant the same for all types.
Luckily because that meant my confusion caused no harm, unluckily because
otherwise the compiler might have warned... In passing, synchronize parameter
names between definition and declaration. Reported-By: Peter Geoghegan
<pg(at)bowt(dot)ie> Author: Andres Freund <andres(at)anarazel(dot)de> Discussion:
[https://postgr.es/m/CAH2-Wz=L=nBoepQdH9b5Qd0nMvepFT2CnT6sjWvvpOXa=K8HVQ@mail.gmail.com](https://postgr.es/m/CAH2-Wz=L=nBoepQdH9b5Qd0nMvepFT2CnT6sjWvvpOXa=K8HVQ@mail.gmail.com)
[https://git.postgresql.org/pg/commitdiff/8001cb77ee6cb4f32632850d41f00206a86bac3e](https://git.postgresql.org/pg/commitdiff/8001cb77ee6cb4f32632850d41f00206a86bac3e)

Peter Eisentraut pushed:

- Use errmsg_internal for debug messages. An inconsistent set of debug-level
messages was not using errmsg_internal(), thus uselessly exposing the messages
to translation work. Fix those.
[https://git.postgresql.org/pg/commitdiff/0e392fcc0d5ab73c81d9284e7dda5acbb7ad6d21](https://git.postgresql.org/pg/commitdiff/0e392fcc0d5ab73c81d9284e7dda5acbb7ad6d21)

- Routine usage information schema tables. Several information schema views
track dependencies between functions/procedures and objects used by them.
These had not been implemented so far because PostgreSQL doesn't track objects
used in a function body. However, formally, these also show dependencies used
in parameter default expressions, which PostgreSQL does support and track. So
for the sake of completeness, we might as well add these. If dependency
tracking for function bodies is ever implemented, these views will
automatically work correctly. Reviewed-by: Erik Rijkers <er(at)xs4all(dot)nl>
Discussion:
[https://www.postgresql.org/message-id/flat/ac80fc74-e387-8950-9a31-2560778fc1e3%40enterprisedb.com](https://www.postgresql.org/message-id/flat/ac80fc74-e387-8950-9a31-2560778fc1e3%40enterprisedb.com)
[https://git.postgresql.org/pg/commitdiff/f40c6969d0eddfc6de786006bd1048961a65a0eb](https://git.postgresql.org/pg/commitdiff/f40c6969d0eddfc6de786006bd1048961a65a0eb)

- Allow specifying CRL directory. Add another method to specify CRLs, hashed
directory method, for both server and client side. This offers a means for
server or libpq to load only CRLs that are required to verify a certificate.
The CRL directory is specifed by separate GUC variables or connection options
ssl_crl_dir and sslcrldir, alongside the existing ssl_crl_file and sslcrl, so
both methods can be used at the same time. Author: Kyotaro Horiguchi
Discussion:
[https://www.postgresql.org/message-id/flat/20200731(dot)173911(dot)904649928639357911(dot)horikyota(dot)ntt(at)gmail(dot)com](https://www.postgresql.org/message-id/flat/20200731(dot)173911(dot)904649928639357911(dot)horikyota(dot)ntt(at)gmail(dot)com)
[https://git.postgresql.org/pg/commitdiff/f5465fade90827534fbd0b795d18dc62e56939e9](https://git.postgresql.org/pg/commitdiff/f5465fade90827534fbd0b795d18dc62e56939e9)

- Add tests for bytea LIKE operator. Add test coverage for the following
operations, which were previously not tested at all: bytea LIKE bytea
(bytealike) bytea NOT LIKE bytea (byteanlike) ESCAPE clause for the above
(like_escape_bytea) also name NOT ILIKE text (nameicnlike) Discussion:
[https://www.postgresql.org/message-id/flat/4d13563a-2c8d-fd91-20d5-e71b7a4eaa87%40enterprisedb.com](https://www.postgresql.org/message-id/flat/4d13563a-2c8d-fd91-20d5-e71b7a4eaa87%40enterprisedb.com)
[https://git.postgresql.org/pg/commitdiff/eb42110d952f8d1ad4049b8f2491e9dfba75ffed](https://git.postgresql.org/pg/commitdiff/eb42110d952f8d1ad4049b8f2491e9dfba75ffed)

- Update snowball. Update to snowball tag v2.1.0. Major changes are new
stemmers for Armenian, Serbian, and Yiddish.
[https://git.postgresql.org/pg/commitdiff/678d0e239b67174f349a401ea7dcecabb3c5b137](https://git.postgresql.org/pg/commitdiff/678d0e239b67174f349a401ea7dcecabb3c5b137)

Magnus Hagander pushed:

- Fix typo. Author: Daniel Gustafsson <daniel(at)yesql(dot)se> Discussion:
[https://postgr.es/m/0CF087FC-BEAD-4010-8BB9-3CDD74DC9060@yesql.se](https://postgr.es/m/0CF087FC-BEAD-4010-8BB9-3CDD74DC9060@yesql.se)
[https://git.postgresql.org/pg/commitdiff/a29f30780f34d7706fcd398dea1d6882d184d17a](https://git.postgresql.org/pg/commitdiff/a29f30780f34d7706fcd398dea1d6882d184d17a)

Tomáš Vondra pushed:

- Fix pointer type in ExecForeignBatchInsert SGML docs. Reported-by: Ian Barwick
Discussion:
[https://postgr.es/m/20200628151002.7x5laxwpgvkyiu3q@development](https://postgr.es/m/20200628151002.7x5laxwpgvkyiu3q@development)
[https://git.postgresql.org/pg/commitdiff/c15283ff429bf318f161bf84768795843b22696d](https://git.postgresql.org/pg/commitdiff/c15283ff429bf318f161bf84768795843b22696d)

- Fix tuple routing to initialize batching only for inserts. A cross-partition
update on a partitioned table is implemented as a delete followed by an
insert. With foreign partitions, this was however causing issues, because the
FDW and core may disagree on when to enable batching. postgres_fdw was only
allowing batching for plain inserts (CMD_INSERT) while core was trying to
batch the insert component of the cross-partition update. Fix by restricting
core to apply batching only to plain CMD_INSERT queries. It's possible to
allow batching for cross-partition updates, but that will require more
extensive changes, so better to leave that for a separate patch. Author: Amit
Langote Reviewed-by: Tomas Vondra, Takayuki Tsunakawa Discussion:
[https://postgr.es/m/20200628151002.7x5laxwpgvkyiu3q@development](https://postgr.es/m/20200628151002.7x5laxwpgvkyiu3q@development)
[https://git.postgresql.org/pg/commitdiff/927f453a941061e3d5884bab206581c34784e45b](https://git.postgresql.org/pg/commitdiff/927f453a941061e3d5884bab206581c34784e45b)

# Pending Patches

Justin Pryzby sent in a patch to remove some dead code in the REINDEX
(CONCURRENTLY, TABLESPACE ..) implementation.

Masahiro Ikeda sent in another revision of a patch to add statistics related to
write/sync wal record, and make the wal receiver report WAL statistics.

Michaël Paquier sent in another revision of a patch to refactor the HMAC
implementations.

Daniel Gustafsson sent in another revision of a patch to support checksum
enable/disable in a running cluster.

Tomáš Vondra sent in another revision of a patch to implement BRIN multi-range
indexes.

Peter Eisentraut sent in another revision of a patch to improve new hash
partition bound check error messages by enhancing the error message "every hash
partition modulus must be a factor of the next larger modulus" with a detail
message that shows the particular numbers involved.

Andrey Borodin sent in another revision of a patch to make all SLRU buffer sizes
configurable.

Justin Pryzby sent in another revision of a patch to allow CREATE INDEX
CONCURRENTLY on partitioned tables.

Takayuki Tsunakawa sent in two more revisions of a patch to speed up COPY FROM
into tables with remote partitions in part by adding and using COPY routines to
the FDW API.

Peter Eisentraut sent in a patch to set SNI for SSL connections from the client.

Mark Rofail and Joel Jacobson traded patches to implement foreign key arrays.

Bharath Rupireddy sent in two more revisions of a patch to implement ALTER
SUBSCRIPTION ... DROP PUBLICATION.

Peter Smith sent in three more revisions of a patch to implement logical
decoding of two-phase transactions.

Peter Geoghegan sent in two more revisions of a patch to use full a 64-bit XID
for nbtree page deletion, recycle pages deleted during the same VACUUM, and show
"pages newly deleted" in VACUUM VERBOSE output.

Amit Langote sent in two more revisions of a patch to ensure that foreign key
triggers are create on partitioned tables, and enforce foreign key constraints
correctly during cross-partition updates.

Greg Nancarrow and Amit Langote traded patches to make it possible to execute
INSERT ... SELECT ... in parallel.

Seamus Abshere and Amit Langote traded patches to allow setting parallel_workers
on partitioned tables.

Michaël Paquier sent in a patch to add no_storage, fallback table AM for
relations without storage.

Tomáš Vondra and Matthias van de Meent traded patches to extend COPY progress
reporting.

Amit Langote sent in another revision of a patch to make updates and deletes on
inheritance trees scale better.

Pavel Stěhule sent in another revision of a patch to implement schema variables.

Pavel Stěhule sent in another revision of a patch to make it possible to read
pg_dump options from a file.

Paul Martinez sent in a patch to document the effect of max_replication_slots on
the subscriber side.

Amit Langote sent in three more revisions of a patch to fix tuple routing to
initialize batching only for inserts.

Andy Fan sent in two more revisions of a patch to Introduce notnullattrs field
in RelOptInfo to indicate which attrs are not null in current query.

Yugo Nagata sent in another revision of a patch to implement incremental
maintenance of materialized views.

David Rowley sent in two more revisions of a patch to add TID Range Scans to
support efficient scanning ranges of TIDs.

Kyotaro HORIGUCHI sent in two revisions of a patch to intended to fix a bug that
manifested as an error in some invocations of ALTER TABLE by correcting the
set of relation types that are actually permitted.

Justin Pryzby and Michaël Paquier traded patches to implement progress reporting
for CREATE INDEX on partitioned tables.

Amit Kapila sent in three more revisions of a patch to distinguishing between
physical and logical replication connections when there is an authentication
failure.

John Naylor sent in four more revisions of a patch to validate UTF-8 using SIMD
instructions.

Vik Fearing sent in three revisions of a patch to implement the SQL standard
TRIM_ARRAY, which removes the last elements from an array.

David Rowley and Andy Fan traded patches to Allow estimate_num_groups() to pass
back further details about the estimation, allow users of simplehash.h to
perform direct deletions, add a Result Cache executor node, and remove some code
duplication in nodeResultCache.c.

Justin Pryzby and Dilip Kumar traded patches to add custom table compression
methods.

Takashi Menjo sent in another revision of a patch to make it possible to use
persistent memory for WAL operations.

Mark Dilger sent in another revision of a patch to add a heapcheck contrib
extension.

Thomas Munro sent in two more revisions of a patch to fix a bug that manifested
as pg_collation_actual_version() ERROR: cache lookup failed for collation 123 by
fixing the way collation providers are handled.

Kyotaro HORIGUCHI sent in another revision of a patch to make it possible to
specify a CRL directory in addition to a CRL file.

Daniel Gustafsson sent in another revision of a patch to make it possible to use
NSS as a TLS backend for libpq.

Álvaro Herrera sent in another revision of a patch to implement batch/pipelining
support in libpq.

Bharath Rupireddy sent in another revision of a patch to add table AMs for
multi- and single inserts, then use same for CTAS, REFRESH MATERIALIZED VIEW,
and COPY.

Tomáš Vondra sent in another revision of a patch to implement extended
statistics on expressions.

Hou Zhijie sent in another revision of a patch to add a new GUC,
enable_parallel_dml (boolean default false), and a new table option,
parallel_dml_enabled (boolean default true). Each do what they say.

Thomas Munro sent in a patch to add sort_template.h for making fast sort
functions.

Amit Langote sent in a patch to allow batching of inserts during cross-partition
updates.

Daniel Gustafsson sent in a patch to disallow SSL compression on the grounds
that it makes cryptanalytic attacks easier to mount.

Peter Eisentraut sent in another revision of a patch to Simplify printing of
LSNs by adding a LSN_FORMAT_ARGS macro for use in printf-style printing of LSNs.

Konstantin Knizhnik sent in another revision of a patch to fix an infelicity
between stored procedures and accesses to TOAST data.

Jan Wieck sent in a patch to add a wire protocol hook and a sample
implementation, telnet.

Guillaume Lelarge sent in another revision of a patch to add an --extension (-e)
option to pg_dump, which specifies an extension to be dumped. It can be used 0
or more times.

Nathan Bossart sent in another revision of a patch to avoid creating archive
status ".ready" files too early, and keep track of notified-ready-for-archive
position through crashes.

Nathan Bossart sent in another revision of a patch to clarify the documentation
of the behavior of RESET ROLE when "role" is set per-user, per-database, or via
command-line options, and add configuration parameter entries for "role"
and "session_authorization".

Paul Guo sent in another revision of a patch to speed up pg_rewind by
fsync()ing only the affected files/directories, and using copy_file_range() for
file copying.

Michaël Paquier sent in another revision of a patch to implement the missing
locking functions for OpenSSL <= 1.0.2.

Iwata Aya sent in another revision of a patch to add tracing to libpq.

Andres Freund sent in another revision of a patch to implement wal prohibit
state using global barriers, Error or Assert before START_CRIT_SECTION for WAL
write, and document the effects of these for transam and page via READMEs.

Georgios Kokolatos sent in another revision of a patch to make dbsize a bit more
consistent.

Denis Smirnov sent in two more revisions of a patch to make the analyze AM more
flexible by allowing for variable-sized blocks.

Paul Guo sent in two revisions of a patch to freeze tuples during CTAS, which
can avert unneeded vacuums.

Andy Fan sent in two more revisions of a patch to make some static functions
extern and extend ChangeVarNodes so it can change var->attno, and build some
implied pruning quals to extend the usecase of planning time partition pruning
and init partition pruning.

Marcus Wanner sent in two revisions of a patch to present empty prepares to the
output plugin.

Ajin Cherian and Marcus Wanner traded patches to preserve the ordering of
PREPAREs vs COMMITs in logical decoding.

Andrew Dunstan sent in another revision of a patch to help track down cfbot
failures by having the make files and the msvc build system create a well-known
file with the location(s) to search for log files if there's an error.

Andy Fan sent in a patch to introduce notnullattrs field in RelOptInfo to
indicate which attrs are not null in current query, and add UniqueKey with
EquivalenceClass for single rel only.

Thomas Munro sent in a patch per Andrew Gierth to remove an outdated reference
to spindles in the description of effective_io_concurrency.

Bharath Rupireddy sent in a patch to update multiple progress params at once.

Vik Fearing sent in two revisions of a patch to implement GROUP BY DISTINCT per
the standard.

Vik Fearing sent in a patch to add catalog version to pg_config along with a new
catalog_version guc, accessible from SQL.