== PostgreSQL Weekly News - August 07 2016 ==

== PostgreSQL Weekly News - August 07 2016 ==

PGconf.ASIA 2016 will be held On December 2 and 3 in Tokyo.
Send your proposals to
pgconf-asia-2016-submission AT pgconf DOT asia
Submission deadline is midnight, 31st August, 2016.
http://www.pgconf.asia/EN/

== PostgreSQL Product News ==

oracle_fdw 1.5.0 released.
https://laurenz.github.io/oracle_fdw

asyncpg a Python client library for PostgreSQL build specifically for
asyncio and Python 3.5 async / await, released.
https://github.com/MagicStack/asyncpg

== PostgreSQL Jobs for August ==

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

== PostgreSQL Local ==

PostgresOpen 2016 in will be held in Dallas, Texas September 13-16.
The CfP is open.
https://2016.postgresopen.org/callforpapers/

PostgreSQL Session will be held on September 22th, 2016, in Lyon,
France. The submission deadline is May 20, 2016. Send proposals to
call-for-paper AT postgresql-sessions DOT org.

PostgreSQL Conference Europe will take place in Tallin, Estonia, on
November 1-4, 2016. Early bird registration is open until September
14th, 2016.
http://2016.pgconf.eu/registration/

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. Call for
papers is open until midnight (EDT) September 13, 2016.
http://charconference.org/

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

Fujii Masao pushed:

- Fix pg_basebackup so that it accepts 0 as a valid compression level.
The help message for pg_basebackup specifies that the numbers 0
through 9 are accepted as valid values of -Z option. But, previously
-Z 0 was rejected as an invalid compression level. Per discussion,
it's better to make pg_basebackup treat 0 as valid compression level
meaning no compression, like pg_dump. Back-patch to all supported
versions. Reported-By: Jeff Janes Reviewed-By: Amit Kapila
Discussion:
CAMkU=1x+GwjSayc57v6w87ij6iRGFWt=hVfM0B64b1_bPVKRqg(at)mail(dot)gmail(dot)com
http://git.postgresql.org/pg/commitdiff/74d8c95b7456faefdd4244acf854361711fb42ce

- Remove unused arguments from pg_replication_origin_xact_reset
function. The document specifies that
pg_replication_origin_xact_reset function doesn't have any argument
variables. But previously it was actually defined so as to have two
argument variables, though they were not used at all. That is, the
pg_proc entry for that function was incorrect. This patch fixes the
pg_proc entry and removes those two arguments from the function
definition. No back-patch because this change needs a catalog
version bump although the issue exists in 9.5 as well. Instead, a
note about those unused argument variables will be added to 9.5
document later. Catalog version bumped due to the change of
pg_proc.
http://git.postgresql.org/pg/commitdiff/dd5eb805d5e5384963f09c9986845a544ef41810

Michael Meskes pushed:

- Fixed array checking code for "unsigned long long" datatypes in
libecpg.
http://git.postgresql.org/pg/commitdiff/3ebc88e568053fa16766e05155eb005cc72978db

Bruce Momjian pushed:

- pg_rewind docs: clarify handling of remote servers
http://git.postgresql.org/pg/commitdiff/878bd9accb553f6eee32af8acdb7ee3e54a74e23

- doc: OS collation changes can break indexes. Discussion:
20160702155517(dot)GD18610(at)momjian(dot)us Reviewed-by: Christoph Berg
Backpatch-through: 9.1
http://git.postgresql.org/pg/commitdiff/a253a88594f6805168261ea1986df1cd6b9b25e0

- C comment: fix typo Author: Amit Langote
http://git.postgresql.org/pg/commitdiff/6eb5b05d225006adaf38adc9f30637ee22521881

- docs: mention rsync of temp and unlogged tables. This happens when
using rsync to pg_upgrade slaves. Reported-by: Jerry Sievers
Discussion: 20160726161946(dot)GA3511(at)momjian(dot)us
http://git.postgresql.org/pg/commitdiff/4eb4b3f24561cb115b24984c755b2a75155afedf

- docs: re-add spaces before units removed. This reverts the spaces
before k/M/G/TB units removed for consistency in commit
ca0c37b56f4a80ad758774e34c86cc4335583d29. Discussion:
20160802165116(dot)GC32575(at)momjian(dot)us
http://git.postgresql.org/pg/commitdiff/5ebad9a580d8f80943fd7095db14621278cc009c

Tom Lane pushed:

- Don't CHECK_FOR_INTERRUPTS between WaitLatch and ResetLatch. This
coding pattern creates a race condition, because if an interesting
interrupt happens after we've checked InterruptPending but before we
reset our latch, the latch-setting done by the signal handler would
get lost, and then we might block at WaitLatch in the next iteration
without ever noticing the interrupt condition. You can put the
CHECK_FOR_INTERRUPTS before WaitLatch or after ResetLatch, but not
between them. Aside from fixing the bugs, add some explanatory
comments to latch.h to perhaps forestall the next person from making
the same mistake. In HEAD, also replace gather_readnext's direct
call of HandleParallelMessages with CHECK_FOR_INTERRUPTS. It does
not seem clean or useful for this one caller to bypass
ProcessInterrupts and go straight to HandleParallelMessages; not
least because that fails to consider the InterruptPending flag,
resulting in useless work both here (if InterruptPending isn't set)
and in the next CHECK_FOR_INTERRUPTS call (if it is). This thinko
seems to have been introduced in the initial coding of
storage/ipc/shm_mq.c (commit ec9037df2), and then blindly copied
into all the subsequent parallel-query support logic. Back-patch
relevant hunks to 9.4 to extirpate the error everywhere.
Discussion: <1661(dot)1469996911(at)sss(dot)pgh(dot)pa(dot)us>
http://git.postgresql.org/pg/commitdiff/887feefe87b9099eeeec2967ec31ce20df4dfa9b

- Minor cleanup for access/transam/parallel.c. ParallelMessagePending
*must* be marked volatile, because it's set by a signal handler. On
the other hand, it's pointless for HandleParallelMessageInterrupt to
save/restore errno; that must be, and is, done at the outer level of
the SIGUSR1 signal handler. Calling CHECK_FOR_INTERRUPTS() inside
HandleParallelMessages, which itself is called from
CHECK_FOR_INTERRUPTS(), seems both useless and hazardous. The
comment claiming that this is needed to handle the error queue going
away is certainly misguided, in any case. Improve a couple of error
message texts, and use ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE to
report loss of parallel worker connection, since that's what's used
in e.g. tqueue.c. (Maybe it would be worth inventing a dedicated
ERRCODE for this type of failure? But I do not think
ERRCODE_INTERNAL_ERROR is appropriate.) Minor stylistic cleanups.
http://git.postgresql.org/pg/commitdiff/a5fe473ad79d8d2c85a625621c165e8c601274e4

- Fix pg_dump's handling of public schema with both -c and -C options.
Since -c plus -C requests dropping and recreating the target
database as a whole, not dropping individual objects in it, we
should assume that the public schema already exists and need not be
created. The previous coding considered only the state of the -c
option, so it would emit "CREATE SCHEMA public" anyway, leading to
an unexpected error in restore. Back-patch to 9.2. Older versions
did not accept -c with -C so the issue doesn't arise there. (The
logic being patched here dates to 8.0, cf commit 2193121fa, so it's
not really wrong that it didn't consider the case at the time.) Note
that versions before 9.6 will still attempt to emit REVOKE/GRANT on
the public schema; but that happens without -c/-C too, and doesn't
seem to be the focus of this complaint. I considered extending this
stanza to also skip the public schema's ACL, but that would be a
misfeature, as it'd break cases where users intentionally changed
that ACL. The real fix for this aspect is Stephen Frost's work to
not dump built-in ACLs, and that's not going to get back-ported.
Per bugs #13804 and #14271. Solution found by David Johnston and
later rediscovered by me. Report:
<20151207163520(dot)2628(dot)95990(at)wrigleys(dot)postgresql(dot)org> Report:
<20160801021955(dot)1430(dot)47434(at)wrigleys(dot)postgresql(dot)org>
http://git.postgresql.org/pg/commitdiff/e2e95f5ef3c17197e319e4bbee70486f6a33e7d1

- Block interrupts during HandleParallelMessages(). As noted by
Alvaro, there are CHECK_FOR_INTERRUPTS() calls in the shm_mq.c
functions called by HandleParallelMessages(). I believe they're all
unreachable since we always pass nowait = true, but it doesn't seem
like a great idea to assume that no such call will ever be reachable
from HandleParallelMessages(). If that did happen, there would be a
risk of a recursive call to HandleParallelMessages(), which it does
not appear to be designed for --- for example, there's nothing that
would prevent out-of-order processing of received messages. And
certainly such cases cannot easily be tested. So let's prevent it
by holding off interrupts for the duration of the function.
Back-patch to 9.5 which contains identical code. Discussion:
<14869(dot)1470083848(at)sss(dot)pgh(dot)pa(dot)us>
http://git.postgresql.org/pg/commitdiff/b6a97b91ffe8e0c6b6557eb4aef85bcbd423ad5f

- Remove duplicate InitPostmasterChild() call while starting a
bgworker. This is apparently harmless on Windows, but on Unix it
results in an assertion failure. We'd not noticed because this code
doesn't get used on Unix unless you build with -DEXEC_BACKEND. Bug
was evidently introduced by sloppy refactoring in commit 31c453165.
Thomas Munro Discussion:
<CAEepm=1VOnbVx4wsgQFvj94hu9jVt2nVabCr7QiooUSvPJXkgQ(at)mail(dot)gmail(dot)com>
http://git.postgresql.org/pg/commitdiff/c6ea616ff702862fc6923323a49dd24a0e0ae2d9

- Do not let PostmasterContext survive into background workers. We
don't want postmaster child processes to contain a copy of the
postmaster's PostmasterContext. That would be a waste of memory at
least, and at worst a security issue, since there are copies of the
semi-sensitive pg_hba and pg_ident data in there. All other child
process types delete the PostmasterContext after forking, but the
original coding of the background worker patch (commit da07a1e85)
did not do so. It appears that the only reason for that was to
avoid copying the bgworker's MyBgworkerEntry out of that context;
but the couple of additional statements needed to do so are hardly
good justification for it. Hence, copy that data and then clear the
context as other child processes do. Because this patch changes the
memory context in which a bgworker function gains control,
back-patching it would be a bit risky, so we won't fix this in back
branches. The "security" complaint is pretty thin anyway for
generic bgworkers; only with the introduction of parallel query is
there any question of running untrusted code in a bgworker process.
Discussion: <14111(dot)1470082717(at)sss(dot)pgh(dot)pa(dot)us>
http://git.postgresql.org/pg/commitdiff/ef1b5af82339a49564037be656a3ff657fb2a246

- Make INSERT-from-multiple-VALUES-rows handle targetlist indirection
better. Previously, if an INSERT with multiple rows of VALUES had
indirection (array subscripting or field selection) in its
target-columns list, the parser handled that by applying
transformAssignedExpr() to each element of each VALUES row
independently. This led to having ArrayRef assignment nodes or
FieldStore nodes in each row of the VALUES RTE. That works for
simple cases, but in bug #14265 Nuri Boardman points out that it
fails if there are multiple assignments to elements/fields of the
same target column. For such cases to work, rewriteTargetListIU()
has to nest the ArrayRefs or FieldStores together to produce a
single expression to be assigned to the column. But it failed to
find them in the top-level targetlist and issued an error about
"multiple assignments to same column". We could possibly fix this
by teaching the rewriter to apply rewriteTargetListIU to each VALUES
row separately, but that would be messy (it would change the output
rowtype of the VALUES RTE, for example) and inefficient. Instead,
let's fix the parser so that the VALUES RTE outputs are just the
user-specified values, cast to the right type if necessary, and then
the ArrayRefs or FieldStores are applied in the top-level targetlist
to Vars representing the RTE's outputs. This is the same parsetree
representation already used for similar cases with INSERT/SELECT
syntax, so it allows simplifications in ruleutils.c, which no longer
needs to treat INSERT-from-multiple-VALUES as its own special case.
This implementation works by applying transformAssignedExpr to the
VALUES entries as before, and then stripping off any ArrayRefs or
FieldStores it adds. With lots of VALUES rows it would be
noticeably more efficient to not add those nodes in the first place.
But that's just an optimization not a bug fix, and there doesn't
seem to be any good way to do it without significant refactoring.
(A non-invasive answer would be to apply transformAssignedExpr +
stripping to just the first VALUES row, and then just forcibly cast
remaining rows to the same data types exposed in the first row. But
this way would lead to different, not-INSERT-specific errors being
reported in casting failure cases, so it doesn't seem very nice.)
So leave that for later; this patch at least isn't making the
per-row parsing work worse, and it does make the finished parsetree
smaller, saving rewriter and planner work. Catversion bump because
stored rules containing such INSERTs would need to change. Because
of that, no back-patch, even though this is a very long-standing
bug. Report: <20160727005725(dot)7438(dot)26021(at)wrigleys(dot)postgresql(dot)org>
Discussion: <9578(dot)1469645245(at)sss(dot)pgh(dot)pa(dot)us>
http://git.postgresql.org/pg/commitdiff/a3c7a993d5eb29df4d33075b83c75ae25f257897

- Fix bogus coding in WaitForBackgroundWorkerShutdown(). Some
conditions resulted in "return" directly out of a PG_TRY block,
which left the exception stack dangling, and to add insult to injury
failed to restore the state of set_latch_on_sigusr1. This is a bug
only in 9.5; in HEAD it was accidentally fixed by commit db0f6cad4,
which removed the surrounding PG_TRY block. However, I (tgl) chose
to apply the patch to HEAD as well, because the old coding was
gratuitously different from WaitForBackgroundWorkerStartup(), and
there would indeed have been no bug if it were done like that to
start with. Dmitry Ivanov Discussion: <1637882(dot)WfYN5gPf1A(at)abook>
http://git.postgresql.org/pg/commitdiff/8d498a5c8a4c702ca71463a5c76bb4f319872378

- Update time zone data files to tzdata release 2016f. DST law
changes in Kemerovo and Novosibirsk. Historical corrections for
Azerbaijan, Belarus, and Morocco. Asia/Novokuznetsk and
Asia/Novosibirsk now use numeric time zone abbreviations instead of
invented ones. Zones for Antarctic bases and other locations that
have been uninhabited for portions of the time span known to the
tzdata database now report "-00" rather than "zzz" as the zone
abbreviation for those time spans. Also, I decided to remove some
of the timezone/data/ files that we don't use. At one time that
subdirectory was a complete copy of what IANA distributes in the
tzdata tarballs, but that hasn't been true for a long time. There
seems no good reason to keep shipping those specific files but not
others; they're just bloating our tarballs.
http://git.postgresql.org/pg/commitdiff/a629330b2990c2e76cc8e45a78ede0920c16e0bf

- Re-pgindent tsvector_op.c. Messed up by recent commits --- this is
annoying me while trying to fix some bugs here.
http://git.postgresql.org/pg/commitdiff/33fe7360afdc0bb1820743ea5bfe3fc7d522f6c4

- Fix ts_delete(tsvector, text[]) to cope with duplicate array
entries. Such cases either failed an Assert, or produced a corrupt
tsvector in non-Assert builds, as reported by Andreas Seltenreich.
The reason is that tsvector_delete_by_indices() just assumed that
its input array had no duplicates. Fix by explicitly de-duping. In
passing, improve some comments, and fix a number of tests for null
values to use ERRCODE_NULL_VALUE_NOT_ALLOWED not
ERRCODE_INVALID_PARAMETER_VALUE. Discussion:
<87invhoj6e(dot)fsf(at)credativ(dot)de>
http://git.postgresql.org/pg/commitdiff/c50d192ce33c10fa06411306f8644b4f47ce9a06

- Make array_to_tsvector() sort and de-duplicate the given strings.
This is required for the result to be a legal tsvector value. Noted
while fooling with Andreas Seltenreich's ts_delete() crash.
Discussion: <87invhoj6e(dot)fsf(at)credativ(dot)de>
http://git.postgresql.org/pg/commitdiff/f10eab73df2b94c860dea4a906c54e3c903f42e2

- Fix copy-and-pasteo in 81c766b3fd41c78c634d78ebae8d316808dfc630.
Report: <57A4E6DF(dot)8070209(at)dunslane(dot)net>
http://git.postgresql.org/pg/commitdiff/fc509cd82443a4cf338032492f6b1bd6e8698f8d

- Teach libpq to decode server version correctly from future servers.
Beginning with the next development cycle, PG servers will report
two-part not three-part version numbers. Fix libpq so that it will
compute the correct numeric representation of such server versions
for reporting by PQserverVersion(). It's desirable to get this into
the field and back-patched ASAP, so that older clients are more
likely to understand the new server version numbering by the time
any such servers are in the wild. (The results with an old client
would probably not be catastrophic anyway for a released server; for
example "10.1" would be interpreted as 100100 which would be wrong
in detail but would not likely cause an old client to misbehave
badly. But "10devel" or "10beta1" would result in sversion==0 which
at best would result in disabling all use of modern features.)
Extracted from a patch by Peter Eisentraut; comments added by me
Patch: <802ec140-635d-ad86-5fdf-d3af0e260c22(at)2ndquadrant(dot)com>
http://git.postgresql.org/pg/commitdiff/69dc5ae408f68c302029a6b43912a2cc16b1256c

- In B-tree page deletion, clean up properly after page deletion
failure. In _bt_unlink_halfdead_page(), we might fail to find an
immediate left sibling of the target page, perhaps because of
corruption of the page sibling links. The code intends to cope with
this by just abandoning the deletion attempt; but what actually
happens is that it fails outright due to releasing the same buffer
lock twice. (And error recovery masks a second problem, which is
possible leakage of a pin on another page.) Seems to have been
introduced by careless refactoring in commit efada2b8e. Since there
are multiple cases to consider, let's make releasing the buffer lock
in the failure case the responsibility of _bt_unlink_halfdead_page()
not its caller. Also, avoid fetching the leaf page's left-link
again after we've dropped lock on the page. This is probably
harmless, but it's not exactly good coding practice. Per report
from Kyotaro Horiguchi. Back-patch to 9.4 where the faulty code was
introduced. Discussion:
<20160803(dot)173116(dot)111915228(dot)horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>
http://git.postgresql.org/pg/commitdiff/e89526d4f3567c58c2a69fa1b1d9e44df89349fb

- First-draft release notes for 9.5.4. As usual, the release notes
for other branches will be made by cutting these down, but put them
up for community review first.
http://git.postgresql.org/pg/commitdiff/3676631c687009c2fadcb35e7d312e9eb8a98182

- Don't propagate a null subtransaction snapshot up to parent
transaction. This oversight could cause logical decoding to fail to
decode an outer transaction containing changes, if a subtransaction
had an XID but no actual changes. Per bug #14279 from Marko
Tiikkaja. Patch by Marko based on analysis by Andrew Gierth.
Discussion: <20160804191757(dot)1430(dot)39011(at)wrigleys(dot)postgresql(dot)org>
http://git.postgresql.org/pg/commitdiff/bcbecbce2fde3c6dfa9080db11663877808a007d

- Avoid crashing in GetOldestSnapshot() if there are no known
snapshots. The sole caller expects NULL to be returned in such a
case, so make it so and document it. Per reports from Andreas
Seltenreich and Regina Obe. This doesn't really fix their problem,
as now their RETURNING queries will say "ERROR: no known snapshots",
but in any case this function should not dump core in a
reasonably-foreseeable situation. Report:
<87vazemeda(dot)fsf(at)credativ(dot)de> Report:
<20160807051854(dot)1427(dot)32414(at)wrigleys(dot)postgresql(dot)org>
http://git.postgresql.org/pg/commitdiff/07a601eedab7c5fa4d62055fa3efacef2f38e446

Peter Eisentraut pushed:

- Consistently capitalize names of recovery tests
http://git.postgresql.org/pg/commitdiff/f6ced51f9188ad5806219471a0b40a91dde923aa

- doc: Whitespace fixes in man pages
http://git.postgresql.org/pg/commitdiff/e9888c2a48d490ae75d8692db1b1f12c3740c21b

- Change minimum max_worker_processes from 1 to 0. Setting it to 0 is
probably not useful in practice, but it allows testing of situations
without available background worker slots.
http://git.postgresql.org/pg/commitdiff/c4d3a039f0ea735c4c21831a74b753678c0e6794

- doc: Remove slightly confusing xreflabels. It seems clearer to
refer to these tables in the normal way.
http://git.postgresql.org/pg/commitdiff/0a4d67b16cd6a0d435169e66a1b4911007cb6aef

- Small wording tweaks. Dmitry Igrishin
http://git.postgresql.org/pg/commitdiff/071049919566c22a276ae6441097c436e382a679

- doc: Change recommendation to put NOTIFY into a rule. Suggest a
statement trigger instead.
http://git.postgresql.org/pg/commitdiff/69bdfc4090816d77a3d08684a30bfb05f8b1e104

- doc: Remove documentation of nonexistent information schema columns.
These were probably copied in by accident. From: Clément Prévost
<prevostclement(at)gmail(dot)com>
http://git.postgresql.org/pg/commitdiff/2b8fd4fa67693b0b07c412eed34c6b6da6c74d43

- Add missing casts in information schema. From: Clément Prévost
<prevostclement(at)gmail(dot)com>
http://git.postgresql.org/pg/commitdiff/6a9e09c49e1405c47b0870de73fec5748302f92d

- doc: Move indexterms to avoid whitespace issue in man pages
http://git.postgresql.org/pg/commitdiff/81568a971f2634bc447af2788eafee899f2db2a1

Kevin Grittner pushed:

- Add OldSnapshotTimeMapLock to wait_event table in docs. Ashutosh
Sharma with minor fixes by me.
http://git.postgresql.org/pg/commitdiff/c93d8737be47667091b36f5852fd706146514008

Álvaro Herrera pushed:

- Fix assorted problems in recovery tests. In test 001_stream_rep
we're using pg_stat_replication.write_location to determine catch-up
status, but we care about xlog having been applied not just
received, so change that to apply_location. In test
003_recovery_targets, we query the database for a recovery target
specification and later for the xlog position supposedly
corresponding to that recovery specification. If for whatever
reason more WAL is written between the two queries, the recovery
specification is earlier than the xlog position used by the query in
the test harness, so we wait forever, leading to test failures.
Deal with this by using a single query to extract both items. In
2a0f89cd717 we tried to deal with it by giving them more tests to
run, but in hindsight that was obviously doomed to failure (no
revert of that, though). Per hamster buildfarm failures. Author:
Michaël Paquier
http://git.postgresql.org/pg/commitdiff/b26f7fa6ae2b4e5d64525b3d5bc66a0ddccd9e24

Robert Haas pushed:

- Prevent "snapshot too old" from trying to return pruned TOAST
tuples. Previously, we tested for MVCC snapshots to see whether
they were too old, but not TOAST snapshots, which can lead to
complaints about missing TOAST chunks if those chunks are subject to
early pruning. Ideally, the threshold lsn and timestamp for a TOAST
snapshot would be that of the corresponding MVCC snapshot, but since
we have no way of deciding which MVCC snapshot was used to fetch the
TOAST pointer, use the oldest active or registered snapshot instead.
Reported by Andres Freund, who also sketched out what the fix should
look like. Patch by me, reviewed by Amit Kapila.
http://git.postgresql.org/pg/commitdiff/3e2f3c2e423b3ae906668c186bac79522b8e3e29

- Change InitToastSnapshot to a macro. tqual.h is included in some
front-end compiles, and a static inline breaks on buildfarm member
castoroides. Since the macro is never referenced, it should dodge
that problem, although this doesn't seem like the cleanest way of
hiding things from front-end compiles. Report and review by Tom
Lane; patch by me.
http://git.postgresql.org/pg/commitdiff/81c766b3fd41c78c634d78ebae8d316808dfc630

Andres Freund pushed:

- Fix hard to hit race condition in heapam's tuple locking code. As
mentioned in its commit message, eca0f1db left open a race
condition, where a page could be marked all-visible, after the code
checked PageIsAllVisible() to pin the VM, but before the page is
locked. Plug that hole. Reviewed-By: Robert Haas, Andres Freund
Author: Amit Kapila Discussion:
CAEepm=3fWAbWryVW9swHyLTY4sXVf0xbLvXqOwUoDiNCx9mBjQ(at)mail(dot)gmail(dot)com
Backpatch: -
http://git.postgresql.org/pg/commitdiff/e7caacf733f3ee77a555aa715ab6fbf4434e6b52

== Pending Patches ==

Etsuro Fujita sent in a patch to clarify the documentation around
PlanForeignModify.

Karan Sikka sent in a patch to implement Boyer-Moore searching in LIKE
queries.

Vladimir Sitnikov sent in a WIP patch to try CreateOneShotCachedPlan
for unnamed statements in exec_parse_message.

Peter Geoghegan sent in a patch to implement parallel tuplesort.

Bruce Momjian sent in a patch to change usages of prefixes (k- to K,
for example).

Tomas Vondra sent in a patch to add two slab-like memory allocators.

Masahiko Sawada sent in a patch to add a quorum commit for multiple
synchronous replication.

Etsuro Fujita sent in two revisions of a patch to fix an oddity in
EXPLAIN for foreign/custom join pushdown plans.

Tomas Vondra sent in another revision of a patch to add multivariate
statistics.

Alexey Grishchenko sent in a patch to add upport for multi-dimensional
arrays to PL/PythonU.

Andres Freund sent in a PoC patch to fix some messed-up-ness in SRF
handling in target lists.

Masahiko Sawada sent in a patch to ensure that lazy_scan_heap accesses
the visibility map only once.

Peter Eisentraut sent in a WIP patch to stamp version 10 for
development.

Peter Eisentraut sent in another revision of a patch to add a -w
(wait) pg_ctl promote option.

Ildar Musin sent in a patch to remove a now-unused argument in the
PinBuffer function.

Mithun Cy sent in a patch to add coverage tests for hash indexes.

Michaël Paquier sent in two revisions of a patch to fix a crash in
pg_basebackup uncovered by Andreas Seltenreich's sqlsmith.

Peter Eisentraut sent in a patch to improve DefElem list processing.

Aleksander Alekseev sent in another revision of a patch add a "fast"
variant of temp tables which don't bloat the catalog.

Tom Lane sent in two revisions of a patch to fix an issue that
resulted in bogus ANALYZE results for an otherwise-unique column with
many nulls.

Amit Kapila sent in another revision of a patch to implement
WAL-logged hash indexes.

Jeff Janes sent in a patch to add a new GUC, notice_lock_waits, which
acts like log_lock_waits but sends the message as NOTICE so it will
show up on interactive connections like psql.

Petr Jelinek sent in WIP a patch to add logical replication, and there
was much rejoicing.

Peter Eisentraut sent in a patch to fix an overflow in the MONEY type.

Anastasia Lubennikova sent in a patch to refactor the heapam code.

Thomas Munro sent in a patch to consolidate the 'unique array values'
logic into a reusable function.

Pavel Stehule sent in a PoC patch to add an xmltable function.

Andreas Seltenreich sent in a patch to fix a crash in
pg_get_viewdef_name_ext().