== PostgreSQL Weekly News - August 9, 2020 ==

== PostgreSQL Weekly News - August 9, 2020 ==

PGDay Ukraine has been cancelled due to COVID-19.

Person of the week: https://postgresql.life/post/tatsuo_ishii/

== PostgreSQL Jobs for August ==

http://archives.postgresql.org/pgsql-jobs/2020-08/

== PostgreSQL Local ==

pgDay Israel 2020 will take place on September 10, 2020 in Tel Aviv.
http://pgday.org.il/

== PostgreSQL in the News ==

Planet PostgreSQL: http://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:

- Fix minor issues in psql's new \dAc and related commands. The type-name
pattern in \dAc and \dAf was matched only to the actual pg_type.typname
string, which is fairly user-unfriendly in cases where that is not what's
shown to the user by format_type (compare "_int4" and "integer[]"). Make this
code match what \dT does, i.e. match the pattern against either typname or
format_type() output. Also fix its broken handling of schema-name
restrictions. (IOW, make these processSQLNamePattern calls match \dT's.)
While here, adjust whitespace to make the query a little prettier in -E
output, too. Also improve some inaccuracies and shaky grammar in the related
documentation. Noted while working on a patch for intarray's opclasses; I
wondered why I couldn't get a match to "integer*" for the input type name.
https://git.postgresql.org/pg/commitdiff/533020d05045046a3481fdd92777de7bb2e30ab3

- Fix behavior of ecpg's "EXEC SQL elif name". This ought to work much like C's
"#elif defined(name)"; but the code implemented it in a way equivalent to
endif followed by ifdef, so that it didn't matter whether any previous branch
of the IF construct had succeeded. Fix that; add some test cases covering
elif and nested IFs; and improve the documentation, which also seemed a bit
confused. AFAICS the code has been like this since the feature was added in
1999 (commit b57b0e044). So while it's surely wrong, there might be code out
there relying on the current behavior. Hence, don't back-patch into stable
branches. It seems all right to fix it in v13 though. Per report from
Ashutosh Sharma. Reviewed by Ashutosh Sharma and Michael Meskes. Discussion:
https://postgr.es/m/CAE9k0P=dQk9X0cU2tN49S7a9tv733-e1pVdpB1P-pWJ5PdTktg@mail.gmail.com
https://git.postgresql.org/pg/commitdiff/5f28b21eb3c5c2fb72c24608bc686acd7c9b113c

- Doc: fix obsolete info about allowed range of TZ offsets in timetz. We've
allowed UTC offsets up to +/- 15:59 since commit cd0ff9c0f, but that commit
forgot to fix the documentation about timetz. Per bug #16571 from osdba.
Discussion: https://postgr.es/m/16571-eb7501598de78c8a@postgresql.org
https://git.postgresql.org/pg/commitdiff/eeb01e3122bb0acb6f8575d352e8e63101662ae7

- Remove unnecessary "DISTINCT" in psql's queries for \dAc and \dAf. A moment's
examination of these queries is sufficient to see that they do not produce
duplicate rows, unless perhaps there's catalog corruption. Using DISTINCT
anyway is inefficient and confusing; moreover it sets a poor example for
anyone who refers to psql -E output to see how to query the catalogs.
https://git.postgresql.org/pg/commitdiff/9e496768b8a7303ea07888ea1baae8e2a57dda7b

- Increase hard-wired timeout values in ecpg regression tests. A couple of test
cases had connect_timeout=14, a value that seems to have been plucked from a
hat. While it's more than sufficient for normal cases, slow/overloaded
buildfarm machines can get a timeout failure here, as per recent report from
"sungazer". Increase to 180 seconds, which is in line with our typical
timeouts elsewhere in the regression tests. Back-patch to 9.6; the code looks
different in 9.5, and this doesn't seem to be quite worth the effort to adapt
to that. Report:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=sungazer&dt=2020-08-04%2007%3A12%3A22
https://git.postgresql.org/pg/commitdiff/0f76294260b92849c4958fb706ecd5b5cd73e40e

- Fix matching of sub-partitions when a partitioned plan is stale. Since we no
longer require AccessExclusiveLock to add a partition, the executor may see
that a partitioned table has more partitions than the planner saw.
ExecCreatePartitionPruneState's code for matching up the partition lists in
such cases was faulty, and would misbehave if the planner had successfully
pruned any partitions from the query. (Thus, trouble would occur only if a
partition addition happens concurrently with a query that uses both static and
dynamic partition pruning.) This led to an Assert failure in debug builds,
and probably to crashes or query misbehavior in production builds. To repair
the bug, just explicitly skip zeroes in the plan's relid_map[] list. I also
made some cosmetic changes to make the code more readable (IMO anyway). Also,
convert the cross-checking Assert to a regular test-and-elog, since it's now
apparent that this logic is more fragile than one would like. Currently,
there's no way to repeatably exercise this code, except with manual use of a
debugger to stop the backend between planning and execution. Hence, no test
case in this patch. We oughta do something about that testability gap, but
that's for another day. Amit Langote and Tom Lane, per report from Justin
Pryzby. Oversight in commit 898e5e329; backpatch to v12 where that appeared.
Discussion: https://postgr.es/m/20200802181131.GA27754@telsasoft.com
https://git.postgresql.org/pg/commitdiff/7a980dfc6c15add6ec3309932cf3061bb6745f65

- Support testing of cases where table schemas change after planning. We have
various cases where we allow DDL on tables to be performed with less than full
AccessExclusiveLock. This requires concurrent queries to be able to cope with
the DDL change mid-flight, but up to now we had no repeatable way to test such
cases. To improve that, invent a test module that allows halting a backend
after planning and then resuming execution once we've done desired actions in
another session. (The same approach could be used to inject delays in other
places, if there's a suitable hook available.) This commit includes a single
test case, which is meant to exercise the previously-untestable
ExecCreatePartitionPruneState code repaired by commit 7a980dfc6. We'd
probably not bother with this if that were the only foreseen benefit, but I
expect additional test cases will use this infrastructure in the future. Test
module by Andy Fan, partition-addition test case by me. Discussion:
https://postgr.es/m/20200802181131.GA27754@telsasoft.com
https://git.postgresql.org/pg/commitdiff/6f0b632f083ba08fabb6c496caf733802cee9d2e

- Remove <@ from contrib/intarray's GiST operator classes. Since commit
efc77cf5f, an indexed query using <@ has required a full-index scan, so that
it actually performs worse than a plain seqscan would do. As I noted at the
time, we'd be better off to not treat <@ as being indexable by such indexes at
all; and that's what this patch does. It would have been difficult to remove
these opclass members without dropping the whole opclass before commit
9f9682783 fixed GiST opclass member dependency rules, but now it's quite
simple, so let's do it. I left the existing support code in place for the
time being, with comments noting it's now unreachable. At some point, perhaps
we should remove that code in favor of throwing an error telling people to
upgrade the extension version. Discussion:
https://postgr.es/m/2176979.1596389859@sss.pgh.pa.us Discussion:
https://postgr.es/m/458.1565114141@sss.pgh.pa.us
https://git.postgresql.org/pg/commitdiff/20e7e1fe316467720d8d062e1a1429f798fc31bf

- Remove useless Assert. Testing that an unsigned variable is >= 0 is pretty
pointless, as noted by Coverity and numerous buildfarm members. In passing,
add comment about new uses of "volatile" --- Coverity doesn't much like that
either, but it seems probably necessary.
https://git.postgresql.org/pg/commitdiff/1c164ef3d28dfab445a885a03e80cfd0d552f64a

- Check for fseeko() failure in pg_dump's _tarAddFile(). Coverity pointed out,
not unreasonably, that we checked fseeko's result at every other call site but
these. Failure to seek in the temp file (note this is NOT pg_dump's output
file) seems quite unlikely, and even if it did happen the file length
cross-check further down would probably detect the problem. Still, that's a
poor excuse for not checking the result of a system call.
https://git.postgresql.org/pg/commitdiff/1b9cde51246c7773eac119b84cc18095118735de

Thomas Munro pushed:

- Correct comment in simplehash.h. Post-commit review for commit 84c0e4b9.
Author: David Rowley <dgrowleyml(at)gmail(dot)com> Discussion:
https://postgr.es/m/CAApHDvptBx_%2BUPAzY0uXzopbvPVGKPeZ6Hoy8rnPcWz20Cr0Bw%40mail.gmail.com
https://git.postgresql.org/pg/commitdiff/63e9aa6879cc5b87c77bab9afea3740748a4f00b

- Fix rare failure in LDAP tests. Instead of writing a query to psql's stdin,
use -c. This avoids a failure where psql exits before we write, seen a few
times on the build farm. Thanks to Tom Lane for the suggestion. Back-patch
to 11, where the LDAP tests arrived. Reviewed-by: Noah Misch
<noah(at)leadboat(dot)com> Discussion:
https://postgr.es/m/CA%2BhUKGLFmW%2BHQYPeKiwSp5sdFFHtFViCpw4Mh6yAgEx74r5-Cw%40mail.gmail.com
https://git.postgresql.org/pg/commitdiff/f44b9b625bedd8e0bca67b3b42ba10ce482fa31b

Michaël Paquier pushed:

- Add %P to log_line_prefix for parallel group leader. This is useful for
monitoring purposes with log parsing. Similarly to pg_stat_activity, the
leader's PID is shown only for active parallel workers, minimizing the log
footprint for the leaders as the equivalent shared memory field is set as long
as a backend is alive. Author: Justin Pryzby Reviewed-by: Álvaro Herrera,
Michael Paquier, Julien Rouhaud, Tom Lane Discussion:
https://postgr.es/m/20200315111831.GA21492@telsasoft.com
https://git.postgresql.org/pg/commitdiff/b8fdee7d0ca8bd2165d46fb1468f75571b706a01

- Make new SSL TAP test for channel_binding more robust. The test would fail in
an environment including a certificate file in ~/.postgresql/. bdd6e9b fixed
a similar failure, and d6e612f introduced the same problem again with a new
test. Author: Kyotaro Horiguchi Discussion:
https://postgr.es/m/20200804.120033.31225582282178001.horikyota.ntt@gmail.com
Backpatch-through: 13
https://git.postgresql.org/pg/commitdiff/dd877998d498c511352bd3640fd57f041c90ea62

Peter Geoghegan pushed:

- Add nbtree page deletion assertion. Add a documenting assertion that's similar
to the nearby assertion added by commit cd8c73a3. This conveys that the
entire call to _bt_pagedel() does no work if it isn't possible to get a
descent stack for the initial scanblkno page.
https://git.postgresql.org/pg/commitdiff/a451b7d44249b8655db8d40476ace9f84d76ab88

- Fix replica backward scan race condition. It was possible for the logic used
by backward scans (which must reason about concurrent page splits/deletions in
its own peculiar way) to become confused when running on a replica.
Concurrent replay of a WAL record that describes the second phase of page
deletion could cause _bt_walk_left() to get confused.
btree_xlog_unlink_page() simply failed to adhere to the same locking protocol
that we use on the primary, which is obviously wrong once you consider these
two disparate functions together. This bug is present in all stable branches.
More concretely, the problem was that nothing stopped _bt_walk_left() from
observing inconsistencies between the deletion's target page and its original
sibling pages when running on a replica. This is true even though the second
phase of page deletion is supposed to work as a single atomic action. Queries
running on replicas raised "could not find left sibling of block %u in index
%s" can't-happen errors when they went back to their scan's "original" page
and observed that the page has not been marked deleted (even though it really
was concurrently deleted). There is no evidence that this actually happened
in the real world. The issue came to light during unrelated feature
development work. Note that _bt_walk_left() is the only code that cares about
the difference between a half-dead page and a fully deleted page that isn't
also exclusively used by nbtree VACUUM (unless you include contrib/amcheck
code). It seems very likely that backward scans are the only thing that could
become confused by the inconsistency. Even amcheck's complex
bt_right_page_check_scankey() dance was unaffected. To fix, teach
btree_xlog_unlink_page() to lock the left sibling, target, and right sibling
pages in that order before releasing any locks (just like
_bt_unlink_halfdead_page()). This is the simplest possible approach. There
doesn't seem to be any opportunity to be more clever about lock acquisition in
the REDO routine, and it hardly seems worth the trouble in any case. This fix
might enable contrib/amcheck verification of leaf page sibling links with only
an AccessShareLock on the relation. An amcheck patch from Andrey Borodin was
rejected back in January because it clashed with btree_xlog_unlink_page()'s
lax approach to locking pages. It now seems likely that the real problem was
with btree_xlog_unlink_page(), not the patch. This is a low severity, low
likelihood bug, so no backpatch. Author: Michail Nikolaev Diagnosed-By:
Michail Nikolaev Discussion:
https://postgr.es/m/CANtu0ohkR-evAWbpzJu54V8eCOtqjJyYp3PQ_SGoBTRGXWhWRw@mail.gmail.com
https://git.postgresql.org/pg/commitdiff/9a9db08ae46209edcc5ecb120328a2bf92fd6069

- amcheck: Sanitize metapage's allequalimage field. This will be helpful if it
ever proves necessary to revoke an opclass's support for deduplication.
Backpatch: 13-, where nbtree deduplication was introduced.
https://git.postgresql.org/pg/commitdiff/c254d8d7b20bf629420b407a5451c3b32d1a7b0b

- Remove obsolete amcheck comment. Oversight in commit d114cc53871.
https://git.postgresql.org/pg/commitdiff/3a3be80641c01e675d0ed484f15df8ec536d0a06

- Rename nbtree split REDO routine variables. Make the nbtree page split REDO
routine variable names consistent with _bt_split() (which handles the original
execution of page splits). These names make the code easier to follow by
making the distinction between the original page and the left half of the
split clear. (The left half of the split page is a temp page that REDO
creates to replace the origpage contents.) Also reduce the elevel used when
adding a new high key to the temp page from PANIC to ERROR to be consistent.
We already only raise an ERROR when data item PageAddItem() temp page calls
fail.
https://git.postgresql.org/pg/commitdiff/3df92bbd1dba98f72e3f005406463b0718193a0f

- Make nbtree split REDO locking match original execution. Make the nbtree page
split REDO routine consistent with original execution in its approach to
acquiring and releasing buffer locks (at least for pages on the tree level of
the page being split). This brings btree_xlog_split() in line with
btree_xlog_unlink_page(), which was taught to couple buffer locks by commit
9a9db08a. Note that the precise order in which we both acquire and release
sibling buffer locks in btree_xlog_split() now matches original execution
exactly (the precise order in which the locks are released probably doesn't
matter much, but we might as well be consistent about it). The rule for
nbtree REDO routines from here on is that same-level locks should be acquired
in an order that's consistent with original execution. It's not practical to
have a similar rule for cross-level page locks, since for the most part
original execution holds those locks for a period that spans multiple atomic
actions/WAL records. It's also not necessary, because clearly the cross-level
lock coupling is only truly needed during original execution because of the
presence of concurrent inserters. This is not a bug fix (unlike the similar
aforementioned commit, commit 9a9db08a). The immediate reason to tighten
things up in this area is to enable an upcoming enhancement to contrib/amcheck
that allows it to verify that sibling links are in agreement with only an
AccessShareLock (this check produced false positives when run on a replica
server on account of the inconsistency fixed by this commit). But that's not
the only reason to be stricter here. It is generally useful to make locking
on replicas be as close to what happens during original execution as
practically possible. It makes it less likely that hard to catch bugs will
slip in in the future. The previous state of affairs seems to be a holdover
from before the introduction of Hot Standby, when buffer lock acquisitions
during recovery were totally unnecessary. See also: commit 3bbf668d, which
tightened things up in this area a few years after the introduction of Hot
Standby. Discussion:
https://postgr.es/m/CAH2-Wz=465cJj11YXD9RKH8z=nhQa2dofOZ_23h67EXUGOJ00Q@mail.gmail.com
https://git.postgresql.org/pg/commitdiff/0a7d771f0f63eb120e7f0a60aecd543ab25ba197

- Teach amcheck to verify sibling links in all cases. Teach contrib/amcheck's
bt_index_check() function to check agreement between siblings links. The left
sibling's right link should point to a right sibling page whose left link
points back to the same original left sibling. This extends a check that
bt_index_parent_check() always performed to bt_index_check(). This is the
first time amcheck has been taught to perform buffer lock coupling, which we
have explicitly avoided up until now. The sibling link check tends to catch a
lot of real world index corruption with little overhead, so it seems worth
accepting the complexity. Note that the new lock coupling logic would not
work correctly on replica servers without the changes made by commits 0a7d771f
and 9a9db08a (there could be false positives without those changes). Author:
Andrey Borodin, Peter Geoghegan Discussion:
https://postgr.es/m/0EB0CFA8-CBD8-4296-8049-A2C0F28FAE8C@yandex-team.ru
https://git.postgresql.org/pg/commitdiff/39132b784aeaaacf5ddfb5c35b6e29a6926f4345

Alexander Korotkov pushed:

- Remove btree page items after page unlink. Currently, page unlink leaves
remaining items "as is", but replay of corresponding WAL-record re-initializes
page leaving it with no items. For the sake of consistency, this commit makes
primary delete all the items during page unlink as well. Thanks to this
change, we now don't mask contents of deleted btree page for WAL consistency
checking. Discussion:
https://postgr.es/m/CAPpHfdt_OTyQpXaPJcWzV2N-LNeNJseNB-K_A66qG%3DL518VTFw%40mail.gmail.com
Author: Alexander Korotkov Reviewed-by: Peter Geoghegan
https://git.postgresql.org/pg/commitdiff/f47b5e139579a77c1f7c63400f01ea39d515e8c8

Bruce Momjian pushed:

- doc: clarify "state" table reference in tutorial. Reported-by: Vyacheslav
Shablistyy Discussion:
https://postgr.es/m/159586122762.680.1361378513036616007@wrigleys.postgresql.org
Backpatch-through: 9.5
https://git.postgresql.org/pg/commitdiff/a6775352476ac92d6b3eb3ae2dfd2775e3622afe

Robert Haas pushed:

- Register llvm_shutdown using on_proc_exit, not before_shmem_exit. This seems
more correct, because other before_shmem_exit calls may expect the
infrastructure that is needed to run queries and access the database to be
working, and also because this cleanup has nothing to do with shared memory.
There are no known user-visible consequences to this, though, apart from what
was previous fixed by commit 303640199d0436c5e7acdf50b837a027b5726594 and
back-patched as commit bcbc27251d35336a6442761f59638138a772b839 and commit
f7013683d9bb663a6a917421b1374306a32f165b, so for now, no back-patch. Bharath
Rupireddy Discussion:
http://postgr.es/m/CALj2ACWk7j4F2v2fxxYfrroOF=AdFNPr1WsV+AGtHAFQOqm_pw@mail.gmail.com
https://git.postgresql.org/pg/commitdiff/bab150045bd9766869f471ede88734ea0989261c

David Rowley pushed:

- Fix bogus EXPLAIN output for Hash Aggregate. 9bdb300de modified the EXPLAIN
output for Hash Aggregate to show details from parallel workers. However, it
neglected to consider that a given parallel worker may not have assisted with
the given Hash Aggregate. This can occur when workers fail to start or during
Parallel Append with enable_partitionwise_join enabled when only a single
worker is working on a non-parallel aware sub-plan. It could also happen if a
worker simply wasn't fast enough to get any work done before other processes
went and finished all the work. The bogus output came from the fact that
ExplainOpenWorker() skipped showing any details for non-initialized workers
but show_hashagg_info() did show details from the worker. This meant that the
worker properties that were shown were not properly attributed to the worker
that they belong to. In passing, we also now don't show Hash Aggregate
properties for the leader process when it did not contribute any work to the
Hash Aggregate. This can occur either during Parallel Append when only a
parallel worker worked on a given sub plan or with
parallel_leader_participation set to off. This aims to make the behavior of
Hash Aggregate's EXPLAIN output more similar to Sort's. Reported-by: Justin
Pryzby Discussion: https://postgr.es/m/20200805012105.GZ28072%40telsasoft.com
Backpatch-through: 13, where the original breakage was introduced
https://git.postgresql.org/pg/commitdiff/d5e96520ffca8eeeefc11f8fc82af610f68e63a8

Etsuro Fujita pushed:

- Fix yet another issue with step generation in partition pruning. Commit
13838740f fixed some issues with step generation in partition pruning, but
there was yet another one: get_steps_using_prefix() assumes that clauses in
the passed-in prefix list are sorted in ascending order of their partition key
numbers, but the caller failed to ensure this for range partitioning, which
led to an assertion failure in debug builds. Adjust the caller function to
arrange the clauses in the prefix list in the required order for range
partitioning. Back-patch to v11, like the previous commit. Patch by me,
reviewed by Amit Langote. Discussion:
https://postgr.es/m/CAPmGK16jkXiFG0YqMbU66wte-oJTfW6D1HaNvQf%3D%2B5o9%3Dm55wQ%40mail.gmail.com
https://git.postgresql.org/pg/commitdiff/199cec9779504c08aaa8159c6308283156547409

Álvaro Herrera pushed:

- Remove PROC_IN_ANALYZE and derived flags. These flags are unused and always
have been. Discussion:
https://postgr.es/m/20200805235549.GA8118@alvherre.pgsql
https://git.postgresql.org/pg/commitdiff/cea3d55898655582e3a3835a7bed2c3a1b002fef

- walsnd: Don't set waiting_for_ping_response spuriously. Ashutosh Bapat noticed
that when logical walsender needs to wait for WAL, and it realizes that it
must send a keepalive message to walreceiver to update the sent-LSN, which
*does not* request a reply from walreceiver, it wrongly sets the flag that
it's going to wait for that reply. That means that any future would-be sender
of feedback messages ends up not sending a feedback message, because they all
believe that a reply is expected. With built-in logical replication there's
not much harm in this, because WalReceiverMain will send a ping-back every
wal_receiver_timeout/2 anyway; but with other logical replication systems
(e.g. pglogical) it can cause significant pain. This problem was introduced
in commit 41d5f8ad734, where the request-reply flag was changed from true to
false to WalSndKeepalive, without at the same time removing the line that sets
waiting_for_ping_response. Just removing that line would be a sufficient fix,
but it seems better to shift the responsibility of setting the flag to
WalSndKeepalive itself instead of requiring caller to do it; this is clearly
less error-prone. Author: Álvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
Reported-by: Ashutosh Bapat <ashutosh(dot)bapat(at)2ndquadrant(dot)com> Backpatch: 9.5
and up Discussion: https://postgr.es/m/20200806225558.GA22401@alvherre.pgsql
https://git.postgresql.org/pg/commitdiff/470687b4a5bb3b9f2b5bf7c9235680b3c91bd050

Amit Kapila pushed:

- Implement streaming mode in ReorderBuffer. Instead of serializing the
transaction to disk after reaching the logical_decoding_work_mem limit in
memory, we consume the changes we have in memory and invoke stream API methods
added by commit 45fdc9738b. However, sometimes if we have incomplete toast or
speculative insert we spill to the disk because we can't generate the complete
tuple and stream. And, as soon as we get the complete tuple we stream the
transaction including the serialized changes. We can do this incremental
processing thanks to having assignments (associating subxact with toplevel
xacts) in WAL right away, and thanks to logging the invalidation messages at
each command end. These features are added by commits 0bead9af48 and
c55040ccd0 respectively. Now that we can stream in-progress transactions, the
concurrent aborts may cause failures when the output plugin consults catalogs
(both system and user-defined). We handle such failures by returning
ERRCODE_TRANSACTION_ROLLBACK sqlerrcode from system table scan APIs to the
backend or WALSender decoding a specific uncommitted transaction. The decoding
logic on the receipt of such a sqlerrcode aborts the decoding of the current
transaction and continue with the decoding of other transactions. We have
ReorderBufferTXN pointer in each ReorderBufferChange by which we know which
xact it belongs to. The output plugin can use this to decide which changes to
discard in case of stream_abort_cb (e.g. when a subxact gets discarded). We
also provide a new option via SQL APIs to fetch the changes being streamed.
Author: Dilip Kumar, Tomas Vondra, Amit Kapila, Nikhil Sontakke Reviewed-by:
Amit Kapila, Kuntal Ghosh, Ajin Cherian Tested-by: Neha Sharma, Mahendra Singh
Thalor and Ajin Cherian Discussion:
https://postgr.es/m/688b0b7f-2f6c-d827-c27b-216a8e3ea700@2ndquadrant.com
https://git.postgresql.org/pg/commitdiff/7259736a6e5b7c7588fff9578370736a6648acbb

- Fix the logical streaming test. Commit 7259736a6e added the capability to
stream changes in ReorderBuffer which has some tests to test the streaming
mode. It is quite possible that while this test is running a parallel
transaction could be logged by autovacuum. Such a transaction won't perform
any insert/update/delete to non-catalog tables so will be shown as an empty
transaction. Fix it by skipping the empty transactions during this test. Per
report by buildfarm.
https://git.postgresql.org/pg/commitdiff/82a0ba7707e010a29f5fe1a0020d963c82b8f1cb

Peter Eisentraut pushed:

- Add some const decorations.
https://git.postgresql.org/pg/commitdiff/a13421c96c0e8ffa34310f92d03d0e6f3bfa27f8

== Pending Patches ==

Anastasia Lubennikova sent in another revision of a patch to set VM all_visible
and all_frozen bits when COPY FREEZE inserts tuples into empty page.

Justin Pryzby sent in another revision of a patch to create some secondary index
access optimizations, and avoid bitmap index scans inconsistent with partition
constraints.

Justin Pryzby sent in a patch to elog.c to remove a special case which avoided
%*s format strings, which should no longer be needed since it was a performance
hack for specific platform snprintf, which are no longer used.

Andrew Dunstan sent in two more revisions of a patch to support libnss as a TLS
backend.

Bharath Rupireddy sent in another revision of a patch to parallelize COPY.

Amit Langote sent in another revision of a patch to use heap slot for
partitioned tables.

Peter Eisentraut sent in three revisions of a patch to replace the remaining
StrNCpy() calls with strlcpy() calls.

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

Kyotaro HORIGUCHI sent in a patch to allow using a directory name for the
ssl_crl_file GUC and the sslcrl connection option. X509_STORE_load_locations
accepts a directory, which leads to on-demand loading method with which method
only relevant CRLs are loaded.

Peter Eisentraut sent in a patch to change return type of EXTRACT to numeric.

Bertrand Drouvot sent in a patch to add information to rm_redo_error_callback().

David Cramer sent in a patch to throw an error and rollback on a failed
transaction instead of silently rolling back.

Andrey Borodin sent in another revision of a patch to add sort support for point
gist_point_sortsupport, and implement GiST index builds using same.

Álvaro Herrera sent in a patch to let ALTER TABLE exec routines deal with the
relation, and implement ALTER TABLE ... DETACH CONCURRENTLY.

Alexander Korotkov sent in another revision of a patch to remove btree page
items after page unlink, which removal makes it possible to stop masking the
contents of deleted btree pages for WAL consistency checking.

Bharath Rupireddy sent in another revision of a patch to implement background
worker shared memory access for EXEC_BACKEND cases.

David Rowley sent in another revision of a patch to allow estimate_num_groups()
to pass back further details about the estimation, allow users of simplehash.h
to perform direct deletions, and add a Result Cache executor node.

Mahendra Singh sent in another revision of a patch to add offset with block
number in vacuum errcontext.

Amit Langote, Tom Lane, and Andy Fan traded patches to fix an issue that
manifested as FailedAssertion("pd_idx == pinfo->nparts", File:
"execPartition.c", Line: 1689).

Amit Langote sent in two more revisions of a patch to revise how FDWs obtain
result relation information, avoid making "root" ResultRelInfo for insert
queries, revise the child-to-root tuple conversion map management, and
Initialize result relation information lazily.

Thomas Munro sent in another revision of a patch to ask the checkpointer to
flush SLRU files.

Jehan-Guillaume de Rorthais sent in another revision of a patch to implement
DEMOTE, a command that turns a writer node into a standby.

Dmitry Dolgov sent in another revision of a patch to implement generic type
subscripting.

David Rowley sent in a patch to avoid displaying hashagg properties for workers
that don't assist.

Asim Praveen sent in two more revisions of a patch to use a stringInfo instead
of a char for replace_string in pg_regress.

Ashutosh Sharma sent in two more revisions of a patch to add contrib/pg_surgery
to perform surgery on a damaged heap table.

Álvaro Herrera sent in a patch to flag CREATE INDEX CONCURRENTLY to avoid
spurious waiting.

Michaël Paquier sent in a patch to implement range checks of pg_test_fsync
--secs-per-test and pg_test_timing --duration.

Bertrand Drouvot sent in another revision of a patch to display individual
queries in pg_stat_activity.

Ryo Matsumura sent in another revision of a patch to ensure that "make
installcheck" works with PGXS.

Michaël Paquier sent in another revision of a patch to use multi-inserts for
pg_depend, and switch to multi-insert dependencies for many code paths.

Amit Langote sent in a patch to fix some inefficiencies in the patch to make
inserts to tables with foreign partitions faster.

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

Robert Haas sent in another revision of a patch to fix a bug that manifested as
parallel worker hanging while handling errors.

Bharath Rupireddy sent in another revision of a patch to modify the
cancel_before_shmem_exit() comments.

Pavel Borisov sent in a patch to implement covering GiST indexes.

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

Asim Praveen sent in another revision of a patch to start the WAL receiver
before the startup process replays existing WAL.

Michaël Paquier sent in a patch to support REINDEX in psql's tab completion.

Thomas Munro sent in a patch to optimize latches to send fewer signals, and
remove the self-pipe in WAIT_USE_EPOLL and WAIT_USE_KQUEUE builds.

Jeff Janes sent in a patch to implement tab completion for IMPORT FOREIGN SCHEMA
in psql.