== PostgreSQL Weekly News - May 5, 2019 ==

== PostgreSQL Weekly News - May 5, 2019 ==

== PostgreSQL Product News ==

pgAdmin4 4.6, a web- and native GUI control center for PostgreSQL, released.
https://www.pgadmin.org/docs/pgadmin4/dev/release_notes_4_6.html

== PostgreSQL Jobs for May ==

http://archives.postgresql.org/pgsql-jobs/2019-05/

== PostgreSQL Local ==

The German-speaking PostgreSQL Conference 2019 will take place on May 10, 2019
in Leipzig.
http://2019.pgconf.de/

PGDay.IT 2019 will take place May 16th and May 17th in Bologna, Italy.
https://2019.pgday.it/en/

PgConf Belgium will take place on May 17, 2019 at the UCLL Campus in Haasrode
(near Leuven). Registration is open.
http://pgconf.be

PGCon 2019 will take place in Ottawa on May 28-31, 2019. Registration is open.
https://www.pgcon.org/2019

Swiss PGDay 2019 will take place in Rapperswil (near Zurich) on June 28, 2019.
Registration is open.
http://www.pgday.ch/2019/

PostgresLondon 2019 will be July 2-3, 2019 with an optional training day on
July 1.
http://postgreslondon.org

PGConf.Brazil 2019 will take place August 1-3, 2019 in São Paulo.
http://pgconf.com.br

The first Austrian pgDay, will take place September 6, 2019 at the Hilton Garden
Inn in Wiener Neustadt.
https://pgday.at/en/

PostgresConf South Africa 2019 will take place in Johannesburg on October 8-9, 2019
The Call for Papers is open through June 30, 2019.
https://postgresconf.org/conferences/SouthAfrica2019

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

- Clean up minor warnings from buildfarm. Be more consistent about use of
XXXGetDatum macros in new jsonpath code. This is mostly to avoid having code
that looks randomly different from everyplace else that's doing the exact same
thing. In pg_regress.c, avoid an unreferenced-function warning from compilers
that don't understand pg_attribute_unused(). Putting the function inside the
same #ifdef as its only caller is more straightforward coding anyway. In
be-secure-openssl.c, avoid use of pg_attribute_unused() on a label. That's
pretty creative, but there's no good reason to suppose that it's portable, and
there's absolutely no need to use goto's here in the first place. (This
wasn't actually causing any buildfarm complaints, but it's new code in v12 so
it has no portability track record.)
https://git.postgresql.org/pg/commitdiff/e481d26285b160058b093588e062cf3071fea192

- Do pre-release housekeeping on catalog data, and fix jsonpath send/recv. Run
renumber_oids.pl to move high-numbered OIDs down, as per pre-beta tasks
specified by RELEASE_CHANGES. (The only change is 8394 -> 3428.) Also run
reformat_dat_file.pl while I'm here. While looking at the reformat diffs, I
chanced to notice that type jsonpath had typsend and typreceive = '-', which
surely is not the intention given that jsonpath_send and jsonpath_recv exist.
Fix that. It's safe to assume that these functions have never been tested
:-(. I didn't try, but somebody should.
https://git.postgresql.org/pg/commitdiff/c3f67ed6e434333e1bc011afc94c25d9959a86bd

- In walreceiver, don't try to do ereport() in a signal handler. This is quite
unsafe, even for the case of ereport(FATAL) where we won't return control to
the interrupted code, and despite this code's use of a flag to restrict the
areas where we'd try to do it. It's possible for example that we interrupt
malloc or free while that's holding a lock that's meant to protect against
cross-thread interference. Then, any attempt to do malloc or free within
ereport() will result in a deadlock, preventing the walreceiver process from
exiting in response to SIGTERM. We hypothesize that this explains some
hard-to-reproduce failures seen in the buildfarm. Hence, get rid of the
immediate-exit code in WalRcvShutdownHandler, as well as the logic associated
with WalRcvImmediateInterruptOK. Instead, we need to take care that
potentially-blocking operations in the walreceiver's data transmission logic
(libpqwalreceiver.c) will respond reasonably promptly to the process's latch
becoming set and then call ProcessWalRcvInterrupts. Much of the needed code
for that was already present in libpqwalreceiver.c. I refactored things a bit
so that all the uses of PQgetResult use latch-aware waiting, but didn't need
to do much more. These changes should be enough to ensure that
libpqwalreceiver.c will respond promptly to SIGTERM whenever it's waiting to
receive data. In principle, it could block for a long time while waiting to
send data too, and this patch does nothing to guard against that. I think that
that hazard is mostly theoretical though: such blocking should occur only if
we fill the kernel's data transmission buffers, and we don't generally send
enough data to make that happen without waiting for input. If we find out
that the hazard isn't just theoretical, we could fix it by using
PQsetnonblocking, but that would require more ticklish changes than I care to
make now. This is a bug fix, but it seems like too big a change to push into
the back branches without much more testing than there's time for right now.
Perhaps we'll back-patch once we have more confidence in the change. Patch by
me; thanks to Thomas Munro for review. Discussion:
https://postgr.es/m/20190416070119.GK2673@paquier.xyz
https://git.postgresql.org/pg/commitdiff/a1a789eb5ac894b4ca4b7742f2dc2d9602116e46

- Clean up handling of constraint_exclusion and enable_partition_pruning. The
interaction of these parameters was a bit confused/confusing, and in fact v11
entirely misses the opportunity to apply partition constraints when a
partition is accessed directly (rather than indirectly from its parent). In
HEAD, establish the principle that enable_partition_pruning controls partition
pruning and nothing else. When accessing a partition via its parent, we do
partition pruning (if enabled by enable_partition_pruning) and then there is
no need to consider partition constraints in the constraint_exclusion logic.
When accessing a partition directly, its partition constraints are applied by
the constraint_exclusion logic, only if constraint_exclusion = on. In v11, we
can't have such a clean division of these GUCs' effects, partly because we
don't want to break compatibility too much in a released branch, and partly
because the clean coding requires inheritance_planner to have applied
partition pruning to a partitioned target table, which it doesn't in v11.
However, we can tweak things enough to cover the missed case, which seems like
a good idea since it's potentially a performance regression from v10. This
patch keeps v11's previous behavior in which enable_partition_pruning
overrides constraint_exclusion for an inherited target table, though. In
HEAD, also teach relation_excluded_by_constraints that it's okay to use
inheritable constraints when trying to prune a traditional inheritance tree.
This might not be thought worthy of effort given that that feature is
semi-deprecated now, but we have enough infrastructure that it only takes a
couple more lines of code to do it correctly. Amit Langote and Tom Lane
Discussion:
https://postgr.es/m/9813f079-f16b-61c8-9ab7-4363cab28d80@lab.ntt.co.jp
Discussion: https://postgr.es/m/29069.1555970894@sss.pgh.pa.us
https://git.postgresql.org/pg/commitdiff/e03ff739695cb731956763355e8e0f38c6905008

- Fix reindexing of pg_class indexes some more. Commits 3dbb317d3 et al failed
under CLOBBER_CACHE_ALWAYS testing. Investigation showed that to reindex
pg_class_oid_index, we must suppress accesses to the index (via
SetReindexProcessing) before we call RelationSetNewRelfilenode, or at least
before we do CommandCounterIncrement therein; otherwise, relcache reloads
happening within the CCI may try to fetch pg_class rows using the index's new
relfilenode value, which is as yet an empty file. Of course, the point of
3dbb317d3 was that that ordering didn't work either, because then
RelationSetNewRelfilenode's own update of the index's pg_class row cannot
access the index, should it need to. There are various ways we might have got
around that, but Andres Freund came up with a brilliant solution: for a mapped
index, we can really just skip the pg_class update altogether. The only
fields it was actually changing were relpages etc, but it was just setting
them to zeroes which is useless make-work. (Correct new values will be
installed at the end of index build.) All pg_class indexes are mapped and
probably always will be, so this eliminates the problem by removing work
rather than adding it, always a pleasant outcome. Having taught
RelationSetNewRelfilenode to do it that way, we can revert the code reordering
in reindex_index. (But I left the moved setup code where it was; there seems
no reason why it has to run without use of the old index. If you're trying to
fix a busted pg_class index, you'll have had to disable system index use
altogether to get this far.) Moreover, this means we don't need
RelationSetIndexList at all, because reindex_relation's hacking to make
"REINDEX TABLE pg_class" work is likewise now unnecessary. We'll leave that
code in place in the back branches, but a follow-on patch will remove it in
HEAD. In passing, do some minor cleanup for commit 5c1560606 (in HEAD only),
notably removing a duplicate newrnode assignment. Patch by me, using a core
idea due to Andres Freund. Back-patch to all supported branches, as 3dbb317d3
was. Discussion: https://postgr.es/m/28926.1556664156@sss.pgh.pa.us
https://git.postgresql.org/pg/commitdiff/f912d7dec29341d55315fccef8dc3fdfd068c6e3

- Remove RelationSetIndexList(). In the wake of commit f912d7dec,
RelationSetIndexList isn't used any more. It was always a horrid wart, so
getting rid of it is very nice. We can also convert rd_indexvalid back to a
plain boolean. Discussion: https://postgr.es/m/28926.1556664156@sss.pgh.pa.us
https://git.postgresql.org/pg/commitdiff/f884dca4959f64bd47e78102d1dadd2c77d49201

- Doc: remove obsolete comment about per-branch documentation. I should have
removed this in a0b762626, but forgot.
https://git.postgresql.org/pg/commitdiff/8309eae499d6782bfc5e81f4d1cfcbf8e3fc8f5d

- Fix style violations in syscache lookups. Project style is to check the
success of SearchSysCacheN and friends by applying HeapTupleIsValid to the
result. A tiny minority of calls creatively did it differently. Bring them
into line with the rest. This is just cosmetic, since HeapTupleIsValid is
indeed just a null check at the moment ... but that may not be true forever,
and in any case it puts a mental burden on readers who may wonder why these
call sites are not like the rest. Back-patch to v11 just to keep the branches
in sync. (The bulk of these errors seem to have originated in v11 or v12,
though a few are old.) Per searching to see if anyplace else had made the same
error repaired in 62148c352.
https://git.postgresql.org/pg/commitdiff/9691aa72e2a7fb146ac759e1f8a8b04962128cc0

- Add check for syscache lookup failure in update_relispartition(). Omitted in
commit 05b38c7e6 (though it looks like the original blame belongs to
9e9befac4). A failure is admittedly unlikely, but if it did happen, SIGSEGV
is not the approved method of reporting it. Per Coverity. Back-patch to v11
where the broken code originated.
https://git.postgresql.org/pg/commitdiff/62148c3520b562e518f17134b22120bab0cb113b

Noah Misch pushed:

- Use preprocessor conditions compatible with Emacs indent. Emacs wrongly
indented hundreds of subsequent lines.
https://git.postgresql.org/pg/commitdiff/90e7f317735159116fdc3f90e287dd688b18a353

- Suppress compiler warning in non-SSL, non-assert builds. Jeff Janes, reviewed
by Michael Paquier. Discussion:
https://postgr.es/m/CAMkU=1x8taZfsbPkv_MsWbTtzibW_yQHXoMhF_DTtm=z2hVHDg@mail.gmail.com
https://git.postgresql.org/pg/commitdiff/726cc4242a2f766c8280a72ef7c8418965d139c8

- MSVC: Build ~35% faster by calling dumpbin just once per directory. Peifeng
Qiu Discussion:
https://postgr.es/m/CABmtVJiKXQjast0dQD-8KAtfm8XmyYxo-4Dc7+M+fBr8JRTqkw@mail.gmail.com
https://git.postgresql.org/pg/commitdiff/34ff542a71f8e8e768b24d40548dec4be0c707c3

Peter Eisentraut pushed:

- Fix potential catalog corruption with temporary identity columns. If a
temporary table with an identity column and ON COMMIT DROP is created in a
single-statement transaction (not useful, but allowed), it would leave the
catalog corrupted. We need to add a CommandCounterIncrement() so that
PreCommit_on_commit_actions() sees the created dependency between table and
sequence and can clean it up. The analogous and more useful case of doing
this in a transaction block already runs some CommandCounterIncrement() before
it gets to the on-commit cleanup, so it wasn't a problem in practical use.
Several locations for placing the new CommandCounterIncrement() call were
discussed. This patch places it at the end of standard_ProcessUtility().
That would also help if other commands were to create catalog entries that
some on-commit action would like to see. Bug: #15631 Reported-by: Serge
Latyntsev <dnsl48(at)gmail(dot)com> Author: Peter Eisentraut
<peter(dot)eisentraut(at)2ndquadrant(dot)com> Reviewed-by: Michael Paquier
<michael(at)paquier(dot)xyz>
https://git.postgresql.org/pg/commitdiff/cd3e27464cca40664c54fb8cd10454f979c1db4e

Álvaro Herrera pushed:

- Message fixes.
https://git.postgresql.org/pg/commitdiff/ffbce803e646e254367a3f0670d8b64604badc50

- Widen tuple counter variables from long to int64. Mistake in ab0dfc961b6a;
progress reporting would have wrapped around for indexes created with more
than 2^31 tuples. Reported-by: Peter Geoghegan Discussion:
https://postgr.es/m/CAH2-Wz=WbNxc5ob5NJ9yqo2RMJ0q4HXDS30GVCobeCvC9A1L9A@mail.gmail.com
https://git.postgresql.org/pg/commitdiff/9a83afecb7ec6e828b7dbef3133f3dd8b0b4dddb

- Message style fixes.
https://git.postgresql.org/pg/commitdiff/9f8b717a80c59e4a8e8091a8ff6c6f7666a69c33

- heap_prepare_freeze_tuple: Simplify coding. Commit d2599ecfcc74 introduced
some contorted, confused code around: readers would think that it's possible
for HeapTupleHeaderGetXmin return a non-frozen value for some frozen tuples,
which would be disastrous. There's no actual bug, but it seems better to make
it clearer. Per gripe from Tom Lane and Andres Freund. Discussion:
https://postgr.es/m/30116.1555430496@sss.pgh.pa.us
https://git.postgresql.org/pg/commitdiff/2bf372a4ae26337ee61cf7a82081cf4bed05182d

Michaël Paquier pushed:

- Fix some typos. Author: Daniel Gustafsson Discussion:
https://postgr.es/m/42kEeWei6VxLGh12QbR08hiI5Pm-c3XgbK7qj393PSttEhVbnnQoFXHKzXjPRZLUpndWAfHIuZuUqGZBzyXadmEUCSqm9xphWur_I8vESMA=@yesql.se
https://git.postgresql.org/pg/commitdiff/9c592896d9fc81d8def7b98c89a869588e76f0ea

- Fix set of issues with memory-allocation system calls in frontend code. Like
the backend, the frontend has wrappers on top of malloc() and such whose use
is recommended. Particularly, it is possible to do memory allocation without
issuing an error. Some binaries missed the use of those wrappers, so let's
fix the gap for consistency. This also fixes two latent bugs: - In
pg_dump/pg_dumpall when parsing an ACL item, on an out-of-memory error for
strdup(), the code considered the failure as a ACL parsing problem instead of
an actual OOM. - In pg_waldump, an OOM when building the target directory
string would cause a crash. Author: Daniel Gustafsson Discussion:
https://postgr.es/m/gY0y9xenfoBPc-Tufsr2Zg-MmkrJslm0Tw_CMg4p_j58-k_PXNC0klMdkKQkg61BkXC9_uWo-DcUzfxnHqpkpoR5jjVZrPHqKYikcHIiONhg=@yesql.se
https://git.postgresql.org/pg/commitdiff/84e4570da9230d45022ef77f98b560f26eaf6916

Peter Geoghegan pushed:

- Remove obsolete _bt_insert_parent() comment. Remove a comment that refers to a
coding practice that was fully removed by commit a8b8f4db, which introduced
MarkBufferDirty(). It looks like the comment was even obsolete before then,
since it concerns write-ordering dependencies with synchronous buffer writes.
https://git.postgresql.org/pg/commitdiff/9ee7414ed0435d8946d040eb523824f2d71e2418

- Fix nbtsort.c's page space accounting. Commit dd299df8189, which made heap TID
a tiebreaker nbtree index column, introduced new rules on page space
management to make suffix truncation safe. In general, suffix truncation
needs to have a small amount of extra space available on the new left page
when splitting a leaf page. This is needed in case it turns out that
truncation cannot even "truncate away the heap TID column", resulting in a
larger-than-firstright leaf high key with an explicit heap TID representation.
Despite all this, CREATE INDEX/nbtsort.c did not account for the possible need
for extra heap TID space on leaf pages when deciding whether or not a new item
could fit on current page. This could lead to "failed to add item to the
index page" errors when CREATE INDEX/nbtsort.c tried to finish off a leaf page
that lacked space for a larger-than-firstright leaf high key (it only had
space for firstright tuple, which was just short of what was needed following
"truncation"). Several conditions needed to be met all at once for CREATE
INDEX to fail. The problem was in the hard limit on what will fit on a page,
which tends to be masked by the soft fillfactor-wise limit. The easiest way
to recreate the problem seems to be a CREATE INDEX on a low cardinality text
column, with tuples that are of non-uniform width, using a fillfactor of 100.
To fix, bring nbtsort.c in line with nbtsplitloc.c, which already
pessimistically assumes that all leaf page splits will have high keys that
have a heap TID appended. Reported-By: Andreas Joseph Krogh Discussion:
https://postgr.es/m/VisenaEmail.c5.3ee7fe277d514162.16a6d785bea@tc7-visena
https://git.postgresql.org/pg/commitdiff/6dd86c269d5b9a176f6c9f67ea61cc17fef9d860

- Correct more obsolete nbtree page split comments. Commit 3f342839 corrected
obsolete comments about buffer locks at the main _bt_insert_parent() call
site, but missed similar obsolete comments above _bt_insert_parent() itself.
Both sets of comments were rendered obsolete by commit 40dae7ec537, which made
the nbtree page split algorithm more robust. Fix the comments that were
missed the first time around now. In passing, refine a related
_bt_insert_parent() comment about re-finding the parent page to insert new
downlink.
https://git.postgresql.org/pg/commitdiff/7b37f4b02e11813b3cd9f7086149ba962a91e03c

Andres Freund pushed:

- Fix several recently introduced issues around handling new relation forks.
Most of these stem from d25f519107 "tableam: relation creation, VACUUM
FULL/CLUSTER, SET TABLESPACE.". 1) To pass data to the
relation_set_new_filenode() RelationSetNewRelfilenode() was made to update
RelationData.rd_rel directly. That's not OK however, as it makes the
relcache entries temporarily inconsistent. Which among other scenarios is a
problem if a REINDEX targets an index on pg_class - the
CatalogTupleUpdate() in RelationSetNewRelfilenode(). Presumably that was
introduced because other places in the code do so - while those aren't
"good practice" they don't appear to be actively buggy (e.g. because system
tables may not be targeted). I (Andres) should have caught this while
reviewing and signficantly evolving the code in that commit, mea culpa.
Fix that by instead passing in the new RelFileNode as separate argument to
relation_set_new_filenode() and rely on the relcache to update the catalog
entry. Also revert that the RelationMapUpdateMap() call was changed to
immediate, and undo some other more unnecessary changes. 2) Document that
the relation_set_new_filenode cannot rely on the whole relcache entry to be
valid. It might be worthwhile to refactor the code to never have to rely on
that, but given the way heap_create() is currently coded, that'd be a large
change. 3) ATExecSetTableSpace() shouldn't do FlushRelationBuffers() itself.
A table AM might not use shared buffers at all. Move to
index_copy_data() and heapam_relation_copy_data(). 4)
heapam_relation_set_new_filenode() previously sometimes accessed
rel->rd_rel->relpersistence rather than the `persistence` argument. Code
movement mistake. 5) Previously heapam_relation_set_new_filenode() re-opened
the smgr relation to create the init for, if necesary. Instead have
RelationCreateStorage() return the SMgrRelation and use it to create the
init fork. 6) Add a note about the danger of modifying the relcache directly
to ATExecSetTableSpace() - it's currently not a bug because there's a
check ERRORing for catalog tables. Regression tests and assertion
improvements that together trigger the bug described in 1) will be added in a
later commit, as there is a related bug on all branches. Reported-By: Michael
Paquier Diagnosed-By: Tom Lane and Andres Freund Author: Andres Freund
Reviewed-By: Tom Lane Discussion:
https://postgr.es/m/20190418011430.GA19133@paquier.xyz
https://git.postgresql.org/pg/commitdiff/5c1560606dc4c73993fb07f0176b5ec6c515a1b1

- Fix potential assertion failure when reindexing a pg_class index. When
reindexing individual indexes on pg_class it was possible to either trigger an
assertion failure: TRAP:
FailedAssertion("!(!ReindexIsProcessingIndex(((index)->rd_id))) That's
because reindex_index() called SetReindexProcessing() - which enables an
asserts ensuring no index insertions happen into the index - before calling
RelationSetNewRelfilenode(). That not correct for indexes on pg_class, because
RelationSetNewRelfilenode() updates the relevant pg_class row, which needs to
update the indexes. The are two reasons this wasn't noticed earlier. Firstly
the bug doesn't trigger when reindexing all of pg_class, as reindex_relation
has code "hiding" all yet-to-be-reindexed indexes. Secondly, the bug only
triggers when the the update to pg_class doesn't turn out to be a HOT update -
otherwise there's no index insertion to trigger the bug. Most of the time
there's enough space, making this bug hard to trigger. To fix, move
RelationSetNewRelfilenode() to before the SetReindexProcessing() (and,
together with some other code, to outside of the PG_TRY()). To make sure the
error checking intended by SetReindexProcessing() is more robust, modify
CatalogIndexInsert() to check ReindexIsProcessingIndex() even when the update
is a HOT update. Also add a few regression tests for REINDEXing of system
catalogs. The last two improvements would have prevented some of the issues
fixed in 5c1560606dc4c from being introduced in the first place. Reported-By:
Michael Paquier Diagnosed-By: Tom Lane and Andres Freund Author: Andres Freund
Reviewed-By: Tom Lane Discussion:
https://postgr.es/m/20190418011430.GA19133@paquier.xyz Backpatch: 9.4-, the
bug is present in all branches
https://git.postgresql.org/pg/commitdiff/3dbb317d32f4f084ef7badaed8ef36f5c9b85fe6

- docs: Fix small copy & paste mistake. Author: Justin Pryzby Discussion:
https://postgr.es/m/20190418005115.r4mat75wvlski3ij@alap3.anarazel.de
https://git.postgresql.org/pg/commitdiff/b06a354e381d30e13cef28904bb923896aa4719b

- Improve code inferring length of bitmap for JITed tuple deforming. While
discussing comment improvements (see next commit) by Justin Pryzby, Tom
complained about a few details of the logic to infer the length of the NULL
bitmap when building the JITed tuple deforming function. That bitmap allows to
avoid checking the tuple header's natts, a check which often causes a pipeline
stall Improvements: a) As long as missing columns aren't taken into account,
we can continue to infer the length of the NULL bitmap from NOT NULL
columns following it. Previously we stopped at the first missing column.
It's unlikely to matter much in practice, but the alternative would have
been to document why we stop. b) For robustness reasons it seems better to
also check against attisdropped - RemoveAttributeById() sets attnotnull to
false, but an additional check is trivial. c) Improve related comments
Discussion: https://postgr.es/m/20637.1555957068@sss.pgh.pa.us Backpatch: -
https://git.postgresql.org/pg/commitdiff/3a48005b0049d69b4376e6ae386479ae3d255a11

- Improve comment spelling and style in llvmjit_deform.c. Author: Justin Pryzby
Discussion: https://postgr.es/m/20190408141828.GE10080@telsasoft.com
https://postgr.es/m/20181127184133.GM10913@telsasoft.com
https://git.postgresql.org/pg/commitdiff/a0b5bb6e026a3acf739843b744f3b14d4093450a

- Run catalog reindexing test from 3dbb317d32 serially, to avoid deadlocks. The
tests turn out to cause deadlocks in some circumstances. Fairly reproducibly
so with -DRELCACHE_FORCE_RELEASE -DCATCACHE_FORCE_RELEASE. Some of the
deadlocks may be hard to fix without disproportionate measures, but others
probably should be fixed - but not in 12. We discussed removing the new tests
until we can fix the issues underlying the deadlocks, but results from
buildfarm animal markhor (which runs with CLOBBER_CACHE_ALWAYS) indicates that
there might be a more severe, as of yet undiagnosed, issue (including on
stable branches) with reindexing catalogs. The failure is: ERROR: could not
read block 0 in file "base/16384/28025": read only 0 of 8192 bytes Therefore
it seems advisable to keep the tests. It's not certain that running the tests
in isolation removes the risk of deadlocks. It's possible that additional
locks are needed to protect against a concurrent auto-analyze or such. Per
discussion with Tom Lane. Discussion:
https://postgr.es/m/28926.1556664156@sss.pgh.pa.us Backpatch: 9.4-, like
3dbb317d3
https://git.postgresql.org/pg/commitdiff/809c9b48f4bdd11dfc088f6d0b9a6c57936c32ca

- Fix unused variable compiler warning in !debug builds. Introduced in
3dbb317d3. Fix by using the new local variable in more places. Reported-By:
Bruce Momjian (off-list) Backpatch: 9.4-, like 3dbb317d3
https://git.postgresql.org/pg/commitdiff/4b40d40b30ae04ba524cd410f14e64ae4425a180

Bruce Momjian pushed:

- doc: move "only" to a more appropriate place in the sentence.
https://git.postgresql.org/pg/commitdiff/345473862571d5b2c63849f6472828bdc5b49320

- doc: improve PG 12 to_timestamp()/to_date() wording.
https://git.postgresql.org/pg/commitdiff/ad23adc5a169b114f9ff325932cbf2ce1c5e69c1

- doc: clarify behavior of pg_upgrade's clone mode. Be more precise about the
benefits of using clone mode.
https://git.postgresql.org/pg/commitdiff/26950273dc27ec7775029cffe1140165f942325d

Magnus Hagander pushed:

- Fix union for pgstat message types. The message type for temp files and for
checksum failures were missing from the union. Due to the coding style used
there was no compiler error when this happend. So change the code to actively
use the union thereby producing a compiler error if the same mistake happens
again, suggested by Tom Lane. Author: Julien Rouhaud Reported-By: Tomas
Vondra Discussion:
https://postgr.es/m/20190430163328.zd4rrlnbvgaqlcdz@development
https://git.postgresql.org/pg/commitdiff/659e53498c3c04e4f400323c02bef98fe8d13ec8

Robert Haas pushed:

- Fix some problems with VACUUM (INDEX_CLEANUP FALSE). The new nleft_dead_tuples
and nleft_dead_itemids fields are confusing and do not seem like the correct
way forward. One of them is tested via an assertion that can fail, as it has
already done on buildfarm member topminnow. Remove the assertion and the
fields. Change the logic for the case where a tuple is not initially pruned
by heap_page_prune but later diagnosed HEAPTUPLE_DEAD by
HeapTupleSatisfiesVacuum. Previously, tupgone = true was set in that case,
which leads to treating the tuple as one that will be removed. In a normal
vacuum, that's OK, because we'll remove index entries for it and then the
second heap pass will remove the tuple itself, but when index cleanup is
disabled, those things don't happen, so we must instead treat it as a
recently-dead tuple that we have voluntarily chosen to keep. Report and
analysis by Tom Lane. This patch loosely based on one from Masahiko Sawada,
but I changed most of it.
https://git.postgresql.org/pg/commitdiff/dd69597988859c51131e0cbff3e30432db4259e1

== Pending Patches ==

Alexander Korotkov sent in two more revisions of a patch to improve error
messages for JSONPATH.

David Fetter sent in three more revisions of a patch to add \warn to psql.

Anastasia Lubennikova sent in another revision of a patch to track splits
correctly in the WAL optimization for GiST index creation.

David Fetter and Fabien COELHO traded patches to show detailed table persistence
in psql's \dt+.

Paul Guo sent in another revision of a patch to skip copydir() if either src
directory or dst directory is missing due to re-redoing create database but the
tablespace is dropped.

Justin Pryzby sent in another revision of a patch to improve the wording in
to_timestamp()/to_date().

John Naylor and Amit Kapila traded patches to revert "Avoid the creation of the
free space map for small heap relations".

Amit Kapila and Dilip Kumar traded patches to allow undo actions to be applied
on rollbacks and discard unwanted undo.

Tomáš Vondra sent in a patch to fix a hang in walsender.

Laurenz Albe sent in another revision of a patch to avoid canonicalizing
dateranges with 'infinity' bounds.

Antonin Houska sent in another revision of a patch to consolidate reading of
XLOG pages into a single code path.

Fabien COELHO sent in another revision of a patch for pgbench to add option to
show actual builtin script code.

Thomas Munro sent in two revisions of a patch to make file_fdw parallel-aware.

Jeff Janes sent in a patch to fix a bug in the error checking of pg_upgrade
--clone.

Tom Lane sent in a patch to make AppendInvalidationMessageList actually append
the current-commands list to the prior-cmds list.

Justin Pryzby sent in another revision of a patch to make \d pg_toast.foo show
its indices in psql.

Dmitry Dolgov sent in another revision of a patch to speed up GROUP BY.

Robert Haas sent in a patch to improve wraparound behavior.

Peter Eisentraut sent in a patch to fix table lock levels for REINDEX INDEX
CONCURRENTLY.

Tomáš Vondra sent in a patch to account for memory used for BufFile during hash
joins.

Julien Rouhaud sent in a patch to fix a mistaken return code in vacuumdb when
multiple jobs are used.

Artur Zakirov sent in a patch to fix the explanation of FX in the to_timestamp.

Peter Geoghegan sent in a patch to remove the nbtree half-dead internal page
check.

Tomáš Vondra sent in a patch to fix the way error messages are logged in
extended statistics.

Michaël Paquier sent in another revision of a patch to fix some inconsistent
error message wording for REINDEX CONCURRENTLY.