PostgreSQL Weekly News - April 18, 2021

# PostgreSQL Weekly News - April 18, 2021

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

# PostgreSQL Product News

pgmetrics 1.11, a command-line tool for PostgreSQL metrics, released.
[https://pgmetrics.io/](https://pgmetrics.io/)

hypopg 1.2.0, an extension which implements hypothetical indexes, released.
[https://github.com/HypoPG/hypopg/releases](https://github.com/HypoPG/hypopg/releases)

# PostgreSQL Jobs for April

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

# 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:

- Silence some Coverity warnings and improve code consistency. Coverity
complained about possible overflow in expressions like `intresult =
tm->tm_sec * 1000000 + fsec`; on the grounds that the multiplication would
happen in 32-bit arithmetic before widening to the int64 result. I think
these are all false positives because of the limited possible range of tm_sec;
but nonetheless it seems silly to spell it like that when nearby lines have
the identical computation written with a 64-bit constant. ... or more
accurately, with an LL constant, which is not project style. Make all of
these use INT64CONST(), as we do elsewhere. This is all new code from
a2da77cdb, so no need for back-patch.
[https://git.postgresql.org/pg/commitdiff/6277435a8a89c59f716c111200c072d1454b8ff2](https://git.postgresql.org/pg/commitdiff/6277435a8a89c59f716c111200c072d1454b8ff2)

- Fix old bug with coercing the result of a COLLATE expression. There are hacks
in parse_coerce.c to push down a requested coercion to below any CollateExpr
that may appear. However, we did that even if the requested data type is
non-collatable, leading to an invalid expression tree in which CollateExpr is
applied to a non-collatable type. The fix is just to drop the CollateExpr
altogether, reasoning that it's useless. This bug is ten years old, dating to
the original addition of COLLATE support. The lack of field complaints
suggests that there aren't a lot of user-visible consequences. We noticed the
problem because it would trigger an assertion in DefineVirtualRelation if the
invalid structure appears as an output column of a view; however, in a
non-assert build, you don't see a crash just a (subtly incorrect) complaint
about applying collation to a non-collatable type. I found that by putting
the incorrect structure further down in a view, I could make a view definition
that would fail dump/reload, per the added regression test case. But
CollateExpr doesn't do anything at run-time, so this likely doesn't lead to
any really exciting consequences. Per report from Yulin Pei. Back-patch to
all supported branches. Discussion:
[https://postgr.es/m/HK0PR01MB22744393C474D503E16C8509F4709@HK0PR01MB2274.apcprd01.prod.exchangelabs.com](https://postgr.es/m/HK0PR01MB22744393C474D503E16C8509F4709@HK0PR01MB2274.apcprd01.prod.exchangelabs.com)
[https://git.postgresql.org/pg/commitdiff/c402b02b9fb53aee2a26876de90a8f95f9a9be92](https://git.postgresql.org/pg/commitdiff/c402b02b9fb53aee2a26876de90a8f95f9a9be92)

- Remove no-longer-relevant test case. collate.icu.utf8.sql was exercising the
recording of a collation dependency for an enum comparison expression, but
such an expression should never have had any collation dependency in the first
place. After I fixed that in commit c402b02b9, the test started failing. We
don't need to test that scenario anymore, so just remove the now-useless test
steps. (This test case is new in HEAD, so no need to back-patch.)
Discussion:
[https://postgr.es/m/3044030.1618261159@sss.pgh.pa.us](https://postgr.es/m/3044030.1618261159@sss.pgh.pa.us)
Discussion:
[https://postgr.es/m/HK0PR01MB22744393C474D503E16C8509F4709@HK0PR01MB2274.apcprd01.prod.exchangelabs.com](https://postgr.es/m/HK0PR01MB22744393C474D503E16C8509F4709@HK0PR01MB2274.apcprd01.prod.exchangelabs.com)
[https://git.postgresql.org/pg/commitdiff/cf0020080a3de20287217621da57bfd840e9a693](https://git.postgresql.org/pg/commitdiff/cf0020080a3de20287217621da57bfd840e9a693)

- Avoid improbable PANIC during heap_update. heap_update needs to clear any
existing "all visible" flag on the old tuple's page (and on the new page too,
if different). Per coding rules, to do this it must acquire pin on the
appropriate visibility-map page while not holding exclusive buffer lock; which
creates a race condition since someone else could set the flag whenever we're
not holding the buffer lock. The code is supposed to handle that by
re-checking the flag after acquiring buffer lock and retrying if it became
set. However, one code path through heap_update itself, as well as one in its
subroutine RelationGetBufferForTuple, failed to do this. The end result, in
the unlikely event that a concurrent VACUUM did set the flag while we're
transiently not holding lock, is a non-recurring "PANIC: wrong buffer passed
to visibilitymap_clear" failure. This has been seen a few times in the
buildfarm since recent VACUUM changes that added code paths that could set the
all-visible flag while holding only exclusive buffer lock. Previously, the
flag was (usually?) set only after doing LockBufferForCleanup, which would
insist on buffer pin count zero, thus preventing the flag from becoming set
partway through heap_update. However, it's clear that it's heap_update not
VACUUM that's at fault here. What's less clear is whether there is any hazard
from these bugs in released branches. heap_update is certainly violating API
expectations, but if there is no code path that can set all-visible without a
cleanup lock then it's only a latent bug. That's not 100% certain though,
besides which we should worry about extensions or future back-patch fixes that
could introduce such code paths. I chose to back-patch to v12. Fixing
RelationGetBufferForTuple before that would require also back-patching
portions of older fixes (notably 0d1fe9f74), which is more code churn than
seems prudent to fix a hypothetical issue. Discussion:
[https://postgr.es/m/2247102.1618008027@sss.pgh.pa.us](https://postgr.es/m/2247102.1618008027@sss.pgh.pa.us)
[https://git.postgresql.org/pg/commitdiff/34f581c39e97e2ea237255cf75cccebccc02d477](https://git.postgresql.org/pg/commitdiff/34f581c39e97e2ea237255cf75cccebccc02d477)

- Redesign the caching done by get_cached_rowtype(). Previously,
get_cached_rowtype() cached a pointer to a reference-counted tuple descriptor
from the typcache, relying on the ExprContextCallback mechanism to release the
tupdesc refcount when the expression tree using the tupdesc was destroyed.
This worked fine when it was designed, but the introduction of within-DO-block
COMMITs broke it. The refcount is logged in a transaction-lifespan resource
owner, but plpgsql won't destroy simple expressions made within the DO block
(before its first commit) until the DO block is exited. That results in a
warning about a leaked tupdesc refcount when the COMMIT destroys the original
resource owner, and then an error about the active resource owner not holding
a matching refcount when the expression is destroyed. To fix, get rid of the
need to have a shutdown callback at all, by instead caching a pointer to the
relevant typcache entry. Those survive for the life of the backend, so we
needn't worry about the pointer becoming stale. (For registered RECORD types,
we can still cache a pointer to the tupdesc, knowing that it won't change for
the life of the backend.) This mechanism has been in use in plpgsql and
expandedrecord.c since commit 4b93f5799, and seems to work well. This change
requires modifying the ExprEvalStep structs used by the relevant expression
step types, which is slightly worrisome for back-patching. However, there
seems no good reason for extensions to be familiar with the details of these
particular sub-structs. Per report from Rohit Bhogate. Back-patch to v11
where within-DO-block COMMITs became a thing. Discussion:
[https://postgr.es/m/CAAV6ZkQRCVBh8qAY+SZiHnz+U+FqAGBBDaDTjF2yiKa2nJSLKg@mail.gmail.com](https://postgr.es/m/CAAV6ZkQRCVBh8qAY+SZiHnz+U+FqAGBBDaDTjF2yiKa2nJSLKg@mail.gmail.com)
[https://git.postgresql.org/pg/commitdiff/c2db458c1036efae503ce5e451f8369e64c99541](https://git.postgresql.org/pg/commitdiff/c2db458c1036efae503ce5e451f8369e64c99541)

- Fix some inappropriately-disallowed uses of ALTER ROLE/DATABASE SET. Most GUC
check hooks that inspect database state have special checks that prevent them
from throwing hard errors for state-dependent issues when source ==
PGC_S_TEST. This allows, for example, "ALTER DATABASE d SET
default_text_search_config = foo" when the "foo" configuration hasn't been
created yet. Without this, we have problems during dump/reload or pg_upgrade,
because pg_dump has no idea about possible dependencies of GUC values and
can't ensure a safe restore ordering. However, check_role() and
check_session_authorization() hadn't gotten the memo about that, and would
throw hard errors anyway. It's not entirely clear what is the use-case for
"ALTER ROLE x SET role = y", but we've now heard two independent complaints
about that bollixing an upgrade, so apparently some people are doing it.
Hence, fix these two functions to act more like other check hooks with similar
needs. (But I did not change their insistence on being inside a transaction,
as it's still not apparent that setting either GUC from the configuration file
would be wise.) Also fix check_temp_buffers, which had a different form of
the disease of making state-dependent checks without any exception for
PGC_S_TEST. A cursory survey of other GUC check hooks did not find any more
issues of this ilk. (There are a lot of interdependencies among
PGC_POSTMASTER and PGC_SIGHUP GUCs, which may be a bad idea, but they're not
relevant to the immediate concern because they can't be set via ALTER
ROLE/DATABASE.) Per reports from Charlie Hornsby and Nathan Bossart.
Back-patch to all supported branches. Discussion:
[https://postgr.es/m/HE1P189MB0523B31598B0C772C908088DB7709@HE1P189MB0523.EURP189.PROD.OUTLOOK.COM](https://postgr.es/m/HE1P189MB0523B31598B0C772C908088DB7709@HE1P189MB0523.EURP189.PROD.OUTLOOK.COM)
Discussion:
[https://postgr.es/m/20160711223641.1426.86096@wrigleys.postgresql.org](https://postgr.es/m/20160711223641.1426.86096@wrigleys.postgresql.org)
[https://git.postgresql.org/pg/commitdiff/69d5ca484b69771073380e234e5377b6d6a5ebaf](https://git.postgresql.org/pg/commitdiff/69d5ca484b69771073380e234e5377b6d6a5ebaf)

- Allow table-qualified variable names in ON CONFLICT ... WHERE. Previously you
could only use unqualified variable names here. While that's not a functional
deficiency, since only the target table can be referenced, it's a surprising
inconsistency with the rules for partial-index predicates, on which this
syntax is supposedly modeled. The fix for that is no harder than passing
addToRelNameSpace = true to addNSItemToQuery. However, it's really pretty
bogus for transformOnConflictArbiter and transformOnConflictClause to be
messing with the namespace item for the target table at all. It's not theirs
to manage, it results in duplicative creations of namespace items, and
transformOnConflictClause wasn't even doing it quite correctly (that coding
resulted in two nsitems for the target table, since it hadn't cleaned out the
existing one). Hence, make transformInsertStmt responsible for setting up the
target nsitem once for both these clauses and RETURNING. Also, arrange for ON
CONFLICT ... UPDATE's "excluded" pseudo-relation to be added to the rangetable
before we run transformOnConflictArbiter. This produces a more helpful HINT if
someone writes "excluded.col" in the arbiter expression. Per bug #16958 from
Lukas Eder. Although I agree this is a bug, the consequences are hardly
severe, so no back-patch. Discussion:
[https://postgr.es/m/16958-963f638020de271c@postgresql.org](https://postgr.es/m/16958-963f638020de271c@postgresql.org)
[https://git.postgresql.org/pg/commitdiff/6c0373ab77359c94b279c4e67c91aa623841af65](https://git.postgresql.org/pg/commitdiff/6c0373ab77359c94b279c4e67c91aa623841af65)

- Fix obsolete comments referencing JoinPathExtraData.extra_lateral_rels. That
field went away in commit edca44b15, but it seems that commit 45be99f8c
re-introduced some comments mentioning it. Noted by James Coleman, though this
isn't exactly his proposed new wording. Also thanks to Justin Pryzby for
software archaeology. Discussion:
[https://postgr.es/m/CAAaqYe8fxZjq3na+XkNx4C78gDqykH-7dbnzygm9Qa9nuDTePg@mail.gmail.com](https://postgr.es/m/CAAaqYe8fxZjq3na+XkNx4C78gDqykH-7dbnzygm9Qa9nuDTePg@mail.gmail.com)
[https://git.postgresql.org/pg/commitdiff/e1623b7d86812ee6ab98a42f38b43a192c149988](https://git.postgresql.org/pg/commitdiff/e1623b7d86812ee6ab98a42f38b43a192c149988)

- Stabilize recently-added information_schema test queries. These queries could
show unexpected entries if the core system, or concurrently-running test
scripts, created any functions that would appear in the information_schema
views. Restrict them to showing functions belonging to this test's schema, as
the far-older nearby test case does. Per experimentation with conversion of
some built-in functions to SQL-function-body style.
[https://git.postgresql.org/pg/commitdiff/3157cbe974846729d49a1ee081944eee1839bdd8](https://git.postgresql.org/pg/commitdiff/3157cbe974846729d49a1ee081944eee1839bdd8)

- Undo decision to allow pg_proc.prosrc to be NULL. Commit e717a9a18 changed the
longstanding rule that prosrc is NOT NULL because when a SQL-language function
is written in SQL-standard style, we don't currently have anything useful to
put there. This seems a poor decision though, as it could easily have
negative impacts on external PLs (opening them to crashes they didn't use to
have, for instance). SQL-function-related code can just as easily test "is
prosqlbody not null" as "is prosrc null", so there's no real gain there
either. Hence, revert the NOT NULL marking removal and adjust related logic.
For now, we just put an empty string into prosrc for SQL-standard functions.
Maybe we'll have a better idea later, although the history of things like
pg_attrdef.adsrc suggests that it's not easy to maintain a string equivalent
of a node tree. This also adds an assertion that queryDesc->sourceText !=
NULL to standard_ExecutorStart. We'd been silently relying on that for
awhile, so let's make it less silent. Also fix some overlooked documentation
and test cases. Discussion:
[https://postgr.es/m/2197698.1617984583@sss.pgh.pa.us](https://postgr.es/m/2197698.1617984583@sss.pgh.pa.us)
[https://git.postgresql.org/pg/commitdiff/1111b2668d89bfcb6f502789158b1233ab4217a6](https://git.postgresql.org/pg/commitdiff/1111b2668d89bfcb6f502789158b1233ab4217a6)

- Revert "Cope with NULL query string in ExecInitParallelPlan().". This reverts
commit b3ee4c503872f3d0a5d6a7cbde48815f555af15b. We don't need it in the wake
of the preceding commit, which added an upstream check that the querystring
isn't null. Discussion:
[https://postgr.es/m/2197698.1617984583@sss.pgh.pa.us](https://postgr.es/m/2197698.1617984583@sss.pgh.pa.us)
[https://git.postgresql.org/pg/commitdiff/83efce7a1ebc5bae79617ddba12a64790141725c](https://git.postgresql.org/pg/commitdiff/83efce7a1ebc5bae79617ddba12a64790141725c)

- Provide query source text when parsing a SQL-standard function body. Without
this, we lose error cursor positions, as shown in the modified regression test
result. Discussion:
[https://postgr.es/m/2197698.1617984583@sss.pgh.pa.us](https://postgr.es/m/2197698.1617984583@sss.pgh.pa.us)
[https://git.postgresql.org/pg/commitdiff/409723365b2708acd3bdf2e830257504bdefac4b](https://git.postgresql.org/pg/commitdiff/409723365b2708acd3bdf2e830257504bdefac4b)

- Fix wrong units in two ExplainPropertyFloat calls. This is only a latent bug,
since these calls are only reached for non-text output formats, and currently
none of those will print the units. Still, we should get it right in case
that ever changes. Justin Pryzby Discussion:
[https://postgr.es/m/20210415163846.GA3315@telsasoft.com](https://postgr.es/m/20210415163846.GA3315@telsasoft.com)
[https://git.postgresql.org/pg/commitdiff/f90c708a048667befbf6bbe5f48ae9695cb89de4](https://git.postgresql.org/pg/commitdiff/f90c708a048667befbf6bbe5f48ae9695cb89de4)

- Fix bogus collation-version-recording logic. recordMultipleDependencies had
the wrong scope for its "version" variable, allowing a version label to leak
from the collation entry it was meant for to subsequent non-collation entries.
This is relatively hard to trigger because of the OID-descending order that
the inputs will normally arrive in: subsequent non-collation items will tend
to be pinned. But it can be exhibited easily with a custom collation. Also,
don't special-case the default collation, but instead ignore pinned-ness of a
collation when we've found a version for it. This avoids creating useless
pg_depend entries, and removes a not-very- future-proof assumption that C,
POSIX, and DEFAULT are the only pinned collations. A small problem is that,
because the default collation may or may not have a version, the regression
tests can't assume anything about whether dependency entries will be made for
it. This seems OK though since it's now handled just the same as other
collations, and we have test cases for both versioned and unversioned
collations. Fixes oversights in commit 257836a75. Thanks to Julien Rouhaud
for review. Discussion:
[https://postgr.es/m/3564817.1618420687@sss.pgh.pa.us](https://postgr.es/m/3564817.1618420687@sss.pgh.pa.us)
[https://git.postgresql.org/pg/commitdiff/ef387bed87f2787b1012e68e9a33607a1074c123](https://git.postgresql.org/pg/commitdiff/ef387bed87f2787b1012e68e9a33607a1074c123)

- Split function definitions out of system_views.sql into a new file. Invent
system_functions.sql to carry the function definitions that were formerly in
system_views.sql. The function definitions were already a quarter of the file
and are about to be more, so it seems appropriate to give them their own home.
In passing, fix an oversight in dfb75e478: it neglected to call check_input()
for system_constraints.sql. Discussion:
[https://postgr.es/m/3956760.1618529139@sss.pgh.pa.us](https://postgr.es/m/3956760.1618529139@sss.pgh.pa.us)
[https://git.postgresql.org/pg/commitdiff/e80949372564c126c92aa7d64de483e04c0ef95e](https://git.postgresql.org/pg/commitdiff/e80949372564c126c92aa7d64de483e04c0ef95e)

- Convert built-in SQL-language functions to SQL-standard-body style. Adopt the
new pre-parsed representation for all built-in and information_schema
SQL-language functions, except for a small number that can't presently be
converted because they have polymorphic arguments. This eliminates residual
hazards around search-path safety of these functions, and might provide some
small performance benefits by reducing parsing costs. It seems useful also to
provide more test coverage for the SQL-standard-body feature. Discussion:
[https://postgr.es/m/3956760.1618529139@sss.pgh.pa.us](https://postgr.es/m/3956760.1618529139@sss.pgh.pa.us)
[https://git.postgresql.org/pg/commitdiff/767982e36298be4da44a063e36261e9cfdc0bf49](https://git.postgresql.org/pg/commitdiff/767982e36298be4da44a063e36261e9cfdc0bf49)

- Update dummy prosrc values. Ooops, forgot to
s/system_views.sql/system_functions.sql/g in this part of 767982e36. No need
for an additional catversion bump, I think, since these strings are gone by
the time initdb finishes. Discussion:
[https://postgr.es/m/3956760.1618529139@sss.pgh.pa.us](https://postgr.es/m/3956760.1618529139@sss.pgh.pa.us)
[https://git.postgresql.org/pg/commitdiff/8a2df442b652f83b1c189822737091b90f343965](https://git.postgresql.org/pg/commitdiff/8a2df442b652f83b1c189822737091b90f343965)

- Rethink extraction of collation dependencies. As it stands,
find_expr_references_walker() pays attention to leaf-node collation fields
while ignoring the input collations of actual function and operator nodes.
That seems exactly backwards from a semantic standpoint, and it leads to
reporting dependencies on collations that really have nothing to do with the
expression's behavior. Hence, rewrite to look at function input collations
instead. This isn't completely perfect either; it fails to account for the
behavior of record_eq and its siblings. (The previous coding at least gave an
approximation of that, though I think it could be fooled pretty easily into
considering the columns of irrelevant composite types.) We may be able to
improve on this later, but for now this should satisfy the buildfarm members
that didn't like ef387bed8. In passing fix some oversights in
GetTypeCollations(), and get rid of its duplicative de-duplications. (I'm
worried that it's still potentially O(N^2) or worse, but this makes it a
little better.) Discussion:
[https://postgr.es/m/3564817.1618420687@sss.pgh.pa.us](https://postgr.es/m/3564817.1618420687@sss.pgh.pa.us)
[https://git.postgresql.org/pg/commitdiff/f24b156997059c257c697b825f022d115825091d](https://git.postgresql.org/pg/commitdiff/f24b156997059c257c697b825f022d115825091d)

Michaël Paquier pushed:

- Fix out-of-bound memory access for interval -> char conversion. Using Roman
numbers (via "RM" or "rm") for a conversion to calculate a number of months
has never considered the case of negative numbers, where a conversion could
easily cause out-of-bound memory accesses. The conversions in themselves were
not completely consistent either, as specifying 12 would result in NULL, but
it should mean XII. This commit reworks the conversion calculation to have a
more consistent behavior: - If the number of months and years is 0, return
NULL. - If the number of months is positive, return the exact month number. -
If the number of months is negative, do a backward calculation, with -1
meaning December, -2 November, etc. Reported-by: Theodor Arsenij
Larionov-Trichkin Author: Julien Rouhaud Discussion:
[https://postgr.es/m/16953-f255a18f8c51f1d5@postgresql.org](https://postgr.es/m/16953-f255a18f8c51f1d5@postgresql.org)
backpatch-through: 9.6
[https://git.postgresql.org/pg/commitdiff/7a3972597f6ed7a6976d81abb66c38a7a1c29058](https://git.postgresql.org/pg/commitdiff/7a3972597f6ed7a6976d81abb66c38a7a1c29058)

- Move log_autovacuum_min_duration into its correct sections. This GUC has
already been classified as LOGGING_WHAT, but its location in
postgresql.conf.sample and the documentation did not reflect that, so fix
those inconsistencies. Author: Justin Pryzby Discussion:
[https://postgr.es/m/20210404012546.GK6592@telsasoft.com](https://postgr.es/m/20210404012546.GK6592@telsasoft.com)
[https://git.postgresql.org/pg/commitdiff/b094063cd16d22b2f065a432580bb3568b2d8a77](https://git.postgresql.org/pg/commitdiff/b094063cd16d22b2f065a432580bb3568b2d8a77)

- Remove duplicated --no-sync switches in new tests of test_pg_dump. These got
introduced in 6568cef. Reported-by: Noah Misch Discussion:
[https://postgr.es/m/20210404220802.GA728316@rfd.leadboat.com](https://postgr.es/m/20210404220802.GA728316@rfd.leadboat.com)
[https://git.postgresql.org/pg/commitdiff/885a87641930778d9580fdf0656af24e3f52d276](https://git.postgresql.org/pg/commitdiff/885a87641930778d9580fdf0656af24e3f52d276)

- Simplify tests of postgres_fdw terminating connections. The tests introduced
in 32a9c0b for connections broken and re-established rely on
pg_terminate_backend() for their logic. When these were introduced, this
function simply sent a signal to a backend without waiting for the operation
to complete, and the tests repeatedly looked at pg_stat_activity to check if
the operation was completed or not. Since aaf0432, it is possible to define a
timeout to make pg_terminate_backend() wait for a certain duration, so make
use of it, with a timeout reasonably large enough (3min) to give enough room
for the tests to pass even on slow machines. Some measurements show that the
tests of postgres_fdw are much faster with this change. For example, on my
laptop, they now take 4s instead of 6s. Author: Bharath Rupireddy Discussion:
[https://postgr.es/m/CALj2ACXGY_EfGrMTjKjHy2zi-u1u9rdeioU_fro0T6Jo8t56KQ@mail.gmail.com](https://postgr.es/m/CALj2ACXGY_EfGrMTjKjHy2zi-u1u9rdeioU_fro0T6Jo8t56KQ@mail.gmail.com)
[https://git.postgresql.org/pg/commitdiff/93f41461449f917da20af4fa2973f8afe8e6ea6e](https://git.postgresql.org/pg/commitdiff/93f41461449f917da20af4fa2973f8afe8e6ea6e)

- doc: Move force_parallel_mode to section for developer options. This GUC has
always been classified as a planner option since its introduction in 7c944bd,
and was listed in postgresql.conf.sample. As this parameter exists for
testing purposes, move it to the section dedicated to developer parameters and
hence remove it from postgresql.conf.sample. This will avoid any temptation
to play with it on production servers for users that should never really have
to touch this parameter. The general description used for developer options
is reworded a bit, to take into account the inclusion of force_parallel_mode,
per a suggestion from Tom Lane. Per discussion between Tom Lane, Bruce
Momjian, Justin Pryzby, Bharath Rupireddy and me. Author: Justin Pryzby, Tom
Lane Discussion:
[https://postgr.es/m/20210403152402.GA8049@momjian.us](https://postgr.es/m/20210403152402.GA8049@momjian.us)
[https://git.postgresql.org/pg/commitdiff/ac725ee0f98c3fec703ffd9b070da629608e9a1e](https://git.postgresql.org/pg/commitdiff/ac725ee0f98c3fec703ffd9b070da629608e9a1e)

- Tweak behavior of pg_dump --extension with configuration tables. 6568cef, that
introduced the option, had an inconsistent behavior when it comes to
configuration tables set up by pg_extension_config_dump, as the data of all
configuration tables would included in a dump even for extensions not listed
by a set of --extension switches. The contents dumped changed depending on
the schema where an extension was installed when an extension was not listed.
For example, an extension installed under the public schema would have its
configuration data not dumped even when not listed with --extension, which was
inconsistent with the case of an extension installed on a non-public schema,
where the configuration would be dumped. Per discussion with Noah, we have
settled down to the simple rule of dumping configuration data of an extension
if it is listed in --extension (default is unchanged and backward-compatible,
to dump everything on sight if there are no extensions directly listed). This
avoids some weird cases where the dumps depended on a --schema for one. More
tests are added to cover the gap, where we cross-check more behaviors
depending on --schema when an extension is not listed. Reported-by: Noah
Misch Reviewed-by: Noah Misch Discussion:
[https://postgr.es/m/20210404220802.GA728316@rfd.leadboat.com](https://postgr.es/m/20210404220802.GA728316@rfd.leadboat.com)
[https://git.postgresql.org/pg/commitdiff/344487e2db03f3cec13685a839dbc8a0e2a36750](https://git.postgresql.org/pg/commitdiff/344487e2db03f3cec13685a839dbc8a0e2a36750)

- doc: Simplify example of HISTFILE for psql. e4c7619 has added a space to the
example used for HISTFILE in the docs of psql before the variable DBNAME, as a
workaround because variables were not parsed the same way back then. This
behavior has changed in 9.2, causing the example in the psql docs to result in
the same history file created with or without a space added before the DBNAME
variable. Let's just remove this space in the example, to reduce any
confusion, as the point of it is to prove that a per-database history file is
easy to set up, and that's easier to read this way. Per discussion with Tom
Lane. Reported-by: Ludovic Kuty Discussion:
[https://postgr.es/m/161830067409.691.16198363670687811485@wrigleys.postgresql.org](https://postgr.es/m/161830067409.691.16198363670687811485@wrigleys.postgresql.org)
[https://git.postgresql.org/pg/commitdiff/1840d9f4c89998872a3b46473f8e9e5b6ff3c144](https://git.postgresql.org/pg/commitdiff/1840d9f4c89998872a3b46473f8e9e5b6ff3c144)

- doc: Fix typo in example query of SQL/JSON. Author: Erik Rijkers Discussion:
[https://postgr.es/m/1219476687.20432.1617452918468@webmailclassic.xs4all.nl](https://postgr.es/m/1219476687.20432.1617452918468@webmailclassic.xs4all.nl)
Backpatch-through: 12
[https://git.postgresql.org/pg/commitdiff/254a2164e5b216ecf98882f8bcb9e239ab2d432d](https://git.postgresql.org/pg/commitdiff/254a2164e5b216ecf98882f8bcb9e239ab2d432d)

Amit Kapila pushed:

- doc: Update information of new messages for logical replication. Updated
documentation for new messages added for streaming of in-progress
transactions, as well as changes made to the existing messages. It also
updates the information of protocol versions supported for logical
replication. Author: Ajin Cherian Reviewed-by: Amit Kapila, Peter Smith,
Euler Taveira Discussion:
[https://postgr.es/m/CAFPTHDYHN9m=MZZct-B=BYg_TETvv+kXvL9RD2DpaBS5pGxGYg@mail.gmail.com](https://postgr.es/m/CAFPTHDYHN9m=MZZct-B=BYg_TETvv+kXvL9RD2DpaBS5pGxGYg@mail.gmail.com)
[https://git.postgresql.org/pg/commitdiff/15c1a9d9cb7604472d4823f48b64cdc02c441194](https://git.postgresql.org/pg/commitdiff/15c1a9d9cb7604472d4823f48b64cdc02c441194)

- Use NameData datatype for slotname in stats. This will make it consistent with
the other usage of slotname in the code. In the passing, change
pgstat_report_replslot signature to use a structure rather than multiple
parameters. Reported-by: Andres Freund Author: Vignesh C Reviewed-by: Sawada
Masahiko, Amit Kapila Discussion:
[https://postgr.es/m/20210319185247.ldebgpdaxsowiflw@alap3.anarazel.de](https://postgr.es/m/20210319185247.ldebgpdaxsowiflw@alap3.anarazel.de)
[https://git.postgresql.org/pg/commitdiff/cca57c1d9bf7eeba5b81115e0b82651cf3d8e4ea](https://git.postgresql.org/pg/commitdiff/cca57c1d9bf7eeba5b81115e0b82651cf3d8e4ea)

- Add information of total data processed to replication slot stats. This adds
the statistics about total transactions count and total transaction data
logically sent to the decoding output plugin from ReorderBuffer. Users can
query the pg_stat_replication_slots view to check these stats. Suggested-by:
Andres Freund Author: Vignesh C and Amit Kapila Reviewed-by: Sawada Masahiko,
Amit Kapila Discussion:
[https://postgr.es/m/20210319185247.ldebgpdaxsowiflw@alap3.anarazel.de](https://postgr.es/m/20210319185247.ldebgpdaxsowiflw@alap3.anarazel.de)
[https://git.postgresql.org/pg/commitdiff/f5fc2f5b23d1b1dff60f8ca5dc211161df47eda4](https://git.postgresql.org/pg/commitdiff/f5fc2f5b23d1b1dff60f8ca5dc211161df47eda4)

Fujii Masao pushed:

- Support tab-complete for TRUNCATE on foreign tables. Commit 8ff1c94649
extended TRUNCATE command so that it can also truncate foreign tables. But it
forgot to support tab-complete for TRUNCATE on foreign tables. That is,
previously tab-complete for TRUNCATE displayed only the names of regular
tables. This commit improves tab-complete for TRUNCATE so that it displays
also the names of foreign tables. Author: Fujii Masao Reviewed-by: Bharath
Rupireddy Discussion:
[https://postgr.es/m/551ed8c1-f531-818b-664a-2cecdab99cd8@oss.nttdata.com](https://postgr.es/m/551ed8c1-f531-818b-664a-2cecdab99cd8@oss.nttdata.com)
[https://git.postgresql.org/pg/commitdiff/81e094bdfdd6cf6568cba2b25eea9876daceaacb](https://git.postgresql.org/pg/commitdiff/81e094bdfdd6cf6568cba2b25eea9876daceaacb)

- doc: Fix typo in logicaldecoding.sgml. Introduced in commit 0aa8a01d04.
Author: Peter Smith Discussion:
[https://postgr.es/m/CAHut+Ps8rkVHKWyjg09Fb1PaVG5-EhoFTFJ9OZMF4HPzDSXfew@mail.gmail.com](https://postgr.es/m/CAHut+Ps8rkVHKWyjg09Fb1PaVG5-EhoFTFJ9OZMF4HPzDSXfew@mail.gmail.com)
[https://git.postgresql.org/pg/commitdiff/5fe83adad9efd5e3929f0465b44e786dc23c7b55](https://git.postgresql.org/pg/commitdiff/5fe83adad9efd5e3929f0465b44e786dc23c7b55)

- doc: Add missing COMPRESSION into CREATE TABLE synopsis. Commit bbe0a81db6
introduced "INCLUDING COMPRESSION" option in CREATE TABLE command, but forgot
to mention it in the CREATE TABLE syntax synopsis. Author: Fujii Masao
Reviewed-by: Michael Paquier Discussion:
[https://postgr.es/m/54d30e66-dbd6-5485-aaf6-a291ed55919d@oss.nttdata.com](https://postgr.es/m/54d30e66-dbd6-5485-aaf6-a291ed55919d@oss.nttdata.com)
[https://git.postgresql.org/pg/commitdiff/e2e2efca85b4857361780ed0c736c2a44edb458a](https://git.postgresql.org/pg/commitdiff/e2e2efca85b4857361780ed0c736c2a44edb458a)

Peter Eisentraut pushed:

- Fix files references in nls.mk. broken by
37d2ff38031262a1778bc76a9c55fff7afbcf275
[https://git.postgresql.org/pg/commitdiff/44c8a3d75997b08fa7645dac7ee5c7a918a235c7](https://git.postgresql.org/pg/commitdiff/44c8a3d75997b08fa7645dac7ee5c7a918a235c7)

- pg_amcheck: Add basic NLS support.
[https://git.postgresql.org/pg/commitdiff/fc0fefbfe0d7e805f6a3a4aaaad7127090fcca51](https://git.postgresql.org/pg/commitdiff/fc0fefbfe0d7e805f6a3a4aaaad7127090fcca51)

- pg_upgrade: Print OID using %u instead of %d. This could write wrong output
into the cluster deletion script if a database OID exceeds the signed 32-bit
range.
[https://git.postgresql.org/pg/commitdiff/6787e53fe59eed19095c771a8d3323fb59420733](https://git.postgresql.org/pg/commitdiff/6787e53fe59eed19095c771a8d3323fb59420733)

- Improve quoting in some error messages.
[https://git.postgresql.org/pg/commitdiff/07e5e66742333ab100a557e6e3f710e92fa1fd92](https://git.postgresql.org/pg/commitdiff/07e5e66742333ab100a557e6e3f710e92fa1fd92)

- amcheck: Use correct format placeholder for TOAST chunk numbers. Several of
these were already fixed in passing in
9acaf1a62197205b06a85afbfcaa7ffaac939ef3, but one was remaining inconsistent.
[https://git.postgresql.org/pg/commitdiff/59da8d9eb7255c3cb1c9f3b79d76b18b6a1c7da2](https://git.postgresql.org/pg/commitdiff/59da8d9eb7255c3cb1c9f3b79d76b18b6a1c7da2)

- pg_upgrade: Small fix for better translatability of help output.
[https://git.postgresql.org/pg/commitdiff/cbae8774eb5c2f5552323ee18ca5286f9c8e5d06](https://git.postgresql.org/pg/commitdiff/cbae8774eb5c2f5552323ee18ca5286f9c8e5d06)

- Revert "psql: Show all query results by default". This reverts commit
3a5130672296ed4e682403a77a9a3ad3d21cef75. Per discussion, this patch had too
many issues to resolve at this point of the development cycle. We'll try
again in the future. Discussion:
[https://www.postgresql.org/message-id/flat/alpine(dot)DEB(dot)2(dot)21(dot)1904132231510(dot)8961(at)lancre](https://www.postgresql.org/message-id/flat/alpine(dot)DEB(dot)2(dot)21(dot)1904132231510(dot)8961(at)lancre)
[https://git.postgresql.org/pg/commitdiff/fae65629cec824738ee11bf60f757239906d64fa](https://git.postgresql.org/pg/commitdiff/fae65629cec824738ee11bf60f757239906d64fa)

- psql: Small fixes for better translatability.
[https://git.postgresql.org/pg/commitdiff/25593d7d338232fb855ba563b325237de8f14091](https://git.postgresql.org/pg/commitdiff/25593d7d338232fb855ba563b325237de8f14091)

- psql: Refine lexing of BEGIN...END blocks in CREATE FUNCTION statements. Only
track BEGIN...END blocks if they are in a CREATE [OR REPLACE]
{FUNCTION|PROCEDURE} statement. Ignore if in parentheses. Reviewed-by:
Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> Discussion:
[https://www.postgresql.org/message-id/cee01d26fe55bc086b3bcf10bfe4e8d450e2f608.camel@cybertec.at](https://www.postgresql.org/message-id/cee01d26fe55bc086b3bcf10bfe4e8d450e2f608.camel@cybertec.at)
[https://git.postgresql.org/pg/commitdiff/029c5ac03db72f1898ee17e417650a2e0764b239](https://git.postgresql.org/pg/commitdiff/029c5ac03db72f1898ee17e417650a2e0764b239)

- Use correct format placeholder for block numbers. Should be %u rather than %d.
[https://git.postgresql.org/pg/commitdiff/f59b58e2a1b7e4a48dee36cc61966759da0faedd](https://git.postgresql.org/pg/commitdiff/f59b58e2a1b7e4a48dee36cc61966759da0faedd)

- doc: Fix up spacing around verbatim DocBook elements.
[https://git.postgresql.org/pg/commitdiff/f7c09706c14d0858d5a186f3cc769471cba41578](https://git.postgresql.org/pg/commitdiff/f7c09706c14d0858d5a186f3cc769471cba41578)

- Add missing source files to nls.mk.
[https://git.postgresql.org/pg/commitdiff/4ed7f0599a8984d9ed967780a157d9b23d03fbb5](https://git.postgresql.org/pg/commitdiff/4ed7f0599a8984d9ed967780a157d9b23d03fbb5)

Thomas Munro pushed:

- Fix potential SSI hazard in heap_update(). Commit 6f38d4dac38 failed to heed a
warning about the stability of the value pointed to by "otid". The caller is
allowed to pass in a pointer to newtup->t_self, which will be updated during
the execution of the function. Instead, the SSI check should use the value we
copy into oldtup.t_self near the top of the function. Not a live bug, because
newtup->t_self doesn't really get updated until a bit later, but it was
confusing and broke the rule established by the comment. Back-patch to 13.
Reported-by: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> Discussion:
[https://postgr.es/m/2689164.1618160085%40sss.pgh.pa.us](https://postgr.es/m/2689164.1618160085%40sss.pgh.pa.us)
[https://git.postgresql.org/pg/commitdiff/b1df6b696b759f00ebbf02e6de64e259d4be5785](https://git.postgresql.org/pg/commitdiff/b1df6b696b759f00ebbf02e6de64e259d4be5785)

- Doc: Document known problem with Windows collation versions. Warn users that
locales with traditional Windows NLS names like "English_United States.1252"
won't provide version information, and that something like initdb
--lc-collate=en-US would be needed to fix that problem for the initial
template databases. Discussion:
[https://postgr.es/m/CA%2BhUKGJ_hk3rU%3D%3Dg2FpAMChb_4i%2BTJacpjjqFsinY-tRM3FBmA%40mail.gmail.com](https://postgr.es/m/CA%2BhUKGJ_hk3rU%3D%3Dg2FpAMChb_4i%2BTJacpjjqFsinY-tRM3FBmA%40mail.gmail.com)
[https://git.postgresql.org/pg/commitdiff/1bf946bd43e545b86e567588b791311fe4e36a8c](https://git.postgresql.org/pg/commitdiff/1bf946bd43e545b86e567588b791311fe4e36a8c)

Noah Misch pushed:

- Port regress-python3-mangle.mk to Solaris "sed". It doesn't support `"\(foo\)*"`
like a POSIX "sed" implementation does; see the Autoconf manual. Back-patch
to 9.6 (all supported versions).
[https://git.postgresql.org/pg/commitdiff/c3556f6fac349b31da2fd00107469ce36fb37536](https://git.postgresql.org/pg/commitdiff/c3556f6fac349b31da2fd00107469ce36fb37536)

- Use "-I." in directories holding Bison parsers, for Oracle compilers. With the
Oracle Developer Studio 12.6 compiler, #line directives alter the current
source file location for purposes of #include "..." directives. Hence, a
VPATH build failed with 'cannot find include file: "specscanner.c"'. With two
exceptions, parser-containing directories already add "-I. -I$(srcdir)";
eliminate the exceptions. Back-patch to 9.6 (all supported versions).
[https://git.postgresql.org/pg/commitdiff/455dbc010be53ac61fcb2da83b1e565f4c263449](https://git.postgresql.org/pg/commitdiff/455dbc010be53ac61fcb2da83b1e565f4c263449)

Robert Haas pushed:

- docs: Update TOAST storage docs for configurable compression. Mention that
there are multiple TOAST compression methods and that the compression method
used is stored in a TOAST pointer along with the other information that was
stored there previously. Add a reference to the documentation for
default_toast_compression, where the supported methods are listed, instead of
duplicating that here. I haven't tried to preserve the text claiming that
pglz is "fairly simple and very fast." I have no view on the veracity of the
former claim, but LZ4 seems to be faster (and to compress better) so it seems
better not to muddy the waters by talking about compression speed as a strong
point of PGLZ. Patch by me, reviewed by Justin Pryzby. Discussion:
[http://postgr.es/m/CA+Tgmoaw_YBwQhOS_hhEPPwFhfAnu+VCLs18EfGr9gQw1z4H-w@mail.gmail.com](http://postgr.es/m/CA+Tgmoaw_YBwQhOS_hhEPPwFhfAnu+VCLs18EfGr9gQw1z4H-w@mail.gmail.com)
[https://git.postgresql.org/pg/commitdiff/e8c435a824e123f43067ce6f69d66f14cfb8815e](https://git.postgresql.org/pg/commitdiff/e8c435a824e123f43067ce6f69d66f14cfb8815e)

- amcheck: Reword some messages and fix an alignment problem. We don't need to
mention the attribute number in these messages, because there's a dedicated
column for that, but we should mention the toast value ID, because that's
really useful for any follow-up troubleshooting the user wants to do. This
also rewords some of the messages to hopefully read a little better. Also,
use VARATT_EXTERNAL_GET_POINTER in case we're accessing a TOAST pointer that
isn't aligned on a platform that's fussy about alignment, so that we don't
crash while corruption-checking the user's data. Mark Dilger, reviewed by me.
Discussion:
[http://postgr.es/m/7D3B9BF6-50D0-4C30-8506-1C1851C7F96F@enterprisedb.com](http://postgr.es/m/7D3B9BF6-50D0-4C30-8506-1C1851C7F96F@enterprisedb.com)
[https://git.postgresql.org/pg/commitdiff/9acaf1a62197205b06a85afbfcaa7ffaac939ef3](https://git.postgresql.org/pg/commitdiff/9acaf1a62197205b06a85afbfcaa7ffaac939ef3)

Peter Geoghegan pushed:

- Don't truncate heap when VACUUM's failsafe is in effect. It seems like a good
idea to bypass heap truncation when the wraparound failsafe mechanism (which
was added in commit 1e55e7d1) is in effect. Deliberately don't bypass heap
truncation in the INDEX_CLEANUP=off case, even though it is similar to the
failsafe case. There is already a separate reloption (and related VACUUM
parameter) for that. Reported-By: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
Discussion:
[https://postgr.es/m/CAD21AoDWRh6oTN5T8wa+cpZUVpHXET8BJ8Da7WHVHpwkPP6KLg@mail.gmail.com](https://postgr.es/m/CAD21AoDWRh6oTN5T8wa+cpZUVpHXET8BJ8Da7WHVHpwkPP6KLg@mail.gmail.com)
[https://git.postgresql.org/pg/commitdiff/60f1f09ff44308667ef6c72fbafd68235e55ae27](https://git.postgresql.org/pg/commitdiff/60f1f09ff44308667ef6c72fbafd68235e55ae27)

Tomáš Vondra pushed:

- Initialize t_self and t_tableOid in statext_expressions_load. The function is
building a fake heap tuple, but left some of the header fields (tid and table
OID) uninitialized. Per Coverity report. Reported-by: Ranier Vilela
Discussion:
[https://postgr.es/m/CAEudQApj6h8tZ0-eP5Af5PKc5NG1YUc7=SdN_99YoHS51fKa0Q@mail.gmail.com](https://postgr.es/m/CAEudQApj6h8tZ0-eP5Af5PKc5NG1YUc7=SdN_99YoHS51fKa0Q@mail.gmail.com)
[https://git.postgresql.org/pg/commitdiff/20661c15db8f430d4880ba685e6b12afa271c1ac](https://git.postgresql.org/pg/commitdiff/20661c15db8f430d4880ba685e6b12afa271c1ac)

Andrew Dunstan pushed:

- Allow TestLib::slurp_file to skip contents, and use as needed. In order to
avoid getting old logfile contents certain functions in PostgresNode were
doing one of two things. On Windows it rotated the logfile and restarted the
server, while elsewhere it truncated the log file. Both of these are
unnecessary. We borrow from the buildfarm which does this instead: note the
size of the logfile before we start, and then when fetching the logfile skip
to that position before accumulating contents. This is spelled differently on
Windows but the effect is the same. This is largely centralized in TestLib's
slurp_file function, which has a new optional parameter, the offset to skip to
before starting to reading the file. Code in the client becomes much neater.
Backpatch to all live branches. Michael Paquier, slightly modified by me.
Discussion:
[https://postgr.es/m/YHajnhcMAI3++pJL@paquier.xyz](https://postgr.es/m/YHajnhcMAI3++pJL@paquier.xyz)
[https://git.postgresql.org/pg/commitdiff/3c5b0685b921533f37622345beb0f8dd49200c01](https://git.postgresql.org/pg/commitdiff/3c5b0685b921533f37622345beb0f8dd49200c01)

# Pending Patches

Andy Fan sent in a patch to document the enhancement for RelOptInfo.partexprs
and nullable_partexprs, and split gen_prune_steps_from_exprs into some smaller
chunks.

Luc Vlaming sent in another revision of a patch to add explicit partial UNION
ALL path and improve parallel subquery rowcounts and costing.

Luc Vlaming sent in another revision of a patch to improve jitting performance
by not emitting the LLVMPassManagerBuilderUseInlinerWithThreshold pass, and
generate the IR code lazily on first call.

Amul Sul sent in another revision of a patch to implement ALTER SYSTEM ... READ
{ONLY | WRITE}.

James Coleman sent in a patch to add HashedScalarArrayOp support for NOT IN.

Amit Langote sent in a patch to fix a thinko in PartitionDesc includes_detached.

Masahiko Sawada sent in a patch to fix a performance degradation of REFRESH
MATERIALIZED VIEW.

Peter Smith sent in another revision of a patch to add support for prepared
transactions to built-in logical replication, and add prepare API support for
streaming transactions.

Vigneshwaran C and traded patches to identify missing publications from
publisher in CREATE/ALTER SUBSCRIPTION.

Vigneshwaran C sent in a patch to fix a monitoring stats docs inconsistency.

Bruce Momjian sent in two revisions of a patch to fix some naming in the latest
addition of query IDs to pg_stat_activity.

Mark Dilger sent in two more revisions of a patch to the pg_amcheck application
to add TOAST pointer corruption checks.

Melanie Plageman sent in a patch to add a system view, pg_stat_buffers_written,
which does what it says on the label.

Fujii Masao, Kyotaro HORIGUCHI, and Justin Pryzby traded patches to fix some
infelicities in the new TRUNCATE on foreign table capability.

Justin Pryzby sent in two more revisions of a patch to polish up the
documentation for 14.

Amit Langote sent in a patch to initialize WITH CHECK OPTIONS and RETURNING
expressions on demand.

Ekaterina Sokolova sent in another revision of a patch to add extra statistics
to explain for Nested Loop.

Haiying Tang sent in another revision of a patch to support tab completion with
a query result for upper character inputs in psql.

Dave Page sent in a patch to fix a logging issue in sepgsql.

Andrei Zubkov sent in another revision of a patch to track statement entry
timestamp in pg_stat_statements.

David Christensen sent in a patch to expand the units that
pg_size_pretty(numeric) knows about to include units up to yottabytes.

Bharath Rupireddy sent in two more revisions of a patch to avoid accessing
system catalogues inside slot_store_error_callback and conversion_error_callback.

Masahiko Sawada and Peter Geoghegan traded patches to make sure that the code
comments for VACUUM accounting explain LP_DEAD accounting.

Ajin Cherian sent in two more revisions of a patch to skip empty transactions
for logical replication.

Julien Rouhaud sent in a patch to handle some corner cases around logging with
respect to query IDs. The issue here is that some queries can be logged when
syntactically valid, missing checks for existence of the objects to which they
refer in the catalog. The fix adds a %Q option to log_line_prefix which checks
whether the object(s) are actually found.

Zeng Wenjing and Shawn Wang traded patches to implement global temporary tables.

Tom Lane sent in a patch to replace pg_depend PIN entries with a fixed range
check.

Amul Sul sent in a patch to remove a edundant variable from transformCreateStmt.

Pavel Stěhule sent in two more revisions of a patch to implement schema
variables.

Matthias van de Meent sent in two revisions of a patch to document the locking
behavior of ATTACH PARTITION for default partitions.

Matthias van de Meent sent in a patch to implement page-level dynamic prefix
truncation for `_bt_binsrch*`, then use same to implement and use index tuple
attribute iteration.

James Coleman, Tomáš Vondra, and Tom Lane traded patches intended to fix a
bug that manifested as "could not find pathkey item to sort" for TPC-DS queries
94-96.

Masahiro Ikeda sent in another revision of a patch to improve the performance of
reporting WAL stats.

Tomáš Vondra sent in a patch to generate fractional cheapest paths in
generate_orderedappend_path.

Takamichi Osumi and Li Japin traded patches to fix an infelicity between
TRUNCATE and synchronous logical replication.

Michaël Paquier sent in another revision of a patch to fix a relcache leak in
the logical replication worker.

Mark Dilger sent in two revisions of a patch to add an --install-missing option
to pg_amcheck.

Sven Klemm sent in a patch to fix pg_event_trigger_ddl_commands, which could be
looking at an invalid cache in the case of an object dropped in the same
transaction.

Andy Fan sent in a patch to ensure that set_append_rel_size considers the
initial partition prune.

Tom Lane sent in a patch to save some cycles in repeated subquery pullup.