PostgreSQL 10.5 commit log

Stamp 10.5.

commit   : 4191e37a9a1fb598267c445c717914012d9bc423    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 6 Aug 2018 16:05:31 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 6 Aug 2018 16:05:31 -0400    

Click here for diff

M configure
M configure.in
M doc/bug.template
M src/include/pg_config.h.win32
M src/interfaces/libpq/libpq.rc.in
M src/port/win32ver.rc

Translation updates

commit   : 4ae11214238b382242c038566e5da970fbdaa355    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 6 Aug 2018 20:03:55 +0200    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 6 Aug 2018 20:03:55 +0200    

Click here for diff

Source-Git-URL: https://git.postgresql.org/git/pgtranslation/messages.git  
Source-Git-Hash: 3463878fc340cb1436153b18a300f8cfdcb12adb  

M src/backend/po/de.po
M src/backend/po/fr.po
M src/backend/po/it.po
M src/backend/po/sv.po
M src/backend/po/tr.po
M src/bin/initdb/po/cs.po
M src/bin/pg_archivecleanup/nls.mk
A src/bin/pg_archivecleanup/po/cs.po
M src/bin/pg_basebackup/nls.mk
A src/bin/pg_basebackup/po/cs.po
M src/bin/pg_basebackup/po/it.po
M src/bin/pg_config/po/cs.po
M src/bin/pg_controldata/po/cs.po
M src/bin/pg_controldata/po/de.po
M src/bin/pg_controldata/po/sv.po
M src/bin/pg_ctl/po/cs.po
M src/bin/pg_dump/po/cs.po
M src/bin/pg_resetwal/nls.mk
A src/bin/pg_resetwal/po/cs.po
M src/bin/pg_rewind/nls.mk
A src/bin/pg_rewind/po/cs.po
M src/bin/pg_test_fsync/nls.mk
A src/bin/pg_test_fsync/po/cs.po
M src/bin/pg_test_timing/nls.mk
A src/bin/pg_test_timing/po/cs.po
M src/bin/pg_upgrade/nls.mk
A src/bin/pg_upgrade/po/cs.po
M src/bin/pg_waldump/nls.mk
A src/bin/pg_waldump/po/cs.po
M src/bin/psql/nls.mk
A src/bin/psql/po/cs.po
M src/bin/psql/po/sv.po
M src/bin/scripts/po/cs.po
M src/interfaces/ecpg/ecpglib/po/cs.po
M src/interfaces/ecpg/preproc/po/cs.po
M src/interfaces/ecpg/preproc/po/pt_BR.po
M src/interfaces/libpq/po/cs.po
M src/pl/plperl/po/cs.po
M src/pl/plpgsql/src/po/cs.po
M src/pl/plpython/nls.mk
A src/pl/plpython/po/cs.po
M src/pl/tcl/nls.mk
A src/pl/tcl/po/cs.po

Last-minute updates for release notes.

commit   : 9d3072d2db2edbc19603d8d65189a504cc4e4712    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 6 Aug 2018 13:13:41 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 6 Aug 2018 13:13:41 -0400    

Click here for diff

Security: CVE-2018-10915, CVE-2018-10925  

M doc/src/sgml/release-10.sgml
M doc/src/sgml/release-9.3.sgml
M doc/src/sgml/release-9.4.sgml
M doc/src/sgml/release-9.5.sgml
M doc/src/sgml/release-9.6.sgml

Fix failure to reset libpq’s state fully between connection attempts.

commit   : ab5400469b5db281a4d804ef59b80fcef7c9fc93    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 6 Aug 2018 10:53:35 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 6 Aug 2018 10:53:35 -0400    

Click here for diff

The logic in PQconnectPoll() did not take care to ensure that all of  
a PGconn's internal state variables were reset before trying a new  
connection attempt.  If we got far enough in the connection sequence  
to have changed any of these variables, and then decided to try a new  
server address or server name, the new connection might be completed  
with some state that really only applied to the failed connection.  
  
While this has assorted bad consequences, the only one that is clearly  
a security issue is that password_needed didn't get reset, so that  
if the first server asked for a password and the second didn't,  
PQconnectionUsedPassword() would return an incorrect result.  This  
could be leveraged by unprivileged users of dblink or postgres_fdw  
to allow them to use server-side login credentials that they should  
not be able to use.  
  
Other notable problems include the possibility of forcing a v2-protocol  
connection to a server capable of supporting v3, or overriding  
"sslmode=prefer" to cause a non-encrypted connection to a server that  
would have accepted an encrypted one.  Those are certainly bugs but  
it's harder to paint them as security problems in themselves.  However,  
forcing a v2-protocol connection could result in libpq having a wrong  
idea of the server's standard_conforming_strings setting, which opens  
the door to SQL-injection attacks.  The extent to which that's actually  
a problem, given the prerequisite that the attacker needs control of  
the client's connection parameters, is unclear.  
  
These problems have existed for a long time, but became more easily  
exploitable in v10, both because it introduced easy ways to force libpq  
to abandon a connection attempt at a late stage and then try another one  
(rather than just giving up), and because it provided an easy way to  
specify multiple target hosts.  
  
Fix by rearranging PQconnectPoll's state machine to provide centralized  
places to reset state properly when moving to a new target host or when  
dropping and retrying a connection to the same host.  
  
Tom Lane, reviewed by Noah Misch.  Our thanks to Andrew Krasichkov  
for finding and reporting the problem.  
  
Security: CVE-2018-10915  

M src/interfaces/libpq/fe-connect.c
M src/interfaces/libpq/libpq-int.h

Adjust error message

commit   : e155ddd9180ca059c6049b87c62fb243fefdeebe    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 11 Jun 2018 17:19:11 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 11 Jun 2018 17:19:11 -0400    

Click here for diff

Makes it look more similar to other ones, and avoids the need for  
pluralization.  

M src/common/controldata_utils.c

Release notes for 10.5, 9.6.10, 9.5.14, 9.4.19, 9.3.24.

commit   : 9468474902fa90cf533211d7e8011a11328bae3f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 5 Aug 2018 16:38:43 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 5 Aug 2018 16:38:43 -0400    

Click here for diff

M doc/src/sgml/release-10.sgml
M doc/src/sgml/release-9.3.sgml
M doc/src/sgml/release-9.4.sgml
M doc/src/sgml/release-9.5.sgml
M doc/src/sgml/release-9.6.sgml

Doc: fix incorrectly stated argument list for pgcrypto’s hmac() function.

commit   : aa72d54198cb84b974665848608b267605d9c6a8    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 5 Aug 2018 13:03:42 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 5 Aug 2018 13:03:42 -0400    

Click here for diff

The bytea variant takes (bytea, bytea, text).  
Per unsigned report.  
  
Discussion: https://postgr.es/m/153344327294.1404.654155870612982042@wrigleys.postgresql.org  

M doc/src/sgml/pgcrypto.sgml

Fix INSERT ON CONFLICT UPDATE through a view that isn’t just SELECT *.

commit   : f6a124d019a4e8fd368fb759814c94b02a65781f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 4 Aug 2018 19:38:58 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 4 Aug 2018 19:38:58 -0400    

Click here for diff

When expanding an updatable view that is an INSERT's target, the rewriter  
failed to rewrite Vars in the ON CONFLICT UPDATE clause.  This accidentally  
worked if the view was just "SELECT * FROM ...", as the transformation  
would be a no-op in that case.  With more complicated view targetlists,  
this omission would often lead to "attribute ... has the wrong type" errors  
or even crashes, as reported by Mario De Frutos Dieguez.  
  
Fix by adding code to rewriteTargetView to fix up the data structure  
correctly.  The easiest way to update the exclRelTlist list is to rebuild  
it from scratch looking at the new target relation, so factor the code  
for that out of transformOnConflictClause to make it sharable.  
  
In passing, avoid duplicate permissions checks against the EXCLUDED  
pseudo-relation, and prevent useless view expansion of that relation's  
dummy RTE.  The latter is only known to happen (after this patch) in cases  
where the query would fail later due to not having any INSTEAD OF triggers  
for the view.  But by exactly that token, it would create an unintended  
and very poorly tested state of the query data structure, so it seems like  
a good idea to prevent it from happening at all.  
  
This has been broken since ON CONFLICT was introduced, so back-patch  
to 9.5.  
  
Dean Rasheed, based on an earlier patch by Amit Langote;  
comment-kibitzing and back-patching by me  
  
Discussion: https://postgr.es/m/CAFYwGJ0xfzy8jaK80hVN2eUWr6huce0RU8AgU04MGD00igqkTg@mail.gmail.com  

M src/backend/parser/analyze.c
M src/backend/rewrite/rewriteHandler.c
M src/include/parser/analyze.h
M src/test/regress/expected/updatable_views.out
M src/test/regress/sql/updatable_views.sql

Reset properly errno before calling write()

commit   : 7124e64520834cd238c9f0efcfe429c28696b11d    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sun, 5 Aug 2018 05:32:12 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sun, 5 Aug 2018 05:32:12 +0900    

Click here for diff

6cb3372 enforces errno to ENOSPC when less bytes than what is expected  
have been written when it is unset, though it forgot to properly reset  
errno before doing a system call to write(), causing errno to  
potentially come from a previous system call.  
  
Reported-by: Tom Lane  
Author: Michael Paquier  
Reviewed-by: Tom Lane  
Discussion: https://postgr.es/m/31797.1533326676@sss.pgh.pa.us  

M src/backend/access/heap/rewriteheap.c
M src/backend/access/transam/twophase.c
M src/backend/replication/logical/origin.c
M src/backend/replication/logical/reorderbuffer.c
M src/backend/replication/logical/snapbuild.c
M src/backend/replication/slot.c
M src/bin/pg_basebackup/walmethods.c

Add table relcache invalidation to index builds.

commit   : c83408aa71e06f60c30ffda103f513b7d52db05d    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Fri, 3 Aug 2018 14:44:56 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Fri, 3 Aug 2018 14:44:56 -0700    

Click here for diff

It's necessary to make sure that owning tables have a relcache  
invalidation prior to advancing the command counter to make  
newly-entered catalog tuples for the index visible.  inval.c must be  
able to maintain the consistency of the local caches in the event of  
transaction abort.  There is usually only a problem when CREATE INDEX  
transactions abort, since there is a generic invalidation once we reach  
index_update_stats().  
  
This bug is of long standing.  Problems were made much more likely by  
the addition of parallel CREATE INDEX (commit 9da0cc35284), but it is  
strongly suspected that similar problems can be triggered without  
involving plan_create_index_workers().  (plan_create_index_workers()  
triggers a relcache build or rebuild, which previously only happened in  
rare edge cases.)  
  
Author: Peter Geoghegan  
Reported-By: Luca Ferrari  
Diagnosed-By: Andres Freund  
Reviewed-By: Andres Freund  
Discussion: https://postgr.es/m/CAKoxK+5fVodiCtMsXKV_1YAKXbzwSfp7DgDqUmcUAzeAhf=HEQ@mail.gmail.com  
Backpatch: 9.3-  

M src/backend/catalog/index.c

Add ‘n’ to list of possible values to pg_default_acl.defaclobjtype

commit   : 2e838371b98bdda10368482af95758087badca05    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 3 Aug 2018 16:45:08 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 3 Aug 2018 16:45:08 -0400    

Click here for diff

This was missed in commit ab89e465cb20; backpatch to v10.  
  
Author: Fabien Coelho <coelho@cri.ensmp.fr>  
Discussion: https://postgr.es/m/alpine.DEB.2.21.1807302243001.13230@lancre  

M doc/src/sgml/catalogs.sgml

Fix pg_replication_slot example output

commit   : d9c99c666b1124bd9adf5c29fd0ca9815f14ceb8    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 3 Aug 2018 16:34:59 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 3 Aug 2018 16:34:59 -0400    

Click here for diff

The example output of pg_replication_slot is wrong.  Correct it and make  
the output stable by explicitly listing columns to output.  
  
Author: Kyotaro Horiguchi <horiguchi.kyotaro@lab.ntt.co.jp>  
Reviewed-by: Michael Paquier <michael@paquier.xyz>  
Discussion: https://postgr.es/m/20180731.190909.42582169.horiguchi.kyotaro@lab.ntt.co.jp  

M doc/src/sgml/high-availability.sgml

Remove no-longer-appropriate special case in psql’s \conninfo code.

commit   : ed5d8196c0cc769f9e893a59d184ca7efa1fe20a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 3 Aug 2018 12:20:47 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 3 Aug 2018 12:20:47 -0400    

Click here for diff

\conninfo prints the results of PQhost() and some other libpq functions.  
It used to override the PQhost() result with the hostaddr parameter if  
that'd been given, but that's unhelpful when multiple hosts were listed  
in the connection string.  Furthermore, it seems unnecessary in the wake  
of commit 1944cdc98, since PQhost does any useful substitution itself.  
So let's just remove the extra code and print PQhost()'s result without  
any editorialization.  
  
Back-patch to v10, as 1944cdc98 (just) was.  
  
Discussion: https://postgr.es/m/23287.1533227021@sss.pgh.pa.us  

M src/bin/psql/command.c

Change libpq’s internal uses of PQhost() to inspect host field directly.

commit   : 8d00858bafb50a8fb06c7e9482af2bfef2eebc75    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 3 Aug 2018 12:12:10 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 3 Aug 2018 12:12:10 -0400    

Click here for diff

Commit 1944cdc98 changed PQhost() to return the hostaddr value when that  
is specified and host isn't.  This is a good idea in general, but  
fe-auth.c and related files contain PQhost() calls for which it isn't.  
Specifically, when we compare SSL certificates or other server identity  
information to the host field, we do not want to use hostaddr instead;  
that's not what's documented, that's not what happened pre-v10, and  
it doesn't seem like a good idea.  
  
Instead, we can just look at connhost[].host directly.  This does what  
we want in v10 and up; in particular, if neither host nor hostaddr  
were given, the host field will be replaced with the default host name.  
That seems useful, and it's likely the reason that these places were  
coded to call PQhost() originally (since pre-v10, the stored field was  
not replaced with the default).  
  
Back-patch to v10, as 1944cdc98 (just) was.  
  
Discussion: https://postgr.es/m/23287.1533227021@sss.pgh.pa.us  

M src/interfaces/libpq/fe-auth.c
M src/interfaces/libpq/fe-secure-openssl.c

libpq: PQhost to return active connected host or hostaddr

commit   : 62038810b73dbb78c66c28a24642b0e066e0b1a1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 3 Aug 2018 11:30:34 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 3 Aug 2018 11:30:34 -0400    

Click here for diff

Previously, PQhost didn't return the connected host details when the  
connection type was CHT_HOST_ADDRESS (i.e., via hostaddr).  Instead, it  
returned the complete host connection parameter (which could contain  
multiple hosts) or the default host details, which was confusing and  
arguably incorrect.  
  
Change this to return the actually connected host or hostaddr  
irrespective of the connection type.  When hostaddr but no host was  
specified, hostaddr is now returned.  Never return the original host  
connection parameter, and document that PQhost cannot be relied on  
before the connection is established.  
  
PQport is similarly changed to always return the active connection port  
and never the original connection parameter.  
  
Back-patch of commit 1944cdc98273dbb8439ad9b387ca2858531afcf0  
into the v10 branch.  
  
Author: Hari Babu <kommi.haribabu@gmail.com>  
Reviewed-by: Michael Paquier <michael@paquier.xyz>  
Reviewed-by: Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>  
Reviewed-by: David G. Johnston <david.g.johnston@gmail.com>  

M doc/src/sgml/libpq.sgml
M src/interfaces/libpq/fe-connect.c

Fix buffer usage stats for parallel nodes.

commit   : b805b63ac277d08beb0eac75469b867553d9a772    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Fri, 3 Aug 2018 11:27:11 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Fri, 3 Aug 2018 11:27:11 +0530    

Click here for diff

The buffer usage stats is accounted only for the execution phase of the  
node.  For Gather and Gather Merge nodes, such stats are accumulated at  
the time of shutdown of workers which is done after execution of node due  
to which we missed to account them for such nodes.  Fix it by treating  
nodes as running while we shut down them.  
  
We can also miss accounting for a Limit node when Gather or Gather Merge  
is beneath it, because it can finish the execution before shutting down  
such nodes.  So we allow a Limit node to shut down the resources before it  
completes the execution.  
  
In the passing fix the gather node code to allow workers to shut down as  
soon as we find that all the tuples from the workers have been retrieved.  
The original code use to do that, but is accidently removed by commit  
01edb5c7fc.  
  
Reported-by: Adrien Nayrat  
Author: Amit Kapila and Robert Haas  
Reviewed-by: Robert Haas and Andres Freund  
Backpatch-through: 9.6 where this code was introduced  
Discussion: https://postgr.es/m/86137f17-1dfb-42f9-7421-82fd786b04a1@anayrat.info  

M src/backend/executor/execProcnode.c
M src/backend/executor/nodeGather.c
M src/backend/executor/nodeLimit.c

Match the buffer usage tracking for leader and worker backends.

commit   : 3f02b5150ad9c97eec7238741411d8970be0eb67    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Fri, 3 Aug 2018 09:50:24 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Fri, 3 Aug 2018 09:50:24 +0530    

Click here for diff

In the leader backend, we don't track the buffer usage for ExecutorStart  
phase whereas in worker backend we track it for ExecutorStart phase as  
well.  This leads to different value for buffer usage stats for the  
parallel and non-parallel query.  Change the code so that worker backend  
also starts tracking buffer usage after ExecutorStart.  
  
Author: Amit Kapila and Robert Haas  
Reviewed-by: Robert Haas and Andres Freund  
Backpatch-through: 9.6 where this code was introduced  
Discussion:https://postgr.es/m/86137f17-1dfb-42f9-7421-82fd786b04a1@anayrat.info  

M src/backend/executor/execParallel.c

Fix libpq’s code for searching .pgpass; rationalize empty-list-item cases.

commit   : 71e3b28901871a72d46d5a8e00e0ff259f036d55    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 1 Aug 2018 12:30:36 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 1 Aug 2018 12:30:36 -0400    

Click here for diff

Before v10, we always searched ~/.pgpass using the host parameter,  
and nothing else, to match to the "hostname" field of ~/.pgpass.  
(However, null host or host matching DEFAULT_PGSOCKET_DIR was replaced by  
"localhost".)  In v10, this got broken by commit 274bb2b38, repaired by  
commit bdac9836d, and broken again by commit 7b02ba62e; in the code  
actually shipped, we'd search with hostaddr if both that and host were  
specified --- though oddly, *not* if only hostaddr were specified.  
Since this is directly contrary to the documentation, and not  
backwards-compatible, it's clearly a bug.  
  
However, the change wasn't totally without justification, even though it  
wasn't done quite right, because the pre-v10 behavior has arguably been  
buggy since we added hostaddr.  If hostaddr is specified and host isn't,  
the pre-v10 code will search ~/.pgpass for "localhost", and ship that  
password off to a server that most likely isn't local at all.  That's  
unhelpful at best, and could be a security breach at worst.  
  
Therefore, rather than just revert to that old behavior, let's define  
the behavior as "search with host if provided, else with hostaddr if  
provided, else search for localhost".  (As before, a host name matching  
DEFAULT_PGSOCKET_DIR is replaced by localhost.)  This matches the  
behavior of the actual connection code, so that we don't pick up an  
inappropriate password; and it allows useful searches to happen when  
only hostaddr is given.  
  
While we're messing around here, ensure that empty elements within a  
host or hostaddr list select the same behavior as a totally-empty  
field would; for instance "host=a,,b" is equivalent to "host=a,/tmp,b"  
if DEFAULT_PGSOCKET_DIR is /tmp.  Things worked that way in some cases  
already, but not consistently so, which contributed to the confusion  
about what key ~/.pgpass would get searched with.  
  
Update documentation accordingly, and also clarify some nearby text.  
  
Back-patch to v10 where the host/hostaddr list functionality was  
introduced.  
  
Discussion: https://postgr.es/m/30805.1532749137@sss.pgh.pa.us  

M doc/src/sgml/libpq.sgml
M src/interfaces/libpq/fe-connect.c

pg_upgrade: fix –check for live source server checks

commit   : d8dd8d221a057a10940c15745ec36e303c2db664    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 31 Jul 2018 18:10:06 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 31 Jul 2018 18:10:06 -0400    

Click here for diff

Fix for commit 244142d32afd02e7408a2ef1f249b00393983822.  
  
Backpatch-through: 9.3  

M src/bin/pg_upgrade/controldata.c

Further fixes for quoted-list GUC values in pg_dump and ruleutils.c.

commit   : 31b29b1b30c897bf6656fab45f60e3a355e5ca19    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 31 Jul 2018 13:00:08 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 31 Jul 2018 13:00:08 -0400    

Click here for diff

Commits 742869946 et al turn out to be a couple bricks shy of a load.  
We were dumping the stored values of GUC_LIST_QUOTE variables as they  
appear in proconfig or setconfig catalog columns.  However, although that  
quoting rule looks a lot like SQL-identifier double quotes, there are two  
critical differences: empty strings ("") are legal, and depending on which  
variable you're considering, values longer than NAMEDATALEN might be valid  
too.  So the current technique fails altogether on empty-string list  
entries (as reported by Steven Winfield in bug #15248) and it also risks  
truncating file pathnames during dump/reload of GUC values that are lists  
of pathnames.  
  
To fix, split the stored value without any downcasing or truncation,  
and then emit each element as a SQL string literal.  
  
This is a tad annoying, because we now have three copies of the  
comma-separated-string splitting logic in varlena.c as well as a fourth  
one in dumputils.c.  (Not to mention the randomly-different-from-those  
splitting logic in libpq...)  I looked at unifying these, but it would  
be rather a mess unless we're willing to tweak the API definitions of  
SplitIdentifierString, SplitDirectoriesString, or both.  That might be  
worth doing in future; but it seems pretty unsafe for a back-patched  
bug fix, so for now accept the duplication.  
  
Back-patch to all supported branches, as the previous fix was.  
  
Discussion: https://postgr.es/m/7585.1529435872@sss.pgh.pa.us  

M src/backend/utils/adt/ruleutils.c
M src/backend/utils/adt/varlena.c
M src/bin/pg_dump/dumputils.c
M src/bin/pg_dump/dumputils.h
M src/bin/pg_dump/pg_dump.c
M src/bin/pg_dump/pg_dumpall.c
M src/include/utils/varlena.h
M src/test/regress/expected/rules.out
M src/test/regress/sql/rules.sql

Set ActiveSnapshot when logically replaying inserts

commit   : 2c4d0f32e0c75179bba360ee884f535117b28b90    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 30 Jul 2018 16:30:07 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 30 Jul 2018 16:30:07 -0400    

Click here for diff

Input functions for the inserted tuples may require a snapshot, when  
they are replayed by native logical replication.  An example is a domain  
with a constraint using a SQL-language function, which prior to this  
commit failed to apply on the subscriber side.  
  
Reported-by: Mai Peng <maily.peng@webedia-group.com>  
Co-authored-by: Minh-Quan TRAN <qtran@itscaro.me>  
Co-authored-by: Álvaro Herrera <alvherre@alvh.no-ip.org>  
Discussion: https://postgr.es/m/4EB4BD78-BFC3-4D04-B8DA-D53DF7160354@webedia-group.com  
Discussion: https://postgr.es/m/153211336163.1404.11721804383024050689@wrigleys.postgresql.org  

M src/backend/replication/logical/worker.c
M src/test/subscription/t/002_types.pl

Fix pg_dump’s failure to dump REPLICA IDENTITY for constraint indexes.

commit   : 96b1d984feab268131dfd09dd7a1048dd221094f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 30 Jul 2018 12:35:49 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 30 Jul 2018 12:35:49 -0400    

Click here for diff

pg_dump knew about printing ALTER TABLE ... REPLICA IDENTITY USING INDEX  
for indexes declared as indexes, but it failed to print that for indexes  
declared as unique or primary-key constraints.  Per report from Achilleas  
Mantzios.  
  
This has been broken since the feature was introduced, AFAICS.  
Back-patch to 9.4.  
  
Discussion: https://postgr.es/m/1e6cc5ad-b84a-7c07-8c08-a4d0c3cdc938@matrix.gatewaynet.com  

M src/bin/pg_dump/pg_dump.c

Doc: fix oversimplified example for CREATE POLICY.

commit   : 406df42a5f6d7139df50f190cb7845418f9c0cfa    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 30 Jul 2018 11:54:41 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 30 Jul 2018 11:54:41 -0400    

Click here for diff

As written, this policy constrained only the post-image not the pre-image  
of rows, meaning that users could delete other users' rows or take  
ownership of such rows, contrary to what the docs claimed would happen.  
We need two separate policies to achieve the documented effect.  
  
While at it, try to explain what's happening a bit more fully.  
  
Per report from Олег Самойлов.  Back-patch to 9.5 where this was added.  
Thanks to Stephen Frost for off-list discussion.  
  
Discussion: https://postgr.es/m/3298321532002010@sas1-2b3c3045b736.qloud-c.yandex.net  

M doc/src/sgml/ddl.sgml

Fix earthdistance test suite function name typo.

commit   : e7688696db693fe4be8c08ce85fc2bc002bab285    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sun, 29 Jul 2018 12:02:07 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sun, 29 Jul 2018 12:02:07 -0700    

Click here for diff

Affected test queries have been testing the wrong thing since their  
introduction in commit 4c1383efd132e4f532213c8a8cc63a455f55e344.  
Back-patch to 9.3 (all supported versions).  

M contrib/earthdistance/expected/earthdistance.out
M contrib/earthdistance/sql/earthdistance.sql

Document security implications of qualified names.

commit   : ca4a6de17432bec94988a44de990481f0e18ab22    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sat, 28 Jul 2018 20:08:01 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sat, 28 Jul 2018 20:08:01 -0700    

Click here for diff

Commit 5770172cb0c9df9e6ce27c507b449557e5b45124 documented secure schema  
usage, and that advice suffices for using unqualified names securely.  
Document, in typeconv-func primarily, the additional issues that arise  
with qualified names.  Back-patch to 9.3 (all supported versions).  
  
Reviewed by Jonathan S. Katz.  
  
Discussion: https://postgr.es/m/20180721012446.GA1840594@rfd.leadboat.com  

M doc/src/sgml/ddl.sgml
M doc/src/sgml/ref/create_function.sgml
M doc/src/sgml/syntax.sgml
M doc/src/sgml/typeconv.sgml
M doc/src/sgml/xfunc.sgml
M src/backend/utils/adt/ruleutils.c

pgtest: run clean, build, and check stages separately

commit   : d524a11a72d65c96d16e6108387f2a8288ba15a6    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Sat, 28 Jul 2018 15:34:06 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Sat, 28 Jul 2018 15:34:06 -0400    

Click here for diff

This allows for cleaner error reporting.  
  
Backpatch-through: 9.5  

M src/tools/pgtest

pg_upgrade: check for clean server shutdowns

commit   : 9a13e7f0f0c932c06fb459f497be1d83b0916613    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Sat, 28 Jul 2018 15:01:55 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Sat, 28 Jul 2018 15:01:55 -0400    

Click here for diff

Previously pg_upgrade checked for the pid file and started/stopped the  
server to force a clean shutdown.  However, "pg_ctl -m immediate"  
removes the pid file but doesn't do a clean shutdown, so check  
pg_controldata for a clean shutdown too.  
  
Diagnosed-by: Vimalraj A  
  
Discussion: https://postgr.es/m/CAFKBAK5e4Q-oTUuPPJ56EU_d2Rzodq6GWKS3ncAk3xo7hAsOZg@mail.gmail.com  
  
Backpatch-through: 9.3  

M src/bin/pg_upgrade/controldata.c
M src/bin/pg_upgrade/pg_upgrade.c

pgtest: grab possible warnings from install.log

commit   : fe25526e9d5cd6418313c63e43d6780187a7d1b1    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Sat, 28 Jul 2018 11:35:52 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Sat, 28 Jul 2018 11:35:52 -0400    

Click here for diff

Since PG 9.5, 'make check' records the build output in install.log, so  
look in there for warnings too.  
  
Backpatch-through: 9.5  

M src/tools/pgtest

Fix the buffer release order for parallel index scans.

commit   : ff8ce0b79009cb178f2572ce0abc861e4a0a3fe5    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Fri, 27 Jul 2018 11:05:06 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Fri, 27 Jul 2018 11:05:06 +0530    

Click here for diff

During parallel index scans, if the current page to be read is deleted, we  
skip it and try to get the next page for a scan without releasing the buffer  
lock on the current page.  To get the next page, sometimes it needs to wait  
for another process to complete its scan and advance it to the next page.  
Now, it is quite possible that the master backend has errored out before  
advancing the scan and issued a termination signal for all workers.  The  
workers failed to notice the termination request during wait because the  
interrupts are held due to buffer lock on the previous page.  This lead to  
all workers being stuck.  
  
The fix is to release the buffer lock on current page before trying to get  
the next page.  We are already doing same in backward scans, but missed  
it for forward scans.  
  
Reported-by: Victor Yegorov  
Bug: 15290  
Diagnosed-by: Thomas Munro and Amit Kapila  
Author: Amit Kapila  
Reviewed-by: Thomas Munro  
Tested-By: Thomas Munro and Victor Yegorov  
Backpatch-through: 10 where parallel index scans were introduced  
Discussion: https://postgr.es/m/153228422922.1395.1746424054206154747@wrigleys.postgresql.org  

M src/backend/access/nbtree/nbtsearch.c

Pad semaphores to avoid false sharing.

commit   : 46201d603f9c79d99e56ce62fb71aae31a99303d    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Wed, 25 Jul 2018 10:58:54 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Wed, 25 Jul 2018 10:58:54 +1200    

Click here for diff

In a USE_UNNAMED_SEMAPHORES build, the default on Linux and FreeBSD  
since commit ecb0d20a, we have an array of sem_t objects.  This  
turned out to reduce performance compared to the previous default  
USE_SYSV_SEMAPHORES on an 8 socket system.  Testing showed that the  
lost performance could be regained by padding the array elements so  
that they have their own cache lines.  This matches what we do for  
similar hot arrays (see LWLockPadded, WALInsertLockPadded).  
  
Back-patch to 10, where unnamed semaphores were adopted as the default  
semaphore interface on those operating systems.  
  
Author: Thomas Munro  
Reviewed-by: Andres Freund  
Reported-by: Mithun Cy  
Tested-by: Mithun Cy, Tom Lane, Thomas Munro  
Discussion: https://postgr.es/m/CAD__OugYDM3O%2BdyZnnZSbJprSfsGFJcQ1R%3De59T3hcLmDug4_w%40mail.gmail.com  

M src/backend/port/posix_sema.c

doc: Fix reference to “decoder” to instead be the correct “output plugin”.

commit   : 360cbf1a82894db1e948e152327e84ffa650e99a    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Tue, 24 Jul 2018 10:51:09 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Tue, 24 Jul 2018 10:51:09 -0700    

Click here for diff

Author: Jonathan Katz  
Discussion: https://postgr.es/m/DD02DD86-5989-4BFD-8712-468541F68383@postgresql.org  
Backpatch: 9.4-, where logical decoding was added  

M doc/src/sgml/test-decoding.sgml

Further portability hacking in pg_upgrade’s test script.

commit   : dfbad3f454103e7cd379595fdcdce3952effbd5f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 21 Jul 2018 15:40:51 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 21 Jul 2018 15:40:51 -0400    

Click here for diff

I blew the dust off a Bourne shell (file date 1996, yea verily) and  
tried to run test.sh with it.  It mostly worked, but I found that the  
temp-directory creation code introduced by commit be76a6d39 was not  
compatible, for a couple of reasons: this shell thinks "set -e" should  
force an exit if a command within backticks fails, and it also thinks code  
within braces should be executed by a sub-shell, meaning that variable  
settings don't propagate back up to the parent shell.  In view of Victor  
Wagner's report that Solaris is still using pre-POSIX shells, seems like  
we oughta make this case work.  It's not like the code is any less  
idiomatic this way; the prior coding technique appeared nowhere else.  
  
(There is a remaining bash-ism here, which is that $RANDOM doesn't do  
what the code hopes in non-bash shells.  But the use of $$ elsewhere in  
that path should be enough to ensure uniqueness and some amount of  
randomness, so I think it's okay as-is.)  
  
Back-patch to all supported branches, as the previous commit was.  
  
Discussion: https://postgr.es/m/20180720153820.69e9ae6c@fafnir.local.vm  

M src/bin/pg_upgrade/test.sh

Guard against rare RAND_bytes() failures in pg_strong_random().

commit   : 821200405cc3f25fda28c5f58d17d640e25559b8    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Fri, 20 Jul 2018 08:58:37 +0100    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Fri, 20 Jul 2018 08:58:37 +0100    

Click here for diff

When built using OpenSSL, pg_strong_random() uses RAND_bytes() to  
generate the random number. On very rare occasions that can fail, if  
its PRNG has not been seeded with enough data. Additionally, once it  
does fail, all subsequent calls will also fail until more seed data is  
added. Since this is required during backend startup, this can result  
in all new backends failing to start until a postmaster restart.  
  
Guard against that by checking the state of OpenSSL's PRNG using  
RAND_status(), and if necessary (very rarely), seeding it using  
RAND_poll().  
  
Back-patch to v10, where pg_strong_random() was introduced.  
  
Dean Rasheed and Michael Paquier.  
  
Discussion: https://postgr.es/m/CAEZATCXMtxbzSAvyKKk5uCRf9pNt4UV%2BF_5v%3DgLfJUuPxU4Ytg%40mail.gmail.com  

M src/port/pg_strong_random.c

Remove undocumented restriction against duplicate partition key columns.

commit   : 2131d4501f9472ed3714970e45485e5e892615e8    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 19 Jul 2018 15:41:46 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 19 Jul 2018 15:41:46 -0400    

Click here for diff

transformPartitionSpec rejected duplicate simple partition columns  
(e.g., "PARTITION BY RANGE (x,x)") but paid no attention to expression  
columns, resulting in inconsistent behavior.  Worse, cases like  
"PARTITION BY RANGE (x,(x))") were accepted but would then result in  
dump/reload failures, since the expression (x) would get simplified  
to a plain column later.  
  
There seems no better reason for this restriction than there was for  
the one against duplicate included index columns (cf commit 701fd0bbc),  
so let's just remove it.  
  
Back-patch to v10 where this code was added.  
  
Report and patch by Yugo Nagata.  
  
Discussion: https://postgr.es/m/20180712165939.36b12aff.nagata@sraoss.co.jp  

M src/backend/commands/tablecmds.c
M src/test/regress/expected/create_table.out
M src/test/regress/sql/create_table.sql

Fix handling of empty uncompressed posting list pages in GIN

commit   : 0d26812a4331a5bc50c1bb3115702d48d2601453    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Thu, 19 Jul 2018 21:04:17 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Thu, 19 Jul 2018 21:04:17 +0300    

Click here for diff

PostgreSQL 9.4 introduces posting list compression in GIN.  This feature  
supports online upgrade, so that after pg_upgrade uncompressed posting  
lists are compressed on-the-fly.  Underlying code appears to always  
expect at least one item on uncompressed posting list page.  But there  
could be completely empty pages, because VACUUM never deletes leftmost  
and rightmost pages from posting trees.  This commit fixes that.  
  
Reported-by: Sivasubramanian Ramasubramanian  
Discussion: https://postgr.es/m/1531867212836.63354%40amazon.com  
Author: Sivasubramanian Ramasubramanian, Alexander Korotkov  
Backpatch-through: 9.4  

M src/backend/access/gin/gindatapage.c
M src/backend/access/gin/ginxlog.c

Fix error message when a hostaddr cannot be parsed.

commit   : ff4fb4cc1bde61a536a30834d19be088828a350e    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 19 Jul 2018 20:24:29 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 19 Jul 2018 20:24:29 +0300    

Click here for diff

We were incorrectly passing hostname, not hostaddr, in the error message,  
and because of that, you got:  
  
$ psql 'hostaddr=foo'  
psql: could not parse network address "(null)": Name or service not known  
  
Backpatch to v10, where this was broken (by commit 7b02ba62e9).  
  
Report and fix by Robert Haas.  
  
Discussion: https://www.postgresql.org/message-id/CA+TgmoapFQA30NomGKEaZCu3iN7mF7fux8fbbk9SouVOT2JP7w@mail.gmail.com  

M src/interfaces/libpq/fe-connect.c

Rephrase a few comments for clarity.

commit   : a1dc4ea02044af557e4464029016507ea0940d8c    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 19 Jul 2018 16:08:09 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 19 Jul 2018 16:08:09 +0300    

Click here for diff

I was confused by what "intended to be parallel serially" meant, until  
Robert Haas and David G. Johnston explained it. Rephrase the comment to  
make it more clear, using David's suggested wording.  
  
Discussion: https://www.postgresql.org/message-id/1fec9022-41e8-e484-70ce-2179b08c2092%40iki.fi  

M src/backend/executor/nodeIndexonlyscan.c
M src/backend/executor/nodeIndexscan.c
M src/backend/executor/nodeSeqscan.c

Fix print of Path nodes when using OPTIMIZER_DEBUG

commit   : 49d506dd2162c1798150bab18d7c332d29b4aa93    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 19 Jul 2018 09:55:15 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 19 Jul 2018 09:55:15 +0900    

Click here for diff

GatherMergePath (introduced in 10) and CustomPath (introduced in 9.5)  
have gone missing.  The order of the Path nodes was inconsistent with  
what is listed in nodes.h, so make the order consistent at the same time  
to ease future checks and additions.  
  
Author: Sawada Masahiko  
Reviewed-by: Michael Paquier  
Discussion: https://postgr.es/m/CAD21AoBQMLoc=ohH-oocuAPsELrmk8_EsRJjOyR8FQLZkbE0wA@mail.gmail.com  

M src/backend/optimizer/path/allpaths.c

Remove race-prone hot_standby_feedback test cases in 001_stream_rep.pl.

commit   : 5c513db12c2921a1cf31348132ede42442517389    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 18 Jul 2018 17:39:27 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 18 Jul 2018 17:39:27 -0400    

Click here for diff

This script supposed that if it turned hot_standby_feedback on and then  
shut down the standby server, at least one feedback message would be  
guaranteed to be sent before the standby stops.  But there is no such  
guarantee, if the standby's walreceiver process is slow enough --- and  
we've seen multiple failures in the buildfarm showing that that does  
happen in practice.  While we could rearrange the walreceiver logic to  
make it less likely, it seems probably impossible to create a really  
bulletproof guarantee of that sort; and if we tried, we might create  
situations where the walreceiver wouldn't react in a timely manner to  
shutdown commands.  It seems better instead to remove the script's  
assumption that feedback will occur before shutdown.  
  
But once we do that, these last few tests seem quite redundant with  
the earlier tests in the script.  So let's just drop them altogether  
and save some buildfarm cycles.  
  
Backpatch to v10 where these tests were added.  
  
Discussion: https://postgr.es/m/1922.1531592205@sss.pgh.pa.us  

M src/test/recovery/t/001_stream_rep.pl

Fix misc typos, mostly in comments.

commit   : ed529faf7ec1e1a879c6f3b9eecd426c813749e6    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 9 Jul 2018 16:10:44 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 9 Jul 2018 16:10:44 +0300    

Click here for diff

A collection of typos I happened to spot while reading code, as well as  
grepping for common mistakes.  
  
Backpatch to all supported versions, as applicable, to avoid conflicts  
when backporting other commits in the future.  

M contrib/bloom/blscan.c
M doc/src/sgml/protocol.sgml
M doc/src/sgml/spi.sgml
M src/backend/access/transam/multixact.c
M src/backend/commands/cluster.c
M src/backend/executor/nodeModifyTable.c
M src/backend/replication/logical/origin.c
M src/backend/utils/time/snapmgr.c
M src/bin/initdb/t/001_initdb.pl
M src/bin/pg_upgrade/tablespace.c
M src/include/nodes/parsenodes.h
M src/include/storage/latch.h
M src/interfaces/ecpg/ecpglib/execute.c
M src/pl/tcl/pltcl.c
M src/test/regress/expected/rowsecurity.out
M src/test/regress/expected/rules.out
M src/test/regress/sql/rowsecurity.sql
M src/test/regress/sql/rules.sql

Add subtransaction handling for table synchronization workers.

commit   : 4beb25c63221393f8a7ec790ebce1d6b5911289a    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Mon, 16 Jul 2018 17:33:22 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Mon, 16 Jul 2018 17:33:22 -0400    

Click here for diff

Since the old logic was completely unaware of subtransactions, a  
change made in a subsequently-aborted subtransaction would still cause  
workers to be stopped at toplevel transaction commit.  Fix that by  
managing a stack of worker lists rather than just one.  
  
Amit Khandekar and Robert Haas  
  
Discussion: http://postgr.es/m/CAJ3gD9eaG_mWqiOTA2LfAug-VRNn1hrhf50Xi1YroxL37QkZNg@mail.gmail.com  

M src/backend/access/transam/xact.c
M src/backend/replication/logical/launcher.c
M src/include/replication/logicallauncher.h
M src/tools/pgindent/typedefs.list

Fix hashjoin costing mistake introduced with inner_unique optimization.

commit   : 0bb28ca36eaf14ba73695bc0a29e3f36de34e07b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 14 Jul 2018 11:59:12 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 14 Jul 2018 11:59:12 -0400    

Click here for diff

In final_cost_hashjoin(), commit 9c7f5229a allowed inner_unique cases  
to follow a code path previously used only for SEMI/ANTI joins; but it  
neglected to fix an if-test within that path that assumed SEMI and ANTI  
were the only possible cases.  This resulted in a wrong value for  
hashjointuples, and an ensuing bad cost estimate, for inner_unique normal  
joins.  Fortunately, for inner_unique normal joins we can assume the number  
of joined tuples is the same as for a SEMI join; so there's no need for  
more code, we just have to invert the test to check for ANTI not SEMI.  
  
It turns out that in two contrib tests in which commit 9c7f5229a  
changed the plan expected for a query, the change was actually wrong  
and induced by this estimation error, not by any real improvement.  
Hence this patch also reverts those changes.  
  
Per report from RK Korlapati.  Backpatch to v10 where the error was  
introduced.  
  
David Rowley  
  
Discussion: https://postgr.es/m/CA+SNy03bhq0fodsfOkeWDCreNjJVjsdHwUsb7AG=jpe0PtZc_g@mail.gmail.com  

M contrib/citext/expected/citext.out
M contrib/citext/expected/citext_1.out
M contrib/postgres_fdw/expected/postgres_fdw.out
M src/backend/optimizer/path/costsize.c

Fix crash in contrib/ltree’s lca() function for empty input array.

commit   : 1f47eb08cb42986f1f0c6ef52156f55ba9f7b1a3    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 13 Jul 2018 18:45:30 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 13 Jul 2018 18:45:30 -0400    

Click here for diff

lca_inner() wasn't prepared for the possibility of getting no inputs.  
Fix that, and make some cosmetic improvements to the code while at it.  
  
Also, I thought the documentation of this function as returning the  
"longest common prefix" of the paths was entirely misleading; it really  
returns a path one shorter than the longest common prefix, for the typical  
definition of "prefix".  Don't use that term in the docs, and adjust the  
examples to clarify what really happens.  
  
This has been broken since its beginning, so back-patch to all supported  
branches.  
  
Per report from Hailong Li.  Thanks to Pierre Ducroquet for diagnosing  
and for the initial patch, though I whacked it around some and added  
test cases.  
  
Discussion: https://postgr.es/m/5b0d8e4f-f2a3-1305-d612-e00e35a7be66@qunar.com  

M contrib/ltree/expected/ltree.out
M contrib/ltree/ltree_op.c
M contrib/ltree/sql/ltree.sql
M doc/src/sgml/ltree.sgml

Fix inadequate buffer locking in FSM and VM page re-initialization.

commit   : f1963a1e79a499c2cf362fa41206a3b9e4348a54    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 13 Jul 2018 11:52:50 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 13 Jul 2018 11:52:50 -0400    

Click here for diff

When reading an existing FSM or VM page that was found to be corrupt by the  
buffer manager, the code applied PageInit() to reinitialize the page, but  
did so without any locking.  There is thus a hazard that two backends might  
concurrently do PageInit, which in itself would still be OK, but the slower  
one might then zero over subsequent data changes applied by the faster one.  
Even that is unlikely to be fatal; but it's not desirable, so add locking  
to prevent it.  
  
This does not add any locking overhead in the normal code path where the  
page is OK.  It's not immediately obvious that that's safe, but I believe  
it is, for reasons explained in the added comments.  
  
Problem noted by R P Asim.  It's been like this for a long time, so  
back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/CANXE4Te4G0TGq6cr0-TvwP0H4BNiK_-hB5gHe8mF+nz0mcYfMQ@mail.gmail.com  

M src/backend/access/heap/visibilitymap.c
M src/backend/storage/freespace/freespace.c

docs: Remove “New” description of the libpqxx interface

commit   : c81e49bd0fd6fe10b082ca27ea1158ea01fae0d3    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Fri, 13 Jul 2018 11:16:55 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Fri, 13 Jul 2018 11:16:55 -0400    

Click here for diff

Backpatch-through: 9.3  

M doc/src/sgml/external-projects.sgml

Doc: minor improvement in pl/pgsql FETCH/MOVE documentation.

commit   : 93532dbb5d91280400d337197752f4f91f29349f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 12 Jul 2018 12:28:43 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 12 Jul 2018 12:28:43 -0400    

Click here for diff

Explain that you can use any integer expression for the "count" in  
pl/pgsql's versions of FETCH/MOVE, unlike the SQL versions which only  
allow a constant.  
  
Remove the duplicate version of this para under MOVE.  I don't see  
a good reason to maintain two identical paras when we just said that  
MOVE works exactly like FETCH.  
  
Per Pavel Stehule, though I didn't use his text.  
  
Discussion: https://postgr.es/m/CAFj8pRAcvSXcNdUGx43bOK1e3NNPbQny7neoTLN42af+8MYWEA@mail.gmail.com  

M doc/src/sgml/plpgsql.sgml
M doc/src/sgml/ref/fetch.sgml

Make logical WAL sender report streaming state appropriately

commit   : 11abea37d5d16e553a93fc96fd95421090d78fe0    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 12 Jul 2018 10:20:08 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 12 Jul 2018 10:20:08 +0900    

Click here for diff

WAL senders sending logically-decoded data fail to properly report in  
"streaming" state when starting up, hence as long as one extra record is  
not replayed, such WAL senders would remain in a "catchup" state, which  
is inconsistent with the physical cousin.  
  
This can be easily reproduced by for example using pg_recvlogical and  
restarting the upstream server.  The TAP tests have been slightly  
modified to detect the failure and strengthened so as future tests also  
make sure that a node is in streaming state when waiting for its  
catchup.  
  
Backpatch down to 9.4 where this code has been introduced.  
  
Reported-by: Sawada Masahiko  
Author: Simon Riggs, Sawada Masahiko  
Reviewed-by: Petr Jelinek, Michael Paquier, Vaishnavi Prabakaran  
Discussion: https://postgr.es/m/CAD21AoB2ZbCCqOx=bgKMcLrAvs1V0ZMqzs7wBTuDySezTGtMZA@mail.gmail.com  

M src/backend/replication/walsender.c

Fix create_scan_plan’s handling of sortgrouprefs for physical tlists.

commit   : c3503202708c467f609163672ca09f2db082f3b5    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 11 Jul 2018 15:25:29 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 11 Jul 2018 15:25:29 -0400    

Click here for diff

We should only run apply_pathtarget_labeling_to_tlist if CP_LABEL_TLIST  
was specified, because only in that case has use_physical_tlist checked  
that the labeling will succeed; otherwise we may get an "ORDER/GROUP BY  
expression not found in targetlist" error.  (This subsumes the previous  
test about gating_clauses, because we reset "flags" to zero earlier  
if there are gating clauses to apply.)  
  
The only known case in which a failure can occur is with a ProjectSet  
path directly atop a table scan path, although it seems likely that there  
are other cases or will be such in future.  This means that the failure  
is currently only visible in the v10 branch: 9.6 didn't have ProjectSet,  
while in v11 and HEAD, apply_scanjoin_target_to_paths for some weird  
reason is using create_projection_path not apply_projection_to_path,  
masking the problem because there's a ProjectionPath in between.  
  
Nonetheless this code is clearly wrong on its own terms, so back-patch  
to 9.6 where this logic was introduced.  
  
Per report from Regina Obe.  
  
Discussion: https://postgr.es/m/001501d40f88$75186950$5f493bf0$@pcorp.us  

M src/backend/optimizer/plan/createplan.c
M src/test/regress/expected/tsrf.out
M src/test/regress/sql/tsrf.sql

Better handle pseudotypes as partition keys

commit   : 7c644b7d3f83b642aac16bc57dfe0de76a7045bb    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 10 Jul 2018 15:07:28 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 10 Jul 2018 15:07:28 -0400    

Click here for diff

We fail to handle polymorphic types properly when they are used as  
partition keys: we were unnecessarily adding a RelabelType node on top,  
which confuses code examining the nodes.  In particular, this makes  
predtest.c-based partition pruning not to work, and ruleutils.c to emit  
expressions that are uglier than needed.  Fix it by not adding RelabelType  
when not needed.  
  
In master/11 the new pruning code is separate so it doesn't suffer from  
this problem, since we already fixed it (in essentially the same way) in  
e5dcbb88a15d, which also added a few tests; back-patch those tests to  
pg10 also.  But since UPDATE/DELETE still uses predtest.c in pg11, this  
change improves partitioning for those cases too.  Add tests for this.  
The ruleutils.c behavior change is relevant in pg11/master too.  
  
Co-authored-by: Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>  
Co-authored-by: Álvaro Herrera <alvherre@alvh.no-ip.org>  
Reviewed-by: Álvaro Herrera <alvherre@alvh.no-ip.org>  
Reviewed-by: Robert Haas <robertmhaas@gmail.com>  
Discussion: https://postgr.es/m/54745d13-7ed4-54ac-97d8-ea1eec95ae25@lab.ntt.co.jp  

M src/backend/catalog/partition.c
M src/test/regress/expected/create_table.out
M src/test/regress/expected/inherit.out
M src/test/regress/sql/inherit.sql

Fix typos

commit   : 7f0911f33ece28c85e9561f7b3e4157336cfd354    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 10 Jul 2018 11:14:53 +0200    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 10 Jul 2018 11:14:53 +0200    

Click here for diff

M config/c-compiler.m4
M src/include/pg_config.h.in

Avoid emitting a bogus WAL record when recycling an all-zero btree page.

commit   : 59b2dcbf45abd1139741054039de36ae3d2e2a1a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Jul 2018 19:26:19 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Jul 2018 19:26:19 -0400    

Click here for diff

Commit fafa374f2 caused _bt_getbuf() to possibly emit a WAL record for  
a page that it was about to recycle.  However, it failed to distinguish  
all-zero pages from dead pages, which is important because only the  
latter have valid btpo.xact values, or indeed any special space at all.  
Recycling an all-zero page with XLogStandbyInfoActive() enabled therefore  
led to an Assert failure, or to emission of a WAL record containing a  
bogus cutoff XID, which might lead to unnecessary query cancellations  
on hot standby servers.  
  
Per reports from Antonin Houska and 自己.  Amit Kapila was first to  
propose this fix, and Robert Haas, myself, and Kyotaro Horiguchi  
reviewed it at various times.  
  
This is an old bug, so back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/2628.1474272158@localhost  
Discussion: https://postgr.es/m/48875502.f4a0.1635f0c27b0.Coremail.zoulx1982@163.com  

M src/backend/access/nbtree/nbtpage.c

Prevent accidental linking of system-supplied copies of libpq.so etc.

commit   : c74f48a4ec54c36b515f85a6b779a4751b7070b7    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Jul 2018 17:23:31 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Jul 2018 17:23:31 -0400    

Click here for diff

Back-patch commit dddfc4cb2, which broke LDFLAGS and related Makefile  
variables into two parts, one for within-build-tree library references and  
one for external libraries, to ensure that the order of -L flags has all  
of the former before all of the latter.  This turns out to fix a problem  
recently noted on buildfarm member peripatus, that we attempted to  
incorporate code from libpgport.a into a shared library.  That will fail on  
platforms that are sticky about putting non-PIC code into shared libraries.  
(It's quite surprising we hadn't seen such failures before, since the code  
in question has been like that for a long time.)  
  
I think that peripatus' problem could have been fixed with just a subset  
of this patch; but since the previous issue of accidentally linking to the  
wrong copy of a Postgres shlib seems likely to bite people in the field,  
let's just back-patch the whole change.  Now that commit dddfc4cb2 has  
survived some beta testing, I'm less afraid to back-patch it than I was  
at the time.  
  
This also fixes undesired inclusion of "-DFRONTEND" in pg_config's CPPFLAGS  
output (in 9.6 and up) and undesired inclusion of "-L../../src/common" in  
its LDFLAGS output (in all supported branches).  
  
Back-patch to v10 and older branches; this is already in v11.  
  
Discussion: https://postgr.es/m/20180704234304.bq2dxispefl65odz@ler-imac.local  

M contrib/dblink/Makefile
M contrib/hstore_plperl/Makefile
M contrib/hstore_plpython/Makefile
M contrib/ltree_plpython/Makefile
M contrib/oid2name/Makefile
M contrib/postgres_fdw/Makefile
M contrib/spi/Makefile
M contrib/vacuumlo/Makefile
M src/Makefile.global.in
M src/Makefile.shlib
M src/backend/replication/libpqwalreceiver/Makefile
M src/bin/initdb/Makefile
M src/bin/pg_basebackup/Makefile
M src/bin/pg_ctl/Makefile
M src/bin/pg_dump/Makefile
M src/bin/pg_rewind/Makefile
M src/bin/pg_upgrade/Makefile
M src/bin/pgbench/Makefile
M src/bin/psql/Makefile
M src/bin/scripts/Makefile
M src/common/Makefile
M src/interfaces/ecpg/compatlib/Makefile
M src/interfaces/ecpg/ecpglib/Makefile
M src/interfaces/ecpg/pgtypeslib/Makefile
M src/interfaces/ecpg/test/Makefile.regress
M src/interfaces/ecpg/test/compat_informix/Makefile
M src/interfaces/libpq/test/Makefile
M src/makefiles/pgxs.mk
M src/test/examples/Makefile
M src/tools/findoidjoins/Makefile

rel notes: mention enabling of parallelism in PG 10

commit   : b0da7ecad332244364152ff6f00fd0ceb8733781    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 9 Jul 2018 11:19:18 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 9 Jul 2018 11:19:18 -0400    

Click here for diff

Reported-by: Justin Pryzby  
  
Discussion: https://postgr.es/m/20180525010025.GT30060@telsasoft.com  
  
Backpatch-through: 10  

M doc/src/sgml/release-10.sgml

Rework order of end-of-recovery actions to delay timeline history write

commit   : c030db349501600e9d45857da9b461e91b387441    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 9 Jul 2018 10:26:18 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 9 Jul 2018 10:26:18 +0900    

Click here for diff

A critical failure in some of the end-of-recovery actions before the  
end-of-recovery record is written can cause PostgreSQL to react  
inconsistently with the rest of the cluster in the event of a crash  
before the final record is written.  Two such failures are for example  
an error while processing a two-phase state files or when operating on  
recovery.conf.  With this commit, the failures are still considered  
FATAL, but the write of the timeline history file is delayed as much as  
possible so as the window between the moment the file is written and the  
end-of-recovery record is generated gets minimized. This way, in the  
event of a crash or a failure, the new timeline decided at promotion  
will not seem taken by other nodes in the cluster.  It is not really  
possible to reduce to zero this window, hence one could still see  
failures if a crash happens between the history file write and the  
end-of-recovery record, so any future code should be careful when  
adding new end-of-recovery actions.  The original report from Magnus  
Hagander mentioned a renamed recovery.conf as original end-of-recovery  
failure which caused a timeline to be seen as taken but the subsequent  
processing on the now-missing recovery.conf cause the startup process to  
issue stop on FATAL, which at follow-up startup made the system  
inconsistent because of on-disk changes which already happened.  
  
Processing of two-phase state files still needs some work as corrupted  
entries are simply ignored now.  This is left as a future item and this  
commit fixes the original complain.  
  
Reported-by: Magnus Hagander  
Author: Heikki Linnakangas  
Reviewed-by: Alexander Korotkov, Michael Paquier, David Steele  
Discussion: https://postgr.es/m/CABUevEz09XY2EevA2dLjPCY-C5UO4Hq=XxmXLmF6ipNFecbShQ@mail.gmail.com  

M src/backend/access/transam/xlog.c

Add note in pg_rewind documentation about read-only files

commit   : 42303977916599074a96d760d645180fc8df9867    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sat, 7 Jul 2018 08:10:39 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sat, 7 Jul 2018 08:10:39 +0900    

Click here for diff

When performing pg_rewind, the presence of a read-only file which is not  
accessible for writes will cause a failure while processing.  This can  
cause the control file of the target data folder to be truncated,  
causing it to not be reusable with a successive run.  
  
Also, when pg_rewind fails mid-flight, there is likely no way to be able  
to recover the target data folder anyway, in which case a new base  
backup is the best option.  A note is added in the documentation as  
well about.  
  
Reported-by: Christian H.  
Author: Michael Paquier  
Reviewed-by: Andrew Dunstan  
Discussion: https://postgr.es/m/20180104200633.17004.16377%40wrigleys.postgresql.org  

M doc/src/sgml/ref/pg_rewind.sgml

Allow replication slots to be dropped in single-user mode

commit   : a1f680d962ffdd563eee7665da5b3b9967a6070f    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 6 Jul 2018 16:38:29 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 6 Jul 2018 16:38:29 -0400    

Click here for diff

Starting with commit 9915de6c1cb2, replication slot drop uses a  
condition variable sleep to wait until the current user of the slot goes  
away.  This is more user friendly than the previous behavior of erroring  
out if the slot is in use, but it fails with a not-for-user-consumption  
error message in single-user mode; plus, if you're using single-user  
mode because you don't want to start the server in the regular mode  
(say, disk is full and WAL won't recycle because of the slot), it's  
inconvenient.  
  
Fix by skipping the cond variable sleep in single-user mode, since  
there can't be anybody to wait for anyway.  
  
Reported-by: tushar <tushar.ahuja@enterprisedb.com>  
Author: Álvaro Herrera <alvherre@alvh.no-ip.org>  
Discussion: https://postgr.es/m/3b2f809f-326c-38dd-7a9e-897f957a4eb1@enterprisedb.com  

M src/backend/replication/slot.c

logical decoding: beware of an unset specinsert change

commit   : bba8c612117416907f332fce8b9e80b748e0b798    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 5 Jul 2018 17:42:37 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 5 Jul 2018 17:42:37 -0400    

Click here for diff

Coverity complains that there is no protection in the code (at least in  
non-assertion-enabled builds) against speculative insertion failing to  
follow the expected protocol.  Add an elog(ERROR) for the case.  

M src/backend/replication/logical/reorderbuffer.c

Reduce cost of test_decoding’s new oldest_xmin test

commit   : 7acbb481c808effffae7033b5ea1069112d6545f    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 5 Jul 2018 16:37:32 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 5 Jul 2018 16:37:32 -0400    

Click here for diff

Change a whole-database VACUUM into doing just pg_attribute, which is  
the portion that verifies what we want it to do.  The original  
formulation wastes a lot of CPU time, which leads the test to fail when  
runtime exceeds isolationtester timeout when it's super-slow, such as  
under CLOBBER_CACHE_ALWAYS.  Per buildfarm member friarbird.  
  
It turns out that the previous shape of the test doesn't always detect  
the condition it is supposed to detect (on unpatched reorderbuffer  
code): the reason is that there is a good chance of encountering a  
xl_running_xacts record (logged every 15 seconds) before the checkpoint  
-- and because we advance the xmin when we receive that WAL record, and  
we *don't* advance the xmin twice consecutively without receiving a  
client message in between, that means the xmin is not advanced enough  
for the tuple to be pruned from pg_attribute by VACUUM.  So the test  
would spuriously pass.  
  
The reason this test deficiency wasn't detected earlier is that HOT  
pruning removes the tuple anyway, even if vacuum leaves it in place, so  
the test correctly fails (detecting the coding mistake), but for the  
wrong reason.  
  
To fix this mess, run the s0_get_changes step twice before vacuum  
instead of once: this seems to cause the xmin to be advanced reliably,  
wreaking havoc with more certainty.  
  
Author: Arseny Sher  
Discussion: https://postgr.es/m/87h8lkuxoa.fsf@ars-thinkpad  

M contrib/test_decoding/expected/oldest_xmin.out
M contrib/test_decoding/specs/oldest_xmin.spec

doc: Fix typos

commit   : b1def471d5a24648c1c5005da182c74a828ae2f6    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 5 Jul 2018 22:52:19 +0200    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 5 Jul 2018 22:52:19 +0200    

Click here for diff

Author: Justin Pryzby <pryzby@telsasoft.com>  

M doc/src/sgml/ddl.sgml

Fix typo

commit   : fbbe29ba66d0d707977f17f6194be6d6ad8c3888    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 3 Jul 2018 20:18:56 +0200    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 3 Jul 2018 20:18:56 +0200    

Click here for diff

M doc/src/sgml/ref/psql-ref.sgml

doc: Improve wording and fix whitespace

commit   : a1974349bdd588683db9e445104119fb3c94a08c    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 27 Jun 2018 07:51:20 +0200    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 27 Jun 2018 07:51:20 +0200    

Click here for diff

M doc/src/sgml/logical-replication.sgml

Prevent references to invalid relation pages after fresh promotion

commit   : 6716f2f96256d1705c4a634741a950e6fa32e92d    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 5 Jul 2018 10:47:01 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 5 Jul 2018 10:47:01 +0900    

Click here for diff

If a standby crashes after promotion before having completed its first  
post-recovery checkpoint, then the minimal recovery point which marks  
the LSN position where the cluster is able to reach consistency may be  
set to a position older than the first end-of-recovery checkpoint while  
all the WAL available should be replayed.  This leads to the instance  
thinking that it contains inconsistent pages, causing a PANIC and a hard  
instance crash even if all the WAL available has not been replayed for  
certain sets of records replayed.  When in crash recovery,  
minRecoveryPoint is expected to always be set to InvalidXLogRecPtr,  
which forces the recovery to replay all the WAL available, so this  
commit makes sure that the local copy of minRecoveryPoint from the  
control file is initialized properly and stays as it is while crash  
recovery is performed.  Once switching to archive recovery or if crash  
recovery finishes, then the local copy minRecoveryPoint can be safely  
updated.  
  
Pavan Deolasee has reported and diagnosed the failure in the first  
place, and the base fix idea to rely on the local copy of  
minRecoveryPoint comes from Kyotaro Horiguchi, which has been expanded  
into a full-fledged patch by me.  The test included in this commit has  
been written by Álvaro Herrera and Pavan Deolasee, which I have modified  
to make it faster and more reliable with sleep phases.  
  
Backpatch down to all supported versions where the bug appears, aka 9.3  
which is where the end-of-recovery checkpoint is not run by the startup  
process anymore.  The test gets easily supported down to 10, still it  
has been tested on all branches.  
  
Reported-by: Pavan Deolasee  
Diagnosed-by: Pavan Deolasee  
Reviewed-by: Pavan Deolasee, Kyotaro Horiguchi  
Author: Michael Paquier, Kyotaro Horiguchi, Pavan Deolasee, Álvaro  
Herrera  
Discussion: https://postgr.es/m/CABOikdPOewjNL=05K5CbNMxnNtXnQjhTx2F--4p4ruorCjukbA@mail.gmail.com  

M src/backend/access/transam/xlog.c
A src/test/recovery/t/013_promotion_pages.pl

Check for interrupts inside the nbtree page deletion code.

commit   : 0095809890dd74e8f8aa54c684f84e76aebf9406    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Wed, 4 Jul 2018 14:53:30 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Wed, 4 Jul 2018 14:53:30 -0700    

Click here for diff

When deleting pages the nbtree code has to walk through siblings of a  
tree node. When those sibling links are corrupted that can lead to  
endless loops - which are currently not interruptible.  This is  
especially problematic if autovacuum is repeatedly blocked on such  
indexes, as it can be hard to get out of that situation without  
resorting to single user mode.  
  
Thus add interrupt checks to appropriate places in such  
loops. Unfortunately in one of the cases it's it's not easy to do so.  
  
Between 9.3 and 9.4 the page deletion (and page split) code changed  
significantly. Before it was significantly less robust against  
interruptions. Therefore don't backpatch to 9.3.  
  
Author: Andres Freund  
Discussion: https://postgr.es/m/20180627191629.wkunw2qbibnvlz53@alap3.anarazel.de  
Backpatch: 9.4-  

M src/backend/access/nbtree/nbtpage.c

Improve the performance of relation deletes during recovery.

commit   : 8463be060d4c4b67b1382607433ea1a3a51002e5    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Thu, 5 Jul 2018 02:21:15 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Thu, 5 Jul 2018 02:21:15 +0900    

Click here for diff

When multiple relations are deleted at the same transaction,  
the files of those relations are deleted by one call to smgrdounlinkall(),  
which leads to scan whole shared_buffers only one time. OTOH,  
previously, during recovery, smgrdounlink() (not smgrdounlinkall()) was  
called for each file to delete, which led to scan shared_buffers  
multiple times. Obviously this could cause to increase the WAL replay  
time very much especially when shared_buffers was huge.  
  
To alleviate this situation, this commit changes the recovery so that  
it also calls smgrdounlinkall() only one time to delete multiple  
relation files.  
  
This is just fix for oversight of commit 279628a0a7, not new feature.  
So, per discussion on pgsql-hackers, we concluded to backpatch this  
to all supported versions.  
  
Author: Fujii Masao  
Reviewed-by: Michael Paquier, Andres Freund, Thomas Munro, Kyotaro Horiguchi, Takayuki Tsunakawa  
Discussion: https://postgr.es/m/CAHGQGwHVQkdfDqtvGVkty+19cQakAydXn1etGND3X0PHbZ3+6w@mail.gmail.com  

M src/backend/access/transam/twophase.c
M src/backend/access/transam/xact.c
M src/backend/storage/smgr/md.c
M src/include/storage/smgr.h

Fix libpq example programs

commit   : c2c69d43addb23cde95eb428ef85902d52529251    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Sun, 1 Jul 2018 14:06:40 +0200    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Sun, 1 Jul 2018 14:06:40 +0200    

Click here for diff

When these programs call pg_catalog.set_config, they need to check for  
PGRES_TUPLES_OK instead of PGRES_COMMAND_OK.  Fix for  
5770172cb0c9df9e6ce27c507b449557e5b45124.  
  
Reported-by: Ideriha, Takeshi <ideriha.takeshi@jp.fujitsu.com>  

M doc/src/sgml/libpq.sgml
M doc/src/sgml/lobj.sgml
M src/test/examples/testlibpq.c
M src/test/examples/testlibpq2.c
M src/test/examples/testlibpq4.c
M src/test/examples/testlo.c
M src/test/examples/testlo64.c

Replace search.cpan.org with metacpan.org

commit   : b241c119b7b65e14201ba287f3239fd60ec8b67a    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 29 Jun 2018 22:17:37 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 29 Jun 2018 22:17:37 +0900    

Click here for diff

search.cpan.org has been EOL'd, with metacpan.org being the official  
replacement to which URLs now redirect.  Update links to match the new  
URL. Also update links to CPAN to use https as it will redirect from  
http.  
  
Author: Daniel Gustafsson  
Discussion: https://postgr.es/m/B74C0219-6BA9-46E1-A524-5B9E8CD3BDB3@yesql.se  

M doc/src/sgml/acronyms.sgml
M doc/src/sgml/external-projects.sgml
M doc/src/sgml/install-windows.sgml

doc: backpatch mention use of cross platform logical replication

commit   : 5b0539aba9b3708bd424a5933805631038c848f2    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Thu, 28 Jun 2018 09:12:07 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Thu, 28 Jun 2018 09:12:07 -0400    

Click here for diff

Backpatch 21c1f0c607f0344ae8f71ecaae1fe6f58cf7ff9a to PG 10 docs.  
  
Reported-by: Haribabu Kommi  
  
Discussion: https://postgr.es/m/CAJrrPGfdknoqZcMipPy8XnH3hO3uRic6JTD=jv35oj1DWqL07g@mail.gmail.com  
  
Backpatch-through: only 10  

M doc/src/sgml/logical-replication.sgml

Fix thinko in comments.

commit   : 5521e3bd5ffc57887f76f280ed8c88b5990752f8    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Wed, 27 Jun 2018 18:29:42 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Wed, 27 Jun 2018 18:29:42 +0530    

Click here for diff

A slot can not be stored in a tuple but it's vice versa.  
  
Reported-by: Ashutosh Bapat  
Author: Ashutosh Bapat  
Reviewed-by: Amit Kapila  
Discussion: https://postgr.es/m/CAFjFpRcHhNhXdegyJv3KKDWrwO1_NB_KYZM_ZSDeMOZaL1A5jQ@mail.gmail.com  

M src/backend/executor/execReplication.c

Fix “base” snapshot handling in logical decoding

commit   : b767b3f2e5b7aadb53c67cb2a2d7ded8e0825193    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 26 Jun 2018 16:38:34 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 26 Jun 2018 16:38:34 -0400    

Click here for diff

Two closely related bugs are fixed.  First, xmin of logical slots was  
advanced too early.  During xl_running_xacts processing, xmin of the  
slot was set to the oldest running xid in the record, but that's wrong:  
actually, snapshots which will be used for not-yet-replayed transactions  
might consider older txns as running too, so we need to keep xmin back  
for them.  The problem wasn't noticed earlier because DDL which allows  
to delete tuple (set xmax) while some another not-yet-committed  
transaction looks at it is pretty rare, if not unique: e.g. all forms of  
ALTER TABLE which change schema acquire ACCESS EXCLUSIVE lock  
conflicting with any inserts. The included test case (test_decoding's  
oldest_xmin) uses ALTER of a composite type, which doesn't have such  
interlocking.  
  
To deal with this, we must be able to quickly retrieve oldest xmin  
(oldest running xid among all assigned snapshots) from ReorderBuffer. To  
fix, add another list of ReorderBufferTXNs to the reorderbuffer, where  
transactions are sorted by base-snapshot-LSN.  This is slightly  
different from the existing (sorted by first-LSN) list, because a  
transaction can have an earlier LSN but a later Xmin, if its first  
record does not obtain an xmin (eg. xl_xact_assignment).  Note this new  
list doesn't fully replace the existing txn list: we still need that one  
to prevent WAL recycling.  
  
The second issue concerns SnapBuilder snapshots and subtransactions.  
SnapBuildDistributeNewCatalogSnapshot never assigned a snapshot to a  
transaction that is known to be a subtxn, which is good in the common  
case that the top-level transaction already has one (no point in doing  
so), but a bug otherwise.  To fix, arrange to transfer the snapshot from  
the subtxn to its top-level txn as soon as the kinship gets known.  
test_decoding's snapshot_transfer verifies this.  
  
Also, fix a minor memory leak: refcount of toplevel's old base snapshot  
was not decremented when the snapshot is transferred from child.  
  
Liberally sprinkle code comments, and rewrite a few existing ones.  This  
part is my (Álvaro's) contribution to this commit, as I had to write all  
those comments in order to understand the existing code and Arseny's  
patch.  
  
Reported-by: Arseny Sher <a.sher@postgrespro.ru>  
Diagnosed-by: Arseny Sher <a.sher@postgrespro.ru>  
Co-authored-by: Arseny Sher <a.sher@postgrespro.ru>  
Co-authored-by: Álvaro Herrera <alvherre@alvh.no-ip.org>  
Reviewed-by: Antonin Houska <ah@cybertec.at>  
Discussion: https://postgr.es/m/87lgdyz1wj.fsf@ars-thinkpad  

M contrib/test_decoding/Makefile
A contrib/test_decoding/expected/oldest_xmin.out
A contrib/test_decoding/expected/snapshot_transfer.out
A contrib/test_decoding/specs/oldest_xmin.spec
A contrib/test_decoding/specs/snapshot_transfer.spec
M src/backend/replication/logical/reorderbuffer.c
M src/backend/replication/logical/snapbuild.c
M src/include/replication/reorderbuffer.h

commit   : 09879f7536350e53ca21319b80430fb244bddfe7    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Wed, 27 Jun 2018 00:45:21 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Wed, 27 Jun 2018 00:45:21 +0900    

Click here for diff

The backup history file has been no longer necessary for recovery  
since the version 9.0. It's now basically just for informational purpose.  
But previously the documentations still described that a recovery  
requests the backup history file to proceed. The commit fixes this  
documentation bug.  
  
Back-patch to all supported versions.  
  
Author: Yugo Nagata  
Reviewed-by: Kyotaro Horiguchi  
Discussion: https://postgr.es/m/20180626174752.0ce505e3.nagata@sraoss.co.jp  

M doc/src/sgml/backup.sgml
M doc/src/sgml/high-availability.sgml

Add PGTYPESchar_free() to avoid cross-module problems on Windows.

commit   : 3566873f21909397561418fab22c98332fa8b72a    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Mon, 18 Jun 2018 18:33:53 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Mon, 18 Jun 2018 18:33:53 +1200    

Click here for diff

On Windows, it is sometimes important for corresponding malloc() and  
free() calls to be made from the same DLL, since some build options can  
result in multiple allocators being active at the same time.  For that  
reason we already provided PQfreemem().  This commit adds a similar  
function for freeing string results allocated by the pgtypes library.  
  
Author: Takayuki Tsunakawa  
Reviewed-by: Kyotaro Horiguchi  
Discussion: https://postgr.es/m/0A3221C70F24FB45833433255569204D1F8AD5D6%40G01JPEXMBYT05  

M doc/src/sgml/ecpg.sgml
M src/interfaces/ecpg/include/Makefile
A src/interfaces/ecpg/include/pgtypes.h
M src/interfaces/ecpg/include/pgtypes_date.h
M src/interfaces/ecpg/include/pgtypes_interval.h
M src/interfaces/ecpg/include/pgtypes_numeric.h
M src/interfaces/ecpg/include/pgtypes_timestamp.h
M src/interfaces/ecpg/pgtypeslib/common.c
M src/interfaces/ecpg/pgtypeslib/exports.txt
M src/interfaces/ecpg/test/expected/pgtypeslib-dt_test.c
M src/interfaces/ecpg/test/expected/pgtypeslib-dt_test2.c
M src/interfaces/ecpg/test/expected/pgtypeslib-num_test.c
M src/interfaces/ecpg/test/expected/pgtypeslib-num_test2.c
M src/interfaces/ecpg/test/expected/preproc-outofscope.c
M src/interfaces/ecpg/test/expected/sql-sqlda.c
M src/interfaces/ecpg/test/pgtypeslib/dt_test.pgc
M src/interfaces/ecpg/test/pgtypeslib/dt_test2.pgc
M src/interfaces/ecpg/test/pgtypeslib/num_test.pgc
M src/interfaces/ecpg/test/pgtypeslib/num_test2.pgc
M src/interfaces/ecpg/test/sql/sqlda.pgc

Move RecoveryLockList into a hash table.

commit   : 88554c0911018c1c60423fbb60557626142dec10    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Tue, 26 Jun 2018 17:17:27 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Tue, 26 Jun 2018 17:17:27 +1200    

Click here for diff

Standbys frequently need to release all locks held by a given xid.  
Instead of searching one big list linearly, let's create one list  
per xid and put them in a hash table, so we can find what we need  
in O(1) time.  
  
Earlier analysis and a prototype were done by David Rowley, though  
this isn't his patch.  
  
Back-patch all the way.  
  
Author: Thomas Munro  
Diagnosed-by: David Rowley, Andres Freund  
Reviewed-by: Andres Freund, Tom Lane, Robert Haas  
Discussion: https://postgr.es/m/CAEepm%3D1mL0KiQ2KJ4yuPpLGX94a4Ns_W6TL4EGRouxWibu56pA%40mail.gmail.com  
Discussion: https://postgr.es/m/CAKJS1f9vJ841HY%3DwonnLVbfkTWGYWdPN72VMxnArcGCjF3SywA%40mail.gmail.com  

M src/backend/storage/ipc/standby.c

Correct handling of fsync failures with tar mode of walmethods.c

commit   : 324076a6261756d6f5b3514ed2b2f715b656ba90    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 26 Jun 2018 09:56:55 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 26 Jun 2018 09:56:55 +0900    

Click here for diff

This file has been missing the fact that it needs to report back to  
callers a proper failure on fsync calls.  I have spotted the one in  
tar_finish() while Kuntal has spotted the one in tar_close().  
  
Backpatch down to 10 where this code has been introduced.  
  
Reported by: Michael Paquier, Kuntal Ghosh  
Author: Michael Paquier  
Reviewed-by: Kuntal Ghosh, Magnus Hagander  
Discussion: https://postgr.es/m/20180625024356.GD1146@paquier.xyz  

M src/bin/pg_basebackup/walmethods.c

Update obsolete comments

commit   : 99fb44357c14bf674966b6f08afd311028ce827c    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 25 Jun 2018 15:36:33 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 25 Jun 2018 15:36:33 -0400    

Click here for diff

Commit 9fab40ad32ef removed some pre-allocating logic in  
reorderbuffer.c, but left outdated comments in place.  Repair.  
  
Author: Álvaro Herrera  

M src/backend/replication/logical/reorderbuffer.c

Address set of issues with errno handling

commit   : 6eec6724ff4519ff67c9d402d65ad8a6c27e1d0e    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 25 Jun 2018 11:20:19 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 25 Jun 2018 11:20:19 +0900    

Click here for diff

System calls mixed up in error code paths are causing two issues which  
several code paths have not correctly handled:  
1) For write() calls, sometimes the system may return less bytes than  
what has been written without errno being set.  Some paths were careful  
enough to consider that case, and assumed that errno should be set to  
ENOSPC, other calls missed that.  
2) errno generated by a system call is overwritten by other system calls  
which may succeed once an error code path is taken, causing what is  
reported to the user to be incorrect.  
  
This patch uses the brute-force approach of correcting all those code  
paths.  Some refactoring could happen in the future, but this is let as  
future work, which is not targeted for back-branches anyway.  
  
Author: Michael Paquier  
Reviewed-by: Ashutosh Sharma  
Discussion: https://postgr.es/m/20180622061535.GD5215@paquier.xyz  

M src/backend/access/heap/rewriteheap.c
M src/backend/access/transam/twophase.c
M src/backend/access/transam/xlog.c
M src/backend/access/transam/xlogutils.c
M src/backend/replication/basebackup.c
M src/backend/replication/logical/origin.c
M src/backend/replication/logical/reorderbuffer.c
M src/backend/replication/logical/snapbuild.c
M src/backend/replication/slot.c
M src/bin/pg_basebackup/walmethods.c

doc: adjust order of NUMERIC arguments to match syntax

commit   : 6350dcc1f43154d404f52ab4e891ebecef0c2115    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Sun, 24 Jun 2018 18:07:00 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Sun, 24 Jun 2018 18:07:00 -0400    

Click here for diff

Specifically, mention precision before scale  
  
Reported-by: claytonjsalem@gmail.com  
  
Discussion: https://postgr.es/m/152967566691.1268.1062965601465200209@wrigleys.postgresql.org  
  
Backpatch-through: 9.3  

M doc/src/sgml/datatype.sgml

doc: show how interval’s 3 unit buckets behave using EXTRACT()

commit   : c1975c1af7c2120277c57b1f40996b5d94cf22f6    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Sat, 23 Jun 2018 23:32:41 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Sat, 23 Jun 2018 23:32:41 -0400    

Click here for diff

This clarifies when justify_days() and justify_hours() are useful.  
Paragraph moved too.  
  
Reported-by: vodevsh@gmail.com  
  
Discussion: https://postgr.es/m/152698651482.26744.15456677499485530703@wrigleys.postgresql.org  
  
Backpatch-through: 9.3  

M doc/src/sgml/datatype.sgml

Disclaim support for default namespace in XMLTABLE

commit   : b742010890ab30dc0ef9e23fc341fc60d99b951a    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 21 Jun 2018 17:01:10 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 21 Jun 2018 17:01:10 -0400    

Click here for diff

Pavel Stehule's original patch had support for default namespace, but I  
ripped it out before commit -- hence the docs were correct when written,  
and I broke them by omission :-(.  Remove the offending phrase.  
  
Author: Daniel Gustafsson  
Discussion: https://postgr.es/m/1550C5E5-FC70-4493-A226-AA137D831E8D@yesql.se  

M doc/src/sgml/func.sgml

commit   : b8a1d0302063a8adbfe3f4c43ee457fe724be42a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 21 Jun 2018 16:18:34 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 21 Jun 2018 16:18:34 -0400    

Click here for diff

A typo in numeric_poly_combine caused bogus results for queries using  
it, but of course would only manifest if parallel aggregation is  
performed.  Reported by Rajkumar Raghuwanshi.  
  
David Rowley did the diagnosis and the fix; I editorialized rather  
heavily on his regression test additions.  
  
Back-patch to v10 where the breakage was introduced (by 9cca11c91).  
  
Discussion: https://postgr.es/m/CAKcux6nU4E2x8nkSBpLOT2DPvQ5LviJ3SGyAN6Sz7qDH4G4+Pw@mail.gmail.com  

M src/backend/utils/adt/numeric.c
M src/test/regress/expected/aggregates.out
M src/test/regress/sql/aggregates.sql

Fix mishandling of sortgroupref labels while splitting SRF targetlists.

commit   : a4c95b0b80c70677c09c0d5c82a6fba875160288    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 21 Jun 2018 10:58:42 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 21 Jun 2018 10:58:42 -0400    

Click here for diff

split_pathtarget_at_srfs() neglected to worry about sortgroupref labels  
in the intermediate PathTargets it constructs.  I think we'd supposed  
that their labeling didn't matter, but it does at least for the case that  
GroupAggregate/GatherMerge nodes appear immediately under the ProjectSet  
step(s).  This results in "ERROR: ORDER/GROUP BY expression not found in  
targetlist" during create_plan(), as reported by Rajkumar Raghuwanshi.  
  
To fix, make this logic track the sortgroupref labeling of expressions,  
not just their contents.  This also restores the pre-v10 behavior that  
separate GROUP BY expressions will be kept distinct even if they are  
textually equal().  
  
Discussion: https://postgr.es/m/CAKcux6=1_Ye9kx8YLBPmJs_xE72PPc6vNi5q2AOHowMaCWjJ2w@mail.gmail.com  

M src/backend/optimizer/util/tlist.c
M src/test/regress/expected/select_parallel.out
M src/test/regress/sql/select_parallel.sql

Update expected XML output with disabled XML, too

commit   : 04ab840b8458e824a55fca10772ca9db39ab014c    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 20 Jun 2018 13:02:46 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 20 Jun 2018 13:02:46 -0400    

Click here for diff

M src/test/regress/expected/xml_1.out

Accept TEXT and CDATA nodes in XMLTABLE’s column_expression.

commit   : e10bc161f9a675e21e7421b59c57d2b4c8eec13b    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 20 Jun 2018 12:58:12 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 20 Jun 2018 12:58:12 -0400    

Click here for diff

Column expressions that match TEXT or CDATA nodes must return the  
contents of the nodes themselves, not the content of non-existing  
children (i.e. the empty string).  
  
Author: Markus Winand  
Reported-by: Markus Winand  
Reviewed-by: Álvaro Herrera  
Discussion: https://postgr.es/m/0684A598-002C-42A2-AE12-F024A324EAE4@winand.at  

M src/backend/utils/adt/xml.c
M src/test/regress/expected/xml.out
M src/test/regress/expected/xml_2.out
M src/test/regress/sql/xml.sql

Fix typo

commit   : 99ba8d2f8f84fdc2721000dc5727a41e2ca8d944    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Wed, 20 Jun 2018 16:07:07 +0200    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Wed, 20 Jun 2018 16:07:07 +0200    

Click here for diff

Reported using the website comment form  

M doc/src/sgml/dml.sgml

Clarify use of temporary tables within partition trees

commit   : 5862174ec78a173c41710c5ef33feb993ae45cc7    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 20 Jun 2018 10:48:28 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 20 Jun 2018 10:48:28 +0900    

Click here for diff

Since their introduction, partition trees have been a bit lossy  
regarding temporary relations.  Inheritance trees respect the following  
patterns:  
1) a child relation can be temporary if the parent is permanent.  
2) a child relation can be temporary if the parent is temporary.  
3) a child relation cannot be permanent if the parent is temporary.  
4) The use of temporary relations also imply that when both parent and  
child need to be from the same sessions.  
  
Partitions share many similar patterns with inheritance, however the  
handling of the partition bounds make the situation a bit tricky for  
case 1) as the partition code bases a lot of its lookup code upon  
PartitionDesc which does not really look after relpersistence.  This  
causes for example a temporary partition created by session A to be  
visible by another session B, preventing this session B to create an  
extra partition which overlaps with the temporary one created by A with  
a non-intuitive error message.  There could be use-cases where mixing  
permanent partitioned tables with temporary partitions make sense, but  
that would be a new feature.  Partitions respect 2), 3) and 4) already.  
  
It is a bit depressing to see those error checks happening in  
MergeAttributes() whose purpose is different, but that's left as future  
refactoring work.  
  
Back-patch down to 10, which is where partitioning has been introduced,  
except that default partitions do not apply there.  Documentation also  
includes limitations related to the use of temporary tables with  
partition trees.  
  
Reported-by: David Rowley  
Author: Amit Langote, Michael Paquier  
Reviewed-by: Ashutosh Bapat, Amit Langote, Michael Paquier  
Discussion: https://postgr.es/m/CAKJS1f94Ojk0og9GMkRHGt8wHTW=ijq5KzJKuoBoqWLwSVwGmw@mail.gmail.com  

M doc/src/sgml/ddl.sgml
M src/backend/commands/tablecmds.c
M src/test/regress/expected/alter_table.out
M src/test/regress/expected/create_table.out
M src/test/regress/expected/foreign_data.out
M src/test/regress/sql/alter_table.sql
M src/test/regress/sql/create_table.sql
M src/test/regress/sql/foreign_data.sql

doc: explain use of json_populate_record{set}()

commit   : a6fb9378b8a35a64e94c2851719c787c03917c96    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 19 Jun 2018 13:43:40 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 19 Jun 2018 13:43:40 -0400    

Click here for diff

The set-returning nature of these functions make their use unclear. The  
modified paragraph was added in PG 9.4.  
  
Reported-by: yshaladi@denodo.com  
  
Discussion:  https://postgr.es/m/152571684246.9460.18059951267371255159@wrigleys.postgresql.org  
  
Backpatch-through: 9.4  

M doc/src/sgml/func.sgml

Fix contrib/hstore_plperl to look through scalar refs.

commit   : 7594b7a53366f6c262103acd161e6fee0a30e5c2    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 18 Jun 2018 15:55:06 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 18 Jun 2018 15:55:06 -0400    

Click here for diff

Bring this transform function into sync with the policy established  
by commit 3a382983d.  
  
Also, fix it to make sure that what it drills down to is indeed a  
hash, and not some other kind of Perl SV.  Previously, the test  
cases added here provoked crashes.  
  
Because of the crash hazard, back-patch to 9.5 where this module  
was introduced.  
  
Discussion: https://postgr.es/m/28336.1528393969@sss.pgh.pa.us  

M contrib/hstore_plperl/expected/hstore_plperl.out
M contrib/hstore_plperl/hstore_plperl.c
M contrib/hstore_plperl/sql/hstore_plperl.sql

Prevent hard failures of standbys caused by recycled WAL segments

commit   : fb28104a4baa5488e89fbd7ec2cc7dce1a90fce6    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 18 Jun 2018 10:43:27 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 18 Jun 2018 10:43:27 +0900    

Click here for diff

When a standby's WAL receiver stops reading WAL from a WAL stream, it  
writes data to the current WAL segment without having priorily zero'ed  
the page currently written to, which can cause the WAL reader to read  
junk data from a past recycled segment and then it would try to get a  
record from it.  While sanity checks in place provide most of the  
protection needed, in some rare circumstances, with chances increasing  
when a record header crosses a page boundary, then the startup process  
could fail violently on an allocation failure, as follows:  
FATAL:  invalid memory alloc request size XXX  
  
This is confusing for the user and also unhelpful as this requires in  
the worst case a manual restart of the instance, impacting potentially  
the availability of the cluster, and this also makes WAL data look like  
it is in a corrupted state.  
  
The chances of seeing failures are higher if the connection between the  
standby and its root node is unstable, causing WAL pages to be written  
in the middle.  A couple of approaches have been discussed, like  
zero-ing  new WAL pages within the WAL receiver itself but this has the  
disadvantage of impacting performance of any existing instances as this  
breaks the sequential writes done by the WAL receiver.  This commit  
deals with the problem with a more simple approach, which has no  
performance impact without reducing the detection of the problem: if a  
record is found with a length higher than 1GB for backends, then do not  
try any allocation and report a soft failure which will force the  
standby to retry reading WAL.  It could be possible that the allocation  
call passes and that an unnecessary amount of memory is allocated,  
however follow-up checks on records would just fail, making this  
allocation short-lived anyway.  
  
This patch owes a great deal to Tsunakawa Takayuki for reporting the  
failure first, and then discussing a couple of potential approaches to  
the problem.  
  
Backpatch down to 9.5, which is where palloc_extended has been  
introduced.  
  
Reported-by: Tsunakawa Takayuki  
Reviewed-by: Tsunakawa Takayuki  
Author: Michael Paquier  
Discussion: https://postgr.es/m/0A3221C70F24FB45833433255569204D1F8B57AD@G01JPEXMBYT05  

M src/backend/access/transam/xlogreader.c

Use -Wno-format-truncation and -Wno-stringop-truncation, if available.

commit   : 416e3e318cc42cfc36633ba3d1fde708cfa084af    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 16 Jun 2018 15:34:07 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 16 Jun 2018 15:34:07 -0400    

Click here for diff

gcc 8 has started emitting some warnings that are largely useless for  
our purposes, particularly since they complain about code following  
the project-standard coding convention that path names are assumed  
to be shorter than MAXPGPATH.  Even if we make the effort to remove  
that assumption in some future release, the changes wouldn't get  
back-patched.  Hence, just suppress these warnings, on compilers that  
have these switches.  
  
Backpatch to all supported branches.  
  
Discussion: https://postgr.es/m/1524563856.26306.9.camel@gunduz.org  

M configure
M configure.in

Avoid unnecessary use of strncpy in a couple of places in ecpg.

commit   : 8c924855456eff392391eba49cb02ae581a12898    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 16 Jun 2018 14:58:11 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 16 Jun 2018 14:58:11 -0400    

Click here for diff

Use of strncpy with a length limit based on the source, rather than  
the destination, is non-idiomatic and draws warnings from gcc 8.  
Replace with memcpy, which does exactly the same thing in these cases,  
but with less chance for confusion.  
  
Backpatch to all supported branches.  
  
Discussion: https://postgr.es/m/21789.1529170195@sss.pgh.pa.us  

M src/interfaces/ecpg/ecpglib/descriptor.c
M src/interfaces/ecpg/pgtypeslib/common.c

Use snprintf not sprintf in pg_waldump’s timestamptz_to_str.

commit   : 18933261589c9547d5c517cdc05f25362cce412a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 16 Jun 2018 14:45:47 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 16 Jun 2018 14:45:47 -0400    

Click here for diff

This could only cause an issue if strftime returned a ridiculously  
long timezone name, which seems unlikely; and it wouldn't qualify  
as a security problem even then, since pg_waldump (nee pg_xlogdump)  
is a debug tool not part of the server.  But gcc 8 has started issuing  
warnings about it, so let's use snprintf and be safe.  
  
Backpatch to 9.3 where this code was added.  
  
Discussion: https://postgr.es/m/21789.1529170195@sss.pgh.pa.us  

M src/bin/pg_waldump/compat.c

Fail BRIN control functions during recovery explicitly

commit   : 3b5f4f1f40b241d08ed36df1716e07a6b0560e5c    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 14 Jun 2018 12:51:32 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 14 Jun 2018 12:51:32 -0400    

Click here for diff

They already fail anyway, but prior to this patch they raise an ugly  
error message about a lock that cannot be acquired.  This just improves  
the message.  
  
Author: Masahiko Sawada  
Reported-by: Masahiko Sawada  
Discussion: https://postgr.es/m/CAD21AoBZau4g4_NUf3BKNd=CdYK+xaPdtJCzvOC1TxGdTiJx_Q@mail.gmail.com  
Reviewed-by: Kuntal Ghosh, Alexander Korotkov, Simon Riggs, Michaël Paquier, Álvaro Herrera  

M src/backend/access/brin/brin.c

Documentation improvement for pg_trgm

commit   : 476ba1ec98a70a67bad8af7d178fb56e3df5aa9b    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Wed, 13 Jun 2018 18:31:18 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Wed, 13 Jun 2018 18:31:18 +0300    

Click here for diff

Documentation of word_similarity() and strict_word_similarity() functions  
contains some vague wordings which could confuse users.  This patch makes  
those wordings more clear.  word_similarity() was introduced in PostgreSQL 9.6,  
and corresponding part of documentation needs to be backpatched.  
  
Author: Bruce Momjian, Alexander Korotkov  
Discussion: https://postgr.es/m/20180526165648.GB12510%40momjian.us  
Backpatch: 9.6, where word_similarity() was introduced  

M doc/src/sgml/pgtrgm.sgml

Fix bugs in vacuum of shared rels, by keeping their relcache entries current.

commit   : 2ce64caaf793615d0f7a7ce4380e7255077d130c    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Tue, 12 Jun 2018 11:13:21 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Tue, 12 Jun 2018 11:13:21 -0700    

Click here for diff

When vacuum processes a relation it uses the corresponding relcache  
entry's relfrozenxid / relminmxid as a cutoff for when to remove  
tuples etc. Unfortunately for nailed relations (i.e. critical system  
catalogs) bugs could frequently lead to the corresponding relcache  
entry being stale.  
  
This set of bugs could cause actual data corruption as vacuum would  
potentially not remove the correct row versions, potentially reviving  
them at a later point.  After 699bf7d05c some corruptions in this vein  
were prevented, but the additional error checks could also trigger  
spuriously. Examples of such errors are:  
  ERROR: found xmin ... from before relfrozenxid ...  
and  
  ERROR: found multixact ... from before relminmxid ...  
To be caused by this bug the errors have to occur on system catalog  
tables.  
  
The two bugs are:  
  
1) Invalidations for nailed relations were ignored, based on the  
   theory that the relcache entry for such tables doesn't  
   change. Which is largely true, except for fields like relfrozenxid  
   etc.  This means that changes to relations vacuumed in other  
   sessions weren't picked up by already existing sessions.  Luckily  
   autovacuum doesn't have particularly longrunning sessions.  
  
2) For shared *and* nailed relations, the shared relcache init file  
   was never invalidated while running.  That means that for such  
   tables (e.g. pg_authid, pg_database) it's not just already existing  
   sessions that are affected, but even new connections are as well.  
   That explains why the reports usually were about pg_authid et. al.  
  
To fix 1), revalidate the rd_rel portion of a relcache entry when  
invalid. This implies a bit of extra complexity to deal with  
bootstrapping, but it's not too bad.  The fix for 2) is simpler,  
simply always remove both the shared and local init files.  
  
Author: Andres Freund  
Reviewed-By: Alvaro Herrera  
Discussion:  
    https://postgr.es/m/20180525203736.crkbg36muzxrjj5e@alap3.anarazel.de  
    https://postgr.es/m/CAMa1XUhKSJd98JW4o9StWPrfS=11bPgG+_GDMxe25TvUY4Sugg@mail.gmail.com  
    https://postgr.es/m/CAKMFJucqbuoDRfxPDX39WhA3vJyxweRg_zDVXzncr6+5wOguWA@mail.gmail.com  
    https://postgr.es/m/CAGewt-ujGpMLQ09gXcUFMZaZsGJC98VXHEFbF-tpPB0fB13K+A@mail.gmail.com  
Backpatch: 9.3-  

M src/backend/utils/cache/inval.c
M src/backend/utils/cache/relcache.c
M src/include/storage/standbydefs.h

Fix access to just-closed relcache entry.

commit   : b10edaf4bb4473adc897f5643ede8c9100abddce    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 11 Jun 2018 19:17:50 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 11 Jun 2018 19:17:50 -0400    

Click here for diff

It might be impossible for this to cause a problem in non-debug builds,  
since there'd be no opportunity for the relcache entry to get recycled  
before the fetch.  It blows up nicely with -DRELCACHE_FORCE_RELEASE plus  
valgrind, though.  
  
Evidently introduced by careless refactoring in commit f0e44751d.  
Back-patch accordingly.  
  
Discussion: https://postgr.es/m/27543.1528758304@sss.pgh.pa.us  

M src/backend/commands/tablecmds.c

commit   : 858571843c8affff5a69527faa3e57f8adfa4165    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 11 Jun 2018 09:54:25 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 11 Jun 2018 09:54:25 +0900    

Click here for diff

Reported-by: Christopher Jones  

M doc/src/sgml/wal.sgml

Fix grammar in REVOKE documentation

commit   : fd73508fd15937da6580bed7080ed77563e7e39f    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sun, 10 Jun 2018 22:44:17 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sun, 10 Jun 2018 22:44:17 +0900    

Click here for diff

Reported-by: Erwin Brandstetter  

M doc/src/sgml/ref/revoke.sgml

Teach SHOW ALL to honor pg_read_all_settings membership

commit   : a25c207b2fb8be8dc1bf91b55e8b5b3d809934d9    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 8 Jun 2018 16:18:40 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 8 Jun 2018 16:18:40 -0400    

Click here for diff

Also, fix the pg_settings view to display source filename and line  
number when invoked by a pg_read_all_settings member.  This addition by  
me (Álvaro).  
  
Also, fix wording of the comment in GetConfigOption regarding the  
restriction it implements, renaming the parameter for extra clarity.  
Noted by Michaël.  
  
These were all oversight in commit 25fff40798fc; backpatch to pg10,  
where that commit first appeared.  
  
Author: Laurenz Albe  
Reviewed-by: Michaël Paquier, Álvaro Herrera  
Discussion: https://postgr.es/m/1519917758.6586.8.camel@cybertec.at  

M src/backend/utils/misc/guc.c
M src/include/utils/guc.h

Fix typo

commit   : 6695e956f831f6e124f85bccfb40847875980a5f    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 8 Jun 2018 11:55:12 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 8 Jun 2018 11:55:12 -0400    

Click here for diff

M src/backend/executor/execMain.c

Fix obsolete comment.

commit   : 0692f29ab70c7d12d5d6c19eb30a7017a6693b83    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 7 Jun 2018 09:56:22 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 7 Jun 2018 09:56:22 +0300    

Click here for diff

The 'orig_slot' argument was removed in commit c0a8ae7be392, but that  
commit forgot to update the comment.  
  
Author: Amit Langote  
Discussion: https://www.postgresql.org/message-id/194ac4bf-7b4a-c887-bf26-bc1a85ea995a@lab.ntt.co.jp  

M src/backend/executor/nodeModifyTable.c

Fix function code in error report

commit   : 1d5b249310553c05e6ed1d647734d41be174e634    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 6 Jun 2018 14:46:53 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 6 Jun 2018 14:46:53 -0400    

Click here for diff

This bug causes a lseek() failure to be reported as a "could not open"  
failure in the error message, muddling bug reports.  I introduced this  
copy-and-pasteo in commit 78e122010422.  
  
Noticed while reviewing code for bug report #15221, from lily liang.  In  
version 10 the affected function is only used by multixact.c and  
commit_ts, and only in corner-case circumstances, neither of which are  
involved in the reported bug (a pg_subtrans failure.)  
  
Author: Álvaro Herrera  

M src/backend/access/transam/slru.c

Fix grammar

commit   : b17be5b80763631b0c8f6fd6d85a12ae8d052c6f    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 30 May 2018 14:08:51 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 30 May 2018 14:08:51 -0400    

Click here for diff

Reported-by: Pavlo Golub  
Author: Michaël Paquier  
Discussion: https://postgr.es/m/152741547.20180530101229@cybertec.at  

M doc/src/sgml/monitoring.sgml

doc: mark ‘replaceable’ parameter for backup program listing

commit   : 6160ce9a8f93676d4d9bcd4adccabe49cbbe9f97    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 28 May 2018 14:19:45 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 28 May 2018 14:19:45 -0400    

Click here for diff

Reported-by: Liudmila Mantrova  
  
Discussion: https://postgr.es/m/f3e2c0f5-5266-d626-58d7-b77e1b29d870@postgrespro.ru  
  
Author: Liudmila Mantrova  
  
Backpatch-through: 9.3  

M doc/src/sgml/backup.sgml

doc: adjust DECLARE docs to mention FOR UPDATE behavior

commit   : 9b5532a3c73394cefb24109662841d1634719563    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 28 May 2018 13:16:02 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 28 May 2018 13:16:02 -0400    

Click here for diff

Reported-by: Peter Eisentraut  
  
Discussion: https://postgr.es/m/8dc63ba7-dc56-fc7c-fc16-4fae03e3bfe6@2ndquadrant.com  
  
Author: Peter Eisentraut, Tom Lane, me  
  
Backpatch-through: 9.3  

M doc/src/sgml/ref/declare.sgml

Fix misidentification of SQL statement type in plpgsql’s exec_stmt_execsql.

commit   : 5a225b0d61778c1912e766a8ea0b60216734b1d2    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 25 May 2018 14:31:06 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 25 May 2018 14:31:06 -0400    

Click here for diff

To distinguish SQL statements that are INSERT/UPDATE/DELETE from other  
ones, exec_stmt_execsql looked at the post-rewrite form of the statement  
rather than the original.  This is problematic because it did that only  
during first execution of the statement (in a session), but the correct  
answer could change later due to addition or removal of DO INSTEAD rules  
during the session.  That could lead to an Assert failure, as reported  
by Tushar Ahuja and Robert Haas.  In non-assert builds, there's a hazard  
that we would fail to enforce STRICT behavior when we'd be expected to.  
That would happen if an initially present DO INSTEAD, that replaced the  
original statement with one of a different type, were removed; after that  
the statement should act "normally", including strictness enforcement, but  
it didn't.  (The converse case of enforcing strictness when we shouldn't  
doesn't seem to be a hazard, as addition of a DO INSTEAD that changes the  
statement type would always lead to acting as though the statement returned  
zero rows, so that the strictness error could not fire.)  
  
To fix, inspect the original form of the statement not the post-rewrite  
form, making it valid to assume the answer can't change intra-session.  
This should lead to the same answer in every case except when there is a  
DO INSTEAD that changes the statement type; we will now set mod_stmt=true  
anyway, while we would not have done so before.  That breaks the Assert  
in the SPI_OK_REWRITTEN code path, which expected the latter behavior.  
It might be all right to assert mod_stmt rather than !mod_stmt there,  
but I'm not entirely convinced that that'd always hold, so just remove  
the assertion altogether.  
  
This has been broken for a long time, so back-patch to all supported  
branches.  
  
Discussion: https://postgr.es/m/CA+TgmoZUrRN4xvZe_BbBn_Xp0BDwuMEue-0OyF0fJpfvU2Yc7Q@mail.gmail.com  

M src/pl/plpgsql/src/pl_exec.c

Remove incorrect statement about IPC configuration on OpenBSD

commit   : 0bf5333714955461aaa5fdf0e049cc32105202e2    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Fri, 25 May 2018 13:59:50 +0200    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Fri, 25 May 2018 13:59:50 +0200    

Click here for diff

kern.ipc.shm_use_phys is not a sysctl on OpenBSD, and SEMMAP is not  
a kernel configuration option. These were probably copy pasteos from  
when the documentation had a single paragraph for *BSD.  
  
Author: Daniel Gustafsson <daniel@yesql.se>  

M doc/src/sgml/runtime.sgml

Fix objectaddress.c code for publication relations.

commit   : e8cb8fdfd3a219bbc01e80054d58bf6cbce745ef    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 24 May 2018 12:38:55 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 24 May 2018 12:38:55 -0400    

Click here for diff

getObjectDescription and getObjectIdentity failed to schema-qualify  
the name of the published table, which is bad in getObjectDescription and  
unforgivable in getObjectIdentity.  Actually, getObjectIdentity failed to  
emit the table's name at all unless "objname" output is requested, which  
accidentally works for some (all?) extant callers but is clearly not the  
intended API.  Somebody had also not gotten the memo that the output of  
getObjectIdentity is not to be translated.  
  
To fix getObjectDescription, I made it call getRelationDescription, which  
required refactoring the translatable string for the case, but is more  
future-proof in case we ever publish relations that aren't plain tables.  
While at it, I made the English output look like "publication of table X  
in publication Y"; the added "of" seems to me to make it read much better.  
  
Back-patch to v10 where publications were introduced.  
  
Discussion: https://postgr.es/m/20180522.182020.114074746.horiguchi.kyotaro@lab.ntt.co.jp  

M src/backend/catalog/objectaddress.c
M src/test/regress/expected/object_address.out

Properly schema-qualify additional object types in getObjectDescription().

commit   : eb1aa1b46bd919a84e9524ea7178547cc6b93dd8    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 24 May 2018 12:07:41 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 24 May 2018 12:07:41 -0400    

Click here for diff

Collations, conversions, extended statistics objects (in >= v10),  
and all four types of text search objects have schema-qualified names.  
getObjectDescription() ignored that and would emit just the base name of  
the object, potentially producing wrong or at least highly misleading  
output.  Fix it to add the schema name whenever the object is not "visible"  
in the current search path, as is the rule for other schema-qualifiable  
object types.  
  
Although in common situations the output won't change, this seems to me  
(tgl) to be a bug worthy of back-patching, hence do so.  
  
Kyotaro Horiguchi, per a complaint from me  
  
Discussion: https://postgr.es/m/20180522.182020.114074746.horiguchi.kyotaro@lab.ntt.co.jp  

M src/backend/catalog/objectaddress.c
M src/test/regress/expected/alter_table.out

Fix simple_prompt() to disable echo on Windows when stdin != terminal.

commit   : bed74e9d49598f8b61eea1160851f5ca2d8c1045    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 23 May 2018 19:04:34 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 23 May 2018 19:04:34 -0400    

Click here for diff

If echo = false, simple_prompt() is supposed to prevent echoing the  
input (for password input).  However, the Windows implementation applied  
the mode change to STD_INPUT_HANDLE.  That would not have the desired  
effect if stdin isn't actually the terminal, for instance if the user  
is piping something into psql.  Fix it to apply the mode change to  
the correct input file, so that passwords do not echo in such cases.  
  
In passing, shorten and de-uglify this code by using #elif rather than  
an #if nest and removing some duplicated code.  
  
Back-patch to all supported versions.  To simplify that, also back-patch  
the portions of commit 9daec77e1 that got rid of an unnecessary  
malloc/free in the same area.  
  
Matthew Stickney (cosmetic changes by me)  
  
Discussion: https://postgr.es/m/502a1fff-862b-da52-1031-f68df6ed5a2d@gmail.com  

M src/port/sprompt.c

Widen COPY FROM’s current-line-number counter from 32 to 64 bits.

commit   : c92d1461e10799c20e10582127dbbd6cb50e9de3    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 22 May 2018 13:32:52 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 22 May 2018 13:32:52 -0400    

Click here for diff

Because the code for the HEADER option skips a line when this counter  
is zero, a very long COPY FROM WITH HEADER operation would drop a line  
every 2^32 lines.  A lesser but still unfortunate problem is that errors  
would show a wrong input line number for errors occurring beyond the  
2^31'st input line.  While such large input streams seemed impractical  
when this code was first written, they're not any more.  Widening the  
counter (and some associated variables) to uint64 should be enough to  
prevent problems for the foreseeable future.  
  
David Rowley  
  
Discussion: https://postgr.es/m/CAKJS1f88yh-6wwEfO6QLEEvH3BEugOq2QX1TOja0vCauoynmOQ@mail.gmail.com  

M src/backend/commands/copy.c

Fix SQL:2008 FETCH FIRST syntax to allow parameters.

commit   : cf516dc9d69052360f1de390636c220797120d28    
  
author   : Andrew Gierth <rhodiumtoad@postgresql.org>    
date     : Mon, 21 May 2018 17:02:17 +0100    
  
committer: Andrew Gierth <rhodiumtoad@postgresql.org>    
date     : Mon, 21 May 2018 17:02:17 +0100    

Click here for diff

OFFSET <x> ROWS FETCH FIRST <y> ROWS ONLY syntax is supposed to accept  
<simple value specification>, which includes parameters as well as  
literals. When this syntax was added all those years ago, it was done  
inconsistently, with <x> and <y> being different subsets of the  
standard syntax.  
  
Rectify that by making <x> and <y> accept the same thing, and allowing  
either a (signed) numeric literal or a c_expr there, which allows for  
parameters, variables, and parenthesized arbitrary expressions.  
  
Per bug #15200 from Lukas Eder.  
  
Backpatch all the way, since this has been broken from the start.  
  
Discussion: https://postgr.es/m/877enz476l.fsf@news-spur.riddles.org.uk  
Discussion: http://postgr.es/m/152647780335.27204.16895288237122418685@wrigleys.postgresql.org  

M doc/src/sgml/ref/select.sgml
M src/backend/parser/gram.y

Fix unsafe usage of strerror(errno) within ereport().

commit   : 28782d7e3b923a9eb9e1063c6e3cc69e167fad11    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 21 May 2018 00:32:28 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 21 May 2018 00:32:28 -0400    

Click here for diff

This is the converse of the unsafe-usage-of-%m problem: the reason  
ereport/elog provide that format code is mainly to dodge the hazard  
of errno getting changed before control reaches functions within the  
arguments of the macro.  I only found one instance of this hazard,  
but it's been there since 9.4 :-(.  

M src/backend/libpq/auth.c

printf(“%lf”) is not portable, so omit the “l”.

commit   : fa2cfb962c05df730f6bf586614eb39a4b0b5238    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 20 May 2018 11:40:54 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 20 May 2018 11:40:54 -0400    

Click here for diff

The "l" (ell) width spec means something in the corresponding scanf usage,  
but not here.  While modern POSIX says that applying "l" to "f" and other  
floating format specs is a no-op, SUSv2 says it's undefined.  Buildfarm  
experience says that some old compilers emit warnings about it, and at  
least one old stdio implementation (mingw's "ANSI" option) actually  
produces wrong answers and/or crashes.  
  
Discussion: https://postgr.es/m/21670.1526769114@sss.pgh.pa.us  
Discussion: https://postgr.es/m/c085e1da-0d64-1c15-242d-c921f32e0d5c@dunslane.net  

M doc/src/sgml/ecpg.sgml
M src/interfaces/ecpg/test/compat_informix/sqlda.pgc
M src/interfaces/ecpg/test/expected/compat_informix-sqlda.c
M src/interfaces/ecpg/test/expected/preproc-outofscope.c
M src/interfaces/ecpg/test/expected/sql-sqlda.c
M src/interfaces/ecpg/test/preproc/outofscope.pgc
M src/interfaces/ecpg/test/sql/sqlda.pgc

Support platforms where strtoll/strtoull are spelled strtoll/strtoull.

commit   : a5be529aaade5ffaf30bd423365b2dd0e1dffff7    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 19 May 2018 14:22:18 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 19 May 2018 14:22:18 -0400    

Click here for diff

Ancient HPUX, for one, does this.  We hadn't noticed due to the lack  
of regression tests that required a working strtoll.  
  
(I was slightly tempted to remove the other historical spelling,  
strto[u]q, since it seems we have no buildfarm members testing that case.  
But I refrained.)  
  
Discussion: https://postgr.es/m/151935568942.1461.14623890240535309745@wrigleys.postgresql.org  

M configure
M configure.in
M src/include/c.h
M src/include/pg_config.h.in
M src/include/pg_config.h.win32

Arrange to supply declarations for strtoll/strtoull if needed.

commit   : c964c2147136a19c8dad6b80c1240906646e4159    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 18 May 2018 22:42:10 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 18 May 2018 22:42:10 -0400    

Click here for diff

Buildfarm member dromedary is still unhappy about the recently-added  
ecpg "long long" tests.  The reason turns out to be that it includes  
"-ansi" in its CFLAGS, and in their infinite wisdom Apple have decided  
to hide the declarations of strtoll/strtoull in C89-compliant builds.  
(I find it pretty curious that they hide those function declarations  
when you can nonetheless declare a "long long" variable, but anyway  
that is their behavior, both on dromedary's obsolete macOS version and  
the newest and shiniest.)  As a result, gcc assumes these functions  
return "int", leading naturally to wrong results.  
  
(Looking at dromedary's past build results, it's evident that this  
problem also breaks pg_strtouint64() on 32-bit platforms; but we  
evidently have no regression tests that exercise that function with  
values above 32 bits.)  
  
To fix, supply declarations for these functions when the platform  
provides the functions but not the declarations, using the same type  
of mechanism as we use for some other similar cases.  
  
Discussion: https://postgr.es/m/151935568942.1461.14623890240535309745@wrigleys.postgresql.org  

M configure
M configure.in
M src/include/c.h
M src/include/pg_config.h.in
M src/include/pg_config.h.win32

Hot-fix ecpg regression test for missing ecpg_config.h inclusion.

commit   : e55a5516deeeefac8542639d599fc3bc3ad5f54d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 18 May 2018 19:03:32 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 18 May 2018 19:03:32 -0400    

Click here for diff

I don't think this is really the best long-term answer, and in  
particular it doesn't fix the pre-existing hazard in sqltypes.h.  
But for the moment let's just try to make the buildfarm green again.  
  
Discussion: https://postgr.es/m/151935568942.1461.14623890240535309745@wrigleys.postgresql.org  

M src/interfaces/ecpg/test/expected/sql-sqlda.c
M src/interfaces/ecpg/test/sql/sqlda.pgc

Add some test coverage for ecpg’s “long long” support.

commit   : e21085da56a9905b7224b18389f16a5d65c0fb52    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 18 May 2018 13:04:59 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 18 May 2018 13:04:59 -0400    

Click here for diff

This will only actually exercise the "long long" code paths on platforms  
where "long" is 32 bits --- otherwise, the SQL bigint type maps to  
plain "long", and we will test that code path instead.  But that's  
probably sufficient coverage, and anyway we weren't testing either  
code path before.  
  
Dang Minh Huong, tweaked a bit by me  
  
Discussion: https://postgr.es/m/151935568942.1461.14623890240535309745@wrigleys.postgresql.org  

M src/interfaces/ecpg/test/expected/sql-sqlda.c
M src/interfaces/ecpg/test/expected/sql-sqlda.stderr
M src/interfaces/ecpg/test/expected/sql-sqlda.stdout
M src/interfaces/ecpg/test/sql/sqlda.pgc

Recognize that MSVC can support strtoll() and strtoull().

commit   : cf39aebf17c571456c9dbcc06d3569a98e2fcecc    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 18 May 2018 12:52:28 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 18 May 2018 12:52:28 -0400    

Click here for diff

This is needed for full support of "long long" variables in ecpg, but  
the previous patch for bug #15080 (commits 51057feaa et al) missed it.  
In MSVC versions where the functions don't exist under those names,  
we can nonetheless use _strtoi64() and _strtoui64().  
  
Like the previous patch, back-patch all the way.  
  
Dang Minh Huong  
  
Discussion: https://postgr.es/m/151935568942.1461.14623890240535309745@wrigleys.postgresql.org  

M src/include/pg_config.h.win32

Fix error message on short read of pg_control

commit   : 29ce50091d128faaabd0a4044e91a7d0da11bb8e    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Fri, 18 May 2018 17:53:12 +0200    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Fri, 18 May 2018 17:53:12 +0200    

Click here for diff

Instead of saying "error: success", indicate that we got a working read  
but it was too short.  

M src/backend/access/transam/xlog.c
M src/common/controldata_utils.c

doc: fix description of backward_scan

commit   : ee68541ce60dd585cbc53142ab9cd14bf10fdf8f    
  
author   : Andrew Gierth <rhodiumtoad@postgresql.org>    
date     : Thu, 17 May 2018 21:23:01 +0100    
  
committer: Andrew Gierth <rhodiumtoad@postgresql.org>    
date     : Thu, 17 May 2018 21:23:01 +0100    

Click here for diff

The description of the index property backward_scan was incorrect and  
misleading; rectify.  
  
Backpatch to 9.6 where the amutils functionality was introduced.  

M doc/src/sgml/func.sgml

Fix misprocessing of equivalence classes involving record_eq().

commit   : aada0a7648e220d6e7a852e827b0d66d04280aed    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 16 May 2018 13:46:09 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 16 May 2018 13:46:09 -0400    

Click here for diff

canonicalize_ec_expression() is supposed to agree with coerce_type() as to  
whether a RelabelType should be inserted to make a subexpression be valid  
input for the operators of a given opclass.  However, it did the wrong  
thing with named-composite-type inputs to record_eq(): it put in a  
RelabelType to RECORDOID, which the parser doesn't.  In some cases this was  
harmless because all code paths involving a particular equivalence class  
did the same thing, but in other cases this would result in failing to  
recognize a composite-type expression as being a member of an equivalence  
class that it actually is a member of.  The most obvious bad effect was to  
fail to recognize that an index on a composite column could provide the  
sort order needed for a mergejoin on that column, as reported by Teodor  
Sigaev.  I think there might be other, subtler, cases that result in  
misoptimization.  It also seems possible that an unwanted RelabelType  
would sometimes get into an emitted plan --- but because record_eq and  
friends don't examine the declared type of their input expressions, that  
would not create any visible problems.  
  
To fix, just treat RECORDOID as if it were a polymorphic type, which in  
some sense it is.  We might want to consider formalizing that a bit more  
someday, but for the moment this seems to be the only place where an  
IsPolymorphicType() test ought to include RECORDOID as well.  
  
This has been broken for a long time, so back-patch to all supported  
branches.  
  
Discussion: https://postgr.es/m/a6b22369-e3bf-4d49-f59d-0c41d3551e81@sigaev.ru  

M src/backend/optimizer/path/equivclass.c
M src/test/regress/expected/join.out
M src/test/regress/sql/join.sql

Fix type checking for support functions of parallel VARIADIC aggregates.

commit   : 17083ab7e121d99c346bebfc979eb83ffe9c41ce    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 15 May 2018 15:06:53 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 15 May 2018 15:06:53 -0400    

Click here for diff

The impact of VARIADIC on the combine/serialize/deserialize support  
functions of an aggregate wasn't thought through carefully.  There is  
actually no impact, because variadicity isn't passed through to these  
functions (and it doesn't seem like it would need to be).  However,  
lookup_agg_function was mistakenly told to check things as though it were  
passed through.  The net result was that it was impossible to declare an  
aggregate that had both VARIADIC input and parallelism support functions.  
  
In passing, fix a runtime check in nodeAgg.c for the combine function's  
strictness to make its error message agree with the creation-time check.  
The previous message was actually backwards, and it doesn't seem like  
there's a good reason to have two versions of this message text anyway.  
  
Back-patch to 9.6 where parallel aggregation was introduced.  
  
Alexey Bashtanov; message fix by me  
  
Discussion: https://postgr.es/m/f86dde87-fef4-71eb-0480-62754aaca01b@imap.cc  

M src/backend/catalog/pg_aggregate.c
M src/backend/executor/nodeAgg.c

Doc: fix minor release-note typo.

commit   : 8cbd679fffbe5f3a88c641280e0b9fb7468be684    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 14 May 2018 12:08:02 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 14 May 2018 12:08:02 -0400    

Click here for diff

Liudmila Mantrova  
  
Discussion: https://postgr.es/m/d13458be-c4b9-0fd8-f333-c8de4d0c9120@postgrespro.ru  

M doc/src/sgml/release-10.sgml

Update time zone data files to tzdata release 2018e.

commit   : aba2f5522c04bc8464132ee899317b3c4dc4f9ef    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 9 May 2018 13:55:27 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 9 May 2018 13:55:27 -0400    

Click here for diff

DST law changes in North Korea.  Redefinition of "daylight savings" in  
Ireland, as well as for some past years in Namibia and Czechoslovakia.  
Additional historical corrections for Czechoslovakia.  
  
With this change, the IANA database models Irish timekeeping as following  
"standard time" in summer, and "daylight savings" in winter, so that the  
daylight savings offset is one hour behind standard time not one hour  
ahead.  This does not change their UTC offset (+1:00 in summer, 0:00 in  
winter) nor their timezone abbreviations (IST in summer, GMT in winter),  
though now "IST" is more correctly read as "Irish Standard Time" not "Irish  
Summer Time".  However, the "is_dst" column in the pg_timezone_names view  
will now be true in winter and false in summer for the Europe/Dublin zone.  
  
Similar changes were made for Namibia between 1994 and 2017, and for  
Czechoslovakia between 1946 and 1947.  
  
So far as I can find, no Postgres internal logic cares about which way  
tm_isdst is reported; in particular, since commit b2cbced9e we do not  
rely on it to decide how to interpret ambiguous timestamps during DST  
transitions.  So I don't think this change will affect any Postgres  
behavior other than the timezone-view outputs.  
  
Discussion: https://postgr.es/m/30996.1525445902@sss.pgh.pa.us  

M src/backend/utils/adt/datetime.c
M src/timezone/data/tzdata.zi
M src/timezone/known_abbrevs.txt
M src/timezone/tznames/Asia.txt
M src/timezone/tznames/Default
M src/timezone/tznames/Europe.txt

Improve inefficient regexes in vacuumdb TAP test.

commit   : da0b4c8a8addc6f03fd530d43b4b2bef390946f4    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 8 May 2018 20:17:43 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 8 May 2018 20:17:43 -0400    

Click here for diff

The regexes used in 102_vacuumdb_stages.pl to check the postmaster log  
for expected output contained several places with ".*.*", which is  
underdetermined and can cause exponential runtime growth in Perl's regex  
matcher (since it's not bright enough not to waste time seeing whether  
different splits of the same substring would allow a match).  We were  
fortunate that the amount of text in the postmaster log was generally not  
enough to make the runtime go to the moon; although commit 6271fceb8 had  
been on the hairy edge of an obvious problem, thanks to its increasing the  
default log verbosity to DEBUG1.  Experimentation shows that anyone who  
tried to run this test case with an even higher log verbosity would have  
been in for serious pain.  But even at default logging level, fixing this  
saves several hundred ms on my workstation, more on slower buildfarm  
members.  
  
Remove the extra ".*"s, restoring more-or-less-linear matching speed.  
Back-patch to 9.4 where the test case was added, mostly in case anyone  
tries to do related debugging in a back branch.  
  
Discussion: https://postgr.es/m/32459.1525657786@sss.pgh.pa.us  

M src/bin/scripts/t/102_vacuumdb_stages.pl