== PostgreSQL Weekly News - March 17, 2019 ==

== PostgreSQL Weekly News - March 17, 2019 ==

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

== PostgreSQL Product News ==

pggraphblas 0.2, a a Postgres extension makes the GraphBLAS API available to
PostgreSQL.
https://github.com/michelp/pggraphblas

== PostgreSQL Jobs for March ==

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

== PostgreSQL Local ==

Nordic PGDay 2019 will be held in Copenhagen, Denmark, at the
Copenhagen Marriott Hotel, on March 19, 2019.
https://2019.nordicpgday.org/

PGConf APAC 2019 will be held in Singapore March 19-21, 2019.
http://2019.pgconfapac.org/

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

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

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

Swiss PGDay 2019 will take place in Rapperswil (near Zurich) on June 28, 2019.
The CfP is open through April 18, 2019, and registration is open.
http://www.pgday.ch/2019/

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

PGConf.Brazil 2019 is on August 1-3 2019 in São Paulo.
http://pgconf.com.br

== PostgreSQL in the News ==

Planet PostgreSQL: http://planet.postgresql.org/

PostgreSQL Weekly News is brought to you this week by David Fetter

Submit news and announcements by Sunday at 3:00pm PST8PDT to david(at)fetter(dot)org(dot)

== Applied Patches ==

Tom Lane pushed:

- Include GUC's unit, if it has one, in out-of-range error messages. This should
reduce confusion in cases where we've applied a units conversion, so that the
number being reported (and the quoted range limits) are in some other units
than what the user gave in the setting we're rejecting. Some of the changes
here assume that float GUCs can have units, which isn't true just yet, but
will be shortly. Discussion:
https://postgr.es/m/3811.1552169665@sss.pgh.pa.us
https://git.postgresql.org/pg/commitdiff/28a65fc3607a0f45c39a9418f747459bb4f1592a

- Convert [autovacuum_]vacuum_cost_delay into floating-point GUCs. This change
makes it possible to specify sub-millisecond delays, which work well on most
modern platforms, though that was not true when the cost-delay feature was
designed. To support this without breaking existing configuration entries,
improve guc.c to allow floating-point GUCs to have units. Also, allow "us"
(microseconds) as an input/output unit for time-unit GUCs. (It's not allowed
as a base unit, at least not yet.) Likewise change the
autovacuum_vacuum_cost_delay reloption to be floating-point; this forces a
catversion bump because the layout of StdRdOptions changes. This patch
doesn't in itself change the default values or allowed ranges for these
parameters, and it should not affect the behavior for any already-allowed
setting for them. Discussion:
https://postgr.es/m/1798.1552165479@sss.pgh.pa.us
https://git.postgresql.org/pg/commitdiff/caf626b2cd471615914986f18282c03c8282a1f4

- Revert "Increase the default vacuum_cost_limit from 200 to 2000". This reverts
commit bd09503e633b8077822bb4daf91625b71ac16253. Per discussion, it seems
like what we should do instead is to reduce the default value of
autovacuum_vacuum_cost_delay by the same factor. That's functionally
equivalent as long as the platform can accurately service the smaller delay
request, which should be true on anything released in the last 10 years or
more. And smaller, more-closely-spaced delays are better in terms of providing
a steady I/O load. Discussion:
https://postgr.es/m/28720.1552101086@sss.pgh.pa.us
https://git.postgresql.org/pg/commitdiff/52985e4fea75f1ec742742f27e246a8775c99e08

- Reduce the default value of autovacuum_vacuum_cost_delay to 2ms. This is a
better way to implement the desired change of increasing autovacuum's default
resource consumption. Discussion:
https://postgr.es/m/28720.1552101086@sss.pgh.pa.us
https://git.postgresql.org/pg/commitdiff/cbccac371c79d96c44fcd8c9cbb5ff4dedaaa522

- In guc.c, ignore ERANGE errors from strtod(). Instead, just proceed with the
infinity or zero result that it should return for overflow/underflow. This
avoids a platform dependency, in that various versions of strtod are
inconsistent about whether they signal ERANGE for a value that's specified as
infinity. It's possible this won't be enough to remove the buildfarm failures
we're seeing from ac75959cd, in which case I'll take out the infinity test
case that commit added. But first let's see if we can fix it. Discussion:
https://postgr.es/m/E1h33xk-0001Og-Gs@gemulon.postgresql.org
https://git.postgresql.org/pg/commitdiff/b212245f96437b574b59993c772e4d9276965e49

- Give up on testing guc.c's behavior for "infinity" inputs. Further buildfarm
testing shows that on the machines that are failing ac75959cd's test case,
what we're actually getting from strtod("-infinity") is a syntax error (endptr
== value) not ERANGE at all. This test case is not worth carrying two sets of
expected output for, so just remove it, and revert commit b212245f9's
misguided attempt to work around the platform dependency. Discussion:
https://postgr.es/m/E1h33xk-0001Og-Gs@gemulon.postgresql.org
https://git.postgresql.org/pg/commitdiff/d9c5e9629bf511a51328fd083ee452de88d91d9d

- Allow fractional input values for integer GUCs, and improve rounding logic.
Historically guc.c has just refused examples like set work_mem = '30.1GB', but
it seems more useful for it to take that and round off the value to some
reasonable approximation of what the user said. Just rounding to the
parameter's native unit would work, but it would lead to rather silly-looking
settings, such as 31562138kB for this example. Instead let's round to the
nearest multiple of the next smaller unit (if any), producing 30822MB. Also,
do the units conversion math in floating point and round to integer (if
needed) only at the end. This produces saner results for inputs that aren't
exact multiples of the parameter's native unit, and removes another difference
in the behavior for integer vs. float parameters. In passing, document the
ability to use hex or octal input where it ought to be documented.
Discussion: https://postgr.es/m/1798.1552165479@sss.pgh.pa.us
https://git.postgresql.org/pg/commitdiff/1a83a80a2fe5b559f85ed4830acb92d5124b7a9a

- Create a script that can renumber manually-assigned OIDs. This commit adds a
Perl script renumber_oids.pl, which can reassign a range of manually-assigned
OIDs to someplace else by modifying OID fields of the catalog *.dat files and
OID-assigning macros in the catalog *.h files. Up to now, we've encouraged
new patches that need manually-assigned OIDs to use OIDs just above the range
of existing OIDs. Predictably, this leads to patches stepping on each others'
toes, as whichever one gets committed first creates an OID conflict that other
patch author(s) have to resolve manually. With the availability of
renumber_oids.pl, we can eliminate a lot of this hassle. The new project
policy, therefore, is: * Encourage new patches to use high OIDs (the
documentation suggests choosing a block of OIDs at random in 8000..9999). *
After feature freeze in each development cycle, run renumber_oids.pl to move
all such OIDs down to lower numbers, thus freeing the high OID range for the
next development cycle. This plan should greatly reduce the risk of OID
collisions between concurrently-developed patches. Also, if such a collision
happens anyway, we have the option to resolve it without much effort by doing
an off-schedule OID renumbering to get the first-committed patch out of the
way. Or a patch author could use renumber_oids.pl to change their patch's
assignments without much pain. This approach does put a premium on not
hard-wiring any OID values in places where renumber_oids.pl and genbki.pl
can't fix them. Project practice in that respect seems to be pretty good
already, but a follow-on patch will sand down some rough edges. John Naylor
and Tom Lane, per an idea of Peter Geoghegan's Discussion:
https://postgr.es/m/CAH2-WzmMTGMcPuph4OvsO7Ykut0AOCF_i-=eaochT0dd2BN9CQ@mail.gmail.com
https://git.postgresql.org/pg/commitdiff/a6417078c4140e51cfd717448430f274b449d687

- Remove remaining hard-wired OID references in the initial catalog data. In the
v11-era commits that taught genbki.pl to resolve symbolic OID references in
the initial catalog data, we didn't bother to make every last reference
symbolic; some of the catalogs have so few initial rows that it didn't seem
worthwhile. However, the new project policy that OIDs assigned by new patches
should be automatically renumberable changes this calculus. A patch that wants
to add a row in one of these catalogs would have a problem when the OID it
assigns gets renumbered. Hence, do the mop-up work needed to make all OID
references in initial data be symbolic, and establish an associated project
policy that we'll never again write a hard-wired OID reference there. No
catversion bump since the contents of postgres.bki aren't actually changed by
this commit. Discussion:
https://postgr.es/m/CAH2-WzmMTGMcPuph4OvsO7Ykut0AOCF_i-=eaochT0dd2BN9CQ@mail.gmail.com
https://git.postgresql.org/pg/commitdiff/3aa0395d4ed36f040f20da304c122b956529dd14

- Add support for hyperbolic functions, as well as log10(). The SQL:2016
standard adds support for the hyperbolic functions sinh(), cosh(), and tanh().
POSIX has long required libm to provide those functions as well as their
inverses asinh(), acosh(), atanh(). Hence, let's just expose the libm
functions to the SQL level. As with the trig functions, we only implement
versions for float8, not numeric. For the moment, we'll assume that all
platforms actually do have these functions; if experience teaches otherwise,
some autoconf effort may be needed. SQL:2016 also adds support for base-10
logarithm, but with the function name log10(), whereas the name we've long
used is log(). Add aliases named log10() for the float8 and numeric versions.
Lætitia Avrot Discussion:
https://postgr.es/m/CAB_COdguG22LO=rnxDQ2DW1uzv8aQoUzyDQNJjrR4k00XSgm5w@mail.gmail.com
https://git.postgresql.org/pg/commitdiff/f1d85aa98ee71d9662309f6f0384b2f7f8f16f02

- Rethink how to test the hyperbolic functions. The initial commit tried to test
them on trivial cases such as 0, reasoning that we shouldn't hit any
portability issues that way. The buildfarm immediately proved that hope
ill-founded, and anyway it's not a great testing scheme because it doesn't
prove that we're even calling the right library function for each SQL
function. Instead, let's test them at inputs such as 1 (or something within
the valid range, as needed), so that each function should produce a different
output. As committed, this is just about certain to show portability
failures, because it's very unlikely that every platform computes these
functions the same as mine down to the last bit. However, I want to put it
through a buildfarm cycle this way, so that we can see how big the variations
are. The plan is to add "set extra_float_digits = -1", or whatever we need in
order to hide the variations; but first we need data. Discussion:
https://postgr.es/m/E1h3nUY-0000sM-Vf@gemulon.postgresql.org
https://git.postgresql.org/pg/commitdiff/c6f153dcfebccf7a0d92290037793c656f1caef5

- Adjust the tests for the hyperbolic functions. Preliminary results from the
buildfarm suggest that no platform gets commit c6f153dcf's test cases wrong by
more than one or two units in the last place, so setting extra_float_digits =
0 should be plenty to hide the cross-platform variations. Also, add tests for
Infinity/NaN inputs. I think it highly likely that we'll end up removing
these again, rather than adding code to make ancient platforms conform. But
it seems useful to find out just how many platforms have such issues before we
make a decision. Discussion:
https://postgr.es/m/E1h3nUY-0000sM-Vf@gemulon.postgresql.org
https://git.postgresql.org/pg/commitdiff/c015f853bf5958dd7562a17952df33a9d115e65f

- Sync commentary in transam.h and bki.sgml. Commit a6417078c missed updating
some comments in transam.h about reservation of high OIDs for development
purposes. Also tamp down an over-optimistic comment there about how easy it'd
be to change FirstNormalObjectId. Earlier, commit 09568ec3d failed to update
bki.sgml for the split between genbki.pl-assigned OIDs and those assigned
during initdb. Also fix genbki.pl so that it will complain if it overruns
that split. It's possible that doing so would have no very bad consequences,
but that's no excuse for not detecting it.
https://git.postgresql.org/pg/commitdiff/401b87a24fbab7bfb48eb48050a51e033452ac6e

- Ensure dummy paths have correct required_outer if rel is parameterized. The
assertions added by commits 34ea1ab7f et al found another problem:
set_dummy_rel_pathlist and mark_dummy_rel were failing to label the dummy
paths they create with the correct outer_relids, in case the relation is
necessarily parameterized due to having lateral references in its tlist. It's
likely that this has no user-visible consequences in production builds, at the
moment; but still an assertion failure is a bad thing, so back-patch the fix.
Per bug #15694 from Roman Zharkov (via Alexander Lakhin) and an independent
report by Tushar Ahuja. Discussion:
https://postgr.es/m/15694-74f2ca97e7044f7f@postgresql.org Discussion:
https://postgr.es/m/7d72ab20-c725-3ce2-f99d-4e64dd8a0de6@enterprisedb.com
https://git.postgresql.org/pg/commitdiff/0a9d7e1f6d814799e6cd5046513702dd1fe38929

- Fix some oversights in commit 2455ab488. The idea was to generate all the junk
in a destroyable subcontext rather than leaking it in the caller's context,
but partition_bounds_create was still being called in the caller's context,
allowing plenty of scope for leakage. Also, get_rel_relkind() was still being
called in the rel's rd_pdcxt, creating a risk of session-lifespan memory
wastage. Simplify the logic a bit while at it. Also, reduce rd_pdcxt to
ALLOCSET_SMALL_SIZES, since it seems likely to not usually be big. Probably
something like this needs to be back-patched into v11, but for now let's get
some buildfarm testing on this. Discussion:
https://postgr.es/m/15943.1552601288@sss.pgh.pa.us
https://git.postgresql.org/pg/commitdiff/de570047993bd5fd65ad2bdf6b0acf5b8939bcb3

- Further reduce memory footprint of CLOBBER_CACHE_ALWAYS testing. Some
buildfarm members using CLOBBER_CACHE_ALWAYS have been having OOM problems of
late. Commit 2455ab488 addressed this problem by recovering space transiently
used within RelationBuildPartitionDesc, but it turns out that leaves quite a
lot on the table, because other subroutines of RelationBuildDesc also leak
memory like mad. Let's move the temp-context management into
RelationBuildDesc so that leakage from the other subroutines is also
recovered. I examined this issue by arranging for postgres.c to dump the size
of MessageContext just before resetting it in each command cycle, and then
running the update.sql regression test (which is one of the two that are
seeing buildfarm OOMs) with and without CLOBBER_CACHE_ALWAYS. Before
2455ab488, the peak space usage with CCA was as much as 250MB. That patch got
it down to ~80MB, but with this patch it's about 0.5MB, and indeed the space
usage now seems nearly indistinguishable from a non-CCA build.
RelationBuildDesc's traditional behavior of not worrying about leaking
transient data is of many years' standing, so I'm pretty hesitant to change
that without more evidence that it'd be useful in a normal build. (So far as I
can see, non-CCA memory consumption is about the same with or without this
change, whuch if anything suggests that it isn't useful.) Hence, configure the
patch so that we recover space only when CLOBBER_CACHE_ALWAYS or
CLOBBER_CACHE_RECURSIVELY is defined. However, that choice can be overridden
at compile time, in case somebody would like to do some performance testing
and try to develop evidence for changing that decision. It's possible that we
ought to back-patch this change, but in the absence of back-branch OOM
problems in the buildfarm, I'm not in a hurry to do that. Discussion:
https://postgr.es/m/CA+TgmoY3bRmGB6-DUnoVy5fJoreiBJ43rwMrQRCdPXuKt4Ykaw@mail.gmail.com
https://git.postgresql.org/pg/commitdiff/d3f48dfae42f9655425d1f58f396e495c7fb7812

- Suppress -Wimplicit-fallthrough warnings in new jsonpath code. Per buildfarm.
See commit 41c912cad for precedent.
https://git.postgresql.org/pg/commitdiff/20f7c3d5606254d8870697f15fd7a7b4e602e1e1

- Further adjust the tests for the hyperbolic functions. It looks like we can
leave in most of the test cases for Infinity/NaN inputs, but buildfarm member
jacana gets the wrong answer for acosh(Inf). It's not worth carrying a variant
expected file for that, so just disable that one test. Discussion:
https://postgr.es/m/E1h3nUY-0000sM-Vf@gemulon.postgresql.org
https://git.postgresql.org/pg/commitdiff/c43ecdee0fff529ca47a90aea0a6954690af045c

Álvaro Herrera pushed:

- Fix documentation on partitioning vs. foreign tables. 1. The PARTITION OF
clause of CREATE FOREIGN TABLE was not explained in the CREATE FOREIGN
TABLE reference page. Add it. (Postgres 10 onwards) 2. The limitation
that tuple routing cannot target partitions that are foreign tables was not
documented clearly enough. Improve wording. (Postgres 10 onwards) 3. The
UPDATE tuple re-routing concurrency behavior was explained in the DDL
chapter, which doesn't seem the right place. Move it to the UPDATE
reference page instead. (Postgres 11 onwards). Authors: Amit Langote, David
Rowley. Reviewed-by: Etsuro Fujita. Reported-by: Derek Hans Discussion:
https://postgr.es/m/CAGrP7a3Xc1Qy_B2WJcgAD8uQTS_NDcJn06O5mtS_Ne1nYhBsyw@mail.gmail.com
https://git.postgresql.org/pg/commitdiff/fc84c05acd151cb1141c47d4af0c5ca803a4c3b4

- Move hash_any prototype from access/hash.h to utils/hashutils.h. ... as well
as its implementation from backend/access/hash/hashfunc.c to
backend/utils/hash/hashfn.c. access/hash is the place for the hash index AM,
not really appropriate for generic facilities, which is what hash_any is;
having things the old way meant that anything using hash_any had to include
the AM's include file, pointlessly polluting its namespace with unrelated,
unnecessary cruft. Also move the HTEqual strategy number to access/stratnum.h
from access/hash.h. To avoid breaking third-party extension code, add an
#include "utils/hashutils.h" to access/hash.h. (An easily removed line by
committers who enjoy their asbestos suits to protect them from angry extension
authors.) Discussion:
https://postgr.es/m/201901251935.ser5e4h6djt2@alvherre.pgsql
https://git.postgresql.org/pg/commitdiff/af38498d4c9b840e0e454574519459edda3871db

Michaël Paquier pushed:

- Adjust error message for partial writes in WAL segments. 93473c6 has removed
openLogOff, changing on the way the error message which is used to report
partial writes to WAL segments. The newly-introduced error message used the
offset up to which the write has happened, keeping always the same total
length to write. This changes the error message so as the number of bytes
left to write are reported. Reported-by: Michael Paquier Author: Robert Haas
Discussion: https://postgr.es/m/20190306235251.GA17293@paquier.xyz
https://git.postgresql.org/pg/commitdiff/f2d84a4a6b4ec891a0a52f583ed5aa081c71acc6

- Add routine able to update the control file to src/common/. This adds a new
routine to src/common/ which is compatible with both the frontend and backend
code, able to update the control file's contents. This is now getting used
only by pg_rewind, but some upcoming patches which add more control on
checksums for offline instances will make use of it. This could also get used
more by the backend as xlog.c has its own flavor of the same logic with some
wait events and an additional flush phase before closing the opened file
descriptor, but this is let as separate work. Author: Michael Banck, Michael
Paquier Reviewed-by: Fabien Coelho, Sergei Kornilov Discussion:
https://postgr.es/m/20181221201616.GD4974@nighthawk.caipicrew.dd-dns.de
https://git.postgresql.org/pg/commitdiff/ce6afc6823fbe2d83a5a77061b05864612b6bab2

- Fix cross-version compatibility checks of pg_verify_checksums.
pg_verify_checksums performs a read of the control file, and the data it
fetches should be from a data folder compatible with the major version of
Postgres the binary has been compiled with, but we never actually checked that
compatibility. Reported-by: Sergei Kornilov Author: Michael Paquier
Reviewed-by: Sergei Kornilov Discussion:
https://postgr.es/m/155231347133.16480.11453587097036807558.pgcf@coridan.postgresql.org
Backpatch-through: 11
https://git.postgresql.org/pg/commitdiff/c9ae7f704c6772a99a456ed50d226c1fdf23f6d7

- Rename pg_verify_checksums to pg_checksums. The current tool name is too
restrictive and focuses only on verifying checksums. As more options to
control checksums for an offline cluster are planned to be added, switch to a
more generic name. Documentation as well as all past references to the tool
are updated. Author: Michael Paquier Reviewed-by: Michael Banck, Fabien
Coelho, Seigei Kornilov Discussion:
https://postgr.es/m/20181221201616.GD4974@nighthawk.caipicrew.dd-dns.de
https://git.postgresql.org/pg/commitdiff/6dd263cfaa8447470af4fae3f61c47438f91d71f

- Add TAP test to check consistency of minimum recovery LSN. c186ba13 has fixed
an issue related to the updates of the minimum recovery LSN across multiple
processes on standbys, but we never really had a test case able to reliably
check its logic. This commit introduces a new test case to close the gap, and
is designed to check the consistency of data based on the minimum recovery
point set by either the startup process or the checkpointer for both an
offline cluster (by looking at the on-disk page headers) and an online cluster
(using pageinspect). Note that with c186ba13 reverted, this test fails badly
for both the online and offline cases, as designed. Author: Michael Paquier,
Andrew Gierth Reviewed-by: Andrew Gierth, Georgios Kokolatos, Arthur Zakirov
Discussion: https://postgr.es/m/20181108044525.GA17482@paquier.xyz
https://git.postgresql.org/pg/commitdiff/b0825d28ea83e44139bd319e6d1db2c499cd4c6a

- Fix race condition in recently-added TAP test for recovery consistency. A
couple of queries are run on the primary to create and fill in a test table,
which gets checked on the standby afterwards. However the test was not
waiting for the confirmation that the necessary records have been replayed on
the standby, leading to spurious failures. Per buildfarm member loach.
Thanks to Thomas Munro for the report and Tom Lane for the failure analysis.
Discussion:
https://postgr.es/m/CA+hUKGLUpqG52xtriUz5RpmeKPoEfNxNc-CginG+Cx+X2-Ycew@mail.gmail.com
https://git.postgresql.org/pg/commitdiff/364298be22090769da14aa749fe730cf16ed3c2c

- Fix thinko when bumping on temporary directories in pg_checksums. This fixes
an oversight from 5c99513. This has no actual consequence as
PG_TEMP_FILE_PREFIX and PG_TEMP_FILES_DIR have the same value so when bumping
on a temporary path the directory scan was still moving on to the next entry
instead of skipping the rest of the scan, but let's keep the logic correct.
Author: Michael Banck Reviewed-by: Kyotaro Horiguchi Discussion:
https://postgr.es/m/20190314.115417.58230569.horiguchi.kyotaro@lab.ntt.co.jp
Backpatch-through: 11
https://git.postgresql.org/pg/commitdiff/6eebfdc38b173edcd179f422cf7083383edb24bc

- Fix typo related to to_tsvector() in tests of json and jsonb. Author: Sho Kato
Reviewed-by: Kyotaro Horiguchi Discussion:
https://postgr.es/m/25C1C6B2E7BE044889E4FE8643A58BA963E1D03D@G01JPEXMBKW03
https://git.postgresql.org/pg/commitdiff/4e197bf19556a1699b0e11e1ff111d77d09f6f80

Peter Eisentraut pushed:

- psql: Add documentation URL to \help output. Add a link to the specific
command's reference web page to the bottom of its \help output. Discussion:
https://www.postgresql.org/message-id/flat/40179bd0-fa7d-4108-1991-a20ae9ad5667%402ndquadrant.com
https://git.postgresql.org/pg/commitdiff/27f3dea64833d68c1fa08c1e5d26176a579f69c8

- Remove unused macro. Use was removed in
25ca5a9a54923a5d6746f771c4c23e85a195bde5.
https://git.postgresql.org/pg/commitdiff/3c067154471100ae691d1a7b2659ee439ab7b96d

- Include all columns in default names for foreign key constraints. When
creating a name for a foreign key constraint when none is specified, use all
column names instead of only the first one, similar to how it is already done
for index names. Author: Paul Martinez <hellopfm(at)gmail(dot)com> Reviewed-by:
Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> Discussion:
https://www.postgresql.org/message-id/flat/CAF+2_SFjky6XRfLNRXpkG97W6PRbOO_mjAxqXzAAimU=c7w7_A(at)mail(dot)gmail(dot)com
https://git.postgresql.org/pg/commitdiff/f177660ab01e53dd5597b195dcc8526baa5cfcbd

- Fix volatile vs. pointer confusion. Variables used after a longjmp() need to
be declared volatile. In case of a pointer, it's the pointer itself that
needs to be declared volatile, not the pointed-to value. So we need
PyObject *volatile items; instead of volatile PyObject *items; /* wrong
*/ Discussion:
https://www.postgresql.org/message-id/flat/f747368d-9e1a-c46a-ac76-3c27da32e8e4%402ndquadrant.com
https://git.postgresql.org/pg/commitdiff/1226d932b4dadc39ba2f9a488e4d784443ea6a78

- Refactor ParamListInfo initialization. There were six copies of identical
nontrivial code. Put it into a function.
https://git.postgresql.org/pg/commitdiff/c6ff0b892c30122b75d32c524109d16ee3c973f0

- Add BKI_DEFAULT to pg_class.relrewrite. This column is always 0 on disk, so it
doesn't have to be tracked separately for each entry.
https://git.postgresql.org/pg/commitdiff/b13a913607b9b304d16029361b1b17e10783cf7c

- Remove unused #include.
https://git.postgresql.org/pg/commitdiff/8bee36708f6ee4bf93be68f9a368379b0e9c6474

- Improve code comment.
https://git.postgresql.org/pg/commitdiff/61dc407893600f551dbcbc235d1dccd134f43da0

- Reorder identity regression test. The previous test order had the effect that
if something was wrong with the identity functionality, the create_table_like
test would likely fail or crash first, which is confusing. Reorder so that
the identity test comes before create_table_like.
https://git.postgresql.org/pg/commitdiff/2fadf24e249bd72fc517663a91a233437460671c

- Add walreceiver API to get remote server version. Add a separate walreceiver
API function walrcv_server_version() to get the version of the remote server,
instead of doing it as part of walrcv_identify_system(). This allows the
server version to be available even for uses that don't call IDENTIFY_SYSTEM,
and it seems cleaner anyway. This is for an upcoming patch, not currently
used. Reviewed-by: Michael Paquier <michael(at)paquier(dot)xyz> Discussion:
https://www.postgresql.org/message-id/20190115071359.GF1433@paquier.xyz
https://git.postgresql.org/pg/commitdiff/69039fda837d7a9c78e42b9dd5291d454e71f460

- PL/Tcl: Improve trigger tests organization. The trigger tests for PL/Tcl were
spread aroud pltcl_setup.sql and pltcl_queries.sql, mixed with other tests,
which makes them hard to follow and edit. Move all the trigger-related pieces
to a new file pltcl_trigger.sql. This also makes the test setup more similar
to plperl and plpython.
https://git.postgresql.org/pg/commitdiff/aefcc2bba211b738b3dd3cb393d9cdfcbcdc83cd

- Don't propagate PGAPPNAME through pg_ctl in tests. When libpq is loaded in the
server (for instance, by libpqwalreceiver), it may use libpq environment
variables set in the postmaster environment for connection parameter defaults.
This has some confusing effects in our test suites. For example, the TAP test
infrastructure sets PGAPPNAME to allow identifying clients in the server log.
But this environment variable is also inherited by temporary servers started
with pg_ctl and is then in turn used by libpqwalreceiver as the
application_name for connecting to remote servers where it then shows up in
pg_stat_replication and is relevant for things like synchronous_standby_names.
Replication already has a suitable default for application_name, and
overriding that accidentally then requires the individual test cases to
re-override that, which is all very confusing and unnecessary. To fix, unset
PGAPPNAME temporarily before running pg_ctl start or restart in the tests.
More comprehensive approaches like unsetting all environment variables in
pg_ctl were considered but might be too complicated to achieve portably. The
now unnecessary re-overriding of application_name by test cases is also
removed. Reviewed-by: Noah Misch <noah(at)leadboat(dot)com> Discussion:
https://www.postgresql.org/message-id/flat/33383613-690e-6f1b-d5ba-4957ff40f6ce(at)2ndquadrant(dot)com
https://git.postgresql.org/pg/commitdiff/8e93a516e68bac3c329fd2e7f423ee9aceca943a

- Avoid casting away a const.
https://git.postgresql.org/pg/commitdiff/893d6f8a1f9b43da805124e93cbf0f7aea890ad4

- Remove another unnecessary application_name specification in test. see
8e93a516e68bac3c329fd2e7f423ee9aceca943a
https://git.postgresql.org/pg/commitdiff/0176eb210e445e8a911c7df79997c7ab62e86dcc

- Add support for collation attributes on older ICU versions. Starting in ICU
54, collation customization attributes can be specified in the locale string,
for example "@colStrength=primary;colCaseLevel=yes". Add support for this for
older ICU versions as well, by adding some minimal parsing of the attributes
in the locale string and calling ucol_setAttribute() on them. This is
essentially what never ICU versions do internally in ucol_open(). This was we
can offer this functionality in a consistent way in all ICU versions supported
by PostgreSQL. Also add some tests for ICU collation customization.
Reported-by: Daniel Verite <daniel(at)manitou-mail(dot)org> Discussion:
https://www.postgresql.org/message-id/0270ebd4-f67c-8774-1a5a-91adfb9bb41f@2ndquadrant.com
https://git.postgresql.org/pg/commitdiff/b8f9a2a69a279d118e366a0d3d45caa84a7620b1

Michael Meskes pushed:

- Fix ecpglib regression that made it impossible to close a cursor that
was.opened in a prepared statement. Patch by: "Kuroda, Hayato"
<kuroda(dot)hayato(at)jp(dot)fujitsu(dot)com>
https://git.postgresql.org/pg/commitdiff/98bdaab0d918169a36d64a06667a809c673ec065

- Fix potential memory access violation in ecpg if filename of include file
is.shorter than 2 characters. Patch by: "Wu, Fei" <wufei(dot)fnst(at)cn(dot)fujitsu(dot)com>
https://git.postgresql.org/pg/commitdiff/08cecfaf60c484f219ba7e6ee23e9699aea4e9af

- Use correct connection name variable in ecpglib. Fixed-by: Kuroda-san
<kuroda(dot)hayato(at)jp(dot)fujitsu(dot)com>
https://git.postgresql.org/pg/commitdiff/c21d6033f77353623f8642c5541e0d002d986f59

Andres Freund pushed:

- Fix typos in commit 8586bf7ed8. Author: Amit Kapila Discussion:
https://postgr.es/m/CAA4eK1KNv1Mg2krf4E9ssWFnE=8A9mZ1VbVywXBZTFSzb+wP2g@mail.gmail.com
https://git.postgresql.org/pg/commitdiff/a6e48da08844eeb5a72c8b59dad3aaab6e891fac

- tableam: Add and use scan APIs. Too allow table accesses to be not directly
dependent on heap, several new abstractions are needed. Specifically: 1) Heap
scans need to be generalized into table scans. Do this by introducing
TableScanDesc, which will be the "base class" for individual AMs. This
contains the AM independent fields from HeapScanDesc. The previous
heap_{beginscan,rescan,endscan} et al. have been replaced with a table_
version. There's no direct replacement for heap_getnext(), as that
returned a HeapTuple, which is undesirable for a other AMs. Instead there's
table_scan_getnextslot(). But note that heap_getnext() lives on, it's
still used widely to access catalog tables. This is achieved by new
scan_begin, scan_end, scan_rescan, scan_getnextslot callbacks. 2) The
portion of parallel scans that's shared between backends need to be able to
do so without the user doing per-AM work. To achieve that new
parallelscan_{estimate, initialize, reinitialize} callbacks are introduced,
which operate on a new ParallelTableScanDesc, which again can be subclassed
by AMs. As it is likely that several AMs are going to be block oriented,
block oriented callbacks that can be shared between such AMs are provided
and used by heap. table_block_parallelscan_{estimate, intiialize,
reinitialize} as callbacks, and table_block_parallelscan_{nextpage, init}
for use in AMs. These operate on a ParallelBlockTableScanDesc. 3) Index
scans need to be able to access tables to return a tuple, and there needs
to be state across individual accesses to the heap to store state like
buffers. That's now handled by introducing a sort-of-scan IndexFetchTable,
which again is intended to be subclassed by individual AMs (for heap
IndexFetchHeap). The relevant callbacks for an AM are index_fetch_{end,
begin, reset} to create the necessary state, and index_fetch_tuple to
retrieve an indexed tuple. Note that index_fetch_tuple implementations
need to be smarter than just blindly fetching the tuples for AMs that have
optimizations similar to heap's HOT - the currently alive tuple in the
update chain needs to be fetched if appropriate. Similar to
table_scan_getnextslot(), it's undesirable to continue to return
HeapTuples. Thus index_fetch_heap (might want to rename that later) now
accepts a slot as an argument. Core code doesn't have a lot of call sites
performing index scans without going through the systable_* API (in
contrast to loads of heap_getnext calls and working directly with
HeapTuples). Index scans now store the result of a search in
IndexScanDesc->xs_heaptid, rather than xs_ctup->t_self. As the target is
not generally a HeapTuple anymore that seems cleaner. To be able to sensible
adapt code to use the above, two further callbacks have been introduced: a)
slot_callbacks returns a TupleTableSlotOps* suitable for creating slots
capable of holding a tuple of the AMs type. table_slot_callbacks() and
table_slot_create() are based upon that, but have additional logic to deal
with views, foreign tables, etc. While this change could have been done
separately, nearly all the call sites that needed to be adapted for the
rest of this commit also would have been needed to be adapted for
table_slot_callbacks(), making separation not worthwhile. b)
tuple_satisfies_snapshot checks whether the tuple in a slot is currently
visible according to a snapshot. That's required as a few places now don't
have a buffer + HeapTuple around, but a slot (which in heap's case
internally has that information). Additionally a few infrastructure changes
were needed: I) SysScanDesc, as used by systable_{beginscan, getnext} et al.
now internally uses a slot to keep track of tuples. While
systable_getnext() still returns HeapTuples, and will so for the
foreseeable future, the index API (see 1) above) now only deals with slots.
The remainder, and largest part, of this commit is then adjusting all scans in
postgres to use the new APIs. Author: Andres Freund, Haribabu Kommi, Alvaro
Herrera Discussion:
https://postgr.es/m/20180703070645.wchpu5muyto5n647@alap3.anarazel.de
https://postgr.es/m/20160812231527.GA690404@alvherre.pgsql
https://git.postgresql.org/pg/commitdiff/c2fe139c201c48f1133e9fbea2dd99b8efe2fadd

- Ensure sufficient alignment for ParallelTableScanDescData in BTShared.
Previously ParallelTableScanDescData was just a member in BTShared, but after
c2fe139c2 that doesn't guarantee sufficient alignment as specific AMs might
(are likely to) need atomic variables in the struct. One might think that
MAXALIGNing would be sufficient, but as a comment in shm_toc_allocate()
explains, that's not enough. For now, copy the hack described there. For
parallel sequential scans no such change is needed, as its allocations go
through shm_toc_allocate(). An alternative approach would have been to
allocate the parallel scan descriptor in a separate TOC entry, but there seems
little benefit in doing so. Per buildfarm member dromedary. Author: Andres
Freund Discussion:
https://postgr.es/m/20190311203126.ty5gbfz42gjbm6i6@alap3.anarazel.de
https://git.postgresql.org/pg/commitdiff/8cacea7a725103f1a037a5ee06112ebe31051c66

- Remove spurious return. Per buildfarm member anole. Author: Andres Freund
https://git.postgresql.org/pg/commitdiff/32b8f0b0332ef96c67f06ded4d458a3ce12fe2ef

Andrew Dunstan pushed:

- pgbench: increase the maximum number of variables/arguments. pgbench's
arbitrary limit of 10 arguments for SQL statements or metacommands is far too
low. Increase it to 256. This results in a very modest increase in memory
usage, not enough to worry about. The maximum includes the SQL statement or
metacommand. This is reflected in the comments and revised TAP tests. Simon
Riggs and Dagfinn Ilmari Mannsåker with some light editing by me. Reviewed by:
David Rowley and Fabien Coelho Discussion:
https://postgr.es/m/CANP8+jJiMJOAf-dLoHuR-8GENiK+eHTY=Omw38Qx7j2g0NDTXA@mail.gmail.com
https://git.postgresql.org/pg/commitdiff/a47841528107921f02c280e0c5f91c5a1d86adb0

- Document incompatibility of comparison expressions with VARIADIC array
arguments. COALESCE, GREATEST and LEAST all look like functions taking
variable numbers of arguments, but in fact they are not functions, and so
VARIADIC array arguments don't work with them. Add a note to the docs
explaining this fact. The consensus is not to try to make this work, but just
to document the limitation. Discussion:
https://postgr.es/m/CAFj8pRCaAtuXuRtvXf5GmPbAVriUQrNMo7-=TXUFN025S31R_w@mail.gmail.com
https://git.postgresql.org/pg/commitdiff/5e74a427854fa17babfbb0e22c4ca95e4f48f2fe

- Tweak wording on VARIADIC array doc patch. Per suggestion from Tom Lane.
https://git.postgresql.org/pg/commitdiff/fe0b2c12c992fa44ca0448bde9099957306c843f

Amit Kapila pushed:

- Add more tests for FSM. In commit b0eaa4c51bb, we left out a test that used a
vacuum to remove dead rows as the behavior of test was not predictable. This
test has been rewritten to use fillfactor instead to control free space.
Since we no longer need to remove dead rows as part of the test, put the fsm
regression test in a parallel group. Author: John Naylor Reviewed-by: Amit
Kapila Discussion:
https://postgr.es/m/CAA4eK1L=qWp_bJ5aTc9+fy4Ewx2LPaLWY-RbR4a60g_rupCKnQ@mail.gmail.com
https://git.postgresql.org/pg/commitdiff/6f918159a97acf76ee2512e44f5ed5dcaaa0d923

- During pg_upgrade, conditionally skip transfer of FSMs. If a heap on the old
cluster has 4 pages or fewer, and the old cluster was PG v11 or earlier, don't
copy or link the FSM. This will shrink space usage for installations with
large numbers of small tables. This will allow pg_upgrade to take advantage
of commit b0eaa4c51b where we have avoided creation of the free space map for
small heap relations. Author: John Naylor Reviewed-by: Amit Kapila
Discussion:
https://postgr.es/m/CACPNZCu4cOdm3uGnNEGXivy7Gz8UWyQjynDpdkPGabQ18_zK6g%40mail.gmail.com
https://git.postgresql.org/pg/commitdiff/13e8643bfc29d3c1455c0946281cdfc24758ffb6

- Improve code comments in b0eaa4c51b. Author: John Naylor Discussion:
https://postgr.es/m/CACPNZCswjyGJxTT=mxHgK=Z=mJ9uJ4WEx_UO=bNwpR_i0EaHHg@mail.gmail.com
https://git.postgresql.org/pg/commitdiff/06c8a5090ed9ec188557a86d4de11384f5128ec0

- Update copyright year in files added by 1bb5e78218.
https://git.postgresql.org/pg/commitdiff/f27314ff9a0eb60b75bb576c3629c8849f7698c1

Etsuro Fujita pushed:

- Fix testing of parallel-safety of scan/join target. In commit 960df2a971
("Correctly assess parallel-safety of tlists when SRFs are used."), the
testing of scan/join target was done incorrectly, which caused a plan-quality
problem. Backpatch through to v11 where the aforementioned commit went in,
since this is a regression from v10. Author: Etsuro Fujita Reviewed-by:
Robert Haas and Tom Lane Discussion:
https://postgr.es/m/5C75303E.8020303@lab.ntt.co.jp
https://git.postgresql.org/pg/commitdiff/b5afdde6a7bb777d399b20da6fb8a664a1cd2784

Peter Geoghegan pushed:

- Correct obsolete nbtree page split comment. Commit 40dae7ec537, which made the
nbtree page split algorithm more robust, made _bt_insert_parent() only unlock
the right child of the parent page before inserting a new downlink into the
parent. Update a comment from the Berkeley days claiming that both left and
right child pages are unlocked before the new downlink actually gets inserted.
The claim that it is okay to release both locks early based on Lehman and
Yao's say-so never made much sense. Lehman and Yao must sometimes "couple"
buffer locks across a pair of internal pages when relocating a downlink,
unlike the corresponding code within _bt_getstack().
https://git.postgresql.org/pg/commitdiff/3f34283973a342aa1cb709d6e8f5cea430efcf29

Magnus Hagander pushed:

- Remove extra comma. Author: Christoph Berg <myon(at)debian(dot)org>
https://git.postgresql.org/pg/commitdiff/95fa9f1a137fcb55ed418d8c91a315c7bb169979

Robert Haas pushed:

- Allow ALTER TABLE .. SET NOT NULL to skip provably unnecessary scans. If
existing CHECK or NOT NULL constraints preclude the presence of nulls, we need
not look to see whether any are present. Sergei Kornilov, reviewed by Stephen
Frost, Ildar Musin, David Rowley, and by me. Discussion:
http://postgr.es/m/81911511895540@web58j.yandex.ru
https://git.postgresql.org/pg/commitdiff/bbb96c3704c041d139181c6601e5bc770e045d26

- Revert setting client_min_messages to 'debug1' in new tests. The buildfarm
doesn't like this, because some buildfarm members have log_statement = 'all'.
We could change the log level of the messages instead, but Tom doesn't like
that. So let's do this instead, at least for now. Patch by Sergei Kornilov,
applied here in reverse. Discussion:
http://postgr.es/m/2123251552490241@myt6-fe24916a5562.qloud-c.yandex.net
https://git.postgresql.org/pg/commitdiff/5655565c077c53b6e9b4b9bfcdf96439cf3af065

- Defend against leaks into RelationBuildPartitionDesc. In normal builds, this
isn't very important, because the leaks go into fairly short-lived contexts,
but under CLOBBER_CACHE_ALWAYS, this can result in leaking hundreds of
megabytes into MessageContext, which probably explains recent failures on
hyrax. This may or may not be the best long-term strategy for dealing with
this leak, but we can change it later if we come up with something better.
For now, do this to make the buildfarm green again (hopefully). Commit
898e5e3290a72d288923260143930fb32036c00c seems to have exacerbated this
problem for reasons that are not quite clear, but I don't believe it's
actually the cause. Discussion:
http://postgr.es/m/CA+TgmoY3bRmGB6-DUnoVy5fJoreiBJ43rwMrQRCdPXuKt4Ykaw@mail.gmail.com
https://git.postgresql.org/pg/commitdiff/2455ab48844c90419714e27eafd235a85de23232

Thomas Munro pushed:

- Use condition variables to wait for checkpoints. Previously we used a
polling/sleeping loop to wait for checkpoints to begin and end, which leads to
up to a couple hundred milliseconds of needless thumb-twiddling. Use
condition variables instead. Author: Thomas Munro Reviewed-by: Andres Freund
Discussion:
https://postgr.es/m/CA%2BhUKGLY7sDe%2Bbg1K%3DbnEzOofGoo4bJHYh9%2BcDCXJepb6DQmLw%40mail.gmail.com
https://git.postgresql.org/pg/commitdiff/c6c9474aafa4de357ae424cd18b69e8bf7a4babe

- Enable parallel query with SERIALIZABLE isolation. Previously, the
SERIALIZABLE isolation level prevented parallel query from being used. Allow
the two features to be used together by sharing the leader's SERIALIZABLEXACT
with parallel workers. An extra per-SERIALIZABLEXACT LWLock is introduced to
make it safe to share, and new logic is introduced to coordinate the early
release of the SERIALIZABLEXACT required for the SXACT_FLAG_RO_SAFE
optimization, as follows: The first backend to observe the SXACT_FLAG_RO_SAFE
flag (set by some other transaction) will 'partially release' the
SERIALIZABLEXACT, meaning that the conflicts and locks it holds are released,
but the SERIALIZABLEXACT itself will remain active because other backends
might still have a pointer to it. Whenever any backend notices the
SXACT_FLAG_RO_SAFE flag, it clears its own MySerializableXact variable and
frees local resources so that it can skip SSI checks for the rest of the
transaction. In the special case of the leader process, it transfers the
SERIALIZABLEXACT to a new variable SavedSerializableXact, so that it can be
completely released at the end of the transaction after all workers have
exited. Remove the serializable_okay flag added to CreateParallelContext() by
commit 9da0cc35, because it's now redundant. Author: Thomas Munro
Reviewed-by: Haribabu Kommi, Robert Haas, Masahiko Sawada, Kevin Grittner
Discussion:
https://postgr.es/m/CAEepm=0gXGYhtrVDWOTHS8SQQy_=S9xo+8oCxGLWZAOoeJ=yzQ@mail.gmail.com
https://git.postgresql.org/pg/commitdiff/bb16aba50c9492490a0b57e600a932798f45cd4f

Alexander Korotkov pushed:

- Partial implementation of SQL/JSON path language. SQL 2016 standards among
other things contains set of SQL/JSON features for JSON processing inside of
relational database. The core of SQL/JSON is JSON path language, allowing
access parts of JSON documents and make computations over them. This commit
implements partial support JSON path language as separate datatype called
"jsonpath". The implementation is partial because it's lacking datetime
support and suppression of numeric errors. Missing features will be added
later by separate commits. Support of SQL/JSON features requires
implementation of separate nodes, and it will be considered in subsequent
patches. This commit includes following set of plain functions, allowing to
execute jsonpath over jsonb values: * jsonb_path_exists(jsonb, jsonpath[,
jsonb, bool]), * jsonb_path_match(jsonb, jsonpath[, jsonb, bool]), *
jsonb_path_query(jsonb, jsonpath[, jsonb, bool]), *
jsonb_path_query_array(jsonb, jsonpath[, jsonb, bool]). *
jsonb_path_query_first(jsonb, jsonpath[, jsonb, bool]). This commit also
implements "jsonb @? jsonpath" and "jsonb @@ jsonpath", which are wrappers
over jsonpath_exists(jsonb, jsonpath) and jsonpath_predicate(jsonb, jsonpath)
correspondingly. These operators will have an index support (implemented in
subsequent patches). Catversion bumped, to add new functions and operators.
Code was written by Nikita Glukhov and Teodor Sigaev, revised by me.
Documentation was written by Oleg Bartunov and Liudmila Mantrova. The work
was inspired by Oleg Bartunov. Discussion:
https://postgr.es/m/fcc6fc6a-b497-f39a-923d-aa34d0c588e8%402ndQuadrant.com
Author: Nikita Glukhov, Teodor Sigaev, Alexander Korotkov, Oleg Bartunov,
Liudmila Mantrova Reviewed-by: Tomas Vondra, Andrew Dunstan, Pavel Stehule,
Alexander Korotkov
https://git.postgresql.org/pg/commitdiff/72b6460336e86ad5cafd3426af6013c7d8457367

- Numeric error suppression in jsonpath. Add support of numeric error
suppression to jsonpath as it's required by standard. This commit doesn't use
PG_TRY()/PG_CATCH() in order to implement that. Instead, it provides internal
versions of numeric functions used, which support error suppression.
Discussion:
https://postgr.es/m/fcc6fc6a-b497-f39a-923d-aa34d0c588e8%402ndQuadrant.com
Author: Alexander Korotkov, Nikita Glukhov Reviewed-by: Tomas Vondra
https://git.postgresql.org/pg/commitdiff/16d489b0fe058e527619f5e9d92fd7ca3c6c2994

- Fix compiler warning in jsonpath_exec.c. Warning was observed in gcc 4.4.6,
gcc 4.4.7 and probably others. Reported-by: Tom Lane Discussion:
https://postgr.es/m/25151.1552751426%40sss.pgh.pa.us
https://git.postgresql.org/pg/commitdiff/042162d6281a7daf1291931ee7b0a5641d3a73d7

- Fix make rules for jsonpath grammar making them similar to SQL grammar.
Reported-by: Jeff Janes, Tom Lane Discussion:
https://postgr.es/m/CAMkU%3D1w1qBvoW82ZTFpAKae027R-2OHw-m6ALe0VQRNAFueBVA%40mail.gmail.com
https://git.postgresql.org/pg/commitdiff/142c400d72f77e7249306b80e0149f4fd35c6304

- Remove some make rules added in 142c400d72. Because they fail build of
jsonpath_scan.c.
https://git.postgresql.org/pg/commitdiff/c183a07f279d1fba8ccea1baf7210e8fafbaa097

- Apply const qualifier to keywords of jsonpath_scan.l. Discussion:
https://postgr.es/m/CAEeOP_a-Pfy%3DU9-f%3DgQ0AsB8FrxrC8xCTVq%2BeO71-2VoWP5cag%40mail.gmail.com
Author: Mark G
https://git.postgresql.org/pg/commitdiff/aa1b7f386687dec17ffa62d13026580050734632

- Beautify initialization of JsonValueList and JsonLikeRegexContext. Instead of
tricky assignment to {0} introduce special macros, which explicitly initialize
every field.
https://git.postgresql.org/pg/commitdiff/4178d8b91cb943b422d1837b4b7798576d88995a

== Pending Patches ==

Dmitry Dolgov sent in a patch to use NULL as an empty value for owner, defn and
dropStmt in ArchiveEntry.

Nikita Glukhov sent in a patch to add the missing <-> for box and point.

Masahiko Sawada sent in another revision of a patch to add a copy function for
replication slots.

Noah Misch sent in another revision of a patch to fix a bug that manifested as a
WAL logging problem in 9.4.3.

Peter Eisentraut sent in another revision of a patch to add a test case for keys
that "look" different but compare as equal, and fix the optimization of
foreign-key on update actions.

Dagfinn Ilmari Mannsåker sent in a patch for pgbench to increase the maximum
number of variables/arguments.

Karl O. Pinc sent in another revision of a patch to document base64.

Peter Eisentraut sent in a patch to add tests for ICU collation customization,
and add support for collation attributes on older ICU versions.

Andrew Dunstan sent in a patch to document the fact that while GREATEST, LEAST,
and COALESCE appear function-like, they are not functions and do not take
VARIADIC parameters.

Dean Rasheed sent in a patch to provide implementations of asinh, acosh, and
atanh for platforms where they're not provided.

Amit Langote and Michaël Paquier traded patches to fix a bug which caused a
server crash in transformPartitionRangeBounds.

Heikki Linnakangas and Andrey Borodin traded patches to implement GiST vacuum.

Haribabu Kommi and Andres Freund traded patches to separate the infrastructure
for table access methods from the current implementation as heap.

Peter Geoghegan and Heikki Linnakangas traded patches to make all nbtree entries
unique by having heap TIDs participate in comparisons.

Michaël Paquier, Fabien COELHO, and Michael Banck traded patches to enable
offline enabling/disabling of data checksums.

Andrew Dunstan sent in a patch to add a compress_tuple_target GUC to specify the
minimum tuple length required before trying to compress columns marked as
Extended or Main. It applies only to new tuples.

Thomas Munro sent in another revision of a patch to clean up orphaned files
using undo logs.

Kirk Jamison sent in a patch to use optional vacuumdb environment variables to
pass vacuumdb options.

Jesper Pedersen sent in a patch to highlight the fact that the --jobs option
isn't passed down to vacuumdb.

Jie Zhang sent in a patch to remove repetitive characters from fdwhandler.sgml.

Nikita Glukhov sent in another revision of a patch to implement BRIN multi-range
indexes.

Tomáš Vondra sent in another revision of a patch to fix a performance issue in
remove_from_unowned_list().

Thomas Munro sent in a patch to use condition variables to wait for checkpoints.

Michaël Paquier sent in two revisions of a patch to fix pg_rewind for promoted
subscribers.

Michael Banck sent in another revision of a patch to add progress reporting for
pg_verify_checksums.

Evgeniy Efimkin sent in two more revisions of a patch to add a role for
subscriptions.

Amit Langote sent in two more revisions of a patch to speed up planning with
partitions.

Sergei Kornilov sent in another revision of a patch to make ALTER TABLE ...
SET ... NOT NULL more efficient by using CHECK constraints or indexes if
available, falling back to a full table scan if not.

Fabien COELHO sent in a patch to cache an expensive computation in pgbench's
Zipfian distribution generator.

David Rowley sent in a patch to document the fact that the current
implementation of partitioning does not scale well, planning-wise, for over a
few hundred partitions, and can overrun available memory.

Julien Rouhaud sent in a patch to add a pg_stat_checksum view.

Paul Ramsey sent in another revision of a patch to implement compressed TOAST
slicing.

Amit Langote sent in another revision of a patch to add \dP (partitions) to
psql.

Peter Eisentraut and Kyotaro HORIGUCHI traded patches to fix handling of
unlogged tables in FOR ALL TABLES publications.

Robert Haas and Masahiko Sawada traded patches to refactor the /ad hoc/ VACUUM
options into the usual key-value pairs used for other commands.

David Rowley sent in another revision of a patch to fix inadequate executor
locking of indexes.

Dagfinn Ilmari Mannsåker sent in a patch to use the return value of strlcpy()
and strlcat().

Heikki Linnakangas sent in a patch to add SparseBitset, which is designed to
hold a large set of 64-bit ints efficiently, and use same to refactor Andrey
Borodin's test_blockset tool.

Maxence Ahlouche sent in a patch to make n_distinct more readable in cases where
it's estimated to be negative.

Peter Eisentraut sent in another revision of a patch to implement REINDEX
CONCURRENTLY.

Robert Haas and Amit Langote traded patches to fix a memory leak in
RelationBuildPartitionDesc, which is called frequently enough for that to become
a problem.

Ryo Matsumura sent in another revision of a patch to fix PREPARE in ECPG.

Shawn Debnath and Kyotaro HORIGUCHI traded patches to introduce a timeout
capability for ConditionVariableSleep.

Tomáš Vondra sent in five more revisions of a patch to implement multivariate
histograms and MCV lists.

Takuma Hoshiai sent in a patch to ensure that the to_reg* functions return null
rather than throwing an error if the name is not found.

John Naylor sent in a patch to remove an outdated reference to tuple header
OIDs.

Nikita Glukhov sent in another revision of a patch to add kNN capability to
B-Tree indexes.

Antonin Houska sent in another revision of a patch to add infrastructure for
encryption at rest.

Amit Kapila and John Naylor traded patches to skip transferring the FSMs of
small tables during pg_upgrade.

Peter Eisentraut sent in a patch to prevent propagating PGAPPNAME through pg_ctl
in tests.

Dmitry Dolgov sent in two more revisions of a patch to add index skip scans
a.k.a. loose index scans.

Edmund Horner sent in another revision of a patch to add a selectivity estimate
for CTID system variables, support backward scans over restricted ranges in heap
access method, which is needed for backward TID scans, reduce the density of the
last page by 0.5, and support range qualifiers in TID scans.

Haribabu Kommi sent in another revision of a patch to change the recommended
value of log_file_mode is 0640 to allow reading of log files by the members of
the same group.

Kato Sho sent in two revisions of a patch to fix a typo in the comments in the
test for tsvector.

Yuzuko Hosoya sent in another revision of a patch to fix partition-pruning with
default partitions.

Ivan Kartyshov sent in another revision of a patch to add custom compression
methods.

Etsuro Fujita sent in another revision of a patch to fix an issue which caused
EvalPlanQual to behave oddly for FDW queries involving system columns.

Michael Kefeder sent in a patch to add GTIN14 support to contrib/isn.

David Rowley sent in two more revisions of a patch to allow Append to be used in
place of MergeAppend for some cases.

Sergei Kornilov sent in a patch to lower the ereport level for
QueuePartitionConstraintValidation from INFO to DEBUG1.

Stephen Frost sent in another revision of a patch to add GSSAPI encryption
support.

Zheng Li sent in a patch to transform NOT IN into an anti-JOIN in some of the
cases where they're equivalent.

Euler Taveira de Oliveira sent in another revision of a patch to make pg_restore
supports stdout with the --file option.

Michaël Paquier sent in two revisions of a patch to make pg_checksums complain
if compiled BLCKSZ and data folder's block size differ.

Alexander Korotkov sent in a patch to add GIN support for the @@ and @? jsonpath
operators.

Ramanarayana sent in another revision of a patch to fix contrib/unaccent on
Windows.

Arseny Sher sent in another revision of a patch to allow parallel workers while
backends are alive in 'smart' shutdown.

Chris Travers sent in another revision of a patch to create a data-only option
for pg_rewind.

Tom Lane sent in a patch to fix checkpoint request waits.

Andrew Gierth sent in a patch to add OR REPLACE as an option to CREATE
AGGREGATE.