== PostgreSQL Weekly News - October 16 2016 ==

== PostgreSQL Weekly News - October 16 2016 ==

== PostgreSQL Jobs for October ==

http://archives.postgresql.org/pgsql-jobs/2016-10/threads.php

== PostgreSQL Local ==

PostgreSQL Conference Europe will take place in Tallin, Estonia, on
November 1-4, 2016. The schedule has been published.
http://2016.pgconf.eu/registration/

PGDay Austin 2016, will take place on November 12, 2016. Submission deadline
is September 21, 2016 by midnight CST. Details and submission form at:
https://www.postgresql.us/events/2016/austin

PgConf Silicon Valley 2016 will be held on November 14-16, 2016.
http://www.pgconfsv.com/

CHAR(16) will take place in New York, December 6, 2016.
http://charconference.org/

PGDay.IT 2016 will take place in Prato on December the 13th 2016.
http://pgday.it

== 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 Pacific time.
Please send English language ones to david(at)fetter(dot)org, German language
to pwn(at)pgug(dot)de, Italian language to pwn(at)itpug(dot)org(dot)

== Applied Patches ==

Peter Eisentraut pushed:

- Add a noreturn attribute to help static analyzers
http://git.postgresql.org/pg/commitdiff/52f0142eb4c755d1f4c390464769d35f21e998c3

Heikki Linnakangas pushed:

- Remove some unnecessary #includes. Amit Langote
http://git.postgresql.org/pg/commitdiff/6fb12cbcd6f1a971e113d7d32cc7ee920db4e097

- Simplify the code for logical tape read buffers. Pass the buffer size as
argument to LogicalTapeRewindForRead, rather than setting it earlier with the
separate LogicTapeAssignReadBufferSize call. This way, the buffer size is set
closer to where it's actually used, which makes the code easier to understand.
This makes the calculation for how much memory to use for the buffers less
precise. We now use the same amount of memory for every tape, rounded down to
the nearest BLCKSZ boundary, instead of using one more block for some tapes,
to get the total up to exact amount of memory available. That should be OK,
merging isn't too sensitive to the exact amount of memory used. Reviewed by
Peter Geoghegan. Discussion: <0f607c4b-df23-353e-bf56-c0389d28495f(at)iki(dot)fi>
http://git.postgresql.org/pg/commitdiff/b75f467b6eec0678452fd8d7f8d306e6df3a1076

- Fix copy-pasto in comment. Amit Langote
http://git.postgresql.org/pg/commitdiff/bb55dd6059dddf2cd44423da6a3f6946826953cf

Tom Lane pushed:

- In PQsendQueryStart(), avoid leaking any left-over async result. Ordinarily
there would not be an async result sitting around at this point, but it
appears that in corner cases there can be. Considering all the work we're
about to launch, it's hardly going to cost anything noticeable to check. It's
been like this forever, so back-patch to all supported branches. Report:
<CAD-Qf1eLUtBOTPXyFQGW-4eEsop31tVVdZPu4kL9pbQ6tJPO8g(at)mail(dot)gmail(dot)com>
http://git.postgresql.org/pg/commitdiff/886f6c5ccdb500eeeec7e0abdf1500e20a304c45

- Update user docs for switch to POSIX semaphores. Since commit ecb0d20a9
hasn't crashed and burned, here's the promised docs update for it. In
addition to explaining that Linux and FreeBSD ports now use POSIX semaphores,
I did some wordsmithing on pre-existing wording; in particular trying to
clarify which SysV parameters need to be set with an eye to total usage across
all applications.
http://git.postgresql.org/pg/commitdiff/3d21f08bccd316c3850a1943c1ee1e381dab1588

- Improve documentation for CREATE RECURSIVE VIEW. It was perhaps not entirely
clear that internal self-references shouldn't be schema-qualified even if the
view name is written with a schema. Spell it out. Discussion:
<871sznz69m(dot)fsf(at)metapensiero(dot)it>
http://git.postgresql.org/pg/commitdiff/e34318725ca5b274efd6f57ea7460e89f4dca9f9

- Docs: grammatical fix. Fix poor grammar introduced in 741ccd501.
http://git.postgresql.org/pg/commitdiff/c7e56811fa38cbc39efd6bdd4bb45f2f0444803e

- Remove "sco" and "unixware" ports. SCO OpenServer and SCO UnixWare are more
or less dead platforms. We have never had a buildfarm member testing the
"sco" port, and the last "unixware" member was last heard from in 2012, so
it's fair to doubt that the code even compiles anymore on either one. Remove
both ports. We can always undo this if someone shows up with an interest in
maintaining and testing these platforms. Discussion:
<17177(dot)1476136994(at)sss(dot)pgh(dot)pa(dot)us>
http://git.postgresql.org/pg/commitdiff/2b860f52ed1b1784cdf3f03886805f5bf250ea74

- Drop server support for FE/BE protocol version 1.0. While this isn't a lot of
code, it's been essentially untestable for a very long time, because libpq
doesn't support anything older than protocol 2.0, and has not since release
6.3. There's no reason to believe any other client-side code still uses that
protocol, either. Discussion: <2661(dot)1475849167(at)sss(dot)pgh(dot)pa(dot)us>
http://git.postgresql.org/pg/commitdiff/2f1eaf87e868a1c42f2b159958623daa6a666de4

- Provide DLLEXPORT markers for C functions via PG_FUNCTION_INFO_V1 macro. This
isn't really necessary for our own code, because we use a .DEF file in MSVC
builds (see gendef.pl), or --export-all-symbols in MinGW and Cygwin builds, to
ensure that all global symbols in loadable modules will be exported on
Windows. However, third-party authors might use different build processes
that need this marker, and it's harmless enough for our own builds. To some
extent, this is an oversight in commit e7128e8db, so back-patch to 9.4 where
that was added. Laurenz Albe. Discussion:
<A737B7A37273E048B164557ADEF4A58B539300BD(at)ntex2010a(dot)host(dot)magwien(dot)gv(dot)at>
http://git.postgresql.org/pg/commitdiff/8518583cdb10340bab3464121629a1a9ec387afa

- Remove unnecessary int2vector-specific hash function and equality operator.
These functions were originally added in commit d8cedf67a to support use of
int2vector columns as catcache lookup keys. However, there are no catcaches
that use such columns. (Indeed I now think it must always have been dead
code: a catcache with such a key column would need an underlying unique index
on the column, but we've never had an int2vector btree opclass.) Getting rid
of the int2vector-specific operator and function does not lose any
functionality, because operations on int2vectors will now fall back to the
generic anyarray support. This avoids a wart that a btree index on an
int2vector column (made using anyarray_ops) would fail to match equality
searches, because int2vectoreq wasn't a member of the opclass. We don't
really care much about that, since int2vector is not meant as a type for users
to use, but it's silly to have extra code and less functionality. If we ever
do want a catcache to be indexed by an int2vector column, we'd need to put
back full btree and hash opclasses for int2vector, comparable to the support
for oidvector. (The anyarray code can't be used at such a low level, because
it needs to do catcache lookups.) But we'll deal with that if/when the need
arises. Also worth noting is that removal of the hash int2vector_ops opclass
will break any user-created hash indexes on int2vector columns. While hash
anyarray_ops would serve the same purpose, it would probably not compute the
same hash values and thus wouldn't be on-disk-compatible. Given that
int2vector isn't a user-facing type and we're planning other incompatible
changes in hash indexes for v10 anyway, this doesn't seem like something to
worry about, but it's probably worth mentioning here. Amit Langote
Discussion: <d9bb74f8-b194-7307-9ebd-90645d377e45(at)lab(dot)ntt(dot)co(dot)jp>
http://git.postgresql.org/pg/commitdiff/5c80642aa8de8393b08cd3cbf612b325cedd98dc

- Remove pg_dump/pg_dumpall support for dumping from pre-8.0 servers. The need
for dumping from such ancient servers has decreased to about nil in the field,
so let's remove all the code that catered to it. Aside from removing a lot of
boilerplate variant queries, this allows us to not have to cope with servers
that don't have (a) schemas or (b) pg_depend. That means we can get rid of
assorted squishy code around that. There may be some nonobvious additional
simplifications possible, but this patch already removes about 1500 lines of
code. I did not remove the ability for pg_restore to read custom-format
archives generated by these old versions (and light testing says that that
does still work). If you have an old server, you probably also have a pg_dump
that will work with it; but you have an old custom-format backup file, that
might be all you have. It'd be possible at this point to remove
fmtQualifiedId()'s version argument, but I refrained since that would affect
code outside pg_dump. Discussion: <2661(dot)1475849167(at)sss(dot)pgh(dot)pa(dot)us>
http://git.postgresql.org/pg/commitdiff/64f3524e2c8deebc02808aa5ebdfa17859473add

- pg_dump's getTypes() needn't retrieve typinput or typoutput anymore. Commit
64f3524e2 removed the stanza of code that examined these values. I failed to
notice they were unnecessary because my compiler didn't warn about the un-read
variables. Noted by Peter Eisentraut.
http://git.postgresql.org/pg/commitdiff/c0a3b211bcb790a8d76022cb2b3ffe9795aaf5e9

- Revert addition of PGDLLEXPORT in PG_FUNCTION_INFO_V1 macro. This turns out
not to be as harmless as I thought: MSVC will complain if it sees an "extern"
declaration without PGDLLEXPORT and then one with. (Seems fairly silly, given
that this can be changed after the fact by the linker, but there you have it.)
Therefore, contrib modules that have extern's for V1 functions in header files
are falling over in the buildfarm, since none of those externs are marked
PGDLLEXPORT. We might or might not conclude that we're willing to plaster
those declarations with PGDLLEXPORT in HEAD, but in any case there's no way
we're going to ship this change in the back branches. Third-party authors
would not thank us for breaking their code in a minor release. Hence, revert
the addition of PGDLLEXPORT (but let's keep the extra info in the comment).
If we do the other changes we can revert this commit in HEAD. Per buildfarm.
http://git.postgresql.org/pg/commitdiff/4f52fd3c6d28a4380a5afc51ae6f774c91837a38

- Fix broken jsonb_set() logic for replacing array elements. Commit 0b62fd036
did a fairly sloppy job of refactoring setPath() to support jsonb_insert()
along with jsonb_set(). In its defense, though, there was no regression test
case exercising the case of replacing an existing element in a jsonb array.
Per bug #14366 from Peng Sun. Back-patch to 9.6 where bug was introduced.
Report: <20161012065349(dot)1412(dot)47858(at)wrigleys(dot)postgresql(dot)org>
http://git.postgresql.org/pg/commitdiff/9c4cc9e2c75e84a8267396be5cccbfe25b8f63f6

- Fix pg_dumpall regression test to be locale-independent. The expected results
in commit b4fc64578 seem to have been generated in a non-C locale, which just
points up the fact that the ORDER BY clause was locale-sensitive. Per
buildfarm.
http://git.postgresql.org/pg/commitdiff/0a4bf6b192377bef8e69c92d0c95434a91509f12

- Clean up handling of anonymous mmap'd shared-memory segment. Fix detaching of
the mmap'd segment to have its own on_shmem_exit callback, rather than
piggybacking on the one for detaching from the SysV segment. That was
confusing, and given the distance between the two attach calls, it was trouble
waiting to happen. Make the detaching calls idempotent by clearing
AnonymousShmem to show we've already unmapped. I spent quite a bit of time
yesterday trying to find a path that would allow the munmap()'s to be done
twice, and while I did not succeed, it seems silly that there's even a
question. Make the #ifdef logic less confusing by separating "do we want to
use anonymous shmem" from EXEC_BACKEND. Even though there's no current
scenario where those conditions are different, it is not helpful for different
places in the same file to be testing EXEC_BACKEND for what are fundamentally
different reasons. Don't do on_exit_reset() in StartBackgroundWorker(). At
best that's useless (InitPostmasterChild would have done it already) and at
worst it could zap some callback that's unrelated to shared memory. Improve
comments, and simplify the huge_pages enablement logic slightly. Back-patch
to 9.4 where hugepage support was introduced. Arguably this should go into
9.3 as well, but the code looks significantly different there, and I doubt
it's worth the trouble of adapting the patch given I can't show a live bug.
http://git.postgresql.org/pg/commitdiff/15fc5e15811337f5a81d4ae44c6149256f6dd15f

- Try to find out the actual hugepage size when making a MAP_HUGETLB request.
Even if Linux's mmap() is okay with a partial-hugepage request, munmap() is
not, as reported by Chris Richards. Therefore it behooves us to try a bit
harder to find out the actual hugepage size, instead of assuming that we can
skate by with a guess. For the moment, just look into /proc/meminfo to find
out the default hugepage size, and use that. Later, on kernels that support
requests for nondefault sizes, we might try to consider other alternatives.
But that smells more like a new feature than a bug fix, especially if we want
to provide any way for the DBA to control it, so leave it for another day. I
set this up to allow easy addition of platform-specific code for non-Linux
platforms, if needed; but right now there are no reports suggesting that we
need to work harder on other platforms. Back-patch to 9.4 where hugepage
support was introduced. Discussion: <31056(dot)1476303954(at)sss(dot)pgh(dot)pa(dot)us>
http://git.postgresql.org/pg/commitdiff/cb775768e3e37d466d69b7177a92508b81c1c204

- Remove dead code in pg_dump. I'm not sure if this provision for "pg_backup"
behaving a bit differently from "pg_dump" ever did anything useful in a
released version. But it's definitely dead code now. Michael Paquier
http://git.postgresql.org/pg/commitdiff/c08521eb55135c493cee23541c233870cdff14b7

- Fix another bug in merging of inherited CHECK constraints. It's not good for
an inherited child constraint to be marked connoinherit; that would result in
the constraint not propagating to grandchild tables, if any are created later.
The code mostly prevented this from happening but there was one case that was
missed. This is somewhat related to commit e55a946a8, which also tightened
checks on constraint merging. Hence, back-patch to 9.2 like that one. This
isn't so much because there's a concrete feature-related reason to stop there,
as to avoid having more distinct behaviors than we have to in this area. Amit
Langote Discussion: <b28ee774-7009-313d-dd55-5bdd81242c41(at)lab(dot)ntt(dot)co(dot)jp>
http://git.postgresql.org/pg/commitdiff/3cca13cbfcc5312f7ae1728213e197c6f37ca62a

- Fix handling of pgstat counters for TRUNCATE in a prepared transaction.
pgstat_twophase_postcommit is supposed to duplicate the math in
AtEOXact_PgStat, but it had missed out the bit about clearing
t_delta_live_tuples/t_delta_dead_tuples for a TRUNCATE. It's harder than you
might think to replicate the issue here, because those counters would only be
nonzero when a previous transaction in the same backend had added/deleted
tuples in the truncated table, and those counts hadn't been sent to the stats
collector yet. Evident oversight in commit d42358efb. I've not added a
regression test for this; we tried to add one in d42358efb, and had to revert
it because it was too timing-sensitive for the buildfarm. Back-patch to 9.5
where d42358efb came in. Stas Kelvich Discussion:
<EB57BF68-C06D-4737-BDDC-4BA778F4E62B(at)postgrespro(dot)ru>
http://git.postgresql.org/pg/commitdiff/81e82a2bd48865f9a294b63d9492f9fde6a32787

- Fix assorted integer-overflow hazards in varbit.c. bitshiftright() and
bitshiftleft() would recursively call each other infinitely if the user passed
INT_MIN for the shift amount, due to integer overflow in negating the shift
amount. To fix, clamp to -VARBITMAXLEN. That doesn't change the results
since any shift distance larger than the input bit string's length produces an
all-zeroes result. Also fix some places that seemed inadequately paranoid
about input typmods exceeding VARBITMAXLEN. While a typmod accepted by
anybit_typmodin() will certainly be much less than that, at least some of
these spots are reachable with user-chosen integer values. Andreas
Seltenreich and Tom Lane Discussion: <87d1j2zqtz(dot)fsf(at)credativ(dot)de>
http://git.postgresql.org/pg/commitdiff/32fdf42cf546f613aab9ca98935c40a046187fa9

Andres Freund pushed:

- Make regression tests less dependent on hash table order. Upcoming changes to
the hash table code used, among others, for grouping and set operations will
change the output order for a few queries. To make it less likely that actual
bugs are hidden between regression test ordering changes, and to make the
tests robust against platform dependant ordering, add ORDER BYs guaranteeing
the output order. As it's possible that some of the changes expose platform
dependant ordering, push this earlier, to let the buildfarm shake out
potentially unstable results. Discussion:
<20160727004333(dot)r3e2k2y6fvk2ntup(at)alap3(dot)anarazel(dot)de>
http://git.postgresql.org/pg/commitdiff/0137caf273f4297c4d36df3a542d7c0c853e75be

- Fix further hash table order dependent tests. Similar to 0137caf273, this
makes contrib and pl tests less dependant on hash-table order. After this
commit, at least some order affecting changes to execGrouping.c don't result
in regression test changes anymore.
http://git.postgresql.org/pg/commitdiff/ccbb852cd6101e93976111676a90f1e5d9268951

- Make pg_dumpall's database ACL query independent of hash table order.
Previously GRANT order on databases was not well defined, due to the use of
EXCEPT without an ORDER BY. Add an ORDER BY, adapt test output. I don't, at
the moment, see reason to backpatch this.
http://git.postgresql.org/pg/commitdiff/b4fc645787cc7c614c0c97fc9fffacf2bdc6a388

- Use more efficient hashtable for tidbitmap.c to speed up bitmap scans. Use
the new simplehash.h to speed up tidbitmap.c uses. For bitmap scan heavy
queries speedups of over 100% have been measured. Both lossy and exact scans
benefit, but the wins are bigger for mostly exact scans. The conversion is
mostly trivial, except that tbm_lossify() now restarts lossifying at the point
it previously stopped. Otherwise the hash table becomes unbalanced because the
scan in done in hash-order, leaving the end of the hashtable more densely
filled then the beginning. That caused performance issues with dynahash as
well, but due to the open chaining they were less pronounced than with the
linear adressing from simplehash.h. Reviewed-By: Tomas Vondra Discussion:
<20160727004333(dot)r3e2k2y6fvk2ntup(at)alap3(dot)anarazel(dot)de>
http://git.postgresql.org/pg/commitdiff/75ae538bc3168bf44475240d4e0487ee2f3bb376

- Add likely/unlikely() branch hint macros. These are useful for very hot code
paths. Because it's easy to guess wrongly about likelihood, and because such
likelihoods change over time, they should be used sparingly. Past tests have
shown it'd be a good idea to use them in some places, e.g. in error checks
around ereports that ERROR out, but that's work for later. Discussion:
<20160727004333(dot)r3e2k2y6fvk2ntup(at)alap3(dot)anarazel(dot)de>
http://git.postgresql.org/pg/commitdiff/aa3ca5e3dd60bf0b992b74f955378f28e601292a

- Add a macro templatized hashtable. dynahash.c hash tables aren't quite fast
enough for some use-cases. There are several reasons for lacking performance:
The use of chaining for collision handling makes them cache inefficient,
that's especially an issue when the tables get bigger. As the element sizes
for dynahash are only determined at runtime, offset computations are somewhat
expensive Hash and element comparisons are indirect function calls, causing
unnecessary pipeline stalls It's two level structure has some benefits
(somewhat natural partitioning), but increases the number of indirections to
fix several of these the hash tables have to be adjusted to the individual
use-case at compile-time. C unfortunately doesn't provide a good way to do
compile code generation (like e.g. c++'s templates for all their weaknesses
do). Thus the somewhat ugly approach taken here is to allow for code
generation using a macro-templatized header file, which generates functions
and types based on a prefix and other parameters. Later patches use this
infrastructure to use such hash tables for tidbitmap.c (bitmap scans) and
execGrouping.c (hash aggregation, ...). In queries where these use up a large
fraction of the time, this has been measured to lead to performance
improvements of over 100%. There are other cases where this could be useful
(e.g. catcache.c). The hash table design chosen is a variant of linear
open-addressing. The biggest disadvantage of simple linear addressing schemes
are highly variable lookup times due to clustering, and deletions leaving a
lot of tombstones around. To address these issues a variant of "robin hood"
hashing is employed. Robin hood hashing optimizes chaining lengths by moving
elements close to their optimal bucket ("rich" elements), out of the way if a
to-be-inserted element is further away from its optimal position (i.e. it's
"poor"). While that can make insertions slower, the average lookup
performance is a lot better, and higher fill factors can be used in a still
performant manner. To avoid tombstones - which normally solve the issue that
a deleted node's presence is relevant to determine whether a lookup needs to
continue looking or is done - buckets following a deleted element are shifted
backwards, unless they're empty or already at their optimal position. There's
further possible improvements that can be made to this implementation. Amongst
others: Use distance as a termination criteria during searches. This is
generally a good idea, but I've been able to see the overhead of distance
calculations in some cases. Consider combining the 'empty' status into the
hashvalue, and enforce storing the hashvalue. That could, in some cases,
increase memory density and remove a few instructions. Experiment further
with the, very conservatively choosen, fillfactor. Make maximum size of
hashtable configurable, to allow storing very very large tables. That'd
require 64bit hash values to be more common than now, though. some smaller
memcpy calls could be optimized to copy larger chunks. But since the new
implementation is already considerably faster than dynahash it seem sensible
to start using it. Reviewed-By: Tomas Vondra Discussion:
<20160727004333(dot)r3e2k2y6fvk2ntup(at)alap3(dot)anarazel(dot)de>
http://git.postgresql.org/pg/commitdiff/b30d3ea824c5ccba43d3e942704f20686e7dbab8

- Use more efficient hashtable for execGrouping.c to speed up hash aggregation.
The more efficient hashtable speeds up hash-aggregations with more than a few
hundred groups significantly. Improvements of over 120% have been measured.
Due to the the different hash table queries that not fully determined (e.g.
GROUP BY without ORDER BY) may change their result order. The conversion is
largely straight-forward, except that, due to the static element types of
simplehash.h type hashes, the additional data some users store in elements
(e.g. the per-group working data for hash aggregaters) is now stored in
TupleHashEntryData->additional. The meaning of BuildTupleHashTable's
entrysize (renamed to additionalsize) has been changed to only be about the
additionally stored size. That size is only used for the initial sizing of
the hash-table. Reviewed-By: Tomas Vondra Discussion:
<20160727004333(dot)r3e2k2y6fvk2ntup(at)alap3(dot)anarazel(dot)de>
http://git.postgresql.org/pg/commitdiff/5dfc198146b49ce7ecc8a1fc9d5e171fb75f6ba5

Robert Haas pushed:

- Remove spurious word. Tatsuo Ishii
http://git.postgresql.org/pg/commitdiff/248776ea06c240ae4605e77369d66bcd7ae4f9e3

Tatsuo Ishii pushed:

- Fix typo. Confirmed by Tom Lane.
http://git.postgresql.org/pg/commitdiff/b1ee762a6138df073d4b2b80c235dd9025a8532c

- Fix typo. Confirmed by Michael Paquier.
http://git.postgresql.org/pg/commitdiff/13d3180fd14c624bbb274e200e98ddb50e260216

== Pending Patches ==

Michaël Paquier sent in a patch to use pg_ctl promote -w in TAP tests.

Michaël Paquier sent in a patch to fix some FSM corruption.

Pavel Stěhule sent in another revision of a patch to add \setfileref to psql.

Heikki Linnakangas sent in two more revisions of a patch to simplify the tape
block format, and add pause/resume support for tapes.

Thomas Munro sent in another revision of a patch to enable DISTINCT with btree
skip scan.

Mithun Cy sent in another revision of a patch to add some tests to cover
hash_index.

Amit Langote sent in a patch to remove the int2vector operator hash
infrastructure.

Haribabu Kommi sent in a patch to add a 64-bit (EUI-64) MAC address data type.

Dilip Kumar sent in a patch to enable scan key push down to heap.

Haribabu Kommi sent in a patch to add a pg_stat_sql system view.

Jim Nasby sent in a patch to add support for SRFs and returning composites from
pl/tcl.

Robert Haas sent in another revision of a patch to bump up max-parallel-workers.

Amit Kapila sent in a patch to enables parallelism for btree scans.

Prabhat Kumar Sahu and Jeevan Chalke traded patches to do aggregate pushdown to
a foreign server.

Aleksander Alekseev sent in a patch to fix some infelicities in pg_filedump.

Michaël Paquier sent in another revision of a patch to rename pg_xlog to pg_wal
and two alternatives for renaming pg_clog: pg_transaction, and pg_xact.

Heikki Linnakangas sent in a patch to replace the polyphase merge algorithm with
a simple balanced k-way merge.

Michaël Paquier and Heikki Linnakangas traded patches to add SCRAM auth.

Michaël Paquier sent in a patch to improve OOM handling in pg_locale.c.

Mithun Cy sent in another revision of a patch to implement failover on libpq
connect level.

Etsuro Fujita sent in another revision of a patch to push down more full joins
in postgres_fdw.

Peter Eisentraut sent in a patch to simplify internal archive version handling
in pg_dump.

Etsuro Fujita sent in a patch to clarify the mention of self-joins in the DELETE
documentation.

Pavel Stěhule sent in another revision of a patch to add xmltable().

Ashutosh Bapat sent in another revision of a patch to optimize partition-wise
JOINs in tables with declarative partitions.

Michaël Paquier sent in a patch to improve the durability of pg_dump(all).

Stas Kelvich sent in a patch to fix some of the logging for 2PC.

Christoph Berg sent in a patch to choose a non-empty default log_line_prefix.

Peter Eisentraut sent in a patch to make getrusage() output a little more
readable.

Heikki Linnakangas sent in another revision of a patch to support
multi-dimensional arrays in PL/python and give a hint when [] is incorrectly
used for a composite type in array.

Magnus Hagander sent in another revision of a patch to enable pg_basebackup to
stream xlog to tar.

Jeff Janes sent in a patch to change the auth check in postgres_fdw to something
a little stricter.

Jim Nasby sent in a patch to return a bitmask of NULL fields in a record.