== PostgreSQL Weekly News - March 13 2016 ==

== PostgreSQL Weekly News - March 13 2016 ==

The first meeting of PostgreSQL Israel will be taking place in Tel
Aviv on April 7, 2016.
http://www.meetup.com/PostgreSQL-Israel/events/229430729/

PG Day UK 2016 - Call for Papers is open until 5th April 2016. The
conference will be 5th July 2016. Please submit proposals to
Simon(dot)Riggs(at)2ndquadrant(dot)com <Simon AT 2ndquadrant DOT com> or via the
website at:
http://www.pgconf.uk/papers

Talks for PGCon in Ottawa have been selected.
http://www.pgcon.org/2016/ugly-list-of-great-talks.txt

== PostgreSQL Product News ==

MJSQLView Version 7.05, a Java-based UI which supports PostgreSQL, released.
http://myjsqlview.com/

== PostgreSQL Jobs for March ==

http://archives.postgresql.org/pgsql-jobs/2016-03/

== PostgreSQL Local ==

The first pan-Asian PostgreSQL conference will be held March 17-19,
2016 in Singapore. Registration is open.
http://2016.pgday.asia/

Nordic PGDay 2016 is a one day one track conference which will be held in
Helsinki, Finland, on March 17, 2016. Registration is still open.
http://2016.nordicpgday.org/

PGDay Paris 2016, on March 31 in Paris, has opened registration.
http://www.pgday.paris/registration/ (scroll down for English)

The 8th PostgreSQL Session will be held on April 6th, 2016, in Lyon,
France.
<AT> postgresql-sessions <DOT> org.

PGConf US 2016 will take place April 18-20, 2016 in NYC. Registration
is open.
http://www.pgconf.us/2016/

LinuxFest Northwest will take place April 23-24, 2016 at Bellingham
Technical College in Bellingham, Washington, USA. The CfP is now
open.
http://www.linuxfestnorthwest.org/2016/present

FOSS4G NA, will be held May 2-5, 2016 in Raleigh, North Carolina.
The CfP is still open.
https://2016.foss4g-na.org/cfp

PGCon 2016 will be held May 17-21, 2016 in Ottawa.
http://www.pgcon.org/

This year's Swiss PGDay will be held on June 24, 2016 at the
University of Applied Sciences in Rapperswil (Switzerland).
The CfP is open.
http://www.pgday.ch/

"5432 ... Meet us!", will take place in Milan, Italy on June 28-29, 2016.
The CfP is open until March 14, 2016.
http://5432meet.us/

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

== 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) Spanish language
to pwn(at)arpug(dot)com(dot)ar(dot)

== Applied Patches ==

Tom Lane pushed:

- Mop-up for setting minimum Tcl version to 8.4.

Commit e2609323e set the minimum Tcl version we support to 8.4, but
I forgot to adjust the documentation to say the same. Some nosing
around for other consequences found that the configure script could
be simplified slightly as well.

Branch
------
master

Details
-------
http://git.postgresql.org/pg/commitdiff/9da70efcbe09954b1006f878d39885a4acf1c534

- Fix unportable usage of <ctype.h> functions. isdigit(), isspace(),
etc are likely to give surprising results if passed a signed char.
We should always cast the argument to unsigned char to avoid that.
Error in commit d78a7d9c7fa3e9cd, found by buildfarm member gaur.
http://git.postgresql.org/pg/commitdiff/cb0ca0c9953aa0614e7b143bd2440a7582a27233

- Fix not-terribly-safe coding in NIImportOOAffixes() and
NIImportAffixes(). There were two places in spell.c that supposed
that they could search for a location in a string produced by
lowerstr() and then transpose the offset into the original string.
But this fails completely if lowerstr() transforms any characters
into characters of different byte length, as can happen in Turkish
UTF8 for instance. We'd added some comments about this coding in
commit 51e78ab4ff328296, but failed to realize that it was not
merely confusing but wrong. Coverity complained about this code
years ago, but in such an opaque fashion that nobody understood what
it was on about. I'm not entirely sure that this issue *is* what
it's on about, actually, but perhaps this patch will shut it up --
and in any case the problem is clear. Back-patch to all supported
branches.
http://git.postgresql.org/pg/commitdiff/b3e05097e58051a7816ed734074fd76345687e0c

- Fix broken definition for function name in pgbench's exprscan.l. As
written, this would accept e.g. 123e9 as a function name. Aside
from being mildly astonishing, that would come back to haunt us if
we ever try to add float constants to the expression syntax. Insist
that function names start with letters (or at least non-digits). In
passing reset yyline as well as yycol when starting a new
expression. This variable is useless since it's used nowhere, but
if we're going to have it we should have it act sanely.
http://git.postgresql.org/pg/commitdiff/3899caf772c8dec5c79e553c91f8fc248ca686c9

- Re-fix broken definition for function name in pgbench's exprscan.l.
Wups, my first try wasn't quite right either. Too focused on fixing
the existing bug, not enough on not introducing new ones.
http://git.postgresql.org/pg/commitdiff/94f1adccd36df3ad75d2c257c9ae1ca448f3e4ac

- Fix backwards test for Windows service-ness in pg_ctl. A thinko in
a96761391 caused pg_ctl to get it exactly backwards when deciding
whether to report problems to the Windows eventlog or to stderr.
Per bug #14001 from Manuel Mathar, who also identified the fix.
Like the previous patch, back-patch to all supported branches.
http://git.postgresql.org/pg/commitdiff/b642e50aea1b966f3b78c49e806b4a2c5497a861

- Make the upper part of the planner work by generating and comparing
Paths. I've been saying we needed to do this for more than five
years, and here it finally is. This patch removes the ever-growing
tangle of spaghetti logic that grouping_planner() used to use to try
to identify the best plan for post-scan/join query steps. Now,
there is (nearly) independent consideration of each execution step,
and entirely separate construction of Paths to represent each of the
possible ways to do that step. We choose the best Path or set of
Paths using the same add_path() logic that's been used inside
query_planner() for years. In addition, this patch removes the old
restriction that subquery_planner() could return only a single Plan.
It now returns a RelOptInfo containing a set of Paths, just as
query_planner() does, and the parent query level can use each of
those Paths as the basis of a SubqueryScanPath at its level. This
allows finding some optimizations that we missed before, wherein a
subquery was capable of returning presorted data and thereby
avoiding a sort in the parent level, making the overall cost cheaper
even though delivering sorted output was not the cheapest plan for
the subquery in isolation. (A couple of regression test outputs
change in consequence of that. However, there is very little change
in visible planner behavior overall, because the point of this patch
is not to get immediate planning benefits but to create the
infrastructure for future improvements.) There is a great deal left
to do here. This patch unblocks a lot of planner work that was
basically impractical in the old code structure, such as allowing
FDWs to implement remote aggregation, or rewriting
plan_set_operations() to allow consideration of multiple
implementation orders for set operations. (The latter will likely
require a full rewrite of plan_set_operations(); what I've done here
is only to fix it to return Paths not Plans.) I have also left
unfinished some localized refactoring in createplan.c and planner.c,
because it was not necessary to get this patch to a working state.
Thanks to Robert Haas, David Rowley, and Amit Kapila for review.
http://git.postgresql.org/pg/commitdiff/3fc6e2d7f5b652b417fa6937c34de2438d60fa9f

- Spell "parallel" correctly. Per David Rowley.
http://git.postgresql.org/pg/commitdiff/cf8e7b16a5f3e63fe692d042fefc0c9f09a23ebc

- Fix minor typo in logical-decoding docs. David Rowley
http://git.postgresql.org/pg/commitdiff/a93aec4e0f061ad43034d5324b8407a824e54395

- Finish refactoring make_foo() functions in createplan.c. This patch
removes some redundant cost calculations that I left for later
cleanup in commit 3fc6e2d7f5b652b4. There's now a uniform policy
that the make_foo() convenience functions don't do any cost
calculations. Most of their callers copy costs from the source Path
node, and for those that don't, the calculation in the make_foo()
function wasn't necessarily right anyhow. (make_result() was
particularly a mess, as it was serving multiple callers using cost
calcs designed for only the first one or two that had ever existed.)
Aside from saving a few cycles, this ensures that what EXPLAIN
prints matches the costs we used for planning purposes. It does not
change any planner decisions, since the decisions are already made.
http://git.postgresql.org/pg/commitdiff/8c314b9853c2fbb85c041d4761426f25a9d63972

- Fix minor thinko in pathification code. I passed the wrong "root"
struct to create_pathtarget in build_minmax_path. Since the subroot
is a clone of the outer root, this would not cause any serious
problems, but it would waste some cycles because
set_pathtarget_cost_width would not have access to Var width
estimates set up while running query_planner on the subroot.
http://git.postgresql.org/pg/commitdiff/61fd218930db53079e5f001dd4ea2fd53afd1b95

- Improve handling of group-column indexes in GroupingSetsPath.
Instead of having planner.c compute a groupColIdx array and store it
in GroupingSetsPaths, make create_groupingsets_plan() find the
grouping columns by searching in the child plan node's tlist.
Although that's probably a bit slower for
create_groupingsets_plan(), it's more like the way every other plan
node type does this, and it provides positive confirmation that we
know which child output columns we're supposed to be grouping on.
(Indeed, looking at this now, I'm not at all sure that it wasn't
broken before, because create_groupingsets_plan() isn't demanding an
exact tlist match from its child node.) Also, this allows
substantial simplification in planner.c, because it no longer needs
to compute the groupColIdx array at all; no other cases were using
it. I'd intended to put off this refactoring until later (like
9.7), but in view of the likely bug fix and the need to rationalize
planner.c's tlist handling so we can do something sane with
Konstantin Knizhnik's function-evaluation-postponement patch, I
think it can't wait.
http://git.postgresql.org/pg/commitdiff/9e8b99420fe5f80495ada8dc50aeb7b954b33093

- Improve handling of pathtargets in planner.c. Refactor so that the
internal APIs in planner.c deal in PathTargets not targetlists, and
establish a more regular structure for deriving the targets needed
for successive steps. There is more that could be done here;
calculating the eval costs of each successive target independently
is both inefficient and wrong in detail, since we won't actually
recompute values available from the input node's tlist. But it's no
worse than what happened before the pathification rewrite. In any
case this seems like a good starting point for considering how to
handle Konstantin Knizhnik's function-evaluation-postponement patch.
http://git.postgresql.org/pg/commitdiff/51c0f63e4d76a86b44e87876a6addcfffb01ec28

- Fix copy-and-pasteo in comment. Wensheng Zhang
http://git.postgresql.org/pg/commitdiff/d31f20e2b5a246f276c73134b610ac7a2f34e274

- Fix incorrect tlist generation in create_gather_plan(). This
function is written as though Gather doesn't project; but it does.
Even if it did not project, though, we must use build_path_tlist to
ensure that the output columns receive correct sortgroupref
labeling. Per report from Amit Kapila.
http://git.postgresql.org/pg/commitdiff/8776c15c85322612b9bf79daf50f74be71c12e05

- Fix incorrect handling of NULL index entries in indexed ROW()
comparisons. An index search using a row comparison such as ROW(a,
b) > ROW('x', 'y') would stop upon reaching a NULL entry in the "b"
column, ignoring the fact that there might be non-NULL "b" values
associated with later values of "a". This happens because
_bt_mark_scankey_required() marks the subsidiary scankey for "b" as
required, which is just wrong: it's for a column after the one with
the first inequality key (namely "a"), and thus can't be considered
a required match. This bit of brain fade dates back to the very
beginnings of our support for indexed ROW() comparisons, in 2006.
Kind of astonishing that no one came across it before Glen
Takahashi, in bug #14010. Back-patch to all supported versions.
Note: the given test case doesn't actually fail in unpatched 9.1,
evidently because the fix for bug #6278 (i.e., stopping at nulls in
either scan direction) is required to make it fail. I'm sure I
could devise a case that fails in 9.1 as well, perhaps with
something involving making a cursor back up; but it doesn't seem
worth the trouble.
http://git.postgresql.org/pg/commitdiff/a298a1e06fb0574c898a07761f9f86c2a323919e

- Remove a couple of useless pstrdup() calls. There's no point in
pstrdup'ing the result of TextDatumGetCString, since that's
necessarily already a freshly-palloc'd C string. These particular
calls are unlikely to be of any consequence performance-wise, but
still they're a bad precedent that can confuse future patch authors.
Noted by Chapman Flack.
http://git.postgresql.org/pg/commitdiff/cc402116ca156babcd3ef941317f462a96277e3a

- Refactor pull_var_clause's API to make it less tedious to extend.
In commit 1d97c19a0f748e94 and later c1d9579dd8bf3c92, we extended
pull_var_clause's API by adding enum-type arguments. That's sort of
a pain to maintain, though, because it means every time we add a new
behavior we must touch every last one of the call sites, even if
there's a reasonable default behavior that most of them could use.
Let's switch over to using a bitmask of flags, instead; that seems
more maintainable and might save a nanosecond or two as well. This
commit changes no behavior in itself, though I'm going to follow it
up with one that does add a new behavior. In passing, remove
flatten_tlist(), which has not been used since 9.1 and would
otherwise need the same API changes. Removing these enums means
that optimizer/tlist.h no longer needs to depend on optimizer/var.h.
Changing that caused a number of C files to need addition of
#include "optimizer/var.h" (probably we can thank old runs of
pgrminclude for that); but on balance it seems like a good change
anyway.
http://git.postgresql.org/pg/commitdiff/364a9f47ab363250f62dd2c381c4da435283725a

- Give pull_var_clause() reject/recurse/return behavior for
WindowFuncs too. All along, this function should have treated
WindowFuncs in a manner similar to Aggrefs, ie with an option
whether or not to recurse into them. By not considering the case,
it was always recursing, which is OK for most callers (although I
suspect that the case in prepare_sort_from_pathkeys might represent
a bug). But now we need return-without-recursing behavior as well.
There are also more than a few callers that should never see a
WindowFunc, and now we'll get some error checking on that.
http://git.postgresql.org/pg/commitdiff/c82c92b111b7b636e80f8a432de10c62011b35b6

- Minor additional refactoring of planner.c's PathTarget handling.
Teach make_group_input_target() and make_window_input_target() to
work entirely with the PathTarget representation of tlists, rather
than constructing a tlist and immediately deconstructing it into
PathTarget format. In itself this only saves a few palloc's; the
bigger picture is that it opens the door for sharing cost_qual_eval
work across all of planner.c's constructions of PathTargets. I'll
come back to that later. In support of this, flesh out tlist.c's
infrastructure for PathTargets a bit more.
http://git.postgresql.org/pg/commitdiff/49635d7b3e86c0088eadd80db1563a210bc89efd

- When appropriate, postpone SELECT output expressions till after
ORDER BY. It is frequently useful for volatile, set-returning, or
expensive functions in a SELECT's targetlist to be postponed till
after ORDER BY and LIMIT are done. Otherwise, the functions might
be executed for every row of the table despite the presence of
LIMIT, and/or be executed in an unexpected order. For example, in
SELECT x, nextval('seq') FROM tab ORDER BY x LIMIT 10; it's probably
desirable that the nextval() values are ordered the same as x, and
that nextval() is not run more than 10 times. In the past, Postgres
was inconsistent in this area: you would get the desirable behavior
if the ordering were performed via an indexscan, but not if it had
to be done by an explicit sort step. Getting the desired behavior
reliably required contortions like SELECT x, nextval('seq') FROM
(SELECT x FROM tab ORDER BY x) ss LIMIT 10; This patch conditionally
postpones evaluation of pure-output target expressions (that is,
those that are not used as DISTINCT, ORDER BY, or GROUP BY columns)
so that they effectively occur after sorting, even if an explicit
sort step is necessary. Volatile expressions and set-returning
expressions are always postponed, so as to provide consistent
semantics. Expensive expressions (costing more than 10 times
typical operator cost, which by default would include any
user-defined function) are postponed if there is a LIMIT or if there
are expressions that must be postponed. We could be more aggressive
and postpone any nontrivial expression, but there are costs
associated with doing so: it requires an extra Result plan node
which adds some overhead, and postponement changes the volume of
data going through the sort step, perhaps for the worse. Since we
tend not to have very good estimates of the output width of
nontrivial expressions, it's hard to have much confidence in our
ability to predict whether postponement would increase or decrease
the cost of the sort; therefore this patch doesn't attempt to make
decisions conditionally on that. Between these factors and a
general desire not to change query behavior when there's not a
demonstrable benefit, it seems best to be conservative about
applying postponement. We might tweak the decision rules in the
future, though. Konstantin Knizhnik, heavily rewritten by me
http://git.postgresql.org/pg/commitdiff/9118d03a8cca3d97327c56bf89a72e328e454e63

- Re-export a few of createplan.c's make_xxx() functions. CitusDB is
using these and don't wish to redesign their code right now. I am
not on board with this being a good idea, or a good precedent, but I
lack the energy to fight about it.
http://git.postgresql.org/pg/commitdiff/570be1f73f385abb557bda15b718d7aac616cc15

- Get rid of scribbling on a const variable in psql's print.c. Commit
a2dabf0e1dda93c8 had the bright idea that it could modify a "const"
global variable if it merely casted away const from a pointer. This
does not work on platforms where the compiler puts "const" variables
into read-only storage. Depressingly, we evidently have no such
platforms in our buildfarm ... an oversight I have now remedied.
(The one platform that is known to catch this is recent OS X with
-fno-common.) Per report from Chris Ruprecht. Back-patch to 9.5
where the bogus code was introduced.
http://git.postgresql.org/pg/commitdiff/fc7a9dfddb073a55a226778acd6a9b3f5ea2e626

- Widen query numbers-of-tuples-processed counters to uint64. This
patch widens SPI_processed, EState's es_processed field,
PortalData's portalPos field, FuncCallContext's call_cntr and
max_calls fields, ExecutorRun's count argument, PortalRunFetch's
result, and the max number of rows in a SPITupleTable to uint64, and
deals with (I hope) all the ensuing fallout. Some of these values
were declared uint32 before, and others "long". I also removed
PortalData's posOverflow field, since that logic seems pretty
useless given that portalPos is now always 64 bits. The
user-visible results are that command tags for SELECT etc will
correctly report tuple counts larger than 4G, as will plpgsql's GET
GET DIAGNOSTICS ... ROW_COUNT command. Queries processing more
tuples than that are still not exactly the norm, but they're
becoming more common. Most values associated with FETCH/MOVE
distances, such as PortalRun's count argument and the count argument
of most SPI functions that have one, remain declared as "long".
It's not clear whether it would be worth promoting those to int64;
but it would definitely be a large dollop of additional API churn on
top of this, and it would only help 32-bit platforms which seem
relatively less likely to see any benefit. Andreas Scherbaum,
reviewed by Christian Ullrich, additional hacking by me
http://git.postgresql.org/pg/commitdiff/23a27b039d94ba359286694831eafe03cd970eef

- Fix Windows portability issue in 23a27b039d94ba35. _strtoui64() is
available in MSVC builds, but apparently not with other Windows
toolchains. Thanks to Petr Jelinek for the diagnosis.
http://git.postgresql.org/pg/commitdiff/ab737f6ba9fc0a26d32a95b115d5cd0e24a63191

- Report memory context stats upon out-of-memory in repalloc[_huge].
This longstanding functionality evidently got lost in commit
3d6d1b585524aab6. Noted while studying an OOM report from Jaime
Casanova. Backpatch to 9.5 where the bug was introduced.
http://git.postgresql.org/pg/commitdiff/4b980167cb5a489346c5e53afb86280a7d59ebc7

- Fix memory leak in repeated GIN index searches. Commit
d88976cfa1302e8d removed this code from ginFreeScanKeys():
if (entry->list)
pfree(entry->list);
evidently in the belief that that ItemPointer array is allocated in
the keyCtx and so would be reclaimed by the following
MemoryContextReset. Unfortunately, it isn't and it won't. It'd
likely be a good idea for that to become so, but as a simple and
back-patchable fix in the meantime, restore this code to
ginFreeScanKeys(). Also, add a similar pfree to where
startScanEntry() is about to zero out entry->list. I am not sure if
there are any code paths where this change prevents a leak today,
but it seems like cheap future-proofing. In passing, make the
initial allocation of so->entries[] use palloc not palloc0. The
code doesn't depend on unused entries being zero; if it did, the
array-enlargement code in ginFillScanEntry() would be wrong. So
using palloc0 initially can only serve to confuse readers about what
the invariant is. Per report from Felipe de Jesús Molina Bravo, via
Jaime Casanova in
<CAJGNTeMR1ndMU2Thpr8GPDUfiHTV7idELJRFusA5UXUGY1y-eA(at)mail(dot)gmail(dot)com>
http://git.postgresql.org/pg/commitdiff/ab4ff2889d0bccc32467e681546aabdb87de4958

Andres Freund pushed:

- Fix wrong allocation size in c8f621c43. In c8f621c43 I forgot to
account for MAXALIGN when allocating a new tuplebuf in
ReorderBufferGetTupleBuf(). That happens to currently not cause
active problems on a number of platforms because the affected
pointer is already aligned, but others, like ppc and hppa, trigger
this in the regression test, due to a debug memset clearing memory.
Fix that. Backpatch: 9.4, like the previous commit.
http://git.postgresql.org/pg/commitdiff/fd45d16f6212df15821684b231a44448389fb002

- Further improvements to c8f621c43. Coverity and inspection for the
issue addressed in fd45d16f found some questionable code.
Specifically coverity noticed that the wrong length was added in
ReorderBufferSerializeChange() - without immediate negative
consequences as the variable isn't used afterwards. During
code-review and testing I noticed that a bit of space was wasted
when allocating tuple bufs in several places. Thirdly, the debug
memset()s in ReorderBufferGetTupleBuf() reduce the error checking
valgrind can do. Backpatch: 9.4, like c8f621c43.
http://git.postgresql.org/pg/commitdiff/b63bea5fd3bba4d7a61c3beaba51a06f24b38da6

- plperl: Correctly handle empty arrays in plperl_ref_from_pg_array.
plperl_ref_from_pg_array() didn't consider the case that postgrs
arrays can have 0 dimensions (when they're empty) and accessed the
first dimension without a check. Fix that by special casing the
empty array case. Author: Alex Hunsaker Reported-By: Andres Freund
/ valgrind / buildfarm animal skink Discussion:
20160308063240(dot)usnzg6bsbjrne667(at)alap3(dot)anarazel(dot)de Backpatch: 9.1-
http://git.postgresql.org/pg/commitdiff/e66197fa2efa8ae0cab1eed6b2257ab4e2134b1e

- ltree: Zero padding bytes when allocating memory for externally
visible data. ltree/ltree_gist/ltxtquery's headers stores data at
MAXALIGN alignment, requiring some padding bytes. So far we left
these uninitialized. Zero those by using palloc0. Author: Andres
Freund Reported-By: Andres Freund / valgrind / buildarm animal skink
Backpatch: 9.1-
http://git.postgresql.org/pg/commitdiff/7a1d4a2448c34ed4669d67ae4f24c594545f10b5

- Add valgrind suppressions for bootstrap related code. Author:
Andres Freund Backpatch: 9.4, where we started to maintain valgrind
suppressions
http://git.postgresql.org/pg/commitdiff/5e43bee8307f1f6f87894c9a4bd9f9045f45c064

- Add valgrind suppressions for python code. Python's allocator does
some low-level tricks for efficiency; unfortunately they trigger
valgrind errors. Those tricks can be disabled making instrumentation
easier; but few people testing postgres will have such a build of
python. So add broad suppressions of the resulting errors. See also
https://svn.python.org/projects/python/trunk/Misc/README.valgrind
This possibly will suppress valid errors, but without it it's
basically impossible to use valgrind with plpython code. Author:
Andres Freund Backpatch: 9.4, where we started to maintain valgrind
suppressions
http://git.postgresql.org/pg/commitdiff/2f1f4439306d2793492e49366d5911e48aa2c4b1

- Introduce durable_rename() and durable_link_or_rename(). Renaming a
file using rename(2) is not guaranteed to be durable in face of
crashes; especially on filesystems like xfs and ext4 when mounted
with data=writeback. To be certain that a rename() atomically
replaces the previous file contents in the face of crashes and
different filesystems, one has to fsync the old filename, rename the
file, fsync the new filename, fsync the containing directory. This
sequence is not generally adhered to currently; which exposes us to
data loss risks. To avoid having to repeat this arduous sequence,
introduce durable_rename(), which wraps all that. Also add
durable_link_or_rename(). Several places use link() (with a fallback
to rename()) to rename a file, trying to avoid replacing the target
file out of paranoia. Some of those rename sequences need to be
durable as well. There seems little reason extend several copies of
the same logic, so centralize the link() callers. This commit does
not yet make use of the new functions; they're used in a followup
commit. Author: Michael Paquier, Andres Freund Discussion:
56583BDD(dot)9060302(at)2ndquadrant(dot)com Backpatch: All supported branches
http://git.postgresql.org/pg/commitdiff/606e0f9841b820d826f837bf741a3e5e9cc62fa1

- Avoid unlikely data-loss scenarios due to rename() without fsync.
Renaming a file using rename(2) is not guaranteed to be durable in
face of crashes. Use the previously added
durable_rename()/durable_link_or_rename() in various places where we
previously just renamed files. Most of the changed call sites are
arguably not critical, but it seems better to err on the side of too
much durability. The most prominent known case where the previously
missing fsyncs could cause data loss is crashes at the end of a
checkpoint. After the actual checkpoint has been performed, old WAL
files are recycled. When they're filled, their contents are
fdatasynced, but we did not fsync the containing directory. An
OS/hardware crash in an unfortunate moment could then end up leaving
that file with its old name, but new content; WAL replay would thus
not replay it. Reported-By: Tomas Vondra Author: Michael Paquier,
Tomas Vondra, Andres Freund Discussion:
56583BDD(dot)9060302(at)2ndquadrant(dot)com Backpatch: All supported branches
http://git.postgresql.org/pg/commitdiff/1d4a0ab19a7e45aa8b94d7f720d1d9cefb81ec40

- Blindly try to fix dtrace enabled builds, broken in 9cd00c45.
Reported-By: Peter Eisentraut Discussion: 56E2239E(dot)1050607(at)gmx(dot)net
http://git.postgresql.org/pg/commitdiff/c94f0c29cecc7944a14aa645c8a97a7250bf146b

- Checkpoint sorting and balancing. Up to now checkpoints were
written in the order they're in the BufferDescriptors. That's nearly
random in a lot of cases, which performs badly on rotating media,
but even on SSDs it causes slowdowns. To avoid that, sort
checkpoints before writing them out. We currently sort by
tablespace, relfilenode, fork and block number. One of the major
reasons that previously wasn't done, was fear of imbalance between
tablespaces. To address that balance writes between tablespaces.
The other prime concern was that the relatively large allocation to
sort the buffers in might fail, preventing checkpoints from
happening. Thus pre-allocate the required memory in shared memory,
at server startup. This particularly makes it more efficient to
have checkpoint flushing enabled, because that'll often result in a
lot of writes that can be coalesced into one flush. Discussion:
alpine(dot)DEB(dot)2(dot)10(dot)1506011320000(dot)28433(at)sto Author: Fabien Coelho and
Andres Freund
http://git.postgresql.org/pg/commitdiff/9cd00c457e6a1ebb984167ac556a9961812a683c

- Allow to trigger kernel writeback after a configurable number of
writes. Currently writes to the main data files of postgres all go
through the OS page cache. This means that some operating systems
can end up collecting a large number of dirty buffers in their
respective page caches. When these dirty buffers are flushed to
storage rapidly, be it because of fsync(), timeouts, or dirty
ratios, latency for other reads and writes can increase massively.
This is the primary reason for regular massive stalls observed in
real world scenarios and artificial benchmarks; on rotating disks
stalls on the order of hundreds of seconds have been observed. On
linux it is possible to control this by reducing the global dirty
limits significantly, reducing the above problem. But global
configuration is rather problematic because it'll affect other
applications; also PostgreSQL itself doesn't always generally want
this behavior, e.g. for temporary files it's undesirable. Several
operating systems allow some control over the kernel page cache.
Linux has sync_file_range(2), several posix systems have msync(2)
and posix_fadvise(2). sync_file_range(2) is preferable because it
requires no special setup, whereas msync() requires the
to-be-flushed range to be mmap'ed. For the purpose of flushing dirty
data posix_fadvise(2) is the worst alternative, as flushing dirty
data is just a side-effect of POSIX_FADV_DONTNEED, which also
removes the pages from the page cache. Thus the feature is enabled
by default only on linux, but can be enabled on all systems that
have any of the above APIs. While desirable and likely possible
this patch does not contain an implementation for windows. With the
infrastructure added, writes made via checkpointer, bgwriter and
normal user backends can be flushed after a configurable number of
writes. Each of these sources of writes controlled by a separate
GUC, checkpointer_flush_after, bgwriter_flush_after and
backend_flush_after respectively; they're separate because the
number of flushes that are good are separate, and because the
performance considerations of controlled flushing for each of these
are different. A later patch will add checkpoint sorting - after
that flushes from the ckeckpoint will almost always be desirable.
Bgwriter flushes are most of the time going to be random, which are
slow on lots of storage hardware. Flushing in backends works well
if the storage and bgwriter can keep up, but if not it can have
negative consequences. This patch is likely to have negative
performance consequences without checkpoint sorting, but
unfortunately so has sorting without flush control. Discussion:
alpine(dot)DEB(dot)2(dot)10(dot)1506011320000(dot)28433(at)sto Author: Fabien Coelho and
Andres Freund
http://git.postgresql.org/pg/commitdiff/428b1d6b29ca599c5700d4bc4f4ce4c5880369bf

- Include portability/mem.h into fd.c for MAP_FAILED. Buildfarm
members gaur and pademelon are old enough not to know about
MAP_FAILED; which is used in 428b1d6. Include portability/mem.h to
fix; as already done in a bunch of other places.
http://git.postgresql.org/pg/commitdiff/e01157500f26342bf4f067a4eb1e45ab9a3cd410

Joe Conway pushed:

- Make get_controlfile() error logging consistent with src/common As
originally committed, get_controlfile() used a non-standard approach
to error logging. Make it consistent with the majority of error
logging done in src/common. Applies to master only.
http://git.postgresql.org/pg/commitdiff/7b077af5000cb94b8547b62ee45697cf6bf806ef

Peter Eisentraut pushed:

- Fix uninstall target in tsearch Makefile. Artur Zakirov
http://git.postgresql.org/pg/commitdiff/1c2db8c305745edb8800e8b146d5c295eb82a4fd

- Suppress GCC 6 warning about self-comparison. Reviewed-by: Thomas
Munro <thomas(dot)munro(at)enterprisedb(dot)com>
http://git.postgresql.org/pg/commitdiff/a2fd62dd53fb606dee69e0f4eb12289c87f5c8b1

- psql: Fix some strange code in SQL help creation. Struct QL_HELP
used to be defined as static in the sql_help.h header file, which is
included in sql_help.c and help.c, thus creating two separate
instances of the struct. This causes a warning from GCC 6, because
the struct is not used in sql_help.c. Instead, declare the struct
as extern in the header file and define it in sql_help.c. This also
allows making a bunch of functions static because they are no longer
needed outside of sql_help.c. Reviewed-by: Thomas Munro
<thomas(dot)munro(at)enterprisedb(dot)com>
http://git.postgresql.org/pg/commitdiff/92d4294d4bbddf94cec0dce729ade7bb2aada1b7

- ecpg: Fix typo. GCC 6 points out the redundant conditions, which
were apparently typos. Reviewed-by: Thomas Munro
<thomas(dot)munro(at)enterprisedb(dot)com>
http://git.postgresql.org/pg/commitdiff/0d0644dce82a87ef4b670fb60709ef1fd6a3030c

- Handle invalid libpq sockets in more places. Also, make error
messages consistent. From: Michael Paquier
<michael(dot)paquier(at)gmail(dot)com>
http://git.postgresql.org/pg/commitdiff/a40814d7aacbda9266c703cc011d3506668899de

- doc: Reorganize pg_resetxlog reference page. The pg_resetxlog
reference page didn't have a proper options list, only running text
listing the options and some explanations of them. This might have
worked when there were only a few options, but the list has grown
over the releases, and now it's hard to find an option and its
associated explanation. So write out the options list as on other
reference pages.
http://git.postgresql.org/pg/commitdiff/e19e4cf0be2892d3c894d6e37b905024f5977ab2

- Fix whitespace and remove obsolete gitattributes entry.
http://git.postgresql.org/pg/commitdiff/96adb14d931e442e0a96f418d483fc896506146f

Robert Haas pushed:

- pg_upgrade: Remove converter plugin facility. We've not found a
use for this so far, and the current need, which is to convert the
visibility map to a new format, does not suit the existing design
anyway. So just rip it out. Author: Masahiko Sawada, slightly
revised by me. Discussion: 20160215211313(dot)GB31273(at)momjian(dot)us
http://git.postgresql.org/pg/commitdiff/6f56b41ac0cd7092b91834da02e70514d28b8edb

- Add pg_visibility contrib module. This lets you examine the
visibility map as well as page-level visibility information. I
initially wrote it as a debugging aid, but was encouraged to polish
it for commit. Patch by me, reviewed by Masahiko Sawada.
Discussion: 56D77803(dot)6080503(at)BlueTreble(dot)com
http://git.postgresql.org/pg/commitdiff/ba0a198fb133eb3426bffdc2e369cce1bafe1612

- Department of second thoughts: remove PD_ALL_FROZEN. Commit
a892234f830e832110f63fc0a2afce2fb21d1584 added a second bit per page
to the visibility map, which still seems like a good idea, but it
also added a second page-level bit alongside PD_ALL_VISIBLE to track
whether the visibility map bit was set. That no longer seems like a
clever plan, because we don't really need that bit for anything. We
always clear both bits when the page is modified anyway. Patch by
me, reviewed by Kyotaro Horiguchi and Masahiko Sawada.
http://git.postgresql.org/pg/commitdiff/77a1d1e79892a20ed15a67be42b96949b8546bf6

- Add some functions to fd.c for the convenience of extensions. For
example, if you want to perform an ioctl() on a file descriptor
opened through the fd.c routines, there's no way to do that without
being able to get at the underlying fd. KaiGai Kohei
http://git.postgresql.org/pg/commitdiff/070140ee48e8524493f882a278b5ced255b34b65

- Fix parallel query on standby servers. Without this fix, it
inevitably bombs out with "ERROR: failed to initialize
transaction_read_only to 0". Repair. Ashutosh Sharma; comments
adjusted by me.
http://git.postgresql.org/pg/commitdiff/dcfecaae9e35afe4fb11304267f547141842447d

- Fix typo. Masahiko Sawada
http://git.postgresql.org/pg/commitdiff/272baaa538f7a3186ac0c03764a8af9c0f5c00ac

- Add new flags argument for xl_heap_visible to heap2_desc. Masahiko
Sawada
http://git.postgresql.org/pg/commitdiff/734f86d50dccc91fb68a99339a22a1bcb87f9cea

- Fix reversed argument to bms_is_subset. Ashutosh Bapat
http://git.postgresql.org/pg/commitdiff/d29b153f180ba374e5e0e1f3e49762aba4a548d7

- Update GetForeignPlan documentation. Commit
385f337c9f39b21dca96ca4770552a10a6d5af24 added a new argument to the
FDW GetForeignPlan method, but failed to update the documentation to
match. Etsuro Fujita
http://git.postgresql.org/pg/commitdiff/dff7ad3c61473a65ff8f166b1eefd099e68595bb

- Comment update for fdw_recheck_quals. Commit
5fc4c26db5120bd90348b6ee3101fcddfdf54800 could've done a better job
updating these comments. Etsuro Fujita
http://git.postgresql.org/pg/commitdiff/7400559a3fe959bdc6822114ef6aa966c42899f9

- postgres_fdw: Consider foreign joining and foreign sorting together.
Commit ccd8f97922944566d26c7d90eb67ab7848ee9905 gave us the ability
to request that the remote side sort the data, and, later, commit
e4106b2528727c4b48639c0e12bf2f70a766b910 gave us the ability to
request that the remote side perform the join for us rather than
doing it locally. But we could not do both things at the same time:
a remote SQL query that had an ORDER BY clause would never be a
join. This commit adds that capability. Ashutosh Bapat, reviewed
by me.
http://git.postgresql.org/pg/commitdiff/aa09cd242fa7e3a694a31f8aed521e80d1e626a4

- Add a generic command progress reporting facility. Using this
facility, any utility command can report the target relation upon
which it is operating, if there is one, and up to 10 64-bit
counters; the intent of this is that users should be able to figure
out what a utility command is doing without having to resort to ugly
hacks like attaching strace to a backend. As a demonstration, this
adds very crude reporting to lazy vacuum; we just report the target
relation and nothing else. A forthcoming patch will make VACUUM
report a bunch of additional data that will make this much more
interesting. But this gets the basic framework in place. Vinayak
Pokale, Rahila Syed, Amit Langote, Robert Haas, reviewed by Kyotaro
Horiguchi, Jim Nasby, Thom Brown, Masahiko Sawada, Fujii Masao, and
Masanori Oyama.
http://git.postgresql.org/pg/commitdiff/b6fb6471f6afaf649e52f38269fd8c5c60647669

- pgbench: When -T is used, don't wait for transactions beyond end of
run. At low rates, this can lead to pgbench taking significantly
longer to terminate than the user might expect. Repair. Fabien
Coelho, reviewed by Aleksander Alekseev, Álvaro Herrera, and me.
http://git.postgresql.org/pg/commitdiff/accf7616ff2854640523d5e42ffa5420cc5a3b51

- Re-pgindent vacuumlazy.c.
http://git.postgresql.org/pg/commitdiff/be060cbcd42737693f6fd425db4c139121181cce

- Code review for b6fb6471f6afaf649e52f38269fd8c5c60647669. Reports
by Tomas Vondra, Vinayak Pokale, and Aleksander Alekseev. Patch by
Amit Langote.
http://git.postgresql.org/pg/commitdiff/090b287fc59e7a44da8c3e0823eecdc8ea4522f2

- Provide much better wait information in pg_stat_activity. When a
process is waiting for a heavyweight lock, we will now indicate the
type of heavyweight lock for which it is waiting. Also, you can now
see when a process is waiting for a lightweight lock - in which case
we will indicate the individual lock name or the tranche, as
appropriate - or for a buffer pin. Amit Kapila, Ildus Kurbangaliev,
reviewed by me. Lots of helpful discussion and suggestions by many
others, including Alexander Korotkov, Vladimir Borodin, and many
others.
http://git.postgresql.org/pg/commitdiff/53be0b1add7064ca5db3cd884302dfc3268d884e

- Simplify GetLockNameFromTagType. The old code is wrong, because it
returns a pointer to an automatic variable. And it's also more
clever than we really need to be considering that the case it's
worrying about should never happen.
http://git.postgresql.org/pg/commitdiff/a414d96ad2b001cddf10e3dedb0bde96d0af6a0b

- Simplify GetLockNameFromTagType. The old code is wrong, because it
returns a pointer to an automatic variable. And it's also more
clever than we really need to be considering that the case it's
worrying about should never happen.
http://git.postgresql.org/pg/commitdiff/a414d96ad2b001cddf10e3dedb0bde96d0af6a0b

- Don't vacuum all-frozen pages. Commit
a892234f830e832110f63fc0a2afce2fb21d1584 gave us enough
infrastructure to avoid vacuuming pages where every tuple on the
page is already frozen. So, replace the notion of a scan_all or
whole-table vacuum with the less onerous notion of an "aggressive"
vacuum, which will pages that are all-visible, but still skip those
that are all-frozen. This should greatly reduce the cost of
anti-wraparound vacuuming on large clusters where the majority of
data is never touched between one cycle and the next, because we'll
no longer have to read all of those pages only to find out that we
don't need to do anything with them. Patch by me, reviewed by
Masahiko Sawada.
http://git.postgresql.org/pg/commitdiff/fd31cd265138019dcccc9b5fe53043670898bc9f

- Fix a typo, and remove unnecessary pgstat_report_wait_end(). Per
Amit Kapila.
http://git.postgresql.org/pg/commitdiff/481c76abf4f5dc99af28a799741c324732a299c6

- psql: Don't automatically use expanded format when there's 1 column.
Andreas Karlsson and Robert Haas
http://git.postgresql.org/pg/commitdiff/69ab7b9d6c9b9e1d782ffad6e440a3615c63f621

- pg_upgrade: Convert old visibility map format to new format. Commit
a892234f830e832110f63fc0a2afce2fb21d1584 added a second bit per page
to the visibility map, but pg_upgrade has been unaware of it up
until now. Therefore, a pg_upgrade from an earlier major release of
PostgreSQL to any commit preceding this one and following the one
mentioned above would result in invalid visibility map contents on
the new cluster, very possibly leading to data corruption. This
plugs that hole. Masahiko Sawada, reviewed by Jeff Janes, Bruce
Momjian, Simon Riggs, Michael Paquier, Andres Freund, me, and
others.
http://git.postgresql.org/pg/commitdiff/7087166a88fe0c04fc6636d0d6d6bea1737fc1fb

Álvaro Herrera pushed:

- pgcrypto: support changing S2K iteration count pgcrypto already
supports key-stretching during symmetric encryption, including the
salted-and-iterated method; but the number of iterations was not
configurable. This commit implements a new s2k-count parameter to
pgp_sym_encrypt() which permits selecting a larger number of
iterations. Author: Jeff Janes
http://git.postgresql.org/pg/commitdiff/188f359d39ed65b5f3ddc1f397140fb9d153e61a

- Add filter capability to RecursiveCopy::copypath This allows
skipping copying certain files and subdirectories in tests. This is
useful in some circumstances such as copying a data directory;
future tests want this feature. Also POD-ify the module. Authors:
Craig Ringer, Pallavi Sontakke Reviewed-By: Álvaro Herrera
http://git.postgresql.org/pg/commitdiff/a31aaec40643e0074f30b1683953cb0b3ea27036

- PostgresNode: add backup_fs_hot and backup_fs_cold These simple
methods rely on RecursiveCopy to create a filesystem-level backup of
a server. They aren't currently used anywhere yet,but will be
useful for future tests. Author: Craig Ringer Reviewed-By: Michael
Paquier, Salvador Fandino, Álvaro Herrera Commitfest-URL:
https://commitfest.postgresql.org/9/569/
http://git.postgresql.org/pg/commitdiff/28f6df3c36769eedce5c73d2f5bab9892d5cd76e

- Document BRIN a bit more thoroughly The chapter "Interfacing
Extensions To Indexes" and CREATE OPERATOR CLASS reference page were
missed when BRIN was added. We document all our other index access
methods there, so make sure BRIN complies. Author: Álvaro Herrera
Reported-By: Julien Rouhaud, Tom Lane Reviewed-By: Emre Hasegeli
Discussion:
https://www.postgresql.org/message-id/56CF604E.9000303%40dalibo.com
Backpatch: 9.5, where BRIN was introduced
http://git.postgresql.org/pg/commitdiff/a3a8309d450f7c4d1b743e84ba54ef5f7877d7be

Simon Riggs pushed:

- Reduce lock level for altering fillfactor Fabrízio de Royes Mello
and Simon Riggs
http://git.postgresql.org/pg/commitdiff/fcb4bfddb6ff46e4495b923987ed6a89bd256174

- Reduce size of two phase file header Previously 2PC header was fixed
at 200 bytes, which in most cases wasted WAL space for a workload
using 2PC heavily. Pavan Deolasee, reviewed by Petr Jelinek
http://git.postgresql.org/pg/commitdiff/e0694cf9c74455fb87beb0f4d66b4c8f5f53715e

- Rework wait for AccessExclusiveLocks on Hot Standby Earlier version
committed in 9.0 caused spurious waits in some cases. New
infrastructure for lock waits in 9.3 used to correct and improve
this. Jeff Janes based upon a proposal by Simon Riggs, who also
reviewed Additional review comments from Amit Kapila
http://git.postgresql.org/pg/commitdiff/37c54863cf71a4a1126d21db8eb68974bef34374

- Allow emit_log_hook to see original message text emit_log_hook could
only see the translated text, making it harder to identify which
message was being sent. Pass original text to allow the exact
message to be identified, whichever language is used for logging.
Discussion: 20160216(dot)184755(dot)59721141(dot)horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp
Author: Kyotaro Horiguchi
http://git.postgresql.org/pg/commitdiff/73e7e49da3b23a15cd84f003e11ad7d55ad80da7

Magnus Hagander pushed:

- Avoid crash on old Windows with AVX2-capable CPU for VS2013 builds.
The Visual Studio 2013 CRT generates invalid code when it makes a
64-bit build that is later used on a CPU that supports AVX2
instructions using a version of Windows before 7SP1/2008R2SP1.
Detect this combination, and in those cases turn off the generation
of FMA3, per recommendation from the Visual Studio team. The bug is
actually in the CRT shipping with Visual Studio 2013, but Microsoft
have stated they're only fixing it in newer major versions. The fix
is therefor conditioned specifically on being built with this
version of Visual Studio, and not previous or later versions.
Author: Christian Ullrich
http://git.postgresql.org/pg/commitdiff/9d90388247e093cd9b3ead79954df2ac18bfeb66

- Refactor receivelog.c parameters. Much cruft had accumulated over
time with a large number of parameters passed down between functions
very deep. With this refactoring, instead introduce a StreamCtl
structure that holds the parameters, and pass around a pointer to
this structure instead. This makes it much easier to add or remove
fields that are needed deeper down in the implementation without
having to modify every function header in the file. Patch by me
after much nagging from Andres Reviewed by Craig Ringer and Daniel
Gustafsson
http://git.postgresql.org/pg/commitdiff/38c83c9b7569378d864d8915e291716b8bec15f2

- Allow setting sample ratio for auto_explain. New configuration
parameter auto_explain.sample_ratio makes it possible to log just a
fraction of the queries meeting the configured threshold, to reduce
the amount of logging. Author: Craig Ringer and Julien Rouhaud
Review: Petr Jelinek
http://git.postgresql.org/pg/commitdiff/92f03fe76fe6be683a8b7497579158b8a82b2c25

- Fix order of MemSet arguments. Noted by Tomas Vondra
http://git.postgresql.org/pg/commitdiff/a1aa8b7ea0558620106e25c27d0a70ee4ac9d6a8

- Rename auto_explain.sample_ratio to sample_rate. Per suggestion from
Tomas Vondra Author: Julien Rouhaud
http://git.postgresql.org/pg/commitdiff/7a8d8748362d4d8505e320c3eaab4a2c2463e3a6

Teodor Sigaev pushed:

- Tsvector editing functions. Adds several tsvector editting
function: convert tsvector to/from text array, set weight for given
lexemes, delete lexeme(s), unnest, filter lexemes with given weights
Author: Stas Kelvich with some editorization by me Reviewers: Tomas
Vondram, Teodor Sigaev
http://git.postgresql.org/pg/commitdiff/6943a946c7e5eb72d53c0ce71f08a81a133503bd

- Bump catalog version missed in
6943a946c7e5eb72d53c0ce71f08a81a133503bd
http://git.postgresql.org/pg/commitdiff/a9eb6c83efd258bb7a658fefa0074e0e65efd673

- Fix merge affixes for numeric ones. Some dictionaries have
duplicated base words with different affix set, we just merge that
sets into one set. But previously merging of sets of affixes was
actually a concatenation of strings but it's wrong for numeric
representation of affixes because such representation uses comma to
separate affixes. Author: Artur Zakirov
http://git.postgresql.org/pg/commitdiff/8829af47ef63d3c484f2e1f97a85a7a76b1baba6

- Fix Windows build broken in 6943a946c7e5eb72d53c0ce71f08a81a133503bd.
Also it fixes dynamic array allocation disallowed by ANSI-C.
Author: Stas Kelvich
http://git.postgresql.org/pg/commitdiff/b1fdc727c37b23da947b4b0d440f723f31beb84d

== Rejected Patches (for now) ==

No one was disappointed this week :-)

== Pending Patches ==

Amit Langote sent in eight more revisions of a patch to implement a
vacuum progress checker.

David Rowley and Haribabu Kommi traded patches to implement parallel
aggregation.

Peter Geoghegan sent in a patch to avoid incorrectly indicating
exclusion constraint wait.

Michaël Paquier and Petr Jelínek traded patches to add support for
MSVC 2015.

Fabien COELHO sent in four more revisions of a patch to extend pgbench
expressions with functions.

Peter Geoghegan sent in another revision of a patch to use quicksort
for every external sort run.

Michaël Paquier sent in four more revisions of a patch to fix a
recovery delay.

Robert Haas sent in another revision of a patch to add an Idle In
Transaction Session timeout GUC.

Robbie Harwood sent in another revision of a patch to add GSSAPI
encryption support.

Ashutosh Bapat sent in another revision of a patch to allow pushing
sorted joins down to the FDW.

Pavan Deolasee sent in two more revisions of a patch to reduce the
amount of WAL in the 2PC case.

David Rowley sent in two more revisions of a patch to make outer joins
faster when the outer side is unique.

Tomas Vondra sent in five more revisions of a patch to implement
multivariate statistics.

Dilip Kumar sent in three more revisions of a patch to scale up
relation extension.

Thomas Munro sent in four more revisions of a patch to implement
"causal reads."

Kyotaro HORIGUCHI sent in another revision of a patch to allow
index-only scans with partial indexes.

Fabien COELHO sent in another revision of a patch to fix pgbench
duration under rate.

Michaël Paquier sent in another revision of a patch to delay status
update to the end of recovery.

David G. Johnston sent in a patch to continue using \pset titles
during \watch iterations after the first in psql.

Etsuro Fujita sent in another revision of a patch to make writes
faster with the PostgreSQL FDW.

Gilles Darold sent in two revisions of a patch to add a
pg_current_logfile() function.

Alexander Korotkov sent in two more revisions of a patch for access
method extendability.

Mithun Cy and Amit Kapila traded patches to fix an issue where Explain
[Analyze] produces a parallel scan for SELECT INTO TABLE statements.
As writes have not yet been parallelized, this is a problem.

Kaigai Kouhei sent in two more revisions of a patch to rework
CustomScan [de]serialization.

Alexander Kuleshov sent in a patch to simplify search of end of argv
in save_ps_display_args().

Stas Kelvich sent in a patch to add 2PC support to pg_logical.

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

Corey Huinker sent in two more revisions of a patch to add
generate_series(date, date[, integer]).

Peter Eisentraut sent in a patch to clear OpenSSL error queue before
OpenSSL calls.

Alexey Grishchenko sent in two revisions of a patch to fix an endless
loop calling PL/Python set returning functions.

Grzegorz Sampolski and Haribabu Kommi traded patches to add rhost to
PAM auth.

Thomas Munro sent in three more revisions of a patch to detect SSI
conflicts before reporting constraint violations.

Kyotaro HORIGUCHI sent in another revision of a patch to fix a WAL
logging issue.

David Steele sent in another revision of a patch to add client log
output filtering.

Sherrylyn Branchaw sent in a patch to change error code for hstore
syntax error.

Alexander Kuleshov sent in a patch to use MemoryContextAlloc() in the
MemoryContextAllocZero() and MemoryContextAllocZeroAligned().

Daniel Verité sent in another revision of a patch to add \crosstabview
to psql.

Alexander Korotkov sent in another revision of a patch to implement
partial sort.

Dagfinn Ilmari Mannsåker sent in a patch to fix obsolete wording in
PL/Perl hv_store_string comment.

Jim Nasby sent in a patch to improve error handling in pltcl.

Jim Nasby sent in another revision of a patch to ensure that configure
checks for a valid [1-65535] port.

Alexander Korotkov sent in another revision of a patch to move
PinBuffer and UnpinBuffer to atomics.

Jim Nasby sent in another revision of a patch to implement \gexec in
psql.

Thomas Munro sent in a patch to make pg_stat_get_progress_info()
strict.

David Rowley sent in two more revisions of a patch to help implement
combining aggregates.

Noah Misch and Tomas Vondra traded patches to split stats file per
database.