== PostgreSQL Weekly News - January 22 2017 ==

== PostgreSQL Weekly News - January 22 2017 ==

== PostgreSQL Jobs for January ==

http://archives.postgresql.org/pgsql-jobs/2017-01/

== PostgreSQL Local ==

PGConf India 2017 will be on March 2-3, 2017 in Bengaluru, Karnataka.
http://pgconf.in/

PostgreSQL(at)SCaLE will take place on March 2-3, 2017, at Pasadena Convention
Center, as part of SCaLE 15X.
http://www.socallinuxexpo.org/scale/15x/

PgConf.Russia 2017 will take place on 15-17 March 2017 in Moscow.
https://pgconf.ru/en

PGDay Asia 2017 will be held March 17-18 in Singapore.
http://tinyurl.com/pgDay-Asia-2017-Cfp

Nordic PGDay 2017 will be held in Stockholm, Sweden, at the Sheraton
Hotel, on March 21, 2017.
https://2017.nordicpgday.org/

pgDay Paris 2017 will be held in Paris, France on March 23, 2017.
http://2017.pgday.paris/

PGConf US 2017 CfP will be on March 28-31 in Jersey City, New Jersey.
http://www.pgconf.us/2017/

PGCon 2017 will take place in Ottawa on 23-26 May. Proposals are due by
19 Jan 2017.
http://www.pgcon.org/2017/papers.php

== PostgreSQL in the News ==

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

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

Submit news and announcements by Sunday at 3:00pm Pacific time.
Please send English language ones to david(at)fetter(dot)org, German language
to pwn(at)pgug(dot)de, Italian language to pwn(at)itpug(dot)org(dot)

== Applied Patches ==

Fujii Masao pushed:

- Fix typos in comments. Masahiko Sawada
http://git.postgresql.org/pg/commitdiff/8fa6019b405f9d39539a77c6f5f11fe640ddf955

- Fix an assertion failure related to an exclusive backup. Previously multiple
sessions could execute pg_start_backup() and pg_stop_backup() to start and
stop an exclusive backup at the same time. This could trigger the assertion
failure of "FailedAssertion("!(XLogCtl->Insert.exclusiveBackup)". This
happend because, even while pg_start_backup() was starting an exclusive
backup, other session could run pg_stop_backup() concurrently and mark the
backup as not-in-progress unconditionally. This patch introduces
ExclusiveBackupState indicating the state of an exclusive backup. This state
is used to ensure that there is only one session running pg_start_backup() or
pg_stop_backup() at the same time, to avoid the assertion failure. Back-patch
to all supported versions. Author: Michael Paquier Reviewed-By: Kyotaro
Horiguchi and me Reported-By: Andreas Seltenreich Discussion:
<87mvktojme(dot)fsf(at)credativ(dot)de>
http://git.postgresql.org/pg/commitdiff/974ece58bbb3c0ef185a9d44b1cedae51cd56b04

- Add description of temporary column into pg_replication_slots doc. Ayumi
Ishii
http://git.postgresql.org/pg/commitdiff/954737095061e5b5f1d87fb8cc43f7f8afff64c6

Magnus Hagander pushed:

- Make pg_basebackup use temporary replication slots. Temporary replication
slots will be used by default when wal streaming is used and no slot name is
specified with -S. If a slot name is specified, then a permanent slot with
that name is used. If --no-slot is specified, then no permanent or temporary
slot will be used. Temporary slots are only used on 10.0 and newer, of
course.
http://git.postgresql.org/pg/commitdiff/e7b020f786bf3b344f81d70aa423525fd4f44dfa

- Fix incorrect comparison due to bad merge. Noted by Fujii Masao
http://git.postgresql.org/pg/commitdiff/fcf708623e860b7a1efef11a5d5661900307b6fc

- Add compression support to pg_receivexlog. Author: Michael Paquier, review
and small changes by me
http://git.postgresql.org/pg/commitdiff/cada1af31d769a6b607018d68894f2c879ff275f

- Implement array version of jsonb_delete and operator. This makes it possible
to delete multiple keys from a jsonb value by passing in an array of text
values, which makes the operaiton much faster than individually deleting the
keys (which would require copying the jsonb structure over and over again.
Reviewed by Dmitry Dolgov and Michael Paquier
http://git.postgresql.org/pg/commitdiff/d00ca333c338b40911e89939c3cc771025978595

Tom Lane pushed:

- Fix NULL pointer dereference in tuplesort.c. Oversight in commit e94568ecc.
This could cause a crash when an external datum tuplesort of a pass-by-value
type required multiple passes. Per report from Mithun Cy. Peter Geoghegan
Discussion:
https://postgr.es/m/CAD__OujuhfWFULGFSt1fyHqUb8N-XafjJhudwt88V0Qs2o84qg@mail.gmail.com
http://git.postgresql.org/pg/commitdiff/4e46c97fde42fa8ca57d29b9b47f2ebd11ab8105

- Fix check_srf_call_placement() to handle VALUES cases correctly. INSERT ...
VALUES with a single VALUES row is implemented quite differently from the
general VALUES case. A user-visible implication of that is that we accept
SRFs in the single-row case, but not in the multi-row case. That's a
historical artifact no doubt, but in view of the lack of field complaints, I'm
not excited about fixing it right now. However, check_srf_call_placement()
needs to know about this, first because it should throw an error in the
unsupported case, and second because it should set p_hasTargetSRFs in the
single-row case (because we treat that like a SELECT tlist). That's an
oversight in commit a4c35ea1c. To fix, split EXPR_KIND_VALUES into two
values. So far as I can see, this is the only place where we need to
distinguish the two cases at present; but there might be more later. Patch by
me, per report from Andres Freund. Discussion:
https://postgr.es/m/20170116081548.zg63zltblwimpfgp@alap3.anarazel.de
http://git.postgresql.org/pg/commitdiff/d43a619c60405ecda275ca9e3ac9ead242e20ecb

- Improve RLS planning by marking individual quals with security levels. In an
RLS query, we must ensure that security filter quals are evaluated before
ordinary query quals, in case the latter contain "leaky" functions that could
expose the contents of sensitive rows. The original implementation of RLS
planning ensured this by pushing the scan of a secured table into a sub-query
that it marked as a security-barrier view. Unfortunately this results in very
inefficient plans in many cases, because the sub-query cannot be flattened and
gets planned independently of the rest of the query. To fix, drop the use of
sub-queries to enforce RLS qual order, and instead mark each qual
(RestrictInfo) with a security_level field establishing its priority for
evaluation. Quals must be evaluated in security_level order, except that
"leakproof" quals can be allowed to go ahead of quals of lower security_level,
if it's helpful to do so. This has to be enforced within the ordering of any
one list of quals to be evaluated at a table scan node, and we also have to
ensure that quals are not chosen for early evaluation (i.e., use as an index
qual or TID scan qual) if they're not allowed to go ahead of other quals at
the scan node. This is sufficient to fix the problem for RLS quals, since we
only support RLS policies on simple tables and thus RLS quals will always
exist at the table scan level only. Eventually these qual ordering rules
should be enforced for join quals as well, which would permit improving
planning for explicit security-barrier views; but that's a task for another
patch. Note that FDWs would need to be aware of these rules --- and not, for
example, send an insecure qual for remote execution --- but since we do not
yet allow RLS policies on foreign tables, the case doesn't arise. This will
need to be addressed before we can allow such policies. Patch by me, reviewed
by Stephen Frost and Dean Rasheed. Discussion:
https://postgr.es/m/8185.1477432701@sss.pgh.pa.us
http://git.postgresql.org/pg/commitdiff/215b43cdc8d6b4a1700886a39df1ee735cb0274d

- Avoid conflicts with collation aliases generated by stripping. This resulted
in failures depending on the order of "locale -a" output. The original coding
in initdb sorted the results, but that should be unnecessary as long as
"locale -a" doesn't print duplicate names. The original entries will then all
be non-dups, and while we might generate duplicate aliases by stripping, they
should be for different encodings and thus not conflict. Even if the latter
assumption fails somehow, it won't be fatal because we're using if_not_exists
mode for the aliases. Discussion:
https://postgr.es/m/26116.1484751196%40sss.pgh.pa.us
http://git.postgresql.org/pg/commitdiff/0333a7340054c3356940759b1ab2391eed572171

- Disable transforms that replaced AT TIME ZONE with RelabelType. These
resulted in wrong answers if the relabeled argument could be matched to an
index column, as shown in bug #14504 from Evgeniy Kozlov. We might be able to
resurrect these optimizations by adjusting the planner's treatment of
RelabelType, or by adjusting btree's rules for selecting comparison functions,
but either solution will take careful analysis and does not sound like a fit
candidate for backpatching. I left the catalog infrastructure in place and
just reduced the transform functions to always-return-NULL. This would be
necessary anyway in the back branches, and it doesn't seem important to be
more invasive in HEAD. Bug introduced by commit b8a18ad48. Back-patch to 9.5
where that came in. Report:
https://postgr.es/m/20170118144828.1432.52823@wrigleys.postgresql.org
Discussion: https://postgr.es/m/18771.1484759439@sss.pgh.pa.us
http://git.postgresql.org/pg/commitdiff/c22ecc6562aac895f0f0529707d7bdb460fd2a49

- Reset the proper GUC in create_index test. Thinko in commit a4523c5aa. It
doesn't really affect anything at present, but it would be a problem if any
tests added later in this file ought to get index-only-scan plans.
Back-patch, like the previous commit, just to avoid surprises in case we add
such a test and then back-patch it. Nikita Glukhov Discussion:
https://postgr.es/m/8b70135d-ad38-bdd8-ac92-71e2b3c273cf@postgrespro.ru
http://git.postgresql.org/pg/commitdiff/1586317c3f57e619e0cde674c6da406f9d73aaff

- Doc: improve documentation of new SRF-in-tlist behavior. Correct a
misstatement about how things used to work: we did allow nested SRFs before,
as long as no function had more than one set-returning input. Also, attempt
to document the fact that the new implementation changes the behavior for SRFs
within conditional constructs (eg CASE): the conditional construct no longer
gates whether the SRF is run, and thus cannot affect the number of rows
emitted. We might want to change this behavior, but first it behooves us to
see if we can explain it. Minor other wordsmithing on what I wrote yesterday,
too. Discussion:
https://postgr.es/m/20170118214702.54b2mdbxce5piwv5@alap3.anarazel.de
http://git.postgresql.org/pg/commitdiff/f13a1277aa2df301583c6db9c2989d2e9d7f6483

- Fix Assert failure induced by commit 215b43cdc. I'd somehow talked myself
into believing that set_append_rel_size doesn't need to worry about getting
back an AND clause when it applies eval_const_expressions to the result of
adjust_appendrel_attrs (that is, transposing the appendrel parent's
restriction clauses for one child). But that is nonsense, and Andreas
Seltenreich's fuzz tester soon turned up a counterexample. Put back the
make_ands_implicit step that was there before, and add a regression test
covering the case. Report: https://postgr.es/m/878tq6vja6.fsf@ansel.ydns.eu
http://git.postgresql.org/pg/commitdiff/d479e37e3d20efad8b178e0f1e468c086a7519a8

- Avoid core dump for empty prepared statement in an aborted transaction.
Brown-paper-bag bug in commit ab1f0c822: the old code here coped with null
CachedPlanSource.raw_parse_tree, the new code not so much. Per report from
Dave Cramer. No regression test, because our core testing infrastructure
doesn't provide any easy way to exercise this path. Fortunately, the JDBC
crew test it regularly. Discussion:
https://postgr.es/m/CADK3HH+Ug3xCysKqw_dZOnaNnytZ1Rh5yP05hjO-e4NoyRxVvA@mail.gmail.com
http://git.postgresql.org/pg/commitdiff/ba61a04bc7fefeee03416d9911eb825c4897c223

- Allow backslash line continuations in pgbench's meta commands. A pgbench meta
command can now be continued onto additional line(s) of a script file by
writing backslash-return. The continuation marker is equivalent to white
space in that it separates tokens. Eventually it'd be nice to have the same
thing in psql, but that will be a much larger project. Fabien Coelho,
reviewed by Rafia Sabih Discussion:
https://postgr.es/m/alpine.DEB.2.20.1610031049310.19411@lancre
http://git.postgresql.org/pg/commitdiff/cdc2a70470bdbe3663dc464deb753d6d931bba61

- Try to fix non-MSVC Windows builds in the wake of logical replication.
pgoutput evidently needs to be built without -DBUILDING_DLL. (It seems like a
pretty bad idea that these makefiles need to know exactly where all the shlibs
are in the tree, or maybe what's bad is putting them under src/backend/. But
right now is not the time to redesign that.) Also, remove "override CPPFLAGS"
in pgoutput's Makefile. I don't think that that actually has any bad
consequences, but it's certainly useless in a directory that has no .h files,
and it might be contributing to the failure somehow. Per buildfarm.
http://git.postgresql.org/pg/commitdiff/0502e854640bd024f349c0df46b7dd6812b8c05c

- Fix cross-shlib linking in temporary installs on HPUX 10. Turns out this has
been broken for years and we'd not noticed. The one case that was getting
exercised in the buildfarm, or probably anywhere else, was postgres_fdw.sl's
reference to libpq.sl; and it turns out that that was always going to libpq.sl
in the actual installation directory not the temporary install. We'd not
noticed because the buildfarm script does "make install" before it tests
contrib. However, the recent addition of a logical-replication test to the
core regression scripts resulted in trying to use libpqwalreceiver.sl before
"make install" happens, and that failed for lack of finding libpq.sl, as shown
by failures on buildfarm members gaur and pademelon. There are two changes
needed to fix it: the magic environment variable to specify shlib search path
at runtime is SHLIB_PATH not LD_LIBRARY_PATH, and the shlib link command needs
to specify the +s switch else the library will not honor SHLIB_PATH. I'm not
quite sure why buildfarm members anole and gharial (HPUX 11) didn't show the
same failure. Consulting man pages on the web says that HPUX 11 honors both
LD_LIBRARY_PATH and SHLIB_PATH, which would explain half of it, and the rather
confusing wording I've been able to find suggests that +s might effectively be
the default in HPUX 11. But it seems at least as likely that there's just a
libpq.so installed in /usr/lib on that machine; as long as it's not too
ancient, that would satisfy the test. In any case I do not think this patch
will break HPUX 11. At the moment I don't see a need to back-patch this,
since it only matters for testing purposes, not to mention that HPUX 10 is
probably dead in the real world anyway.
http://git.postgresql.org/pg/commitdiff/d2ab1176160e30543da1e48f7e0d17564852b693

- Remove no-longer-needed loop in ExecGather(). Coverity complained quite
properly that commit ea15e1867 had introduced unreachable code into
ExecGather(); to wit, it was no longer possible to iterate the final for-loop
more or less than once. So remove the for(). In passing, clean up a couple
of comments, and make better use of a local variable.
http://git.postgresql.org/pg/commitdiff/0a8b9d3b2c57028f7100078cd711370f396d5a81

- Relocate static function declarations to be after typedefs in jsonfuncs.c.
Project style is to put things in this order, for the good and sufficient
reason that you often need the typedefs in the function declarations. There
already was one function declaration that needed a typedef, which was randomly
placed away from all the other static function declarations in consequence.
And the submitted patch for better json_populate_record functionality jumped
through even more hoops in order to preserve this bad idea. This patch only
moves lines from point A to point B, no other changes.
http://git.postgresql.org/pg/commitdiff/90992e0e2f9fc4aa0f6402f0327604e5fef4630c

Peter Eisentraut pushed:

- doc: Update URL for Microsoft download site.
http://git.postgresql.org/pg/commitdiff/6181c34da882544c4842e7442189a7ea1dd03032

- Rename C symbols for backend lo_ functions. Rename the C symbols for lo_* to
be_lo_*, so they don't conflict with libpq prototypes. Reviewed-by: Pavel
Stehule <pavel(dot)stehule(at)gmail(dot)com>
http://git.postgresql.org/pg/commitdiff/6fc547960dbe0b8bd6cefae5ab7ec3605a5c46fc.

- Register missing money operators in system catalogs. The operators money*int8,
int8*money, and money/int8 were implemented in code but not registered in
pg_operator or pg_proc. Reviewed-by: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
http://git.postgresql.org/pg/commitdiff/323b96aa34239b5a8fe773d614a6ee50d731a683.

- Remove unnecessary prototypes in loadable modules. Reviewed-by: Pavel Stehule
<pavel(dot)stehule(at)gmail(dot)com>
http://git.postgresql.org/pg/commitdiff/5d7c9c906a0b888dcfd3b0a2f2170e1f5ca366c4

- Add more tests for money type. Add tests for functions currently not covered
at all. Reviewed-by: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
http://git.postgresql.org/pg/commitdiff/09e35315ccafb83c52da2e0fd6a0a9be410ce6a4

- Remove unnecessary include. Between 6eeb95f0f56bb5e8a0a9328aeec04c9e6de87272
and 7b1c2a0f2066672b24f6257ec9b8d78a1754f494, builtins.h contained additional
prototypes that have now been moved elsewhere, so we don't need to include
nodes/parsenodes.h anymore. Fix some files that were relying on builtins.h
implicitly pulling in some unrelated stuff they needed. Reviewed-by: Pavel
Stehule <pavel(dot)stehule(at)gmail(dot)com>
http://git.postgresql.org/pg/commitdiff/30b9a4495a8ec1f20ba518b34d679c700eadab16

- Correct include file path. Mistake in
352a24a1f9d6f7d4abb1175bfd22acc358f43140, not clear why it worked for some
before.
http://git.postgresql.org/pg/commitdiff/063ef8308b148e3581ddb626fdb397f7a5a48303

- Generate fmgr prototypes automatically. Gen_fmgrtab.pl creates a new file
fmgrprotos.h, which contains prototypes for all functions registered in
pg_proc.h. This avoids having to manually maintain these prototypes across a
random variety of header files. It also automatically enforces a correct
function signature, and since there are warnings about missing prototypes, it
will detect functions that are defined but not registered in pg_proc.h (or
otherwise used). Reviewed-by: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
http://git.postgresql.org/pg/commitdiff/352a24a1f9d6f7d4abb1175bfd22acc358f43140

- initdb: Fix for mixed-case superuser names. The previous coding did not
properly quote the user name before casting it to regrole. To avoid all that,
just pass in BOOTSTRAP_SUPERUSERID numerically. Also fix one place where the
BOOTSTRAP_SUPERUSERID was hardcoded as 10.
http://git.postgresql.org/pg/commitdiff/8b0fec93ecc788c8d8b329d41ab795712d8dcc5a

- Add function to import operating system collations. Move this logic out of
initdb into a user-callable function. This simplifies the code and makes it
possible to update the standard collations later on if additional operating
system collations appear. Reviewed-by: Andres Freund <andres(at)anarazel(dot)de>
Reviewed-by: Euler Taveira <euler(at)timbira(dot)com(dot)br>
http://git.postgresql.org/pg/commitdiff/aa17c06fb58533d09c79c68a4d34a6f56687ee38

- Bump catversion.
http://git.postgresql.org/pg/commitdiff/e4c27f5befbfc80a1bf96fc93256dce08b148238

- Paper over pg_upgrade test failure. The publication test didn't drop all the
publications it was creating when it was probably intending to do that. There
is still a bug with dependency tracking in there, but this should at least
quiet down the build farm.
http://git.postgresql.org/pg/commitdiff/6c488ea13634897df5f9b5769eb26bbc3d926ce0

- Move some things from builtins.h to new header files. This avoids that
builtins.h has to include additional header files.
http://git.postgresql.org/pg/commitdiff/f21a563d25dbae153937aec062161184189478b8

- Logical replication. - Add PUBLICATION catalogs and DDL. - Add SUBSCRIPTION
catalog and DDL. - Define logical replication protocol and output plugin. -
Add logical replication workers. From: Petr Jelinek <petr(at)2ndquadrant(dot)com>
Reviewed-by: Steve Singer <steve(at)ssinger(dot)info> Reviewed-by: Andres Freund
<andres(at)anarazel(dot)de> Reviewed-by: Erik Rijkers <er(at)xs4all(dot)nl> Reviewed-by:
Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
http://git.postgresql.org/pg/commitdiff/665d1fad99e7b11678b0d5fa24d2898424243cd6

- Add more includes so header files are self-contained.
http://git.postgresql.org/pg/commitdiff/b48008676002895c284c9a7a3d4fc7210b58044d

- Add missing break.
http://git.postgresql.org/pg/commitdiff/8f164e1eeaf31438f6706ed45efee607a2c7a21b

Álvaro Herrera pushed:

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

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

- Remove dead code in bootstrap. The bootstrap scanner/parser contains code to
parse floating point values, but this is not exercised anywhere, so remove it.
Reviewed-by: Jim Nasby Discussion:
https://postgr.es/m/20170110051119.b5h7i3z5qagy35rb@alvherre.pgsql
http://git.postgresql.org/pg/commitdiff/193a7d791ebe2adf32b36d5538e4602a90c3e0fb

- Make messages mentioning type names more uniform. This avoids additional
translatable strings for each distinct type, as well as making our quoting
style around type names more consistent (namely, that we don't quote type
names). This continues what started as f402b9950120. Discussion:
https://postgr.es/m/20160401170642.GA57509@alvherre.pgsql
http://git.postgresql.org/pg/commitdiff/9a34123bc315e55b33038464422ef1cd2b67dab2

- Change some test macros to return true booleans. These macros work fine when
they are used directly in an "if" test or similar, but as soon as the return
values are assigned to boolean variables (or passed as boolean arguments to
some function), they become bugs, hopefully caught by compiler warnings. To
avoid future problems, fix the definitions so that they return actual
booleans. To further minimize the risk that somebody uses them in
back-patched fixes that only work correctly in branches starting from the
current master and not in old ones, back-patch the change to supported
branches as appropriate. See also commit
af4472bcb88ab36b9abbe7fd5858e570a65a2d1a, and the long discussion (and larger
patch) in the thread mentioned in its commit message. Discussion:
https://postgr.es/m/18672.1483022414@sss.pgh.pa.us
http://git.postgresql.org/pg/commitdiff/594e61a1de03ab93779e7e3d853edb7859d5c3cf

- Allow negative years in make_date to represent BC years. There doesn't seem
to be any reason not to allow negative years to be interpreted as BC, so do
that. The documentation is pretty vague on the details of this function, so
nothing needs to change there. Reported-by: Andy Abelisto, in bug #14446
http://git.postgresql.org/pg/commitdiff/30bcebbdcf23eb8b78e553c4b3b5eb847410ef19

- Fix race condition in reading commit timestamps. If a user requests the
commit timestamp for a transaction old enough that its data is concurrently
being truncated away by vacuum at just the right time, they would receive an
ugly internal file-not-found error message from slru.c rather than the
expected NULL return value. In a primary server, the window for the race is
very small: the lookup has to occur exactly between the two calls by vacuum,
and there's not a lot that happens between them (mostly just a multixact
truncate). In a standby server, however, the window is larger because the
truncation is executed as soon as the WAL record for it is replayed, but the
advance of the oldest-Xid is not executed until the next checkpoint record.
To fix in the primary, simply reverse the order of operations in
vac_truncate_clog. To fix in the standby, augment the WAL truncation record
so that the standby is aware of the new oldest-XID value and can apply the
update immediately. WAL version bumped because of this. No backpatch,
because of the low importance of the bug and its rarity. Author: Craig Ringer
Reviewed-By: Petr Jelínek, Peter Eisentraut Discussion:
https://postgr.es/m/CAMsr+YFhVtRQT1VAwC+WGbbxZZRzNou=N9Ed-FrCqkwQ8H8oJQ@mail.gmail.com
http://git.postgresql.org/pg/commitdiff/8eace46d34ab6ac0d887aa4d3504bc4222c2e448

- tests: Use the right Perl operator. We were using != to compare strings, for
which "ne" is the right thing. It's not clear why it works everywhere except
on Pavan's machine, but it's clearly bogus anyway. Author and reporter: Pavan
Deolasee Discussion:
https://postgr.es/m/CABOikdPhsHM+pX8skoEY1_T0OtKdO1udzUj4VCjU5VEt+bj4eA@mail.gmail.com
http://git.postgresql.org/pg/commitdiff/a600ee9e3fcc43d4497d18d837f1e86148ca7580

- Record dependencies on owners for logical replication objects. This was
forgotten in 665d1fad99e7b11678b0d5fa24d2898424243cd6 and caused the whole
buildfarm to become red for a little while. Author: Petr Jelínek. Also fix a
typo in a nearby error message.
http://git.postgresql.org/pg/commitdiff/50cf1c80e6be80cc620749824fe9e3cd7f6c118e

Robert Haas pushed:

- Factor out logic for computing number of parallel workers. Forthcoming
patches to allow other types of parallel scans will need this logic, or
something like it. Dilip Kumar
http://git.postgresql.org/pg/commitdiff/716c7d4b242f0a64ad8ac4dc48c6fed6557ba12c

- Update information_schema queries and system views for new relkind. The
original table partitioning patch overlooked this. Discussion:
http://postgr.es/m/CAG1_KcDJiZB=L6yOUO_bVufj2q2851_xdkfhw0JdcD_2VtKssw@mail.gmail.com
Keith Fiske and Amit Langote, adjusted by me.
http://git.postgresql.org/pg/commitdiff/262e821deced47337d6d807515997567bb45fd7d

- Add some more tests for tuple routing. Commit
a25665088d812d08bb888e961f208eaebf522050 fixed some issues with how
PartitionDispatch related code handled multi-level partitioned tables, but
didn't add any tests. Discussion:
http://postgr.es/m/CA%2BTgmoZ86v1G%2Bzx9etMiSQaBBvYMKfU-iitqZArSh5z0n8Q4cA%40mail.gmail.com
Amit Langote, per a complaint from me.
http://git.postgresql.org/pg/commitdiff/d26fa4fd47ae5f09c214e954ae9cf8a890bd3c35

- Avoid use of DROP TABLE .. CASCADE in partitioning tests. This isn't really
guaranteed to always produce exactly the same output; the order can change
from run to run. See related cleanup in
257d8157205a7be5f9799e8941b922521d678a25.
http://git.postgresql.org/pg/commitdiff/e509e7f9e3c565043e1186f5a83122d71653d111

- Improve comment in hashsearch.c. Typo fix from Mithun Cy; other improvements
by me.
http://git.postgresql.org/pg/commitdiff/e37360d5df240443bb6e997d26d54f59146283fc

- Fix failure to enforce partitioning contraint for internal partitions. When a
tuple is inherited into a partitioning root, no partition constraints need to
be enforced; when it is inserted into a leaf, the parent's partitioning quals
needed to be enforced. The previous coding got both of those cases right.
When a tuple is inserted into an intermediate level of the partitioning
hierarchy (i.e. a table which is both a partition itself and in turn
partitioned), it must enforce the partitioning qual inherited from its parent.
That case got overlooked; repair. Amit Langote
http://git.postgresql.org/pg/commitdiff/39162b2030fb0a35a6bb28dc636b5a71b8df8d1c

- Fix RETURNING to work correctly with partition tuple routing. In
ExecInsert(), do not switch back to the root partitioned table ResultRelInfo
until after we finish ExecProcessReturning(), so that RETURNING projection is
done using the partition's descriptor. For the projection to work correctly,
we must initialize the same for each leaf partition during ModifyTableState
initialization. Amit Langote
http://git.postgresql.org/pg/commitdiff/05bd889904e03479a7169b1c36e0e1db13fff7cb

- Fix some problems in check_new_partition_bound(). Account for the fact that
the highest bound less than or equal to the upper bound might be either the
lower or the upper bound of the overlapping partition, depending on whether
the proposed partition completely contains the existing partition or merely
overlaps it. Also, we need not continue searching for even greater bound in
partition_bound_bsearch() once we find the first bound that is *equal* to the
probe, because we don't have duplicate datums. That spends cycles needlessly.
Amit Langote, per a report from Amul Sul. Cosmetic changes by me.
Discussion:
http://postgr.es/m/CAAJ_b94XgbqVoXMyxxs63CaqWoMS1o2gpHiU0F7yGnJBnvDc_A%40mail.gmail.com
http://git.postgresql.org/pg/commitdiff/8a8afe2f54c27dbb47df3853803158c5205d41ce

- Avoid some code duplication in map_partition_varattnos(). Code to map
attribute numbers in map_partition_varattnos() duplicates what
convert_tuples_by_name_map() does. Avoid that. Amit Langote, per a report
from Álvaro Herrera. Discussion:
http://postgr.es/m/9ce97382-54c8-deb3-9ee9-a2ec271d866b%40lab.ntt.co.jp
http://git.postgresql.org/pg/commitdiff/cc144155f7cdd51e19984f82da6625dc75de9fda

- Teach partitioning tests not to use DROP TABLE ... CASCADE. This occasionally
causes failures; the order in which the affected objects are listed is not
100% consistent. Amit Langote
http://git.postgresql.org/pg/commitdiff/c3978149536a9c3fb837524407c58dec2b103c60

- Fix comparison logic in partition_bounds_equal for non-finite bounds. If
either bound is infinite, then we shouldn't even try to perform a comparison
of the values themselves. Rearrange the logic so that we don't. Per
buildfarm member skink and Tom Lane.
http://git.postgresql.org/pg/commitdiff/6546ffb35db78365d9f0011d75d16625e6040437

- Avoid useless respawining the autovacuum launcher at high speed. When (1)
autovacuum = off and (2) there's at least one database with an XID age greater
than autovacuum_freeze_max_age and (3) all tables in that database that need
vacuuming are already being processed by a worker and (4) the autovacuum
launcher is started, a kind of infinite loop occurs. The launcher starts a
worker and immediately exits. The worker, finding no worker to do,
immediately starts the launcher, supposedly so that the next database can be
processed. But because datfrozenxid for that database hasn't been advanced
yet, the new worker gets put right back into the same database as the old one,
where it once again starts the launcher and exits. High-speed ping pong
ensues. There are several possible ways to break the cycle; this seems like
the safest one. Amit Khandekar (code) and Robert Haas (comments), reviewed by
Álvaro Herrera. Discussion:
http://postgr.es/m/CAJ3gD9eWejf72HKquKSzax0r+epS=nAbQKNnykkMA0E8c+rMDg@mail.gmail.com
http://git.postgresql.org/pg/commitdiff/c6a389792e08980e395055ac219303cf4357ba33

Andres Freund pushed:

- Move targetlist SRF handling from expression evaluation to new executor node.
Evaluation of set returning functions (SRFs_ in the targetlist (like SELECT
generate_series(1,5)) so far was done in the expression evaluation (i.e.
ExecEvalExpr()) and projection (i.e. ExecProject/ExecTargetList) code. This
meant that most executor nodes performing projection, and most expression
evaluation functions, had to deal with the possibility that an evaluated
expression could return a set of return values. That's bad because it leads
to repeated code in a lot of places. It also, and that's my (Andres's)
motivation, made it a lot harder to implement a more efficient way of doing
expression evaluation. To fix this, introduce a new executor node
(ProjectSet) that can evaluate targetlists containing one or more SRFs. To
avoid the complexity of the old way of handling nested expressions returning
sets (e.g. having to pass up ExprDoneCond, and dealing with arguments to
functions returning sets etc.), those SRFs can only be at the top level of the
node's targetlist. The planner makes sure (via split_pathtarget_at_srfs())
that SRF evaluation is only necessary in ProjectSet nodes and that SRFs are
only present at the top level of the node's targetlist. If there are nested
SRFs the planner creates multiple stacked ProjectSet nodes. The ProjectSet
nodes always get input from an underlying node. We also discussed and
prototyped evaluating targetlist SRFs using ROWS FROM(), but that turned out
to be more complicated than we'd hoped. While moving SRF evaluation to
ProjectSet would allow to retain the old "least common multiple" behavior when
multiple SRFs are present in one targetlist (i.e. continue returning rows
until all SRFs are at the end of their input at the same time), we decided to
instead only return rows till all SRFs are exhausted, returning NULL for
already exhausted ones. We deemed the previous behavior to be too confusing,
unexpected and actually not particularly useful. As a side effect, the
previously prohibited case of multiple set returning arguments to a function,
is now allowed. Not because it's particularly desirable, but because it ends
up working and there seems to be no argument for adding code to prohibit it.
Currently the behavior for COALESCE and CASE containing SRFs has changed,
returning multiple rows from the expression, even when the SRF containing
"arm" of the expression is not evaluated. That's because the SRFs are
evaluated in a separate ProjectSet node. As that's quite confusing, we're
likely to instead prohibit SRFs in those places. But that's still being
discussed, and the code would reside in places not touched here, so that's a
task for later. There's a lot of, now superfluous, code dealing with set
return expressions around. But as the changes to get rid of those are verbose
largely boring, it seems better for readability to keep the cleanup as a
separate commit. Author: Tom Lane and Andres Freund Discussion:
https://postgr.es/m/20160822214023.aaxz5l4igypowyri@alap3.anarazel.de
http://git.postgresql.org/pg/commitdiff/69f4b9c85f168ae006929eec44fc44d569e846b9

- Adapt python regression tests to 69f4b9c85f16. Hopefully this'll unbreak the
buildfarm.
http://git.postgresql.org/pg/commitdiff/8b07aee8c5d803801c00103f0d61e32356aaf29c

- Remove obsoleted code relating to targetlist SRF evaluation. Since 69f4b9c
plain expression evaluation (and thus normal projection) can't return sets of
tuples anymore. Thus remove code dealing with that possibility. This will
require adjustments in external code using ExecEvalExpr()/ExecProject() - that
should neither be hard nor very common. Author: Andres Freund and Tom Lane
Discussion:
https://postgr.es/m/20160822214023.aaxz5l4igypowyri@alap3.anarazel.de
http://git.postgresql.org/pg/commitdiff/ea15e18677fc2eff3135023e27f69ed8821554ed

- Fix platform dependant regression output triggered by 69f4b9c85f16. Due to
the changed costing in that commit hash-aggregates started to be used, which
results in big-endian vs. little-endian output differences. Disable hash-aggs
for those tests. Author: Andres Freund, with input from Tom Lane Discussion:
https://postgr.es/m/22891.1484791792@sss.pgh.pa.us
http://git.postgresql.org/pg/commitdiff/182200531a92204b0547d337f50b665d222af168

Stephen Frost pushed:

- Dump sequence data based on the TableDataInfo flag. When considering a
sequence's Data entry in dumpSequenceData, we were actually looking at the
sequence definition's dump flag to decide if we should dump the data or not.
That's generally fine, except for when the sequence data entry was created by
processExtensionTables() because it's a config sequence. In that case, the
sequence itself won't be marked as dumping data because it's part of an
extension, leading to the need for processExtensionTables() to create the
sequence data entry. This leads to extension config sequence data not being
included in the dump when it should be. Fix this by looking at the sequence
data's dump flag instead, just as dumpTableData() was doing for tables (which
is why config tables were correctly being handled), and add a regression test
to make sure we don't break it moving forward. All of this is a bit
round-about since we can now represent which components of a given dump item
should be dumped out through the dump flag. A future improvement might be to
change checkExtensionMembership() to check for config sequences/tables and set
the dump flag based on that directly, possibly removing the need for
processExtensionTables(). Bug found by Daniele Varrazzo. Discussion:
https://postgr.es/m/CA+mi_8ZmxQM7+nZ7pJ8uyfxc9V3o=UAG14dVqvftdmvw8OJ3gQ@mail.gmail.com
Patch by Michael Paquier, with some tweaking of the regression tests by me.
Back-patch to 9.6 where the bug was introduced.
http://git.postgresql.org/pg/commitdiff/bec96c82f8ff4fcf7ef0f070f6f7447edf106de3

== Pending Patches ==

Michaël Paquier and Karl O. Pinc traded patches to implement
pg_current_logfile().

Michaël Paquier sent in another revision of a patch to rename pg_clog to
pg_xact and pg_subtrans to pg_subxact.

Masahiko Sawada sent in two more revisions of a patch to support FDW
transactions.

Amit Kapila sent in another revision of a patch to parallelize queries
containing subplans.

Haribabu Kommi sent in four more revisions of a patch to implement a
pg_hba_file_settings view.

Beena Emerson and Robert Haas traded patches to enable increasing WAL segment
size.

Amit Kapila and Robert Haas traded patches to enable parallel index scans.

Michaël Paquier sent in a flock of back-patches for an issue in backups on
standbys uncovered by sqlsmith.

Mithun Cy sent in another revision of a patch to cache hash index meta pages.

Nikita Glukhov sent in a patch to implement K-nearest-neighbor for B-Tree
indexes.

Dilip Kumar sent in another revision of a patch to implement parallel bitmap
heap scan.

Magnus Hagander and Michaël Paquier traded patches to implement a version of
jsonb_delete which takes arrays as input.

Haribabu Kommi sent in another revision of a patch to implement a pg_stat_sql
view.

Etsuro Fujita sent in another revision of a patch to fix a bug in foreign joins.

David Rowley sent in two more revisions of a patch to improve performance for
outer joins where the outer side is unique.

Haribabu Kommi sent in another revision of a patch to implement a 64-bit macaddr
type.

Ashutosh Sharma sent in another revision of a patch to add pgstathashindex to
the pgstattuple extension.

Ashutosh Sharma and Jesper Pedersen traded patches to add hash index support to
pageinspect.

Petr Jelínek sent in two more revisions of a patch to enable logical replication
support for the initial data copy.

Petr Jelínek sent in another revision of a patch to add RENAME support for
PUBLICATIONs and SUBSCRIPTIONs.

Petr Jelínek sent in a flock of patches to fix issues in logical replication.

Rafia Sabih sent in another revision of a patch to implement parallel index-only
scans.

Pavan Deolasee sent in another revision of a patch to implement WARM.

Dmitry Fedin sent in a patch to change a misleading comment in pgtime.h.

Yugo Nagata sent in a patch to fix a comment in freelist.c.

Erik Rijkers sent in a patch to improve the logical replication documentation.

Jim Nasby sent in a patch to protect syscache from bloating with negative cache
entries.

Petr Jelínek sent in a patch to fix AFTER trigger execution in logical
replication.

Tom Lane sent in another revision of a patch to prevent the possibility of
UNKNOWN output columns.