== PostgreSQL Weekly News - August 14 2016 ==

== PostgreSQL Weekly News - August 14 2016 ==

Security releases 9.5.4, 9.4.9, 9.3.14, 9.2.18, and 9.1.23 are out.
Upgrade ASAP.
https://www.postgresql.org/about/news/1688/

PostgreSQL 9.6 Beta 4 released. Test!
https://www.postgresql.org/docs/devel/static/release-9-6.html

== PostgreSQL Product News ==

BDR 1.0, a replicated database system based on PostgreSQL using
logical WALs, released.
http://bdr-project.org/docs/stable/release-1.0.0.html

pgBadger v8.2, a PostgreSQL log analyzer and graph tool written in
Perl, released.
https://github.com/dalibo/pgbadger/releases/

== 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.
https://2016.postgresopen.org/

PostgreSQL Session will be held on September 22th, 2016, in Lyon,
France.
http://blog.dalibo.com/2016/05/13/CFP-pgsession-lyon.html

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 ==
Tom Lane pushed:

- Fix TOAST access failure in RETURNING queries. Discussion of commit
3e2f3c2e4 exposed a problem that is of longer standing: since we
don't detoast data while sticking it into a portal's holdStore for
PORTAL_ONE_RETURNING and PORTAL_UTIL_SELECT queries, and we release
the query's snapshot as soon as we're done loading the holdStore,
later readout of the holdStore can do TOAST fetches against data
that can no longer be seen by any of the session's live snapshots.
This means that a concurrent VACUUM could remove the TOAST data
before we can fetch it. Commit 3e2f3c2e4 exposed the problem by
showing that sometimes we had *no* live snapshots while fetching
TOAST data, but we'd be at risk anyway. I believe this code was all
right when written, because our management of a session's exposed
xmin was such that the TOAST references were safe until end of
transaction. But that's no longer true now that we can advance or
clear our PGXACT.xmin intra-transaction. To fix, copy the query's
snapshot during FillPortalStore() and save it in the Portal; release
it only when the portal is dropped. This essentially implements a
policy that we must hold a relevant snapshot whenever we access
potentially-toasted data. We had already come to that conclusion in
other places, cf commits 08e261cbc94ce9a7 and ec543db77b6b72f2. I'd
have liked to add a regression test case for this, but I didn't see
a way to make one that's not unreasonably bloated; it seems to
require returning a toasted value to the client, and those will be
big. In passing, improve PortalRunUtility() so that it positively
verifies that its ending PopActiveSnapshot() call will pop the
expected snapshot, removing a rather shaky assumption about which
utility commands might do their own PopActiveSnapshot(). There's no
known bug here, but now that we're actively referencing the snapshot
it's almost free to make this code a bit more bulletproof. We might
want to consider back-patching something like this into older
branches, but it would be prudent to let it prove itself more in
HEAD beforehand. Discussion: <87vazemeda(dot)fsf(at)credativ(dot)de>
http://git.postgresql.org/pg/commitdiff/9ee1cf04ab6bcefe03a11837b53f29ca9dc24c7a

- Fix crash when pg_get_viewdef_name_ext() is passed a non-view
relation. Oversight in commit 976b24fb4. Andreas Seltenreich
Report: <87y448l3ag(dot)fsf(at)credativ(dot)de>
http://git.postgresql.org/pg/commitdiff/8a8c6b53810026641a1e12f60f873a7bd3cea5e3

- Fix misestimation of n_distinct for a nearly-unique column with many
nulls. If ANALYZE found no repeated non-null entries in its sample,
it set the column's stadistinct value to -1.0, intending to indicate
that the entries are all distinct. But what this value actually
means is that the number of distinct values is 100% of the table's
rowcount, and thus it was overestimating the number of distinct
values by however many nulls there are. This could lead to very
poor selectivity estimates, as for example in a recent report from
Andreas Joseph Krogh. We should discount the stadistinct value by
whatever we've estimated the nulls fraction to be. (That is what
will happen if we choose to use a negative stadistinct for a column
that does have repeated entries, so this code path was just
inconsistent.) In addition to fixing the stadistinct entries stored
by several different ANALYZE code paths, adjust the logic where
get_variable_numdistinct() forces an "all distinct" estimate on the
basis of finding a relevant unique index. Unique indexes don't
reject nulls, so there's no reason to assume that the null fraction
doesn't apply. Back-patch to all supported branches. Back-patching
is a bit of a judgment call, but this problem seems to affect only a
few users (else we'd have identified it long ago), and it's bad
enough when it does happen that destabilizing plan choices in a
worse direction seems unlikely. Patch by me, with documentation
wording suggested by Dean Rasheed Report:
<VisenaEmail(dot)26(dot)df42f82acae38a58(dot)156463942b8(at)tc7-visena> Discussion:
<16143(dot)1470350371(at)sss(dot)pgh(dot)pa(dot)us>
http://git.postgresql.org/pg/commitdiff/95bee941be4c009ebbc29162a0dc9664f40de12f

- Release notes for 9.5.4, 9.4.9, 9.3.14, 9.2.18, 9.1.23.
http://git.postgresql.org/pg/commitdiff/19322c0a785f656b82a780c3db44920dcc9bd658

- Update 9.6 release notes through today.
http://git.postgresql.org/pg/commitdiff/be7f7ee5ea73626c037600b515087e8f98038140

- Update 9.6 release notes through today.
http://git.postgresql.org/pg/commitdiff/de4b3ea16d8b053e95eb9d862075b0de123e45b9

- Stamp 9.6beta4.
http://git.postgresql.org/pg/commitdiff/67c08c0d704a5f828492642bf9d133cbb2af3661

- Doc: clarify description of CREATE/ALTER FUNCTION ... SET FROM
CURRENT. Per discussion with David Johnston.
http://git.postgresql.org/pg/commitdiff/e775d35317590793863327fedcf3737c3ab838d4

- Doc: write some for adminpack. Previous contents of adminpack.sgml
were rather far short of project norms. Not to mention being
outright wrong about the signature of pg_file_read().
http://git.postgresql.org/pg/commitdiff/ff2fd6b06ac00a3c5d451063e0a87dca6156db4e

- Fix busted Assert for CREATE MATVIEW ... WITH NO DATA. Commit
874fe3aea changed the command tag returned for CREATE MATVIEW/CREATE
TABLE AS ... WITH NO DATA, but missed that there was code in spi.c
that expected the command tag to always be "SELECT". Fortunately,
the consequence was only an Assert failure, so this oversight should
have no impact in production builds. Since this code path was
evidently un-exercised, add a regression test. Per report from
Shivam Saxena. Back-patch to 9.3, like the previous commit. Michael
Paquier Report:
<97218716-480B-4527-B5CD-D08D798A0C7B(at)dresources(dot)com>
http://git.postgresql.org/pg/commitdiff/0f249fe5f5cb3c83fd8e05743740b35ff5d34196

- Trivial cosmetic cleanup in bloom/blutils.c. Don't spell
"InvalidOid" as "0". Initialize method fields in the same order as
amapi.h declares them (and every other AM handler initializes them).
http://git.postgresql.org/pg/commitdiff/e3049285a3b8790e26e584fdf1ca31ea2e2eb4bc

- Last-minute updates for release notes. Security: CVE-2016-5423,
CVE-2016-5424
http://git.postgresql.org/pg/commitdiff/9b8271c5a655ef1c35141b266d5039da8d3b2337

- Fix two errors with nested CASE/WHEN constructs. ExecEvalCase()
tried to save a cycle or two by passing &econtext->caseValue_isNull
as the isNull argument to its sub-evaluation of the CASE value
expression. If that subexpression itself contained a CASE, then
*isNull was an alias for econtext->caseValue_isNull within the
recursive call of ExecEvalCase(), leading to confusion about whether
the inner call's caseValue was null or not. In the worst case this
could lead to a core dump due to dereferencing a null pointer. Fix
by not assigning to the global variable until control comes back
from the subexpression. Also, avoid using the passed-in isNull
pointer transiently for evaluation of WHEN expressions. (Either one
of these changes would have been sufficient to fix the known
misbehavior, but it's clear now that each of these choices was in
itself dangerous coding practice and best avoided. There do not
seem to be any similar hazards elsewhere in execQual.c.) Also, it
was possible for inlining of a SQL function that implements the
equality operator used for a CASE comparison to result in one CASE
expression's CaseTestExpr node being inserted inside another CASE
expression. This would certainly result in wrong answers since the
improperly nested CaseTestExpr would be caused to return the inner
CASE's comparison value not the outer's. If the CASE values were of
different data types, a crash might result; moreover such situations
could be abused to allow disclosure of portions of server memory.
To fix, teach inline_function to check for "bare" CaseTestExpr nodes
in the arguments of a function to be inlined, and avoid inlining if
there are any. Heikki Linnakangas, Michael Paquier, Tom Lane
Report: https://github.com/greenplum-db/gpdb/pull/327 Report:
<4DDCEEB8(dot)50602(at)enterprisedb(dot)com> Security: CVE-2016-5423
http://git.postgresql.org/pg/commitdiff/f0c7b789ab12fbc8248b671c7882dd96ac932ef4

- Fix inappropriate printing of never-measured times in EXPLAIN.
EXPLAIN (ANALYZE, TIMING OFF) would print an elapsed time of zero
for a trigger function, because no measurement has been taken but it
printed the field anyway. This isn't what EXPLAIN does elsewhere,
so suppress it. In the same vein, EXPLAIN (ANALYZE, BUFFERS) with
non-text output format would print buffer I/O timing numbers even
when no measurement has been taken because track_io_timing is off.
That seems not per policy, either, so change it. Back-patch to 9.2
where these features were introduced. Maksim Milyutin Discussion:
<081c0540-ecaa-bd29-3fd2-6358f3b359a9(at)postgrespro(dot)ru>
http://git.postgresql.org/pg/commitdiff/4b234fd8bf21cd6f5ff44f1f1c613bf40860998d

- Doc: clarify that DROP ... CASCADE is recursive. Apparently that's
not obvious to everybody, so let's belabor the point. In passing,
document that DROP POLICY has CASCADE/RESTRICT options (which it
does, per gram.y) but they do nothing (I assume, anyway). Also
update some long-obsolete commentary in gram.y. Discussion:
<20160805104837(dot)1412(dot)84915(at)wrigleys(dot)postgresql(dot)org>
http://git.postgresql.org/pg/commitdiff/499787819309293f3d2cd7219aee334a0e7d5069

- Add SQL-accessible functions for inspecting index AM properties.
Per discussion, we should provide such functions to replace the lost
ability to discover AM properties by inspecting pg_am (cf commit
65c5fcd35). The added functionality is also meant to displace any
code that was looking directly at pg_index.indoption, since we'd
rather not believe that the bit meanings in that field are part of
any client API contract. As future-proofing, define the SQL API to
not assume that properties that are currently AM-wide or index-wide
will remain so unless they logically must be; instead, expose them
only when inquiring about a specific index or even specific index
column. Also provide the ability for an index AM to override the
behavior. In passing, document pg_am.amtype, overlooked in commit
473b93287. Andrew Gierth, with kibitzing by me and others
Discussion: <87mvl5on7n(dot)fsf(at)news-spur(dot)riddles(dot)org(dot)uk>
http://git.postgresql.org/pg/commitdiff/ed0097e4f9e6b1227935e01fa67f12a238b66064

- Fix assorted bugs in contrib/bloom. In blinsert(), cope with the
possibility that a page we pull from the notFullPage list is marked
BLOOM_DELETED. This could happen if VACUUM recently marked it
deleted but hasn't (yet) updated the metapage. We can re-use such a
page safely, but we *must* reinitialize it so that it's no longer
marked deleted. Fix blvacuum() so that it updates the notFullPage
list even if it's going to update it to empty. The previous
"optimization" of skipping the update seems pretty dubious, since it
means that the next blinsert() will uselessly visit whatever pages
we left in the list. Uniformly treat PageIsNew pages the same as
deleted pages. This should allow proper recovery if a crash occurs
just after relation extension. Properly use vacuum_delay_point, not
assorted ad-hoc CHECK_FOR_INTERRUPTS calls, in the blvacuum() main
loop. Fix broken tuple-counting logic: blvacuum.c counted the
number of live index tuples over again in each scan, leading to
VACUUM VERBOSE reporting some multiple of the actual number of
surviving index tuples after any vacuum that removed any tuples
(since they'd be counted in blvacuum, maybe more than once, and then
again in blvacuumcleanup, without ever zeroing the counter). It's
sufficient to count them in blvacuumcleanup. stats->estimated_count
is a boolean, not a counter, and we don't want to set it true, so
don't add tuple counts to it. Add a couple of Asserts that we don't
overrun available space on a bloom page. I don't think there's any
bug there today, but the way the FreeBlockNumberArray size
calculation is set up is scarily fragile, and BloomPageGetFreeSpace
isn't much better. The Asserts should help catch any future
mistakes. Per investigation of a report from Jeff Janes. I think
the first item above may explain his report; the other changes were
things I noticed while casting about for an explanation. Report:
<CAMkU=1xEUuBphDwDmB1WjN4+td4kpnEniFaTBxnk1xzHCw8_OQ(at)mail(dot)gmail(dot)com>
http://git.postgresql.org/pg/commitdiff/d6c9e05cb7db64239887fac65b243229594f331d

- Remove bogus dependencies on NUMERIC_MAX_PRECISION.
NUMERIC_MAX_PRECISION is a purely arbitrary constraint on the
precision and scale you can write in a numeric typmod. It might
once have had something to do with the allowed range of a
typmod-less numeric value, but at least since 9.1 we've allowed, and
documented that we allowed, any value that would physically fit in
the numeric storage format; which is something over 100000 decimal
digits, not 1000. Hence, get rid of numeric_in()'s use of
NUMERIC_MAX_PRECISION as a limit on the allowed range of the
exponent in scientific-format input. That was especially silly in
view of the fact that you can enter larger numbers as long as you
don't use 'e' to do it. Just constrain the value enough to avoid
localized overflow, and let make_result be the final arbiter of what
is too large. Likewise adjust ecpg's equivalent of this code. Also
get rid of numeric_recv()'s use of NUMERIC_MAX_PRECISION to limit
the number of base-NBASE digits it would accept. That created a
dump/restore hazard for binary COPY without doing anything useful;
the wire-format limit on number of digits (65535) is about as tight
as we would want. In HEAD, also get rid of pg_size_bytes()'s
unnecessary intimacy with what the numeric range limit is. That
code doesn't exist in the back branches. Per gripe from Aravind
Kumar. Back-patch to all supported branches, since they all contain
the documentation claim about allowed range of NUMERIC (cf commit
cabf5d84b). Discussion: <2895(dot)1471195721(at)sss(dot)pgh(dot)pa(dot)us>
http://git.postgresql.org/pg/commitdiff/9389fbd0385776adf3252eb8cfe6e37a640fdff4

Peter Eisentraut pushed:

- doc: Move mention of rsync of temp tables to better place
http://git.postgresql.org/pg/commitdiff/4a1f42f287c33e457cb3f081e692853a65dc0efb

- Correct column name in information schema. Although the standard
has routines.result_cast_character_set_name, given the naming of the
surrounding columns, we concluded that this must have been a mistake
and that result_cast_char_set_name was intended, so change the
implementation. The documentation was already using the new name.
found by Clément Prévost <prevostclement(at)gmail(dot)com>
http://git.postgresql.org/pg/commitdiff/d8710f18f4a63947874301311f5558e7d3d93438

- Make format() error messages consistent again. 07d25a964 changed
only one occurrence. Change the other one as well.
http://git.postgresql.org/pg/commitdiff/8a56d4e361d4566ce5d6b55f25c3f23aa44f4741

- doc: Update benchmark results. From: Alexander Law
<exclusion(at)gmail(dot)com>
http://git.postgresql.org/pg/commitdiff/a1f8b6bd14adb724365d91dcc58079ac3a2293e7

- Translation updates. Source-Git-URL:
git://git.postgresql.org/git/pgtranslation/messages.git
Source-Git-Hash: cda21c1d7b160b303dc21dfe9d4169f2c8064c60
http://git.postgresql.org/pg/commitdiff/34927b2920a865559be743836c1aa60a3621c133

- Fix several one-byte buffer over-reads in to_number. Several places
in NUM_numpart_from_char(), which is called from the SQL function
to_number(text, text), could accidentally read one byte past the end
of the input buffer (which comes from the input text datum and is
not null-terminated). 1. One leading space character would be
skipped, but there was no check that the input was at least one byte
long. This does not happen in practice, but for defensiveness, add
a check anyway. 2. Commit 4a3a1e2cf apparently accidentally doubled
that code that skips one space character (so that two spaces might
be skipped), but there was no overflow check before skipping the
second byte. Fix by removing that duplicate code. 3. A logic error
would allow a one-byte over-read when looking for a trailing sign
(S) placeholder. In each case, the extra byte cannot be read out
directly, but looking at it might cause a crash. The third item was
discovered by Piotr Stefaniak, the first two were found and analyzed
by Tom Lane and Peter Eisentraut.
http://git.postgresql.org/pg/commitdiff/9a46324fd46506c86b190d3163902ed90072c53c

- Fix typo
http://git.postgresql.org/pg/commitdiff/ab0a23c7c9a4b6dfba7fbffe798452299a6444b9

Bruce Momjian pushed:

- doc: update list of pg_trgm authors. Author: Oleg Bartunov
http://git.postgresql.org/pg/commitdiff/cfdadf5f930c4e613e3a13ab09673856aa59351e

- docs: my first pass over the 9.6 release notes
http://git.postgresql.org/pg/commitdiff/2abf92bc698558699c199ff14261b00ee92e98dd

- docs: my second pass over the 9.6 release notes
http://git.postgresql.org/pg/commitdiff/fd5a2db774c1952567f75603dffb6d9fb0b0013d

Noah Misch pushed:

- Promote pg_dumpall shell/connstr quoting functions to src/fe_utils.
Rename these newly-extern functions with terms more typical of their
new neighbors. No functional changes; a subsequent commit will use
them in more places. Back-patch to 9.1 (all supported versions).
Back branches lack src/fe_utils, so instead rename the functions in
place; the subsequent commit will copy them into the other programs
using them. Security: CVE-2016-5424
http://git.postgresql.org/pg/commitdiff/41f18f021a0882eccbeca62e2ed4b66c6b96e9c9

- Sort out paired double quotes in \connect, \password and
\crosstabview. In arguments, these meta-commands wrongly treated
each pair as closing the double quoted string. Make the behavior
match the documentation. This is a compatibility break, but I more
expect to find software with untested reliance on the documented
behavior than software reliant on today's behavior. Back-patch to
9.1 (all supported versions). Reviewed by Tom Lane and Peter
Eisentraut. Security: CVE-2016-5424
http://git.postgresql.org/pg/commitdiff/984e5beb38a7c79a5a9243865d9598c405df17f6

- Reject, in pg_dumpall, names containing CR or LF. These characters
prematurely terminate Windows shell command processing, causing the
shell to execute a prefix of the intended command. The chief
alternative to rejecting these characters was to bypass the Windows
shell with CreateProcess(), but the ability to use such names has
little value. Back-patch to 9.1 (all supported versions). This
change formally revokes support for these characters in database
names and roles names. Don't document this; the error message is
self-explanatory, and too few users would benefit. A future major
release may forbid creation of databases and roles so named. For
now, check only at known weak points in pg_dumpall. Future commits
will, without notice, reject affected names from other frontend
programs. Also extend the restriction to pg_dumpall
--dbname=CONNSTR arguments and --file arguments. Unlike the effects
on role name arguments and database names, this does not reflect a
broad policy change. A migration to CreateProcess() could lift
these two restrictions. Reviewed by Peter Eisentraut. Security:
CVE-2016-5424
http://git.postgresql.org/pg/commitdiff/142c24c23447f212e642a0ffac9af878b93f490d

- Field conninfo strings throughout src/bin/scripts. These programs
nominally accepted conninfo strings, but they would proceed to use
the original dbname parameter as though it were an unadorned
database name. This caused "reindexdb dbname=foo" to issue an SQL
command that always failed, and other programs printed a conninfo
string in error messages that purported to print a database name.
Fix both problems by using PQdb() to retrieve actual database names.
Continue to print the full conninfo string when reporting a
connection failure. It is informative there, and if the database
name is the sole problem, the server-side error message will include
the name. Beyond those user-visible fixes, this allows a subsequent
commit to synthesize and use conninfo strings without that
implementation detail leaking into messages. As a side effect, the
"vacuuming database" message now appears after, not before, the
connection attempt. Back-patch to 9.1 (all supported versions).
Reviewed by Michael Paquier and Peter Eisentraut. Security:
CVE-2016-5424
http://git.postgresql.org/pg/commitdiff/c400717172d77e5b07e51e04c5e5e13da181572e

- Fix Windows shell argument quoting. The incorrect quoting may have
permitted arbitrary command execution. At a minimum, it gave
broader control over the command line to actors supposed to have
control over a single argument. Back-patch to 9.1 (all supported
versions). Security: CVE-2016-5424
http://git.postgresql.org/pg/commitdiff/bd65371851b7a9964b4b265d06fe1304315e37c1

- Obstruct shell, SQL, and conninfo injection via database and role
names. Due to simplistic quoting and confusion of database names
with conninfo strings, roles with the CREATEDB or CREATEROLE option
could escalate to superuser privileges when a superuser next ran
certain maintenance commands. The new coding rule for
PQconnectdbParams() calls, documented at conninfo_array_parse(), is
to pass expand_dbname=true and wrap literal database names in a
trivial connection string. Escape zero-length values in
appendConnStrVal(). Back-patch to 9.1 (all supported versions).
Nathan Bossart, Michael Paquier, and Noah Misch. Reviewed by Peter
Eisentraut. Reported by Nathan Bossart. Security: CVE-2016-5424
http://git.postgresql.org/pg/commitdiff/fcd15f13581f6d75c63d213220d5a94889206c1b

- Introduce a psql "\connect -reuse-previous=on|off" option. The
decision to reuse values of parameters from a previous connection
has been based on whether the new target is a conninfo string. Add
this means of overriding that default. This feature arose as one
component of a fix for security vulnerabilities in pg_dump,
pg_dumpall, and pg_upgrade, so back-patch to 9.1 (all supported
versions). In 9.3 and later, comment paragraphs that required
update had already-incorrect claims about behavior when no
connection is open; fix those problems. Security: CVE-2016-5424
http://git.postgresql.org/pg/commitdiff/9d924e9a64b91571e04252424c01210fc0f6f6d9

Álvaro Herrera pushed:

- Add ID property to replication slots' sect2
http://git.postgresql.org/pg/commitdiff/371b572df2d7e24750f8d0fc2e45d673ac70beec

Simon Riggs pushed:

- Correct TABLESAMPLE docs. Original wording was correct but not the
intended meaning. Reported by Patrik Wenger
http://git.postgresql.org/pg/commitdiff/6e75559ea9cb0bc8fd07543567cd02d4ec85ca20

- Code cleanup in SyncRepWaitForLSN() Commit 14e8803f1 removed LWLocks
when accessing MyProc->syncRepState but didn't clean up the
surrounding code and comments. Cleanup and backpatch to 9.5, to
keep code similar. Julien Rouhaud, improved by suggestion from
Michael Paquier, implemented trivially by myself.
http://git.postgresql.org/pg/commitdiff/e05f6f75dbe00a7349dccf1116b5ed983b4728c0

== Pending Patches ==

Thomas Munro sent in a patch to implement dsm_unpin_segment.

Peter Eisentraut sent in a patch to set log_line_prefix and
application name in test drivers for pg_regress.

David G. Johnston sent in a patch to make comprehension of the code in
"TS_phrase_execute" a bit easier.

Amit Langote sent in another revision of the patch set to implement
declarative table partitioning.

Robert Haas sent in a patch to run pgindent before the branch.

Tom Lane sent in a patch to allow GIN array_ops to work on anyarray.

Michaël Paquier sent in a patch to forbid use of LF and CR characters
in database and role names.

Robert Haas sent in a patch to introduce condition variables.
https://en.wikipedia.org/wiki/Monitor_(synchronization)#Condition_variables_2

Craig Ringer sent in a patch to give a more helpful hint as to when
psql's \copy or similar trickery might be needed, as opposed to COPY.

Martín Marqués sent in a patch to add a test which will fail if it
finds tables created by EXTENSIONs in pg_dump output.

Thomas Munro sent in a patch to create jumbo DSM segments, producing a
SIGBUS if overallocated, which is not the right error.

Rushabh Lathia sent in a patch to fix a crash caused by a run of
TPC-H.

Andreas Scherbaum sent in another revision of a patch to add
to_date_valid().

Thomas Munro sent in a patch to add "barriers" to aid parallel
computation.

Ryan Murphy sent in two revisions of a patch to make it possible for
initdb to work with paths that contain spaces.