PostgreSQL 11.0 commit log

Stamp 11.0.

commit   : 19f20081df059fef87e14c8e953669bd173dd7f1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 15 Oct 2018 17:12:02 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 15 Oct 2018 17:12:02 -0400    

Click here for diff

M configure
M configure.in
M doc/bug.template
M src/include/pg_config.h.win32

Check for stack overrun in standard_ProcessUtility().

commit   : db9034bf7653fa527e2531e1a713dbbd37066a6b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 15 Oct 2018 14:01:38 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 15 Oct 2018 14:01:38 -0400    

Click here for diff

ProcessUtility can recurse, and indeed can be driven to infinite  
recursion, so it ought to have a check_stack_depth() call.  This  
covers the reported bug (portal trying to execute itself) and a bunch  
of other cases that could perhaps arise somewhere.  
  
Per bug #15428 from Malthe Borch.  Back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/15428-b3c2915ec470b033@postgresql.org  

M src/backend/tcop/utility.c

Translation updates

commit   : 6c6deadb044bd0353641aff8203fd92eb0e6606f    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 15 Oct 2018 11:33:11 +0200    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 15 Oct 2018 11:33:11 +0200    

Click here for diff

Source-Git-URL: https://git.postgresql.org/git/pgtranslation/messages.git  
Source-Git-Hash: 63764ec4ef426dc469efe1cbcd9f2c45ef9fbe95  

M src/backend/po/ja.po
M src/backend/po/sv.po
M src/bin/pg_basebackup/po/fr.po
M src/bin/pg_basebackup/po/ja.po
M src/bin/pg_basebackup/po/sv.po
M src/bin/pg_rewind/po/ja.po
M src/bin/pg_verify_checksums/po/ja.po
M src/bin/psql/po/fr.po
M src/bin/psql/po/ja.po
M src/pl/plpgsql/src/po/ja.po

Fixes for "Glyph not available" warnings from FOP

commit   : d315639c82e8a2cfd1d1b98b7acf0f6c033ab955    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 15 Oct 2018 09:48:49 +0200    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 15 Oct 2018 09:48:49 +0200    

Click here for diff

With the PostgreSQL 11 release notes acknowledgments list, FOP reported  
  
WARNING: Glyph "?" (0x144, nacute) not available in font "Times-Roman".  
WARNING: Glyph "?" (0x15e, Scedilla) not available in font "Times-Roman".  
WARNING: Glyph "?" (0x15f, scedilla) not available in font "Times-Roman".  
WARNING: Glyph "?" (0x131, dotlessi) not available in font "Times-Roman".  
  
This is because we have some new contributors whose names use letters  
that we haven't used before, and apparently FOP can't handle them out  
of the box.  
  
For now, just fix this by "unaccenting" those names.  In the future,  
maybe this can be fixed better with a different font configuration.  
  
There is also another warning  
  
WARNING: Glyph "?" (0x3c0, pi) not available in font "Times-Roman".  
  
but that existed in previous releases and is not touched here.  

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

contrib/bloom documentation improvement

commit   : 1846bac46da142e0a9fdef3f9004c306370d7213    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Mon, 15 Oct 2018 00:40:17 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Mon, 15 Oct 2018 00:40:17 +0300    

Click here for diff

This commit documents rounding of "length" parameter and absence of support  
for unique indexes and NULLs searching.  Backpatch to 9.6 where contrib/bloom  
was introduced.  
  
Discussion: https://postgr.es/m/CAF4Au4wPQQ7EHVSnzcLjsbY3oLSzVk6UemZLD1Sbmwysy3R61g%40mail.gmail.com  
Author: Oleg Bartunov with minor editorialization by me  
Backpatch-through: 9.6  

M doc/src/sgml/bloom.sgml

Avoid duplicate XIDs at recovery when building initial snapshot

commit   : 18781cd2af97002234f2db08f68cc4b392b2e463    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sun, 14 Oct 2018 22:23:29 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sun, 14 Oct 2018 22:23:29 +0900    

Click here for diff

On a primary, sets of XLOG_RUNNING_XACTS records are generated on a  
periodic basis to allow recovery to build the initial state of  
transactions for a hot standby.  The set of transaction IDs is created  
by scanning all the entries in ProcArray.  However it happens that its  
logic never counted on the fact that two-phase transactions finishing to  
prepare can put ProcArray in a state where there are two entries with  
the same transaction ID, one for the initial transaction which gets  
cleared when prepare finishes, and a second, dummy, entry to track that  
the transaction is still running after prepare finishes.  This way  
ensures a continuous presence of the transaction so as callers of for  
example TransactionIdIsInProgress() are always able to see it as alive.  
  
So, if a XLOG_RUNNING_XACTS takes a standby snapshot while a two-phase  
transaction finishes to prepare, the record can finish with duplicated  
XIDs, which is a state expected by design.  If this record gets applied  
on a standby to initial its recovery state, then it would simply fail,  
so the odds of facing this failure are very low in practice.  It would  
be tempting to change the generation of XLOG_RUNNING_XACTS so as  
duplicates are removed on the source, but this requires to hold on  
ProcArrayLock for longer and this would impact all workloads,  
particularly those using heavily two-phase transactions.  
  
XLOG_RUNNING_XACTS is also actually used only to initialize the standby  
state at recovery, so instead the solution is taken to discard  
duplicates when applying the initial snapshot.  
  
Diagnosed-by: Konstantin Knizhnik  
Author: Michael Paquier  
Discussion: https://postgr.es/m/0c96b653-4696-d4b4-6b5d-78143175d113@postgrespro.ru  
Backpatch-through: 9.3  

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

Doc: still further copy-editing for v11 release notes.

commit   : 52f76a02f6609ab84a4b929d8b0f1ccc0f7f3c9e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 13 Oct 2018 21:39:20 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 13 Oct 2018 21:39:20 -0400    

Click here for diff

Justin Pryzby and myself.  
  
Discussion: https://postgr.es/m/20181006134249.GD871@telsasoft.com  

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

Add "B" suffix for bytes to docs

commit   : e2002b4014d4650ebb42c93111b8a7a9b34ec8d9    
  
author   : Greg Stark <stark@mit.edu>    
date     : Sat, 6 Oct 2018 13:03:43 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 6 Oct 2018 13:03:43 -0400    

Click here for diff

6e7baa3227 and b06d8e58b5 added "B" as a valid suffix for  
GUC_UNIT_BYTES but neglected to add it to the docs.  

M doc/src/sgml/config.sgml

Doc: further copy-editing for v11 release notes.

commit   : d1fd7576e1d3d17d1d63c8796a02de1649fd63fe    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 13 Oct 2018 17:29:12 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 13 Oct 2018 17:29:12 -0400    

Click here for diff

Justin Pryzby, Jonathan S. Katz, and myself.  
  
Discussion: https://postgr.es/m/20181006134249.GD871@telsasoft.com  

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

Doc: copy-editing for CREATE INDEX reference page.

commit   : 4d00ee4b4ac2c17e32633d3c305041f5e6570bea    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 13 Oct 2018 16:42:58 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 13 Oct 2018 16:42:58 -0400    

Click here for diff

Justin Pryzby, Jonathan S. Katz, and myself.  
  
Discussion: https://postgr.es/m/20181006134249.GD871@telsasoft.com  

M doc/src/sgml/ref/create_index.sgml

Make an editing pass over v11 release notes.

commit   : a31af2551fed8cb7d2d52f3dbe6c6e0d21a1c57c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 13 Oct 2018 16:31:09 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 13 Oct 2018 16:31:09 -0400    

Click here for diff

Set the release date.  Do a bunch of copy-editing and markup improvement,  
rearrange some stuff into what seemed a more sensible order, move some  
things that did not seem to be in the right section.  

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

Remove abstime, reltime, tinterval tables from old regression databases.

commit   : 184951a48a107c7e1f128f7fa3887fbd216d6d60    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 12 Oct 2018 19:33:56 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 12 Oct 2018 19:33:56 -0400    

Click here for diff

In the back branches, drop these tables after the regression tests are  
done with them.  This fixes failures of cross-branch pg_upgrade testing  
caused by these types having been removed in v12.  We do lose the ability  
to test dump/restore behavior with these types in the back branches, but  
the actual loss of code coverage seems to be nil given that there's nothing  
very special about these types.  
  
Discussion: https://postgr.es/m/20181009192237.34wjp3nmw7oynmmr@alap3.anarazel.de  

M src/test/regress/expected/horology.out
M src/test/regress/expected/sanity_check.out
M src/test/regress/sql/horology.sql

Simplify use of AllocSetContextCreate() wrapper macro.

commit   : 3d059655be7dfcb7124c6b3ce0925448de89f669    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 12 Oct 2018 14:26:56 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 12 Oct 2018 14:26:56 -0400    

Click here for diff

We can allow this macro to accept either abbreviated or non-abbreviated  
allocation parameters by making use of __VA_ARGS__.  As noted by Andres  
Freund, it's unlikely that any compiler would have __builtin_constant_p  
but not __VA_ARGS__, so this gives up little or no error checking, and  
it avoids a minor but annoying API break for extensions.  
  
With this change, there is no reason for anybody to call  
AllocSetContextCreateExtended directly, so in HEAD I renamed it to  
AllocSetContextCreateInternal.  It's probably too late for an ABI  
break like that in 11, though.  
  
Discussion: https://postgr.es/m/20181012170355.bhxi273skjt6sag4@alap3.anarazel.de  

M src/backend/access/transam/xact.c
M src/backend/utils/mmgr/aset.c
M src/backend/utils/mmgr/mcxt.c
M src/include/utils/memutils.h

Correct attach/detach logic for FKs in partitions

commit   : 355684ee3fa3001adf0de3873fddadd119773819    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 12 Oct 2018 12:36:26 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 12 Oct 2018 12:36:26 -0300    

Click here for diff

There was no code to handle foreign key constraints on partitioned  
tables in the case of ALTER TABLE DETACH; and if you happened to ATTACH  
a partition that already had an equivalent constraint, that one was  
ignored and a new constraint was created.  Adding this to the fact that  
foreign key cloning reuses the constraint name on the partition instead  
of generating a new name (as it probably should, to cater to SQL  
standard rules about constraint naming within schemas), the result was a  
pretty poor user experience -- the most visible failure was that just  
detaching a partition and re-attaching it failed with an error such as  
  
  ERROR:  duplicate key value violates unique constraint "pg_constraint_conrelid_contypid_conname_index"  
  DETAIL:  Key (conrelid, contypid, conname)=(26702, 0, test_result_asset_id_fkey) already exists.  
  
because it would try to create an identically-named constraint in the  
partition.  To make matters worse, if you tried to drop the constraint  
in the now-independent partition, that would fail because the constraint  
was still seen as dependent on the constraint in its former parent  
partitioned table:  
  ERROR:  cannot drop inherited constraint "test_result_asset_id_fkey" of relation "test_result_cbsystem_0001_0050_monthly_2018_09"  
  
This fix attacks the problem from two angles: first, when the partition  
is detached, the constraint is also marked as independent, so the drop  
now works.  Second, when the partition is re-attached, we scan existing  
constraints searching for one matching the FK in the parent, and if one  
exists, we link that one to the parent constraint.  So we don't end up  
with a duplicate -- and better yet, we don't need to scan the referenced  
table to verify that the constraint holds.  
  
To implement this I made a small change to previously planner-only  
struct ForeignKeyCacheInfo to contain the constraint OID; also relcache  
now maintains the list of FKs for partitioned tables too.  
  
Backpatch to 11.  
  
Reported-by: Michael Vitale (bug #15425)  
Discussion: https://postgr.es/m/15425-2dbc9d2aa999f816@postgresql.org  

M src/backend/catalog/pg_constraint.c
M src/backend/commands/tablecmds.c
M src/backend/nodes/copyfuncs.c
M src/backend/nodes/outfuncs.c
M src/backend/utils/cache/relcache.c
M src/include/utils/rel.h
M src/test/regress/expected/foreign_key.out
M src/test/regress/sql/foreign_key.sql

Fix logical decoding error when system table w/ toast is repeatedly rewritten.

commit   : 88670a4366110c946ef47048d1cebd641209fb0d    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Wed, 10 Oct 2018 13:53:02 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Wed, 10 Oct 2018 13:53:02 -0700    

Click here for diff

Repeatedly rewriting a mapped catalog table with VACUUM FULL or  
CLUSTER could cause logical decoding to fail with:  
ERROR, "could not map filenode \"%s\" to relation OID"  
  
To trigger the problem the rewritten catalog had to have live tuples  
with toasted columns.  
  
The problem was triggered as during catalog table rewrites the  
heap_insert() check that prevents logical decoding information to be  
emitted for system catalogs, failed to treat the new heap's toast table  
as a system catalog (because the new heap is not recognized as a  
catalog table via RelationIsLogicallyLogged()). The relmapper, in  
contrast to the normal catalog contents, does not contain historical  
information. After a single rewrite of a mapped table the new relation  
is known to the relmapper, but if the table is rewritten twice before  
logical decoding occurs, the relfilenode cannot be mapped to a  
relation anymore.  Which then leads us to error out.   This only  
happens for toast tables, because the main table contents aren't  
re-inserted with heap_insert().  
  
The fix is simple, add a new heap_insert() flag that prevents logical  
decoding information from being emitted, and accept during decoding  
that there might not be tuple data for toast tables.  
  
Unfortunately that does not fix pre-existing logical decoding  
errors. Doing so would require not throwing an error when a filenode  
cannot be mapped to a relation during decoding, and that seems too  
likely to hide bugs.  If it's crucial to fix decoding for an existing  
slot, temporarily changing the ERROR in ReorderBufferCommit() to a  
WARNING appears to be the best fix.  
  
Author: Andres Freund  
Discussion: https://postgr.es/m/20180914021046.oi7dm4ra3ot2g2kt@alap3.anarazel.de  
Backpatch: 9.4-, where logical decoding was introduced  

M contrib/test_decoding/expected/rewrite.out
M contrib/test_decoding/sql/rewrite.sql
M src/backend/access/heap/heapam.c
M src/backend/access/heap/rewriteheap.c
M src/backend/replication/logical/reorderbuffer.c
M src/include/access/heapam.h

Stamp 11rc1.

commit   : 4c676181cdb6c16c414d5e9cd2304f5c73881601    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 8 Oct 2018 17:24:40 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 8 Oct 2018 17:24:40 -0400    

Click here for diff

M configure
M configure.in
M doc/bug.template
M src/include/pg_config.h.win32

Advance transaction timestamp for intra-procedure transactions.

commit   : 1145c26b749a73419d32e4c997237e84fbbffa04    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 8 Oct 2018 16:16:36 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 8 Oct 2018 16:16:36 -0400    

Click here for diff

Per discussion, this behavior seems less astonishing than not doing so.  
  
Peter Eisentraut and Tom Lane  
  
Discussion: https://postgr.es/m/20180920234040.GC29981@momjian.us  

M src/backend/access/transam/xact.c
M src/backend/executor/spi.c
M src/include/executor/spi.h
M src/pl/plpgsql/src/expected/plpgsql_transaction.out
M src/pl/plpgsql/src/sql/plpgsql_transaction.sql

Silence compiler warning in Assert()

commit   : 8569ef63f4d30d25f950270f62ca7263b56157a3    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 8 Oct 2018 10:36:33 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 8 Oct 2018 10:36:33 -0300    

Click here for diff

gcc 6.3 does not whine about this mistake I made in 39808e8868c8 but  
evidently lots of other compilers do, according to Michael Paquier,  
Peter Eisentraut, Arthur Zakirov, Tomas Vondra.  
  
Discussion: too many to list  

M src/backend/commands/event_trigger.c

Translation updates

commit   : 69ff26b96f6f1ea947bd52d18f21e99fd61c25ec    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 8 Oct 2018 12:03:54 +0200    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 8 Oct 2018 12:03:54 +0200    

Click here for diff

Source-Git-URL: https://git.postgresql.org/git/pgtranslation/messages.git  
Source-Git-Hash: 64b916c6c8a34d9e6aad88e78cc2356a941f1335  

M src/backend/po/de.po
M src/backend/po/ru.po
M src/backend/po/sv.po
M src/bin/initdb/po/fr.po
M src/bin/initdb/po/ru.po
M src/bin/pg_basebackup/po/de.po
M src/bin/pg_basebackup/po/fr.po
M src/bin/pg_basebackup/po/ru.po
M src/bin/pg_controldata/po/fr.po
M src/bin/pg_controldata/po/ru.po
M src/bin/pg_ctl/po/fr.po
M src/bin/pg_ctl/po/ru.po
M src/bin/pg_dump/po/fr.po
M src/bin/pg_dump/po/ru.po
M src/bin/pg_resetwal/po/fr.po
M src/bin/pg_resetwal/po/ru.po
M src/bin/pg_rewind/po/fr.po
M src/bin/pg_rewind/po/ru.po
M src/bin/pg_rewind/po/sv.po
M src/bin/pg_test_fsync/po/ru.po
M src/bin/pg_upgrade/po/fr.po
M src/bin/pg_upgrade/po/ru.po
M src/bin/pg_verify_checksums/nls.mk
A src/bin/pg_verify_checksums/po/fr.po
A src/bin/pg_verify_checksums/po/ru.po
M src/bin/pg_verify_checksums/po/sv.po
M src/bin/pg_waldump/po/fr.po
M src/bin/pg_waldump/po/ru.po
M src/bin/psql/po/ru.po
M src/bin/psql/po/sv.po
M src/bin/scripts/po/fr.po
M src/bin/scripts/po/ru.po
M src/interfaces/ecpg/ecpglib/po/ru.po
M src/interfaces/ecpg/preproc/po/fr.po
M src/interfaces/ecpg/preproc/po/ru.po
M src/interfaces/libpq/po/fr.po
M src/interfaces/libpq/po/ru.po
M src/pl/plperl/po/ru.po
M src/pl/plpgsql/src/po/fr.po
M src/pl/plpgsql/src/po/ru.po
M src/pl/plpython/po/fr.po
M src/pl/plpython/po/ru.po
M src/pl/tcl/po/ru.po

Track procedure calls in pg_stat_user_functions

commit   : c2055a4a171b11a7d0df7fabeaaeec9b8cdf85af    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 5 Oct 2018 14:14:03 +0200    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 5 Oct 2018 14:14:03 +0200    

Click here for diff

This was forgotten when procedures were implemented.  
  
Reported-by: Lukas Fittl <lukas@fittl.com>  

M src/backend/commands/functioncmds.c

commit   : c8ed820c68bcad00d07d60e436cdddb7c0edf44d    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 8 Oct 2018 17:56:13 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 8 Oct 2018 17:56:13 +0900    

Click here for diff

Error messages for creating a foreign key on a partitioned table using  
ONLY or NOT VALID were wrong in mentioning the objects they worked on.  
This commit adds on the way some regression tests missing for those  
cases.  
  
Author: Laurenz Albe  
Reviewed-by: Michael Paquier  
Discussion: https://postgr.es/m/c11c05810a9ed65e9b2c817a9ef442275a32fe80.camel@cybertec.at  

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

Fix speling error

commit   : 4d7c74039f091e04e520d5688c964f653f8c55a8    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Mon, 8 Oct 2018 08:57:24 +0200    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Mon, 8 Oct 2018 08:57:24 +0200    

Click here for diff

Reported by Alexander Lakhin in bug #15423  

M src/bin/pg_basebackup/pg_basebackup.c

Fix catalog insertion order for ATTACH PARTITION

commit   : 1c7f585b5c1a317bdbdf7d41c7ffab9968738149    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Sat, 6 Oct 2018 22:13:19 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Sat, 6 Oct 2018 22:13:19 -0300    

Click here for diff

Commit 2fbdf1b38bc changed the order in which we inserted catalog rows  
when creating partitions, so that we could remove an unsightly hack  
required for untimely relcache invalidations.  However, that commit only  
changed the ordering for CREATE TABLE PARTITION OF, and left ALTER TABLE  
ATTACH PARTITION unchanged, so the latter can be affected when catalog  
invalidations occur, for instance when the partition key involves an SQL  
function.  
  
Reported-by: Rajkumar Raghuwanshi  
Author: Amit Langote  
Reviewed-by: Michaël Paquier  
Discussion: https://postgr.es/m/CAKcux6=nTz9KSfTr_6Z2mpzLJ_09JN-rK6=dWic6gGyTSWueyQ@mail.gmail.com  

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

Fix event triggers for partitioned tables

commit   : 1a852f7c1e27eef563cf0577c2604baec1be5512    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Sat, 6 Oct 2018 19:17:46 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Sat, 6 Oct 2018 19:17:46 -0300    

Click here for diff

Index DDL cascading on partitioned tables introduced a way for ALTER  
TABLE to be called reentrantly.  This caused an an important deficiency  
in event trigger support to be exposed: on exiting the reentrant call,  
the alter table state object was clobbered, causing a crash when the  
outer alter table tries to finalize its processing.  Fix the crash by  
creating a stack of event trigger state objects.  There are still ways  
to cause things to misbehave (and probably other crashers) with more  
elaborate tricks, but at least it now doesn't crash in the obvious  
scenario.  
  
Backpatch to 9.5, where DDL deparsing of event triggers was introduced.  
  
Reported-by: Marco Slot  
Authors: Michaël Paquier, Álvaro Herrera  
Discussion: https://postgr.es/m/CANNhMLCpi+HQ7M36uPfGbJZEQLyTy7XvX=5EFkpR-b1bo0uJew@mail.gmail.com  

M src/backend/catalog/index.c
M src/backend/commands/event_trigger.c
M src/backend/commands/indexcmds.c
M src/backend/commands/tablecmds.c
M src/backend/commands/view.c
M src/include/catalog/index.h
M src/include/tcop/deparse_utility.h
M src/test/modules/test_ddl_deparse/expected/alter_table.out
M src/test/modules/test_ddl_deparse/sql/alter_table.sql
M src/test/regress/expected/event_trigger.out
M src/test/regress/sql/event_trigger.sql

Propagate xactStartTimestamp and stmtStartTimestamp to parallel workers.

commit   : 6bf278df891d7601eda2824a8b0df15dc52b7def    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 6 Oct 2018 12:00:09 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 6 Oct 2018 12:00:09 -0400    

Click here for diff

Previously, a worker process would establish values for these based on  
its own start time.  In v10 and up, this can trivially be shown to cause  
misbehavior of transaction_timestamp(), timestamp_in(), and related  
functions which are (perhaps unwisely?) marked parallel-safe.  It seems  
likely that other behaviors might diverge from what happens in the parent  
as well.  
  
It's not as trivial to demonstrate problems in 9.6 or 9.5, but I'm sure  
it's still possible, so back-patch to all branches containing parallel  
worker infrastructure.  
  
In HEAD only, mark now() and statement_timestamp() as parallel-safe  
(other affected functions already were).  While in theory we could  
still squeeze that change into v11, it doesn't seem important enough  
to force a last-minute catversion bump.  
  
Konstantin Knizhnik, whacked around a bit by me  
  
Discussion: https://postgr.es/m/6406dbd2-5d37-4cb6-6eb2-9c44172c7e7c@postgrespro.ru  

M src/backend/access/transam/parallel.c
M src/backend/access/transam/xact.c
M src/include/access/xact.h

Assign constraint name when cloning FK definition for partitions

commit   : c905b67b79b72b88ba80d2486443c824232c6d85    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sat, 6 Oct 2018 14:59:52 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sat, 6 Oct 2018 14:59:52 +0900    

Click here for diff

This is for example used when attaching a partition to a partitioned  
table which includes foreign keys, and in this case the constraint name  
has been missing in the data cloned.  This could lead to hard crashes,  
as when validating the foreign key constraint, the constraint name is  
always expected.  Particularly, when using log_min_messages >= DEBUG1, a  
log message would be generated with this unassigned constraint name,  
leading to an assertion failure on HEAD.  
  
While on it, rename a variable in ATExecAttachPartition which was  
declared twice with the same name.  
  
Author: Michael Paquier  
Reviewed-by: Álvaro Herrera  
Discussion: https://postgr.es/m/20181005042236.GG1629@paquier.xyz  
Backpatch-through: 11  

M src/backend/catalog/pg_constraint.c
M src/backend/commands/tablecmds.c

doc: update PG 11 release notes

commit   : 076cfffb39af281f4e3b7d9852715bb09e214171    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Fri, 5 Oct 2018 17:20:24 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Fri, 5 Oct 2018 17:20:24 -0400    

Click here for diff

Discussion: https://postgr.es/m/1f5b2e66-7ba8-98ec-c06a-aee9ff33f050@postgresql.org  
  
Author: Jonathan S. Katz  
  
Backpatch-through: 11  

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

Allow btree comparison functions to return INT_MIN.

commit   : 67e7d4da72dca6525fd2b9a2f2522994040897ba    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 5 Oct 2018 16:01:29 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 5 Oct 2018 16:01:29 -0400    

Click here for diff

Historically we forbade datatype-specific comparison functions from  
returning INT_MIN, so that it would be safe to invert the sort order  
just by negating the comparison result.  However, this was never  
really safe for comparison functions that directly return the result  
of memcmp(), strcmp(), etc, as POSIX doesn't place any such restriction  
on those library functions.  Buildfarm results show that at least on  
recent Linux on s390x, memcmp() actually does return INT_MIN sometimes,  
causing sort failures.  
  
The agreed-on answer is to remove this restriction and fix relevant  
call sites to not make such an assumption; code such as "res = -res"  
should be replaced by "INVERT_COMPARE_RESULT(res)".  The same is needed  
in a few places that just directly negated the result of memcmp or  
strcmp.  
  
To help find places having this problem, I've also added a compile option  
to nbtcompare.c that causes some of the commonly used comparators to  
return INT_MIN/INT_MAX instead of their usual -1/+1.  It'd likely be  
a good idea to have at least one buildfarm member running with  
"-DSTRESS_SORT_INT_MIN".  That's far from a complete test of course,  
but it should help to prevent fresh introductions of such bugs.  
  
This is a longstanding portability hazard, so back-patch to all supported  
branches.  
  
Discussion: https://postgr.es/m/20180928185215.ffoq2xrq5d3pafna@alap3.anarazel.de  

M contrib/ltree/ltree_op.c
M contrib/pgcrypto/imath.c
M doc/src/sgml/btree.sgml
M src/backend/access/nbtree/nbtcompare.c
M src/backend/access/nbtree/nbtsearch.c
M src/backend/access/nbtree/nbtutils.c
M src/backend/executor/nodeGatherMerge.c
M src/backend/executor/nodeIndexscan.c
M src/backend/executor/nodeMergeAppend.c
M src/bin/pg_rewind/filemap.c
M src/include/access/nbtree.h
M src/include/c.h
M src/include/utils/sortsupport.h

Ensure that PLPGSQL_DTYPE_ROW variables have valid refname fields.

commit   : 6e526b78706a99dc52182387d0e6f84d05bd597a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 5 Oct 2018 12:45:37 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 5 Oct 2018 12:45:37 -0400    

Click here for diff

Without this, the syntax-tree-dumping functions in pl_funcs.c crash,  
and there are other places that might be at risk too.  Per report  
from Pavel Stehule.  
  
Looks like I broke this in commit f9263006d, so back-patch to v11.  
  
Discussion: https://postgr.es/m/CAFj8pRA+3f5n4642q2g8BXCKjbTd7yU9JMYAgDyHgozk6cQ-VA@mail.gmail.com  

M src/pl/plpgsql/src/pl_comp.c
M src/pl/plpgsql/src/pl_exec.c
M src/pl/plpgsql/src/pl_gram.y
M src/pl/plpgsql/src/plpgsql.h

Remove redundant allocation

commit   : 40159d91cc546b2585efd3eb0b3db05cd6f2be93    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 5 Oct 2018 17:10:19 +0200    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 5 Oct 2018 17:10:19 +0200    

Click here for diff

Author: Nikita Glukhov <n.gluhov@postgrespro.ru>  

M contrib/jsonb_plpython/jsonb_plpython.c

Fix duplicate primary keys in partitions

commit   : ff347f8aff04865680c19ffc818460bb2afaad5b    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 4 Oct 2018 11:37:20 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 4 Oct 2018 11:37:20 -0300    

Click here for diff

When using the CREATE TABLE .. PARTITION OF syntax, it's possible to  
cause a partition to get two primary keys if the parent already has one.  
Tighten the check to disallow that.  
  
Reported-by: Rajkumar Raghuwanshi  
Author: Amul Sul  
Discussion: https://postgr.es/m/CAKcux6=OnSV3-qd8Gb6W=KPPwcCz6Fe_O_MQYjTa24__Xn8XxA@mail.gmail.com  

M src/backend/catalog/index.c
M src/test/regress/expected/indexing.out
M src/test/regress/sql/indexing.sql

Fix issues around EXPLAIN with JIT.

commit   : e97c4d967ba500c7ec427a56467440f036127158    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Wed, 3 Oct 2018 12:48:37 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Wed, 3 Oct 2018 12:48:37 -0700    

Click here for diff

I (Andres) was more than a bit hasty in committing 33001fd7a7072d48327  
after last minute changes, leading to a number of problems (jit output  
was only shown for JIT in parallel workers, and just EXPLAIN without  
ANALYZE didn't work).  Lukas luckily found these issues quickly.  
  
Instead of combining instrumentation in in standard_ExecutorEnd(), do  
so on demand in the new ExplainPrintJITSummary().  
  
Also update a documentation example of the JIT output, changed in  
52050ad8ebec8d831.  
  
Author: Lukas Fittl, with minor changes by me  
Discussion: https://postgr.es/m/CAP53PkxmgJht69pabxBXJBM+0oc6kf3KHMborLP7H2ouJ0CCtQ@mail.gmail.com  
Backpatch: 11, where JIT compilation was introduced  

M contrib/auto_explain/auto_explain.c
M doc/src/sgml/jit.sgml
M src/backend/commands/explain.c
M src/backend/executor/execMain.c
M src/backend/executor/execParallel.c
M src/include/commands/explain.h
M src/include/nodes/execnodes.h

MAXALIGN the target address where we store flattened value.

commit   : ca5ca25d08710d7f5aaf0e390aae284bc594a6da    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Wed, 3 Oct 2018 09:14:09 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Wed, 3 Oct 2018 09:14:09 +0530    

Click here for diff

The API (EOH_flatten_into) that flattens the expanded value representation  
expects the target address to be maxaligned.  All it's usage adhere to that  
principle except when serializing datums for parallel query.  Fix that  
usage.  
  
Diagnosed-by: Tom Lane  
Author: Tom Lane and Amit Kapila  
Backpatch-through: 9.6  
Discussion: https://postgr.es/m/11629.1536550032@sss.pgh.pa.us  

M src/backend/utils/adt/datum.c
M src/test/regress/expected/select_parallel.out
M src/test/regress/sql/select_parallel.sql

Set snprintf.c's maximum number of NL arguments to be 31.

commit   : a051c19c3cf4415b36e6333a83a113de4d90a973    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 2 Oct 2018 12:41:28 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 2 Oct 2018 12:41:28 -0400    

Click here for diff

Previously, we used the platform's NL_ARGMAX if any, otherwise 16.  
The trouble with this is that the platform value is hugely variable,  
ranging from the POSIX-minimum 9 to as much as 64K on recent FreeBSD.  
Values of more than a dozen or two have no practical use and slow down  
the initialization of the argtypes array.  Worse, they cause snprintf.c  
to consume far more stack space than was the design intention, possibly  
resulting in stack-overflow crashes.  
  
Standardize on 31, which is comfortably more than we need (it looks like  
no existing translatable message has more than about 10 parameters).  
I chose that, not 32, to make the array sizes powers of 2, for some  
possible small gain in speed of the memset.  
  
The lack of reported crashes suggests that the set of platforms we  
use snprintf.c on (in released branches) may have no overlap with  
the set where NL_ARGMAX has unreasonably large values.  But that's  
not entirely clear, so back-patch to all supported branches.  
  
Per report from Mateusz Guzik (via Thomas Munro).  
  
Discussion: https://postgr.es/m/CAEepm=3VF=PUp2f8gU8fgZB22yPE_KBS0+e1AHAtQ=09schTHg@mail.gmail.com  

M src/port/snprintf.c

Fix corner-case failures in has_foo_privilege() family of functions.

commit   : 419cc8add5fb81331efbc7ea8862e08b981b7762    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 2 Oct 2018 11:54:12 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 2 Oct 2018 11:54:12 -0400    

Click here for diff

The variants of these functions that take numeric inputs (OIDs or  
column numbers) are supposed to return NULL rather than failing  
on bad input; this rule reduces problems with snapshot skew when  
queries apply the functions to all rows of a catalog.  
  
has_column_privilege() had careless handling of the case where the  
table OID didn't exist.  You might get something like this:  
	select has_column_privilege(9999,'nosuchcol','select');  
	ERROR:  column "nosuchcol" of relation "(null)" does not exist  
or you might get a crash, depending on the platform's printf's response  
to a null string pointer.  
  
In addition, while applying the column-number variant to a dropped  
column returned NULL as desired, applying the column-name variant  
did not:  
	select has_column_privilege('mytable','........pg.dropped.2........','select');  
	ERROR:  column "........pg.dropped.2........" of relation "mytable" does not exist  
It seems better to make this case return NULL as well.  
  
Also, the OID-accepting variants of has_foreign_data_wrapper_privilege,  
has_server_privilege, and has_tablespace_privilege didn't follow the  
principle of returning NULL for nonexistent OIDs.  Superusers got TRUE,  
everybody else got an error.  
  
Per investigation of Jaime Casanova's report of a new crash in HEAD.  
These behaviors have been like this for a long time, so back-patch to  
all supported branches.  
  
Patch by me; thanks to Stephen Frost for discussion and review  
  
Discussion: https://postgr.es/m/CAJGNTeP=-6Gyqq5TN9OvYEydi7Fv1oGyYj650LGTnW44oAzYCg@mail.gmail.com  

M src/backend/utils/adt/acl.c
M src/test/regress/expected/privileges.out
M src/test/regress/sql/privileges.sql

Fix documentation of pgrowlocks using "lock_type" instead of "modes"

commit   : e9cff306168743e6ff2abdc03e4857ecb9fb4001    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 2 Oct 2018 16:34:59 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 2 Oct 2018 16:34:59 +0900    

Click here for diff

The example used in the documentation is outdated as well.  This is an  
oversight from 0ac5ad5, which bumped up pgrowlocks but forgot some bits  
of the documentation.  
  
Reported-by: Chris Wilson  
Discussion: https://postgr.es/m/153838692816.2950.12001142346234155699@wrigleys.postgresql.org  
Backpatch-through: 9.3  

M doc/src/sgml/pgrowlocks.sgml

Change PROCEDURE to FUNCTION in CREATE EVENT TRIGGER syntax

commit   : 3b983c3354df78f273594dc711c207d09cd214dd    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 1 Oct 2018 23:02:55 +0200    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 1 Oct 2018 23:02:55 +0200    

Click here for diff

This was claimed to have been done in  
0a63f996e018ac508c858e87fa39cc254a5db49f, but that actually only  
changed the documentation and not the grammar.  (That commit did fully  
change it for CREATE TRIGGER.)  

M src/backend/parser/gram.y
M src/test/regress/expected/event_trigger.out
M src/test/regress/sql/event_trigger.sql

Fix tuple_data_split() to not open a relation without any lock.

commit   : 1f25c7a8fc99bb33a9b978ab92b9ba9840366753    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 1 Oct 2018 11:51:07 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 1 Oct 2018 11:51:07 -0400    

Click here for diff

contrib/pageinspect's tuple_data_split() function thought it could get  
away with opening the referenced relation with NoLock.  In practice  
there's no guarantee that the current session holds any lock on that  
rel (even if we just read a page from it), so that this is unsafe.  
  
Switch to using AccessShareLock.  Also, postpone closing the relation,  
so that we needn't copy its tupdesc.  Also, fix unsafe use of  
att_isnull() for attributes past the end of the tuple.  
  
Per testing with a patch that complains if we open a relation without  
holding any lock on it.  I don't plan to back-patch that patch, but we  
should close the holes it identifies in all supported branches.  
  
Discussion: https://postgr.es/m/2038.1538335244@sss.pgh.pa.us  

M contrib/pageinspect/heapfuncs.c

Fix ALTER COLUMN TYPE to not open a relation without any lock.

commit   : 4c985549fe82c2a283f5f113747ae2ffd1a95926    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 1 Oct 2018 11:39:13 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 1 Oct 2018 11:39:13 -0400    

Click here for diff

If the column being modified is referenced by a foreign key constraint  
of another table, ALTER TABLE would open the other table (to re-parse  
the constraint's definition) without having first obtained a lock on it.  
This was evidently intentional, but that doesn't mean it's really safe.  
It's especially not safe in 9.3, which pre-dates use of MVCC scans for  
catalog reads, but even in current releases it doesn't seem like a good  
idea.  
  
We know we'll need AccessExclusiveLock shortly to drop the obsoleted  
constraint, so just get that a little sooner to close the hole.  
  
Per testing with a patch that complains if we open a relation without  
holding any lock on it.  I don't plan to back-patch that patch, but we  
should close the holes it identifies in all supported branches.  
  
Discussion: https://postgr.es/m/2038.1538335244@sss.pgh.pa.us  

M src/backend/commands/tablecmds.c

Fix detection of the result type of strerror_r().

commit   : 7871a36255e2675075990714bfe0d051f3807efc    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 30 Sep 2018 16:24:56 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 30 Sep 2018 16:24:56 -0400    

Click here for diff

The method we've traditionally used, of redeclaring strerror_r() to  
see if the compiler complains of inconsistent declarations, turns out  
not to work reliably because some compilers only report a warning,  
not an error.  Amazingly, this has gone undetected for years, even  
though it certainly breaks our detection of whether strerror_r  
succeeded.  
  
Let's instead test whether the compiler will take the result of  
strerror_r() as a switch() argument.  It's possible this won't  
work universally either, but it's the best idea I could come up with  
on the spur of the moment.  
  
Back-patch of commit 751f532b9.  Buildfarm results indicate that only  
icc-on-Linux actually has an issue here; perhaps the lack of field  
reports indicates that people don't build PG for production that way.  
  
Discussion: https://postgr.es/m/10877.1537993279@sss.pgh.pa.us  

M config/c-library.m4
M configure
M src/include/pg_config.h.in
M src/include/pg_config.h.win32

Improve error reporting for unsupported effective_io_concurrency setting.

commit   : a8fb03fceadb5fe9698ff0182ca76b0640348e70    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 28 Sep 2018 16:12:13 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 28 Sep 2018 16:12:13 -0400    

Click here for diff

Give a specific error complaining about lack of posix_fadvise() when  
someone tries to set effective_io_concurrency > 0 on platforms  
without that.  
  
This probably isn't worth extensive back-patching, but I (tgl) felt  
cramming it into v11 was reasonable.  
  
James Robinson  
  
Discussion: https://postgr.es/m/153771876450.14994.560017943128223619@wrigleys.postgresql.org  
Discussion: https://postgr.es/m/A3942987-5BC7-4F05-B54D-2A0EC2914B33@jlr-photo.com  

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

Fix assertion failure when updating full_page_writes for checkpointer.

commit   : 6c8671bc395c9be44571e424c458b94ec20975d3    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Fri, 28 Sep 2018 12:24:09 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Fri, 28 Sep 2018 12:24:09 +0530    

Click here for diff

When the checkpointer receives a SIGHUP signal to update its configuration,  
it may need to update the shared memory for full_page_writes and need to  
write a WAL record for it.  Now, it is quite possible that the XLOG  
machinery has not been initialized by that time and it will lead to  
assertion failure while doing that.  Fix is to allow the initialization of  
the XLOG machinery outside critical section.  
  
This bug has been introduced by the commit 2c03216d83 which added the XLOG  
machinery initialization in RecoveryInProgress code path.  
  
Reported-by: Dilip Kumar  
Author: Dilip Kumar  
Reviewed-by: Michael Paquier and Amit Kapila  
Backpatch-through: 9.5  
Discussion: https://postgr.es/m/CAFiTN-u4BA8KXcQUWDPNgaKAjDXC=C2whnzBM8TAcv=stckYUw@mail.gmail.com  

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

Fix WAL recycling on standbys depending on archive_mode

commit   : 88926fd481b7d1c928947230e154235d9d9720f4    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 28 Sep 2018 11:55:43 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 28 Sep 2018 11:55:43 +0900    

Click here for diff

A restart point or a checkpoint recycling WAL segments treats segments  
marked with neither ".done" (archiving is done) or ".ready" (segment is  
ready to be archived) in archive_status the same way for archive_mode  
being "on" or "always".  While for a primary this is fine, a standby  
running a restart point with archive_mode = on would try to mark such a  
segment as ready for archiving, which is something that will never  
happen except after the standby is promoted.  
  
Note that this problem applies only to WAL segments coming from the  
local pg_wal the first time archive recovery is run.  Segments part of a  
self-contained base backup are the most common case where this could  
happen, however even in this case normally the .done markers would be  
most likely part of the backup.  Segments recovered from an archive are  
marked as .ready or .done by the startup process, and segments finished  
streaming are marked as such by the WAL receiver, so they are handled  
already.  
  
Reported-by: Haruka Takatsuka  
Author: Michael Paquier  
Discussion: https://postgr.es/m/15402-a453c90ed4cf88b2@postgresql.org  
Backpatch-through: 9.5, where archive_mode = always has been added.  

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

Fix assorted bugs in pg_get_partition_constraintdef().

commit   : 49507dec46010cc781a4b4575b6c2ff5088b13d3    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 27 Sep 2018 18:15:06 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 27 Sep 2018 18:15:06 -0400    

Click here for diff

It failed if passed a nonexistent relation OID, or one that was a non-heap  
relation, because of blindly applying heap_open to a user-supplied OID.  
This is not OK behavior for a SQL-exposed function; we have a project  
policy that we should return NULL in such cases.  Moreover, since  
pg_get_partition_constraintdef ought now to work on indexes, restricting  
it to heaps is flat wrong anyway.  
  
The underlying function generate_partition_qual() wasn't on board with  
indexes having partition quals either, nor for that matter with rels  
having relispartition set but yet null relpartbound.  (One wonders  
whether the person who wrote the function comment blocks claiming that  
these functions allow a missing relpartbound had ever tested it.)  
  
Fix by testing relispartition before opening the rel, and by using  
relation_open not heap_open.  (If any other relkinds ever grow the  
ability to have relispartition set, the code will work with them  
automatically.)  Also, don't reject null relpartbound in  
generate_partition_qual.  
  
Back-patch to v11, and all but the null-relpartbound change to v10.  
(It's not really necessary to change generate_partition_qual at all  
in v10, but I thought s/heap_open/relation_open/ would be a good  
idea anyway just to keep the code in sync with later branches.)  
  
Per report from Justin Pryzby.  
  
Discussion: https://postgr.es/m/20180927200020.GJ776@telsasoft.com  

M src/backend/utils/cache/lsyscache.c
M src/backend/utils/cache/partcache.c
M src/include/utils/lsyscache.h
M src/test/regress/expected/indexing.out
M src/test/regress/sql/indexing.sql

Recurse to sequences on ownership change for all relkinds

commit   : 6485469606c15ae219977b1c228a266087eb30ca    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 14 Jun 2018 23:22:14 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 14 Jun 2018 23:22:14 -0400    

Click here for diff

When a table ownership is changed, we must apply that also to any owned  
sequences.  (Otherwise, it would result in a situation that cannot be  
restored, because linked sequences must have the same owner as the  
table.)  But this was previously only applied to regular tables and  
materialized views.  But it should also apply to at least foreign  
tables.  This patch removes the relkind check altogether, because it  
doesn't save very much and just introduces the possibility of similar  
omissions.  
  
Bug: #15238  
Reported-by: Christoph Berg <christoph.berg@credativ.de>  

M src/backend/commands/tablecmds.c

Rework activation of commit timestamps during recovery

commit   : 180feb8c7ef5d4968170d49136faf492b6a03c67    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 26 Sep 2018 10:29:20 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 26 Sep 2018 10:29:20 +0900    

Click here for diff

The activation and deactivation of commit timestamp tracking has not  
been handled consistently for a primary or standbys at recovery.  The  
facility can be activated at three different moments of recovery:  
- The beginning, where a primary would use the GUC value for the  
decision-making, and where a standby relies on the contents of the  
control file.  
- When replaying a XLOG_PARAMETER_CHANGE record at redo.  
- The end, where both primary and standby rely on the GUC value.  
  
Using the GUC value for a primary at the beginning of recovery causes  
problems with commit timestamp access when doing crash recovery.  
Particularly, when replaying transaction commits, it could be possible  
that an attempt to read commit timestamps is done for a transaction  
which committed at a moment when track_commit_timestamp was disabled.  
  
A test case is added to reproduce the failure.  The test works down to  
v11 as it takes advantage of transaction commits within procedures.  
  
Reported-by: Hailong Li  
Author: Masahiko Sawasa, Michael Paquier  
Reviewed-by: Kyotaro Horiguchi  
Discussion: https://postgr.es/m/11224478-a782-203b-1f17-e4797b39bdf0@qunar.com  
Backpatch-through: 9.5, where commit timestamps have been introduced.  

M src/backend/access/transam/commit_ts.c
M src/backend/access/transam/xlog.c
M src/test/modules/commit_ts/t/004_restart.pl

Remove obsolete comment

commit   : 2886a8f7045411c8a1607cf3b01f3856cb475f9e    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 25 Sep 2018 17:55:22 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 25 Sep 2018 17:55:22 -0300    

Click here for diff

The documented shortcoming was actually fixed in 4c728f3829  
so the comment is not true anymore.  

M src/backend/executor/execParallel.c

Collect JIT instrumentation from workers.

commit   : e63441c3f5ca4a3cdb47f9c7fed9e61dde17b60d    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Tue, 25 Sep 2018 12:54:29 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Tue, 25 Sep 2018 12:54:29 -0700    

Click here for diff

Previously, when using parallel query, EXPLAIN (ANALYZE)'s JIT  
compilation timings did not include the overhead from doing so on the  
workers.  Fix that.  
  
We do so by simply aggregating the cost of doing JIT compilation on  
workers and the leader together. Arguably that's not quite accurate,  
because the total time spend doing so is spent in parallel - but it's  
hard to do much better.  For additional detail, when VERBOSE is  
specified, the stats for workers are displayed separately.  
  
Author: Amit Khandekar and Andres Freund  
Discussion: https://postgr.es/m/CAJ3gD9eLrz51RK_gTkod+71iDcjpB_N8eC6vU2AW-VicsAERpQ@mail.gmail.com  
Backpatch: 11-  

M contrib/auto_explain/auto_explain.c
M src/backend/commands/explain.c
M src/backend/executor/execMain.c
M src/backend/executor/execParallel.c
M src/backend/jit/jit.c
M src/backend/jit/llvm/llvmjit.c
M src/backend/jit/llvm/llvmjit_expr.c
M src/include/commands/explain.h
M src/include/executor/execParallel.h
M src/include/jit/jit.h
M src/include/nodes/execnodes.h

Make some fixes to allow building Postgres on macOS 10.14 ("Mojave").

commit   : 9590f7d6c66321214926e13558c42f0099737ce4    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 25 Sep 2018 13:23:29 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 25 Sep 2018 13:23:29 -0400    

Click here for diff

Apple's latest rearrangements of the system-supplied headers have broken  
building of PL/Perl and PL/Tcl.  The only practical way to fix PL/Tcl is to  
start using the "-isysroot" compiler flag to point to SDK-supplied headers,  
as Apple expects.  We must also start distinguishing where to find Perl's  
headers from where to find its shared library; but that seems like good  
cleanup anyway.  
  
Extensions that formerly did something like -I$(perl_archlibexp)/CORE  
should now do -I$(perl_includedir)/CORE instead.  perl_archlibexp  
is still the place to look for libperl.so, though.  
  
If for some reason you don't like the default -isysroot setting, you can  
override that by setting PG_SYSROOT in configure's arguments.  I don't  
currently think people would need to do so, unless maybe for cross-version  
build purposes.  
  
In addition, teach configure where to find tclConfig.sh.  Our traditional  
method of searching $auto_path hasn't worked for the last couple of macOS  
releases, and it now seems clear that Apple's not going to change that.  
The workaround of manually specifying --with-tclconfig was annoying  
already, but Mojave's made it a lot more so because the sysroot path now  
has to be included as well.  Let's just wire the knowledge into configure  
instead.  To avoid breaking builds against non-default Tcl installations  
(e.g. MacPorts) wherein the $auto_path method probably still works,  
arrange to try the additional case only after all else has failed.  
  
Back-patch to all supported versions, since at least the buildfarm  
cares about that.  The changes are set up to not do anything on macOS  
releases that are old enough to not have functional sysroot trees.  

M config/tcl.m4
M configure
M configure.in
M contrib/hstore_plperl/Makefile
M contrib/jsonb_plperl/Makefile
M src/Makefile.global.in
M src/pl/plperl/GNUmakefile
M src/template/darwin

Ignore publication tables when --no-publications is used

commit   : 1f50394119642f1a0e4a207ca57c27a97bfbc8c9    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 25 Sep 2018 11:05:13 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 25 Sep 2018 11:05:13 +0900    

Click here for diff

96e1cb4 has added support for --no-publications in pg_dump, pg_dumpall  
and pg_restore, but forgot the fact that publication tables also need to  
be ignored when this option is used.  
  
Author: Gilles Darold  
Reviewed-by: Michael Paquier  
Discussion: https://postgr.es/m/3f48e812-b0fa-388e-2043-9a176bdee27e@dalibo.com  
Backpatch-through: 10, where publications have been added.  

M src/bin/pg_dump/pg_backup_archiver.c
M src/bin/pg_dump/pg_dump.c

Revoke pg_stat_statements_reset() permissions

commit   : a3bb831efebf846ea1745b5cbe7ba2597bf33029    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 25 Sep 2018 09:56:41 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 25 Sep 2018 09:56:41 +0900    

Click here for diff

Commit 25fff40 has granted execute permission of the function  
pg_stat_statements_reset() to default role "pg_read_all_stats", but this  
role is meant to read statistics, and not to reset them.  The  
permissions on this function are revoked from "pg_read_all_stats".  The  
version of pg_stat_statements is bumped up in consequence.  
  
Author: Haribabu Kommi  
Reviewed-by: Michael Paquier, Amit Kapila  
Discussion: https://postgr.es/m/CAJrrPGf5fCnKqXObpwGN9nMyD--tzOf-7LFCJiz59Z1wJ5qj9A@mail.gmail.com  

M contrib/pg_stat_statements/Makefile
A contrib/pg_stat_statements/pg_stat_statements–1.5–1.6.sql
M contrib/pg_stat_statements/pg_stat_statements.control

auto_explain: Include JIT information if applicable.

commit   : e5b2bd091aa4884f8f68e2d55c851e9ebd2d8c11    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 24 Sep 2018 13:40:57 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Mon, 24 Sep 2018 13:40:57 -0700    

Click here for diff

Due to my (Andres') omission auto_explain did not include information  
about JIT compilation. Fix that.  
  
Author: Lukas Fittl  
Discussion:  
https://postgr.es/m/CAP53PkzgSyoTCau0-5FNaM484B=uO8nLzma7L1ncWLb1=oVJQA@mail.gmail.com  
Backpatch: 11-, where JIT compilation was introduced  

M contrib/auto_explain/auto_explain.c

Make EXPLAIN output for JIT compilation more dense.

commit   : 6859bd2632d80e21d25830ac60bbb48bf12f6d46    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 24 Sep 2018 13:27:08 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Mon, 24 Sep 2018 13:27:08 -0700    

Click here for diff

A discussion about also reporting JIT compilation overhead on workers  
brought unhappiness with the verbosity of the current explain format  
to light.  Make the text format more dense, and restructure the  
structured output to mirror that more closely.  
  
As we're re-jiggering the output format anyway: The denser format  
allows us to report all flags for JIT compilation (now also reporting  
PGJIT_EXPR and PGJIT_DEFORM), and report the total time in addition to  
the individual times.  
  
Per complaint from Tom Lane.  
  
Author: Andres Freund  
Discussion: https://postgr.es/m/27812.1537221015@sss.pgh.pa.us  
Backpatch: 11-, where JIT compilation was introduced  

M src/backend/commands/explain.c

Fast default trigger and expand_tuple fixes

commit   : 9625ab79245b5b91162ede9d1b4d8b4be823c21c    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 24 Sep 2018 16:11:24 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 24 Sep 2018 16:11:24 -0400    

Click here for diff

Ensure that triggers get properly filled in tuples for the OLD value.  
Also fix the logic of detecting missing null values. The previous logic  
failed to detect a missing null column before the first missing column  
with a default. Fixing this has simplified the logic a bit.  
  
Regression tests are added to test changes. This should ensure better  
coverage of expand_tuple().  
  
Original bug reports, and some code and test scripts from Tomas Vondra  
  
Backpatch to release 11.  

M src/backend/access/common/heaptuple.c
M src/backend/commands/trigger.c
M src/test/regress/expected/fast_default.out
M src/test/regress/sql/fast_default.sql

Fix over-allocation of space for array_out()'s result string.

commit   : bfdd02f88b9678dea0e0ba5866ee772f3aa55cba    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 24 Sep 2018 11:30:51 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 24 Sep 2018 11:30:51 -0400    

Click here for diff

array_out overestimated the space needed for its output, possibly by  
a very substantial amount if the array is multi-dimensional, because  
of wrong order of operations in the loop that counts the number of  
curly-brace pairs needed.  While the output string is normally  
short-lived, this could still cause problems in extreme cases.  
  
An additional minor error was that it counted one more delimiter than  
is actually needed.  
  
Repair those errors, add an Assert that the space is now correctly  
calculated, and make some minor improvements in the comments.  
  
I also failed to resist the temptation to get rid of an integer  
modulus operation per array element; a simple comparison is sufficient.  
  
This bug dates clear back to Berkeley days, so back-patch to all  
supported versions.  
  
Keiichi Hirobe, minor additional work by me  
  
Discussion: https://postgr.es/m/CAH=EFxE9W0tRvQkixR2XJRRCToUYUEDkJZk6tnADXugPBRdcdg@mail.gmail.com  

M src/backend/utils/adt/arrayfuncs.c

Initialize random() in bootstrap/stand-alone postgres and in initdb.

commit   : 89f2b64da370e7b0737760e3282f096591d6518f    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sun, 23 Sep 2018 22:56:39 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sun, 23 Sep 2018 22:56:39 -0700    

Click here for diff

This removes a difference between the standard IsUnderPostmaster  
execution environment and that of --boot and --single.  In a stand-alone  
backend, "SELECT random()" always started at the same seed.  
  
On a system capable of using posix shared memory, initdb could still  
conclude "selecting dynamic shared memory implementation ... sysv".  
Crashed --boot or --single postgres processes orphaned shared memory  
objects having names that collided with the not-actually-random names  
that initdb probed.  The sysv fallback appeared after ten crashes of  
--boot or --single postgres.  Since --boot and --single are rare in  
production use, systems used for PostgreSQL development are the  
principal candidate to notice this symptom.  
  
Back-patch to 9.3 (all supported versions).  PostgreSQL 9.4 introduced  
dynamic shared memory, but 9.3 does share the "SELECT random()" problem.  
  
Reviewed by Tom Lane and Kyotaro HORIGUCHI.  
  
Discussion: https://postgr.es/m/20180915221546.GA3159382@rfd.leadboat.com  

M src/backend/utils/init/miscinit.c
M src/bin/initdb/initdb.c

Doc: warn against using parallel restore with --load-via-partition-root.

commit   : b1356f18b70e566da5acd9544632db7b196b3220    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 23 Sep 2018 18:34:18 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 23 Sep 2018 18:34:18 -0400    

Click here for diff

This isn't terribly safe, and making it so doesn't seem like a small  
project, so for the moment just warn against it.  
  
Discussion: https://postgr.es/m/13624.1535486019@sss.pgh.pa.us  

M doc/src/sgml/ref/pg_dump.sgml
M doc/src/sgml/ref/pg_dumpall.sgml

Fix failure in WHERE CURRENT OF after rewinding the referenced cursor.

commit   : fe30cd25ec82bdc9bb9e12d3b52adadc08bedc8e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 23 Sep 2018 16:05:45 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 23 Sep 2018 16:05:45 -0400    

Click here for diff

In a case where we have multiple relation-scan nodes in a cursor plan,  
such as a scan of an inheritance tree, it's possible to fetch from a  
given scan node, then rewind the cursor and fetch some row from an  
earlier scan node.  In such a case, execCurrent.c mistakenly thought  
that the later scan node was still active, because ExecReScan hadn't  
done anything to make it look not-active.  We'd get some sort of  
failure in the case of a SeqScan node, because the node's scan tuple  
slot would be pointing at a HeapTuple whose t_self gets reset to  
invalid by heapam.c.  But it seems possible that for other relation  
scan node types we'd actually return a valid tuple TID to the caller,  
resulting in updating or deleting a tuple that shouldn't have been  
considered current.  To fix, forcibly clear the ScanTupleSlot in  
ExecScanReScan.  
  
Another issue here, which seems only latent at the moment but could  
easily become a live bug in future, is that rewinding a cursor does  
not necessarily lead to *immediately* applying ExecReScan to every  
scan-level node in the plan tree.  Upper-level nodes will think that  
they can postpone that call if their child node is already marked  
with chgParam flags.  I don't see a way for that to happen today in  
a plan tree that's simple enough for execCurrent.c's search_plan_tree  
to understand, but that's one heck of a fragile assumption.  So, add  
some logic in search_plan_tree to detect chgParam flags being set on  
nodes that it descended to/through, and assume that that means we  
should consider lower scan nodes to be logically reset even if their  
ReScan call hasn't actually happened yet.  
  
Per bug #15395 from Matvey Arye.  This has been broken for a long time,  
so back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/153764171023.14986.280404050547008575@wrigleys.postgresql.org  

M src/backend/executor/execCurrent.c
M src/backend/executor/execScan.c
M src/test/regress/expected/portals.out
M src/test/regress/sql/portals.sql

docs: remove use of escape strings and use bytea hex output

commit   : 7f203d60f413007a654a0f9b7763ef986150ce95    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Fri, 21 Sep 2018 19:55:07 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Fri, 21 Sep 2018 19:55:07 -0400    

Click here for diff

standard_conforming_strings defaulted to 'on' in PG 9.1.  
bytea_output defaulted to 'hex' in PG 9.0.  
  
Reported-by: André Hänsel  
  
Discussion: https://postgr.es/m/12e601d447ac$345994a0$9d0cbde0$@webkr.de  
  
Backpatch-through: 9.3  

M doc/src/sgml/array.sgml
M doc/src/sgml/datatype.sgml
M doc/src/sgml/func.sgml
M doc/src/sgml/lobj.sgml
M doc/src/sgml/rowtypes.sgml

Fix bogus tab-completion rule for CREATE PUBLICATION.

commit   : 45a2d45f4ff2e2f1524e7eb3aca9243895eefa8a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 21 Sep 2018 15:58:37 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 21 Sep 2018 15:58:37 -0400    

Click here for diff

You can't use "FOR TABLE" as a single Matches argument, because readline  
will consider that input to be two words not one.  It's necessary to make  
the pattern contain two arguments.  
  
The case accidentally worked anyway because the words_after_create  
test fired ... but only for the first such table name.  
  
Noted by Edmund Horner, though this isn't exactly his proposed fix.  
Backpatch to v10 where the faulty code came in.  
  
Discussion: https://postgr.es/m/CAMyN-kDe=gBmHgxWwUUaXuwK+p+7g1vChR7foPHRDLE592nJPQ@mail.gmail.com  

M src/bin/psql/tab-complete.c

Use size_t consistently in dsa.{ch}.

commit   : ec7b27675dcc39e81555260a5e33c5aa0fb2bcd2    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Sat, 22 Sep 2018 00:40:13 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Sat, 22 Sep 2018 00:40:13 +1200    

Click here for diff

Takeshi Ideriha complained that there is a mixture of Size and size_t  
in dsa.c and corresponding header.  Let's use size_t.  Back-patch to 10  
where dsa.c landed, to make future back-patching easy.  
  
Discussion: https://postgr.es/m/4E72940DA2BF16479384A86D54D0988A6F19ABD9%40G01JPEXMBKW04  

M src/backend/utils/mmgr/dsa.c
M src/include/utils/dsa.h

Document lock taken on referenced table when adding a foreign key

commit   : 3d4b143dc7fd9d060e9f11ac6c17620f58cfc33d    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 21 Sep 2018 15:09:40 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 21 Sep 2018 15:09:40 +0900    

Click here for diff

This can happen for CREATE TABLE and ALTER TABLE, so a mention is added  
to both of them in the concerned subsections.  
  
Author: Adrien Nayrat  
Discussion: https://postgr.es/m/c4e8af11-1dfc-766a-c953-76979b9fcdaa@anayrat.info  

M doc/src/sgml/ref/alter_table.sgml
M doc/src/sgml/ref/create_table.sgml

Error out for clang on x86-32 without SSE2 support, no -fexcess-precision.

commit   : 84f14fb788523d5175fc9b5a11c36853a3697d32    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Thu, 13 Sep 2018 14:18:43 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Thu, 13 Sep 2018 14:18:43 -0700    

Click here for diff

As clang currently doesn't support -fexcess-precision=standard,  
compiling x86-32 code with SSE2 disabled, can lead to problems with  
floating point overflow checks and the like.  
  
This issue was noticed because clang, on at least some BSDs, defaults  
to i386 compatibility, whereas it defaults to pentium4 on Linux.  Our  
forced usage of __builtin_isinf() lead to some overflow checks not  
triggering when compiling for i386, e.g. when the result of the  
calculation didn't overflow in 80bit registers, but did so in 64bit.  
  
While we could just fall back to a non-builtin isinf, it seems likely  
that the use of 80bit registers leads to other problems (which is why  
we force the flag for GCC already).  Therefore error out when  
detecting clang in that situation.  
  
Reported-By: Victor Wagner  
Analyzed-By: Andrew Gierth and Andres Freund  
Author: Andres Freund  
Discussion: https://postgr.es/m/20180905005130.ewk4xcs5dgyzcy45@alap3.anarazel.de  
Backpatch: 9.3-, all supported versions are affected  

M configure
M configure.in

Fix segment_bins corruption in dsa.c.

commit   : 8ffc3be10f86af74d1341ba886237a330e47485f    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Thu, 20 Sep 2018 15:52:39 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Thu, 20 Sep 2018 15:52:39 +1200    

Click here for diff

If a segment has been freed by dsa.c because it is entirely empty, other  
backends must make sure to unmap it before following links to new  
segments that might happen to have the same index number, or they could  
finish up looking at a defunct segment and then corrupt the segment_bins  
lists.  The correct protocol requires checking freed_segment_counter  
after acquiring the area lock and before resolving any index number to a  
segment.  Add the missing checks and an assertion.  
  
Back-patch to 10, where dsa.c first arrived.  
  
Author: Thomas Munro  
Reported-by: Tomas Vondra  
Discussion: https://postgr.es/m/CAEepm%3D0thg%2Bja5zGVa7jBy-uqyHrTqTm8HGhEOtMmigGrAqTbw%40mail.gmail.com  

M src/backend/utils/mmgr/dsa.c

Defer restoration of libraries in parallel workers.

commit   : 9d178fb928040f1a5ab5b566f1ec76d7ac554587    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Thu, 20 Sep 2018 14:02:56 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Thu, 20 Sep 2018 14:02:56 +1200    

Click here for diff

Several users of extensions complained of crashes in parallel workers  
that turned out to be due to syscache access from their _PG_init()  
functions.  Reorder the initialization of parallel workers so that  
libraries are restored after the caches are initialized, and inside a  
transaction.  
  
This was reported in bug #15350 and elsewhere.  We don't consider it  
to be a bug: extensions shouldn't do that, because then they can't be  
used in shared_preload_libraries.  However, it's a fairly obscure  
hazard and these extensions worked in practice before parallel query  
came along.  So let's make it work.  Later commits might add a warning  
message and eventually an error.  
  
Back-patch to 9.6, where parallel query landed.  
  
Author: Thomas Munro  
Reviewed-by: Amit Kapila  
Reported-by: Kieran McCusker, Jimmy  
Discussion: https://postgr.es/m/153512195228.1489.8545997741965926448%40wrigleys.postgresql.org  

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

Fix minor error message style guide violation.

commit   : 6449616419c59c3223b3c4f731cefa3d77fac567    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 19 Sep 2018 17:06:40 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 19 Sep 2018 17:06:40 -0400    

Click here for diff

No periods at the ends of primary error messages, please.  
  
Daniel Gustafsson  
  
Discussion: https://postgr.es/m/43E004C0-18C6-42B4-A313-003B43EB0571@yesql.se  

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

Don't ignore locktable-full failures in StandbyAcquireAccessExclusiveLock.

commit   : c84f83975eb48d19f712b2b4d3c788c018906ed2    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 19 Sep 2018 12:43:51 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 19 Sep 2018 12:43:51 -0400    

Click here for diff

Commit 37c54863c removed the code in StandbyAcquireAccessExclusiveLock  
that checked the return value of LockAcquireExtended.  That created a  
bug, because it's still passing reportMemoryError = false to  
LockAcquireExtended, meaning that LOCKACQUIRE_NOT_AVAIL will be returned  
if we're out of shared memory for the lock table.  
  
In such a situation, the startup process would believe it had acquired an  
exclusive lock even though it hadn't, with potentially dire consequences.  
  
To fix, just drop the use of reportMemoryError = false, which allows us  
to simplify the call into a plain LockAcquire().  It's unclear that the  
locktable-full situation arises often enough that it's worth having a  
better recovery method than crash-and-restart.  (I strongly suspect that  
the only reason the code path existed at all was that it was relatively  
simple to do in the pre-37c54863c implementation.  But now it's not.)  
  
LockAcquireExtended's reportMemoryError parameter is now dead code and  
could be removed.  I refrained from doing so, however, because there  
was some interest in resurrecting the behavior if we do get reports of  
locktable-full failures in the field.  Also, it seems unwise to remove  
the parameter concurrently with shipping commit f868a8143, which added a  
parameter; if there are any third-party callers of LockAcquireExtended,  
we want them to get a wrong-number-of-parameters compile error rather  
than a possibly-silent misinterpretation of its last parameter.  
  
Back-patch to 9.6 where the bug was introduced.  
  
Discussion: https://postgr.es/m/6202.1536359835@sss.pgh.pa.us  

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

Revert "Allow concurrent-safe open() and fopen() in frontend code for Windows"

commit   : df8b5f3eb8a7c477156d0ad9d83e7297912cfe79    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 18 Sep 2018 17:28:27 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 18 Sep 2018 17:28:27 -0400    

Click here for diff

This reverts commit f02259fe93e75d5443a2fabe2f2f38b81924ab36, in the  
v11 branch only.  
  
The hack this required in initdb.c should probably have clued us that it  
wasn't really ready, but we didn't get the hint.  Subsequent developments  
have made clear that it affected text-vs-binary behavior in a lot of  
places, and there's no reason to think that any of those behavioral changes  
are desirable.  There's no time to fix this before 11beta4, so just revert  
for the moment.  We can keep working on this in HEAD, and maybe reconsider  
a back-patch once we're satisfied things are stable.  
  
(I take the blame for this fiasco, having encouraged Michael to back-patch  
a change at the last possible moment before beta wrap.)  

M src/bin/initdb/initdb.c
M src/bin/pg_basebackup/pg_receivewal.c
M src/bin/pg_verify_checksums/pg_verify_checksums.c
M src/common/file_utils.c
M src/include/port.h

Fix some probably-minor oversights in readfuncs.c.

commit   : 5c07d6497d8e694e5de5a78c1e3f74e2b9790c48    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 18 Sep 2018 13:02:27 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 18 Sep 2018 13:02:27 -0400    

Click here for diff

The system expects TABLEFUNC RTEs to have coltypes, coltypmods, and  
colcollations lists, but outfuncs doesn't dump them and readfuncs doesn't  
restore them.  This doesn't cause obvious failures, because the only things  
that look at those fields are expandRTE() and get_rte_attribute_type(),  
which are mostly used during parse analysis, before anything would've  
passed the parsetree through outfuncs/readfuncs.  But expandRTE() is used  
in build_physical_tlist(), which means that that function will return a  
wrong answer for a TABLEFUNC RTE that came from a view.  Very accidentally,  
this doesn't cause serious problems, because what it will return is NIL  
which callers will interpret as "couldn't build a physical tlist because  
of dropped columns".  So you still get a plan that works, though it's  
marginally less efficient than it could be.  There are also some other  
expandRTE() calls associated with transformation of whole-row Vars in  
the planner.  I have been unable to exhibit misbehavior from that, and  
it may be unreachable in any case that anyone would care about ... but  
I'm not entirely convinced, so this seems like something we should back-  
patch a fix for.  Fortunately, we can fix it without forcing a change  
of stored rules and a catversion bump, because we can just copy these  
lists from the subsidiary TableFunc object.  
  
readfuncs.c was also missing support for NamedTuplestoreScan plan nodes.  
This accidentally fails to break parallel query because a query using  
a named tuplestore would never be considered parallel-safe anyway.  
However, project policy since parallel query came in is that all plan  
node types should have outfuncs/readfuncs support, so this is clearly  
an oversight that should be repaired.  
  
Noted while fooling around with a patch to test outfuncs/readfuncs more  
thoroughly.  That exposed some other issues too, but these are the only  
ones that seem worth back-patching.  
  
Back-patch to v10 where both of these features came in.  
  
Discussion: https://postgr.es/m/17114.1537138992@sss.pgh.pa.us  

M src/backend/nodes/readfuncs.c
M src/include/nodes/parsenodes.h

Allow DSM allocation to be interrupted.

commit   : 63efab4ca139ab18095b8e095d5708d5566fc9e2    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Tue, 18 Sep 2018 22:56:36 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Tue, 18 Sep 2018 22:56:36 +1200    

Click here for diff

Chris Travers reported that the startup process can repeatedly try to  
cancel a backend that is in a posix_fallocate()/EINTR loop and cause it  
to loop forever.  Teach the retry loop to give up if an interrupt is  
pending.  Don't actually check for interrupts in that loop though,  
because a non-local exit would skip some clean-up code in the caller.  
  
Back-patch to 9.4 where DSM was added (and posix_fallocate() was later  
back-patched).  
  
Author: Chris Travers  
Reviewed-by: Ildar Musin, Murat Kabilov, Oleksii Kliukin  
Tested-by: Oleksii Kliukin  
Discussion: https://postgr.es/m/CAN-RpxB-oeZve_J3SM_6%3DHXPmvEG%3DHX%2B9V9pi8g2YR7YW0rBBg%40mail.gmail.com  

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

Stamp 11beta4.

commit   : 3d65e406d1ea82060ad13a7bc41178ed22c599d1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 17 Sep 2018 18:43:41 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 17 Sep 2018 18:43:41 -0400    

Click here for diff

M configure
M configure.in
M doc/bug.template
M src/include/pg_config.h.win32

Fix parsetree representation of XMLTABLE(XMLNAMESPACES(DEFAULT ...)).

commit   : 486cfb3b8ce6e94eaad48038acff51064c070ccb    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 17 Sep 2018 13:16:32 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 17 Sep 2018 13:16:32 -0400    

Click here for diff

The original coding for XMLTABLE thought it could represent a default  
namespace by a T_String Value node with a null string pointer.  That's  
not okay, though; in particular outfuncs.c/readfuncs.c are not on board  
with such a representation, meaning you'll get a null pointer crash  
if you try to store a view or rule containing this construct.  
  
To fix, change the parsetree representation so that we have a NULL  
list element, instead of a bogus Value node.  
  
This isn't really a functional limitation since default XML namespaces  
aren't yet implemented in the executor; you'd just get "DEFAULT  
namespace is not supported" anyway.  But crashes are not nice, so  
back-patch to v10 where this syntax was added.  Ordinarily we'd consider  
a parsetree representation change to be un-backpatchable; but since  
existing releases would crash on the way to storing such constructs,  
there can't be any existing views/rules to be incompatible with.  
  
Per report from Andrey Lepikhov.  
  
Discussion: https://postgr.es/m/3690074f-abd2-56a9-144a-aa5545d7a291@postgrespro.ru  

M src/backend/executor/nodeTableFuncscan.c
M src/backend/parser/parse_clause.c
M src/backend/utils/adt/ruleutils.c
M src/include/nodes/execnodes.h
M src/include/nodes/primnodes.h

Fix pgbench lexer's "continuation" rule to cope with Windows newlines.

commit   : d45f157e8b07aee455df0bcc76fdf4e9963c0200    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 17 Sep 2018 12:11:43 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 17 Sep 2018 12:11:43 -0400    

Click here for diff

Our general practice in frontend code is to accept input with either  
Unix-style newlines (\n) or DOS-style (\r\n).  pgbench was mostly down  
with that, but its rule for line continuations (backslash-newline) was  
not.  This had been masked on Windows buildfarm machines before commit  
0ba06e0bf by use of Windows text mode to read files.  We could have fixed  
it by forcing text mode again, but it's better to fix the parsing code  
so that Windows-style text files on Unix systems don't cause problems.  
  
Back-patch to v10 where pgbench grew line continuations.  
  
Discussion: https://postgr.es/m/17194.1537191697@sss.pgh.pa.us  

M src/bin/pgbench/exprscan.l

Allow concurrent-safe open() and fopen() in frontend code for Windows

commit   : f02259fe93e75d5443a2fabe2f2f38b81924ab36    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 17 Sep 2018 20:38:42 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 17 Sep 2018 20:38:42 +0900    

Click here for diff

PostgreSQL uses a custom wrapper for open() and fopen() which is  
concurrent-safe, allowing multiple processes to open and work on the  
same file.  This has a couple of advantages:  
- pg_test_fsync does not handle O_DSYNC correctly otherwise, leading to  
false claims that disks are unsafe.  
- TAP tests can run into race conditions when a postmaster and pg_ctl  
open postmaster.pid, fixing some random failures in the buildfam.  
  
pg_upgrade is one frontend tool using workarounds to bypass file locking  
issues with the log files it generates, however the interactions with  
pg_ctl are proving to be tedious to get rid of, so this is left for  
later.  
  
Author: Laurenz Albe  
Reviewed-by: Michael Paquier, Kuntal Ghosh  
Discussion: https://postgr.es/m/1527846213.2475.31.camel@cybertec.at  
Discussion: https://postgr.es/m/16922.1520722108@sss.pgh.pa.us  

M src/bin/initdb/initdb.c
M src/bin/pg_basebackup/pg_receivewal.c
M src/bin/pg_verify_checksums/pg_verify_checksums.c
M src/common/file_utils.c
M src/include/port.h

Translation updates

commit   : bcbd1590279c1dfc3e6756a09166943437071bd2    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 17 Sep 2018 08:40:36 +0200    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 17 Sep 2018 08:40:36 +0200    

Click here for diff

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

M src/backend/nls.mk
M src/backend/po/de.po
D src/backend/po/id.po
M src/backend/po/ja.po
M src/backend/po/ko.po
D src/backend/po/pt_BR.po
M src/backend/po/sv.po
M src/backend/po/tr.po
M src/bin/initdb/po/ja.po
M src/bin/initdb/po/ko.po
M src/bin/initdb/po/sv.po
M src/bin/pg_basebackup/nls.mk
M src/bin/pg_basebackup/po/de.po
M src/bin/pg_basebackup/po/ja.po
M src/bin/pg_basebackup/po/ko.po
D src/bin/pg_basebackup/po/pt_BR.po
D src/bin/pg_basebackup/po/zh_CN.po
M src/bin/pg_config/po/ja.po
M src/bin/pg_controldata/po/ja.po
M src/bin/pg_controldata/po/ko.po
M src/bin/pg_ctl/po/ja.po
M src/bin/pg_ctl/po/ko.po
M src/bin/pg_ctl/po/sv.po
M src/bin/pg_dump/po/de.po
M src/bin/pg_dump/po/ja.po
M src/bin/pg_dump/po/ko.po
M src/bin/pg_resetwal/nls.mk
D src/bin/pg_resetwal/po/it.po
M src/bin/pg_resetwal/po/ja.po
M src/bin/pg_resetwal/po/ko.po
D src/bin/pg_resetwal/po/pl.po
D src/bin/pg_resetwal/po/pt_BR.po
M src/bin/pg_resetwal/po/sv.po
D src/bin/pg_resetwal/po/zh_CN.po
M src/bin/pg_rewind/po/de.po
M src/bin/pg_rewind/po/ja.po
M src/bin/pg_rewind/po/ko.po
M src/bin/pg_rewind/po/sv.po
M src/bin/pg_upgrade/po/de.po
M src/bin/pg_upgrade/po/ja.po
M src/bin/pg_upgrade/po/ko.po
M src/bin/pg_upgrade/po/sv.po
M src/bin/pg_verify_checksums/nls.mk
A src/bin/pg_verify_checksums/po/de.po
A src/bin/pg_verify_checksums/po/ja.po
A src/bin/pg_verify_checksums/po/ko.po
A src/bin/pg_verify_checksums/po/sv.po
A src/bin/pg_verify_checksums/po/tr.po
M src/bin/pg_waldump/po/ja.po
M src/bin/pg_waldump/po/ko.po
M src/bin/psql/nls.mk
M src/bin/psql/po/de.po
M src/bin/psql/po/ja.po
M src/bin/psql/po/ko.po
M src/bin/psql/po/sv.po
M src/bin/psql/po/tr.po
D src/bin/psql/po/zh_TW.po
M src/bin/scripts/po/ja.po
M src/bin/scripts/po/ko.po
M src/interfaces/ecpg/preproc/po/ja.po
M src/interfaces/ecpg/preproc/po/ko.po
M src/interfaces/libpq/nls.mk
M src/interfaces/libpq/po/de.po
M src/interfaces/libpq/po/ja.po
M src/interfaces/libpq/po/ko.po
M src/interfaces/libpq/po/sv.po
D src/interfaces/libpq/po/zh_TW.po
M src/pl/plperl/nls.mk
D src/pl/plperl/po/zh_TW.po
M src/pl/plpgsql/src/nls.mk
M src/pl/plpgsql/src/po/de.po
M src/pl/plpgsql/src/po/ko.po
D src/pl/plpgsql/src/po/zh_TW.po
M src/pl/plpython/po/ja.po
M src/pl/plpython/po/ko.po
M src/pl/tcl/nls.mk
D src/pl/tcl/po/pt_BR.po
D src/pl/tcl/po/ro.po
D src/pl/tcl/po/zh_CN.po
D src/pl/tcl/po/zh_TW.po

Add list of acknowledgments to release notes

commit   : 05ae1bafa540e7eeba6faa7fd217a2997021c214    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Sun, 16 Sep 2018 22:06:42 +0200    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Sun, 16 Sep 2018 22:06:42 +0200    

Click here for diff

This contains all individuals mentioned in the commit messages during  
PostgreSQL 11 development.  
  
current through 7a2f70f0e5e83871d091ee479abea4b8f850dd29  

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

Fix out-of-tree build for transform modules.

commit   : f1ca5a654d5db32c2af8b28b7fbca38bbb793f56    
  
author   : Andrew Gierth <rhodiumtoad@postgresql.org>    
date     : Sun, 16 Sep 2018 18:46:45 +0100    
  
committer: Andrew Gierth <rhodiumtoad@postgresql.org>    
date     : Sun, 16 Sep 2018 18:46:45 +0100    

Click here for diff

Neither plperl nor plpython installed sufficient header files to  
permit transform modules to be built out-of-tree using PGXS. Fix that  
by installing all plperl and plpython header files (other than those  
with special purposes such as generated data tables), and also install  
plpython's special .mk file for mangling regression tests.  
  
(This commit does not fix the windows install, which does not  
currently install _any_ plperl or plpython headers.)  
  
Also fix the existing transform modules for hstore and ltree so that  
their cross-module #include directives work as anticipated by commit  
df163230b9 et seq. This allows them to serve as working examples of  
how to reference other modules when doing separate out-of-tree builds.  
  
Discussion: https://postgr.es/m/87o9ej8bgl.fsf%40news-spur.riddles.org.uk  

M contrib/hstore_plperl/Makefile
M contrib/hstore_plperl/hstore_plperl.c
M contrib/hstore_plpython/Makefile
M contrib/hstore_plpython/hstore_plpython.c
M contrib/ltree_plpython/Makefile
M contrib/ltree_plpython/ltree_plpython.c
M src/pl/plperl/GNUmakefile
M src/pl/plpython/Makefile
M src/tools/msvc/Mkvcbuild.pm

Add outfuncs.c support for RawStmt nodes.

commit   : 0ca27ea66a18cbf9b9bc69443df15a637f26b9b4    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 16 Sep 2018 13:02:47 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 16 Sep 2018 13:02:47 -0400    

Click here for diff

I noticed while poking at a report from Andrey Lepikhov that the  
recent addition of RawStmt nodes at the top of raw parse trees  
makes it impossible to print any raw parse trees whatsoever,  
because outfuncs.c doesn't know RawStmt and hence fails to descend  
into it.  
  
While we generally lack outfuncs.c support for utility statements,  
there is reasonably complete support for what you can find in a  
raw SELECT statement.  It was not my intention to make that all  
dead code ... so let's add support for RawStmt.  
  
Back-patch to v10 where RawStmt appeared.  

M src/backend/nodes/outfuncs.c

doc: clarify pg_basebackup's -C/--create-slot description

commit   : 7a2f70f0e5e83871d091ee479abea4b8f850dd29    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Sun, 16 Sep 2018 11:35:34 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Sun, 16 Sep 2018 11:35:34 -0400    

Click here for diff

The previous text was overly complex.  
  
Backpatch-through: 11  

M doc/src/sgml/ref/pg_basebackup.sgml

In v11, disable JIT by default (it's still enabled by default in HEAD).

commit   : 0fdadfb0192935e0f8bec7fa5ec9dbb470d6d587    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 15 Sep 2018 17:24:35 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 15 Sep 2018 17:24:35 -0400    

Click here for diff

Per discussion, JIT isn't quite mature enough to ship enabled-by-default.  
  
I failed to resist the temptation to do a bunch of copy-editing on the  
related documentation.  Also, clean up some inconsistencies in which  
section of config.sgml the JIT GUCs are documented in vs. what guc.c  
and postgresql.config.sample had.  
  
Discussion: https://postgr.es/m/20180914222657.mw25esrzbcnu6qlu@alap3.anarazel.de  

M doc/src/sgml/config.sgml
M doc/src/sgml/jit.sgml
M doc/src/sgml/release-11.sgml
M src/backend/jit/jit.c
M src/backend/utils/misc/guc.c
M src/backend/utils/misc/postgresql.conf.sample

Fix failure with initplans used conditionally during EvalPlanQual rechecks.

commit   : f13e2d1cec9b786405d649c72a4aa29fadcea617    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 15 Sep 2018 13:42:34 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 15 Sep 2018 13:42:34 -0400    

Click here for diff

The EvalPlanQual machinery assumes that any initplans (that is,  
uncorrelated sub-selects) used during an EPQ recheck would have already  
been evaluated during the main query; this is implicit in the fact that  
execPlan pointers are not copied into the EPQ estate's es_param_exec_vals.  
But it's possible for that assumption to fail, if the initplan is only  
reached conditionally.  For example, a sub-select inside a CASE expression  
could be reached during a recheck when it had not been previously, if the  
CASE test depends on a column that was just updated.  
  
This bug is old, appearing to date back to my rewrite of EvalPlanQual in  
commit 9f2ee8f28, but was not detected until Kyle Samson reported a case.  
  
To fix, force all not-yet-evaluated initplans used within the EPQ plan  
subtree to be evaluated at the start of the recheck, before entering the  
EPQ environment.  This could be inefficient, if such an initplan is  
expensive and goes unused again during the recheck --- but that's piling  
one layer of improbability atop another.  It doesn't seem worth adding  
more complexity to prevent that, at least not in the back branches.  
  
It was convenient to use the new-in-v11 ExecEvalParamExecParams function  
to implement this, but I didn't like either its name or the specifics of  
its API, so revise that.  
  
Back-patch all the way.  Rather than rewrite the patch to avoid depending  
on bms_next_member() in the oldest branches, I chose to back-patch that  
function into 9.4 and 9.3.  (This isn't the first time back-patches have  
needed that, and it exhausted my patience.)  I also chose to back-patch  
some test cases added by commits 71404af2a and 342a1ffa2 into 9.4 and 9.3,  
so that the 9.x versions of eval-plan-qual.spec are all the same.  
  
Andrew Gierth diagnosed the problem and contributed the added test cases,  
though the actual code changes are by me.  
  
Discussion: https://postgr.es/m/A033A40A-B234-4324-BE37-272279F7B627@tripadvisor.com  

M src/backend/executor/execExprInterp.c
M src/backend/executor/execMain.c
M src/backend/executor/execParallel.c
M src/backend/executor/nodeSubplan.c
M src/include/executor/execExpr.h
M src/include/executor/nodeSubplan.h
M src/test/isolation/expected/eval-plan-qual.out
M src/test/isolation/specs/eval-plan-qual.spec

Move PartitionDispatchData struct definition to execPartition.c

commit   : 444455c2d9094c70f42706184064a9729906253e    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 14 Sep 2018 19:06:57 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 14 Sep 2018 19:06:57 -0300    

Click here for diff

There's no reason to expose the struct definition, so don't.  
  
Author: Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>  
Discussion: https://postgr.es/m/d3fa24c1-bc65-7133-81df-6474387ccc4f@lab.ntt.co.jp  

M src/backend/executor/execPartition.c
M src/include/executor/execPartition.h

Fix ALTER/TYPE on columns referenced by FKs in partitioned tables

commit   : 6009bad9134782babfc45c6bae6cfbca7f4899d0    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 14 Sep 2018 13:57:30 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 14 Sep 2018 13:57:30 -0300    

Click here for diff

When ALTER TABLE ... SET DATA TYPE affects a column referenced by  
constraints and indexes, it drop those constraints and indexes and  
recreates them afterwards, so that the definitions match the new data  
type.  The original code did this by dropping one object at a time  
(commit 077db40fa1f3 of May 2004), which worked fine because the  
dependencies between the objects were pretty straightforward, and  
ordering the objects in a specific way was enough to make this work.  
However, when there are foreign key constraints in partitioned tables,  
the dependencies are no longer so straightforward, and we were getting  
errors when attempted:  
  ERROR:  cache lookup failed for constraint 16398  
  
This can be fixed by doing all the drops in one pass instead, using  
performMultipleDeletions (introduced by df18c51f2955 of Aug 2006).  With  
this change we can also remove the code to carefully order the list of  
objects to be deleted.  
  
Reported-by: Rajkumar Raghuwanshi <rajkumar.raghuwanshi@enterprisedb.com>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/CAKcux6nWS_m+s=1Udk_U9B+QY7pA-Ac58qR5BdUfOyrwnWHDew@mail.gmail.com  

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

Don't allow LIMIT/OFFSET clause within sub-selects to be pushed to workers.

commit   : 830d7565902f8d1da5f07259982a6a54dc65e40d    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Fri, 14 Sep 2018 09:51:47 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Fri, 14 Sep 2018 09:51:47 +0530    

Click here for diff

Allowing sub-select containing LIMIT/OFFSET in workers can lead to  
inconsistent results at the top-level as there is no guarantee that the  
row order will be fully deterministic.  The fix is to prohibit pushing  
LIMIT/OFFSET within sub-selects to workers.  
  
Reported-by: Andrew Fletcher  
Bug: 15324  
Author: Amit Kapila  
Reviewed-by: Dilip Kumar  
Backpatch-through: 9.6  
Discussion: https://postgr.es/m/153417684333.10284.11356259990921828616@wrigleys.postgresql.org  

M src/backend/optimizer/path/allpaths.c
M src/backend/optimizer/plan/planner.c
M src/include/optimizer/planner.h
M src/test/regress/expected/select_parallel.out
M src/test/regress/sql/select_parallel.sql

Message style improvements

commit   : a2afcdab8a1a90245cab3ed4b2d4bd0812d4955a    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 13 Sep 2018 23:35:43 +0200    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 13 Sep 2018 23:35:43 +0200    

Click here for diff

Fix one untranslatable string concatenation in pg_rewind.  
  
Fix one message in pg_verify_checksums to use a style use elsewhere  
and avoid plural issues.  
  
Fix one gratuitous abbreviation in psql.  

M src/bin/pg_rewind/filemap.c
M src/bin/pg_verify_checksums/pg_verify_checksums.c
M src/bin/psql/help.c

Detect LLVM 7 without specifying binaries explicitly.

commit   : 99ba795d982efe2305d94573f2f4594bedaf6eab    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Thu, 13 Sep 2018 10:41:39 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Thu, 13 Sep 2018 10:41:39 -0700    

Click here for diff

Before this commit LLVM 7 was supported, but only if one explicitly  
provided LLVM_CONFIG= and CLANG= paths.  As LLVM 7 is the first  
version that includes our upstreamed debugging and profiling features,  
and as debian is planning to default to 7 due to wider architecture  
support, it seems good to support auto-detecting that version.  
  
Author: Christoph Berg  
Discussion: https://postgr.es/m/20180912124517.GD24584@msg.df7cb.de  
Backpatch: 11, where LLVM was introduced  

M config/llvm.m4
M configure

Attach FPI to the first record after full_page_writes is turned on.

commit   : ff4220ead2c833fb36e9709ab2568c6ac43e9d3b    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Thu, 13 Sep 2018 15:38:15 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Thu, 13 Sep 2018 15:38:15 +0530    

Click here for diff

XLogInsert fails to attach a required FPI to the first record after  
full_page_writes is turned on by the last checkpoint.  This bug got  
introduced in 9.5 due to code rearrangement in commits 2c03216d83 and  
2076db2aea.  Fix it by ensuring that XLogInsertRecord performs a  
recomputation when the given record is generated with FPW as off but  
found that the flag has been turned on while actually inserting the  
record.  
  
Reported-by: Kyotaro Horiguchi  
Author: Kyotaro Horiguchi  
Reviewed-by: Amit Kapila  
Backpatch-through: 9.5 where this problem was introduced  
Discussion: https://postgr.es/m/20180420.151043.74298611.horiguchi.kyotaro@lab.ntt.co.jp  

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

Minor fixes for psql tab completion.

commit   : 12368f5e83e70e015a7352f52115579c135e82e5    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 12 Sep 2018 15:24:56 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 12 Sep 2018 15:24:56 -0400    

Click here for diff

* Include partitioned tables in what's offered after ANALYZE.  
  
* Include toast_tuple_target in what's offered after ALTER TABLE ... SET|RESET.  
  
* Include HASH in what's offered after PARTITION BY.  
  
This is extracted from a larger patch; these bits seem like  
uncontroversial bug fixes for v11 features, so back-patch them into v11.  
  
Justin Pryzby  
  
Discussion: https://postgr.es/m/20180529000623.GA21896@telsasoft.com  

M src/bin/psql/tab-complete.c

Repair bug in regexp split performance improvements.

commit   : f7d0343ead29cd3e44eccd1c8b7cc291b79209fe    
  
author   : Andrew Gierth <rhodiumtoad@postgresql.org>    
date     : Wed, 12 Sep 2018 19:31:06 +0100    
  
committer: Andrew Gierth <rhodiumtoad@postgresql.org>    
date     : Wed, 12 Sep 2018 19:31:06 +0100    

Click here for diff

Commit c8ea87e4b introduced a temporary conversion buffer for  
substrings extracted during regexp splits. Unfortunately the code that  
sized it was failing to ignore the effects of ignored degenerate  
regexp matches, so for regexp_split_* calls it could under-size the  
buffer in such cases.  
  
Fix, and add some regression test cases (though those will only catch  
the bug if run in a multibyte encoding).  
  
Backpatch to 9.3 as the faulty code was.  
  
Thanks to the PostGIS project, Regina Obe and Paul Ramsey for the  
report (via IRC) and assistance in analysis. Patch by me.  

M src/backend/utils/adt/regexp.c
M src/test/regress/expected/strings.out
M src/test/regress/sql/strings.sql

ecpg: Change --version output to common style

commit   : b91ae36029df3db31a951ebda102ace8be5741ba    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 12 Sep 2018 14:33:15 +0200    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 12 Sep 2018 14:33:15 +0200    

Click here for diff

When we removed the ecpg-specific versions, we also removed the  
"(PostgreSQL)" from the --version output, which we show in other  
programs.  
  
Reported-by: Ioseph Kim <pgsql-kr@postgresql.kr>  

M src/interfaces/ecpg/preproc/ecpg.c

doc: adjust PG 11 release notes

commit   : 293010a68afd5b3a1f1e7621d5c89ba422c21d09    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 11 Sep 2018 17:01:51 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 11 Sep 2018 17:01:51 -0400    

Click here for diff

Fixes for channel binding, SQL procedures, and pg_trgm.  
  
Backpatch-through: 11  

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

Remove ruleutils.c's special case for BIT [VARYING] literals.

commit   : 224256f890c71b809c1a6b62b426fc8ceec7b0da    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 11 Sep 2018 16:32:12 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 11 Sep 2018 16:32:12 -0400    

Click here for diff

Up to now, get_const_expr() insisted on prefixing BIT and VARBIT  
literals with 'B'.  That's not really necessary, because we always  
append explicit-cast syntax to identify the constant's type.  
Moreover, it's subtly wrong for VARBIT, because the parser will  
interpret B'...' as '...'::"bit"; see make_const() which explicitly  
assigns type BITOID for a T_BitString literal.  So what had been  
a simple VARBIT literal is reconstructed as ('...'::"bit")::varbit,  
which is not the same thing, at least not before constant folding.  
This results in odd differences after dump/restore, as complained  
of by the patch submitter, and it could result in actual failures in  
partitioning or inheritance DDL operations (see commit 542320c2b,  
which repaired similar misbehaviors for some other data types).  
  
Fixing it is pretty easy: just remove the special case and let the  
default code path handle these types.  We could have kept the special  
case for BIT only, but there seems little point in that.  
  
Like the previous patch, I judge that back-patching this into stable  
branches wouldn't be a good idea.  However, it seems not quite too  
late for v11, so let's fix it there.  
  
Paul Guo, reviewed by Davy Machado and John Naylor, minor adjustments  
by me  
  
Discussion: https://postgr.es/m/CABQrizdTra=2JEqA6+Ms1D1k1Kqw+aiBBhC9TreuZRX2JzxLAA@mail.gmail.com  

M contrib/btree_gist/expected/bit.out
M contrib/btree_gist/expected/varbit.out
M src/backend/utils/adt/ruleutils.c
M src/test/regress/expected/bit.out
M src/test/regress/expected/sanity_check.out
M src/test/regress/sql/bit.sql

Repair double-free in SP-GIST rescan (bug #15378)

commit   : e331d6712f0224160d2699591704ddcc3ef2d67b    
  
author   : Andrew Gierth <rhodiumtoad@postgresql.org>    
date     : Tue, 11 Sep 2018 18:14:19 +0100    
  
committer: Andrew Gierth <rhodiumtoad@postgresql.org>    
date     : Tue, 11 Sep 2018 18:14:19 +0100    

Click here for diff

spgrescan would first reset traversalCxt, and then traverse a  
potentially non-empty stack containing pointers to traversalValues  
which had been allocated in those contexts, freeing them a second  
time. This bug originates in commit ccd6eb49a where traversalValue was  
introduced.  
  
Repair by traversing the stack before the context reset; this isn't  
ideal, since it means doing retail pfree in a context that's about to  
be reset, but the freeing of a stack entry is also done in other  
places in the code during the scan so it's not worth trying to  
refactor it further. Regression test added.  
  
Backpatch to 9.6 where the problem was introduced.  
  
Per bug #15378; analysis and patch by me, originally from a report on  
IRC by user velix; see also PostGIS ticket #4174; review by Alexander  
Korotkov.  
  
Discussion: https://postgr.es/m/153663176628.23136.11901365223750051490@wrigleys.postgresql.org  

M src/backend/access/spgist/spgscan.c
M src/test/regress/expected/spgist.out
M src/test/regress/sql/spgist.sql

Use -Bsymbolic for shared libraries on HP-UX and Solaris.

commit   : e3aafe200125975022653eb3197bcf03f7744391    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Sep 2018 22:22:12 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Sep 2018 22:22:12 -0400    

Click here for diff

These platforms are also subject to the mis-linking problem addressed  
in commit e3d77ea6b.  It's not clear whether we could solve it with  
a solution equivalent to GNU ld's version scripts, but -Bsymbolic  
appears to fix it, so let's use that.  
  
Like the previous commit, back-patch as far as v10.  
  
Discussion: https://postgr.es/m/153626613985.23143.4743626885618266803@wrigleys.postgresql.org  

M src/Makefile.shlib

Prevent mis-linking of src/port and src/common functions on *BSD.

commit   : 6395ac14d99e4a5d9ee1b83dcc382a368e50240c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 9 Sep 2018 15:16:51 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 9 Sep 2018 15:16:51 -0400    

Click here for diff

On ELF-based platforms (and maybe others?) it's possible for a shared  
library, when dynamically loaded into the backend, to call the backend  
versions of src/port and src/common functions rather than the frontend  
versions that are actually linked into the shlib.  This is the cause  
of bug #15367 from Jeremy Evans, and is likely to lead to more problems  
in future; it's accidental that we've failed to notice any bad effects  
up to now.  
  
The recommended way to fix this on ELF-based platforms is to use a  
linker "version script" that makes the shlib's versions of the functions  
local.  (Apparently, -Bsymbolic would fix it as well, but with other  
side effects that we don't want.)  Doing so has the additional benefit  
that we can make sure the shlib only exposes the symbols that are meant  
to be part of its API, and not ones that are just for cross-file  
references within the shlib.  So we'd already been using a version  
script for libpq on popular platforms, but it's now apparent that it's  
necessary for correctness on every ELF-based platform.  
  
Hence, add appropriate logic to the openbsd, freebsd, and netbsd stanzas  
of Makefile.shlib; this is just a copy-and-paste from the linux stanza.  
There may be additional work to do if commit ed0cdf0e0 reveals that the  
problem exists elsewhere, but this is all that is known to be needed  
right now.  
  
Back-patch to v10 where SCRAM support came in.  The problem is ancient,  
but analysis suggests that there were no really severe consequences  
in older branches.  Hence, I won't take the risk of such a large change  
in the build process for older branches.  
  
In passing, remove a rather opaque comment about -Bsymbolic; I don't  
think it's very on-point about why we don't use that, if indeed that's  
what it's talking about at all.  
  
Patch by me; thanks to Andrew Gierth for helping to diagnose the problem,  
and for additional testing.  
  
Discussion: https://postgr.es/m/153626613985.23143.4743626885618266803@wrigleys.postgresql.org  

M src/Makefile.shlib

Fix past pd_upper write in ginRedoRecompress()

commit   : cc909ddbfb480928a781c21b1c142ccf1adb2fe5    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Sun, 9 Sep 2018 21:19:29 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Sun, 9 Sep 2018 21:19:29 +0300    

Click here for diff

ginRedoRecompress() replays actions over compressed segments of posting list  
in-place.  However, it might lead to write past pg_upper, because intermediate  
state during playing the changes can take more space than both original state  
and final state.  This commit fixes that by refuse from in-place modification.  
Instead page tail is copied once modification is started, and then it's used  
as the source of original segments.  Backpatch to 9.4 where posting list  
compression was introduced.  
  
Reported-by: Sivasubramanian Ramasubramanian  
Discussion: https://postgr.es/m/1536091151804.6588%40amazon.com  
Author: Alexander Korotkov based on patch from and ideas by Sivasubramanian Ramasubramanian  
Review: Sivasubramanian Ramasubramanian  
Backpatch-through: 9.4  

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

Allow ENOENT in check_mode_recursive().

commit   : f7d745318b180634e8bb1734867caaf71b00b305    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sat, 8 Sep 2018 18:26:10 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sat, 8 Sep 2018 18:26:10 -0700    

Click here for diff

Buildfarm member tern failed src/bin/pg_ctl/t/001_start_stop.pl when a  
check_mode_recursive() call overlapped a server's startup-time deletion  
of pg_stat/global.stat.  Just warn.  Also, include errno in the message.  
Back-patch to v11, where check_mode_recursive() first appeared.  

M src/test/perl/TestLib.pm

Fix logical subscriber wait in test.

commit   : 475c1fb5a765da70a77f9f24454977a873d96dc4    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sat, 8 Sep 2018 16:20:50 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sat, 8 Sep 2018 16:20:50 -0700    

Click here for diff

Buildfarm members sungazer and tern revealed this deficit.  Back-patch  
to v10, like commit 4f10e7ea7b2231f453bb18b6e710ac333eaf121b, which  
introduced the test.  

M src/test/subscription/t/002_types.pl

Minor cleanup/future-proofing for pg_saslprep().

commit   : 86d226ae5a3607b8bbde2487f821b8f8807da1c8    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 8 Sep 2018 18:20:36 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 8 Sep 2018 18:20:36 -0400    

Click here for diff

Ensure that pg_saslprep() initializes its output argument to NULL in  
all failure paths, and then remove the redundant initialization that  
some (not all) of its callers did.  This does not fix any live bug,  
but it reduces the odds of future bugs of omission.  
  
Also add a comment about why the existing failure-path coding is  
adequate.  
  
Back-patch so as to keep the function's API consistent across branches,  
again to forestall future bug introduction.  
  
Patch by me, reviewed by Michael Paquier  
  
Discussion: https://postgr.es/m/16558.1536407783@sss.pgh.pa.us  

M src/backend/libpq/auth-scram.c
M src/common/saslprep.c
M src/interfaces/libpq/fe-auth-scram.c

Save/restore SPI's global variables in SPI_connect() and SPI_finish().

commit   : 825f10fbda7a5d8a48d187b8193160e5e44e4011    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 7 Sep 2018 20:09:57 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 7 Sep 2018 20:09:57 -0400    

Click here for diff

This patch removes two sources of interference between nominally  
independent functions when one SPI-using function calls another,  
perhaps without knowing that it does so.  
  
Chapman Flack pointed out that xml.c's query_to_xml_internal() expects  
SPI_tuptable and SPI_processed to stay valid across datatype output  
function calls; but it's possible that such a call could involve  
re-entrant use of SPI.  It seems likely that there are similar hazards  
elsewhere, if not in the core code then in third-party SPI users.  
Previously SPI_finish() reset SPI's API globals to zeroes/nulls, which  
would typically make for a crash in such a situation.  Restoring them  
to the values they had at SPI_connect() seems like a considerably more  
useful behavior, and it still meets the design goal of not leaving any  
dangling pointers to tuple tables of the function being exited.  
  
Also, cause SPI_connect() to reset these variables to zeroes/nulls after  
saving them.  This prevents interference in the opposite direction: it's  
possible that a SPI-using function that's only ever been tested standalone  
contains assumptions that these variables start out as zeroes.  That was  
the case as long as you were the outermost SPI user, but not so much for  
an inner user.  Now it's consistent.  
  
Report and fix suggestion by Chapman Flack, actual patch by me.  
Back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/9fa25bef-2e4f-1c32-22a4-3ad0723c4a17@anastigmatix.net  

M src/backend/executor/spi.c
M src/include/executor/spi_priv.h

Limit depth of forced recursion for CLOBBER_CACHE_RECURSIVELY.

commit   : 90fd3bfd17070d3c2467a45204ede17b70a15387    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 7 Sep 2018 18:13:29 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 7 Sep 2018 18:13:29 -0400    

Click here for diff

It's somewhat surprising that we got away with this before.  (Actually,  
since nobody tests this routinely AFAIK, it might've been broken for  
awhile.  But it's definitely broken in the wake of commit f868a8143.)  
It seems sufficient to limit the forced recursion to a small number  
of levels.  
  
Back-patch to all supported branches, like the preceding patch.  
  
Discussion: https://postgr.es/m/12259.1532117714@sss.pgh.pa.us  

M src/backend/utils/cache/inval.c

Fix longstanding recursion hazard in sinval message processing.

commit   : 2569ca0dc8a28f0aa475c32ff122c439700f020a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 7 Sep 2018 18:04:38 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 7 Sep 2018 18:04:38 -0400    

Click here for diff

LockRelationOid and sibling routines supposed that, if our session already  
holds the lock they were asked to acquire, they could skip calling  
AcceptInvalidationMessages on the grounds that we must have already read  
any remote sinval messages issued against the relation being locked.  
This is normally true, but there's a critical special case where it's not:  
processing inside AcceptInvalidationMessages might attempt to access system  
relations, resulting in a recursive call to acquire a relation lock.  
  
Hence, if the outer call had acquired that same system catalog lock, we'd  
fall through, despite the possibility that there's an as-yet-unread sinval  
message for that system catalog.  This could, for example, result in  
failure to access a system catalog or index that had just been processed  
by VACUUM FULL.  This is the explanation for buildfarm failures we've been  
seeing intermittently for the past three months.  The bug is far older  
than that, but commits a54e1f158 et al added a new recursion case within  
AcceptInvalidationMessages that is apparently easier to hit than any  
previous case.  
  
To fix this, we must not skip calling AcceptInvalidationMessages until  
we have *finished* a call to it since acquiring a relation lock, not  
merely acquired the lock.  (There's already adequate logic inside  
AcceptInvalidationMessages to deal with being called recursively.)  
Fortunately, we can implement that at trivial cost, by adding a flag  
to LOCALLOCK hashtable entries that tracks whether we know we have  
completed such a call.  
  
There is an API hazard added by this patch for external callers of  
LockAcquire: if anything is testing for LOCKACQUIRE_ALREADY_HELD,  
it might be fooled by the new return code LOCKACQUIRE_ALREADY_CLEAR  
into thinking the lock wasn't already held.  This should be a fail-soft  
condition, though, unless something very bizarre is being done in  
response to the test.  
  
Also, I added an additional output argument to LockAcquireExtended,  
assuming that that probably isn't called by any outside code given  
the very limited usefulness of its additional functionality.  
  
Back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/12259.1532117714@sss.pgh.pa.us  

M src/backend/storage/ipc/standby.c
M src/backend/storage/lmgr/lmgr.c
M src/backend/storage/lmgr/lock.c
M src/include/storage/lock.h

Refactor installation of extension headers.

commit   : 094ffd68460a8ba905df7b4eae4e9c690dc6e06f    
  
author   : Andrew Gierth <rhodiumtoad@postgresql.org>    
date     : Fri, 7 Sep 2018 13:51:30 +0100    
  
committer: Andrew Gierth <rhodiumtoad@postgresql.org>    
date     : Fri, 7 Sep 2018 13:51:30 +0100    

Click here for diff

Commit be54b3777 failed on gmake 3.80 due to a chained conditional,  
which on closer examination could be removed entirely with some  
refactoring elsewhere for a net simplification and more robustness  
against empty expansions. Along the way, add some more comments.  
  
Also make explicit in the documentation and comments that built  
headers are not removed by 'make clean', since we don't typically want  
that for headers generated by a separate ./configure step, and it's  
much easier to add your own 'distclean' rule or use EXTRA_CLEAN than  
to try and override a deletion rule in pgxs.mk.  
  
Per buildfarm member prariedog and comments by Michael Paquier, though  
all the actual changes are my fault.  

M doc/src/sgml/extend.sgml
M src/makefiles/pgxs.mk

Make contrib/unaccent's unaccent() function work when not in search path.

commit   : 23aad181f44741c2061ce5caceb307774ac14fb8    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 6 Sep 2018 10:49:45 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 6 Sep 2018 10:49:45 -0400    

Click here for diff

Since the fixes for CVE-2018-1058, we've advised people to schema-qualify  
function references in order to fix failures in code that executes under  
a minimal search_path setting.  However, that's insufficient to make the  
single-argument form of unaccent() work, because it looks up the "unaccent"  
text search dictionary using the search path.  
  
The most expedient answer seems to be to remove the search_path dependency  
by making it look in the same schema that the unaccent() function itself  
is declared in.  This will definitely work for the normal usage of this  
function with the unaccent dictionary provided by the extension.  
It's barely possible that there are people who were relying on the  
search-path-dependent behavior to select other dictionaries with the same  
name; but if there are any such people at all, they can still get that  
behavior by writing unaccent('unaccent', ...), or possibly  
unaccent('unaccent'::text::regdictionary, ...) if the lookup has to be  
postponed to runtime.  
  
Per complaint from Gunnlaugur Thor Briem.  Back-patch to all supported  
branches.  
  
Discussion: https://postgr.es/m/CAPs+M8LCex6d=DeneofdsoJVijaG59m9V0ggbb3pOH7hZO4+cQ@mail.gmail.com  

M contrib/unaccent/unaccent.c
M doc/src/sgml/unaccent.sgml

Fix the overrun in hash index metapage for smaller block sizes.

commit   : 834bce0a5293424d127ab72440b9eacc8841051f    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Thu, 6 Sep 2018 10:07:18 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Thu, 6 Sep 2018 10:07:18 +0530    

Click here for diff

The commit 620b49a1 changed the value of HASH_MAX_BITMAPS with the intent  
to allow many non-unique values in hash indexes without worrying to reach  
the limit of the number of overflow pages.  At that time, this didn't  
occur to us that it can overrun the block for smaller block sizes.  
  
Choose the value of HASH_MAX_BITMAPS based on BLCKSZ such that it gives  
the same answer as now for the cases where the overrun doesn't occur, and  
some other sufficiently-value for the cases where an overrun currently  
does occur.  This allows us not to change the behavior in any case that  
currently works, so there's really no reason for a HASH_VERSION bump.  
  
Author: Dilip Kumar  
Reviewed-by: Amit Kapila  
Backpatch-through: 10  
Discussion: https://postgr.es/m/CAA4eK1LtF4VmU4mx_+i72ff1MdNZ8XaJMGkt2HV8+uSWcn8t4A@mail.gmail.com  

M src/include/access/hash.h

Allow extensions to install built as well as unbuilt headers.

commit   : 235526a20a2efb199c4138c5d793260ce37d7231    
  
author   : Andrew Gierth <rhodiumtoad@postgresql.org>    
date     : Wed, 5 Sep 2018 22:01:21 +0100    
  
committer: Andrew Gierth <rhodiumtoad@postgresql.org>    
date     : Wed, 5 Sep 2018 22:01:21 +0100    

Click here for diff

Commit df163230b overlooked the case that an out-of-tree extension  
might need to build its header files (e.g. via ./configure). If it is  
also doing a VPATH build, the HEADERS_* rules in the original commit  
would then fail to find the files, since they would be looking only  
under $(srcdir) and not in the build directory.  
  
Fix by adding HEADERS_built and HEADERS_built_$(MODULE) which behave  
like DATA_built in that they look in the build dir rather than the  
source dir (and also make the files dependencies of the "all" target).  
  
No Windows support appears to be needed for this, since it is only  
relevant to out-of-tree builds (no support exists in Mkvcbuild.pm to  
build extension header files in any case).  

M doc/src/sgml/extend.sgml
M src/makefiles/pgxs.mk

Remove no-longer-used variable.

commit   : c1ea31147248842743c3ba931f71b5a4a218cb58    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 5 Sep 2018 14:29:58 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 5 Sep 2018 14:29:58 -0400    

Click here for diff

Oversight in 2fbdf1b38.  Per buildfarm.  

M src/backend/commands/tablecmds.c

Make argument names of pg_get_object_address consistent, and fix docs.

commit   : 337bf254ae81a3c8426504f3bee04cd6c5eb8a59    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 5 Sep 2018 13:47:16 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 5 Sep 2018 13:47:16 -0400    

Click here for diff

pg_get_object_address and pg_identify_object_as_address are supposed  
to be inverses, but they disagreed as to the names of the arguments  
representing the textual form of an object address.  Moreover, the  
documented argument names didn't agree with reality at all, either  
for these functions or pg_identify_object.  
  
In HEAD and v11, I think we can get away with renaming the input  
arguments of pg_get_object_address to match the outputs of  
pg_identify_object_as_address.  In theory that might break queries  
using named-argument notation to call pg_get_object_address, but  
it seems really unlikely that anybody is doing that, or that they'd  
have much trouble adjusting if they were.  In older branches, we'll  
just live with the lack of consistency.  
  
Aside from fixing the documentation of these functions to match reality,  
I couldn't resist the temptation to do some copy-editing.  
  
Per complaint from Jean-Pierre Pelletier.  Back-patch to 9.5 where these  
functions were introduced.  (Before v11, this is a documentation change  
only.)  
  
Discussion: https://postgr.es/m/CANGqjDnWH8wsTY_GzDUxbt4i=y-85SJreZin4Hm8uOqv1vzRQA@mail.gmail.com  

M doc/src/sgml/func.sgml
M src/include/catalog/catversion.h
M src/include/catalog/pg_proc.dat

Simplify partitioned table creation vs. relcache

commit   : 52ab02d593e9d83c7bff8b6853aba59242ce967a    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 5 Sep 2018 14:36:13 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 5 Sep 2018 14:36:13 -0300    

Click here for diff

In the original code, we were storing the pg_inherits row for a  
partitioned table too early: enough that we had a hack for relcache to  
avoid falling flat on its face while reading such a partial entry.  If  
we finish the pg_class creation first and *then* store the pg_inherits  
entry, we don't need that hack.  
  
Also recognize that pg_class.relpartbound is not marked NOT NULL and  
therefore it's entirely possible to read null values, so having only  
Assert() protection isn't enough.  Change those to if/elog tests  
instead.  This qualifies as a robustness fix, so backpatch to pg11.  
  
In passing, remove one access that wasn't actually needed, and reword  
one message to be like all the others that check for the same thing.  
  
Reviewed-by: Amit Langote  
Discussion: https://postgr.es/m/20180903213916.hh6wasnrdg6xv2ud@alvherre.pgsql  

M src/backend/commands/tablecmds.c
M src/backend/partitioning/partbounds.c
M src/backend/utils/cache/partcache.c

docs: improve AT TIME ZONE description

commit   : 838fd62cab520a5ae15fdab30d0f962070571bdb    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 4 Sep 2018 22:34:07 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 4 Sep 2018 22:34:07 -0400    

Click here for diff

The previous description was unclear.  Also add a third example, change  
use of time zone acronyms to more verbose descriptions, and add a  
mention that using 'time' with AT TIME ZONE uses the current time zone  
rules.  
  
Backpatch-through: 9.3  

M doc/src/sgml/func.sgml

Fully enforce uniqueness of constraint names.

commit   : fb466d7b5dbe73f318324cada80203522f46401f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 4 Sep 2018 13:45:35 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 4 Sep 2018 13:45:35 -0400    

Click here for diff

It's been true for a long time that we expect names of table and domain  
constraints to be unique among the constraints of that table or domain.  
However, the enforcement of that has been pretty haphazard, and it missed  
some corner cases such as creating a CHECK constraint and then an index  
constraint of the same name (as per recent report from André Hänsel).  
Also, due to the lack of an actual unique index enforcing this, duplicates  
could be created through race conditions.  
  
Moreover, the code that searches pg_constraint has been quite inconsistent  
about how to handle duplicate names if one did occur: some places checked  
and threw errors if there was more than one match, while others just  
processed the first match they came to.  
  
To fix, create a unique index on (conrelid, contypid, conname).  Since  
either conrelid or contypid is zero, this will separately enforce  
uniqueness of constraint names among constraints of any one table and any  
one domain.  (If we ever implement SQL assertions, and put them into this  
catalog, more thought might be needed.  But it'd be at least as reasonable  
to put them into a new catalog; having overloaded this one catalog with  
two kinds of constraints was a mistake already IMO.)  This index can replace  
the existing non-unique index on conrelid, though we need to keep the one  
on contypid for query performance reasons.  
  
Having done that, we can simplify the logic in various places that either  
coped with duplicates or neglected to, as well as potentially improve  
lookup performance when searching for a constraint by name.  
  
Also, as per our usual practice, install a preliminary check so that you  
get something more friendly than a unique-index violation report in the  
case complained of by André.  And teach ChooseIndexName to avoid choosing  
autogenerated names that would draw such a failure.  
  
While it's not possible to make such a change in the back branches,  
it doesn't seem quite too late to put this into v11, so do so.  
  
Discussion: https://postgr.es/m/0c1001d4428f$0942b430$1bc81c90$@webkr.de  

M doc/src/sgml/ref/alter_index.sgml
M doc/src/sgml/ref/alter_table.sgml
M doc/src/sgml/ref/create_table.sgml
M src/backend/catalog/heap.c
M src/backend/catalog/index.c
M src/backend/catalog/pg_constraint.c
M src/backend/commands/indexcmds.c
M src/backend/commands/tablecmds.c
M src/backend/commands/typecmds.c
M src/backend/parser/parse_utilcmd.c
M src/backend/utils/cache/relcache.c
M src/include/catalog/catversion.h
M src/include/catalog/indexing.h
M src/include/catalog/pg_constraint.h
M src/include/commands/defrem.h
M src/test/regress/expected/alter_table.out
M src/test/regress/sql/alter_table.sql

Prohibit pushing subqueries containing window function calculation to workers.

commit   : 2ce253cf57b1c3f8100a31f30647449d0b88fe24    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Tue, 4 Sep 2018 10:26:06 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Tue, 4 Sep 2018 10:26:06 +0530    

Click here for diff

Allowing window function calculation in workers leads to inconsistent  
results because if the input row ordering is not fully deterministic, the  
output of window functions might vary across workers.  The fix is to treat  
them as parallel-restricted.  
  
In the passing, improve the coding pattern in max_parallel_hazard_walker  
so that it has a chain of mutually-exclusive if ... else if ... else if  
... else if ... IsA tests.  
  
Reported-by: Marko Tiikkaja  
Bug: 15324  
Author: Amit Kapila  
Reviewed-by: Tom Lane  
Backpatch-through: 9.6  
Discussion: https://postgr.es/m/CAL9smLAnfPJCDUUG4ckX2iznj53V7VSMsYefzZieN93YxTNOcw@mail.gmail.com  

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

During the split, set checksum on an empty hash index page.

commit   : 16e7bcfac57fc21dd2124b39132c58971e41448a    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Tue, 4 Sep 2018 08:33:33 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Tue, 4 Sep 2018 08:33:33 +0530    

Click here for diff

On a split, we allocate a new splitpoint's worth of bucket pages wherein  
we initialize the last page with zeros which is fine, but we forgot to set  
the checksum for that last page.  
  
We decided to back-patch this fix till 10 because we don't have an easy  
way to test it in prior versions.  Another reason is that the hash-index  
code is changed heavily in 10, so it is not advisable to push the fix  
without testing it in prior versions.  
  
Author: Amit Kapila  
Reviewed-by: Yugo Nagata  
Backpatch-through: 10  
Discussion: https://postgr.es/m/5d03686d-727c-dbf8-0064-bf8b97ffe850@2ndquadrant.com  

M src/backend/access/hash/hashpage.c

Remove pg_constraint.conincluding

commit   : bd47c4a9d4ec55e26e841754ce62c23ca9008e87    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 3 Sep 2018 12:58:42 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 3 Sep 2018 12:58:42 -0300    

Click here for diff

This column was added in commit 8224de4f42cc ("Indexes with INCLUDE  
columns and their support in B-tree") to ease writing the ruleutils.c  
supporting code for that feature, but it turns out to be unnecessary --  
we can do the same thing with just one more syscache lookup.  
  
Even the documentation for the new column being removed in this commit  
is awkward.  
  
Discussion: https://postgr.es/m/20180902165018.33otxftp3olgtu4t@alvherre.pgsql  

M doc/src/sgml/catalogs.sgml
M src/backend/catalog/pg_constraint.c
M src/backend/utils/adt/ruleutils.c
M src/include/catalog/catversion.h
M src/include/catalog/pg_constraint.h
M src/test/regress/expected/index_including.out
M src/test/regress/sql/index_including.sql

Fix memory leak in TRUNCATE decoding

commit   : 081cf78d12f17c97efc6199039bc83f059fffcf6    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Mon, 3 Sep 2018 02:10:24 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Mon, 3 Sep 2018 02:10:24 +0200    

Click here for diff

When decoding a TRUNCATE record, the relids array was being allocated in  
the main ReorderBuffer memory context, but not released with the change  
resulting in a memory leak.  
  
The array was also ignored when serializing/deserializing the change,  
assuming all the information is stored in the change itself.  So when  
spilling the change to disk, we've only we have serialized only the  
pointer to the relids array.  Thanks to never releasing the array,  
the pointer however remained valid even after loading the change back  
to memory, preventing an actual crash.  
  
This fixes both the memory leak and (de)serialization.  The relids array  
is still allocated in the main ReorderBuffer memory context (none of the  
existing ones seems like a good match, and adding an extra context seems  
like an overkill).  The allocation is wrapped in a new ReorderBuffer API  
functions, to keep the details within reorderbuffer.c, just like the  
other ReorderBufferGet methods do.  
  
Author: Tomas Vondra  
Discussion: https://www.postgresql.org/message-id/flat/66175a41-9342-2845-652f-1bd4c3ee50aa%402ndquadrant.com  
Backpatch: 11, where decoding of TRUNCATE was introduced  

M src/backend/replication/logical/decode.c
M src/backend/replication/logical/reorderbuffer.c
M src/include/replication/reorderbuffer.h

Fix initial sync of slot parent directory when restoring status

commit   : 680f89e5613cc859356152ae65597c78f0cea4dd    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sun, 2 Sep 2018 12:40:38 -0700    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sun, 2 Sep 2018 12:40:38 -0700    

Click here for diff

At the beginning of recovery, information from replication slots is  
recovered from disk to memory.  In order to ensure the durability of the  
information, the status file as well as its parent directory are  
synced.  It happens that the sync on the parent directory was done  
directly using the status file path, which is logically incorrect, and  
the current code has been doing a sync on the same object twice in a  
row.  
  
Reported-by: Konstantin Knizhnik  
Diagnosed-by: Konstantin Knizhnik  
Author: Michael Paquier  
Discussion: https://postgr.es/m/9eb1a6d5-b66f-2640-598d-c5ea46b8f68a@postgrespro.ru  
Backpatch-through: 9.4-  

M src/backend/replication/slot.c

Doc: fix oversights in "Client/Server Character Set Conversions" table.

commit   : 3099eec7468f081d638be25475f2c5b43b7d1f88    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 1 Sep 2018 16:02:47 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 1 Sep 2018 16:02:47 -0400    

Click here for diff

This table claimed that JOHAB could be used as a server encoding, which  
was true originally but hasn't been true since 8.3.  It also lacked  
entries for EUC_JIS_2004 and SHIFT_JIS_2004.  
  
JOHAB problem noted by Lars Kanis, the others by me.  
  
Discussion: https://postgr.es/m/c0f514a1-b7a9-b9ea-1c02-c34aead56c06@greiz-reinsdorf.de  

M doc/src/sgml/charset.sgml

Avoid using potentially-under-aligned page buffers.

commit   : f5c93cf92223534df862ab7d8c698f05d5b38485    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 1 Sep 2018 15:27:13 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 1 Sep 2018 15:27:13 -0400    

Click here for diff

There's a project policy against using plain "char buf[BLCKSZ]" local  
or static variables as page buffers; preferred style is to palloc or  
malloc each buffer to ensure it is MAXALIGN'd.  However, that policy's  
been ignored in an increasing number of places.  We've apparently got  
away with it so far, probably because (a) relatively few people use  
platforms on which misalignment causes core dumps and/or (b) the  
variables chance to be sufficiently aligned anyway.  But this is not  
something to rely on.  Moreover, even if we don't get a core dump,  
we might be paying a lot of cycles for misaligned accesses.  
  
To fix, invent new union types PGAlignedBlock and PGAlignedXLogBlock  
that the compiler must allocate with sufficient alignment, and use  
those in place of plain char arrays.  
  
I used these types even for variables where there's no risk of a  
misaligned access, since ensuring proper alignment should make  
kernel data transfers faster.  I also changed some places where  
we had been palloc'ing short-lived buffers, for coding style  
uniformity and to save palloc/pfree overhead.  
  
Since this seems to be a live portability hazard (despite the lack  
of field reports), back-patch to all supported versions.  
  
Patch by me; thanks to Michael Paquier for review.  
  
Discussion: https://postgr.es/m/1535618100.1286.3.camel@credativ.de  

M contrib/bloom/blinsert.c
M contrib/pg_prewarm/pg_prewarm.c
M contrib/pg_standby/pg_standby.c
M src/backend/access/gin/ginentrypage.c
M src/backend/access/gin/ginfast.c
M src/backend/access/hash/hashpage.c
M src/backend/access/heap/heapam.c
M src/backend/access/heap/visibilitymap.c
M src/backend/access/transam/generic_xlog.c
M src/backend/access/transam/xlog.c
M src/backend/access/transam/xloginsert.c
M src/backend/access/transam/xlogreader.c
M src/backend/commands/tablecmds.c
M src/backend/replication/walsender.c
M src/backend/storage/file/buffile.c
M src/backend/storage/freespace/freespace.c
M src/backend/utils/sort/logtape.c
M src/bin/pg_basebackup/walmethods.c
M src/bin/pg_resetwal/pg_resetwal.c
M src/bin/pg_rewind/copy_fetch.c
M src/bin/pg_upgrade/file.c
M src/bin/pg_verify_checksums/pg_verify_checksums.c
M src/bin/pg_waldump/pg_waldump.c
M src/include/c.h

Ignore server-side delays when enforcing wal_sender_timeout.

commit   : ee0ab275408f8fc10eedd7fb8c767cdbad0cb57b    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Fri, 31 Aug 2018 22:59:58 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Fri, 31 Aug 2018 22:59:58 -0700    

Click here for diff

Healthy clients of servers having poor I/O performance, such as  
buildfarm members hamster and tern, saw unexpected timeouts.  That  
disagreed with documentation.  This fix adds one gettimeofday() call  
whenever ProcessRepliesIfAny() finds no client reply messages.  
Back-patch to 9.4; the bug's symptom is rare and mild, and the code all  
moved between 9.3 and 9.4.  
  
Discussion: https://postgr.es/m/20180826034600.GA1105084@rfd.leadboat.com  

M src/backend/replication/walsender.c

Fix 8a934d677 for libc++ and make more include order resistant.

commit   : 1f349aa7d9a6633e87db071390c73a39ac279ba4    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Fri, 31 Aug 2018 16:56:11 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Fri, 31 Aug 2018 16:56:11 -0700    

Click here for diff

The previous definition was used in C++ mode, which causes problems  
when using clang with libc++ (rather than libstdc++), due to bugs  
therein.  So just avoid in C++ mode.  
  
A second problem is that depending on include order and implicit  
includes the previous definition did not guarantee that the current  
hack was effective by the time isinf was used, fix that by forcing  
math.h to be included.  This can cause clang using builds, or gcc  
using ones with JIT enabled, to slow down noticably.  
  
It's likely that we at some point want a better solution for the  
performance problem, but while it's there it should better work.  
  
Reported-By: Steven Winfield  
Bug: #15270  
Discussion: https://postgr.es/m/153116283147.1401.360416241833049560@wrigleys.postgresql.org  
Author: Andres Freund  
Backpatch: 11, like the previous commit.  

M src/include/port.h

Fix psql's \dC command to annotate I/O conversion casts as such.

commit   : ed9c336b0f6bcf08e7b6bbe7080fdb63640a680e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 31 Aug 2018 16:45:33 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 31 Aug 2018 16:45:33 -0400    

Click here for diff

A cast declared WITH INOUT was described as '(binary coercible)',  
which seems pretty inaccurate; let's print '(with inout)' instead.  
Per complaint from Jean-Pierre Pelletier.  
  
This definitely seems like a bug fix, but given that it's been wrong  
since 8.4 and nobody complained before, I'm hesitant to back-patch a  
behavior change into stable branches.  It doesn't seem too late for  
v11 though.  
  
Discussion: https://postgr.es/m/5b887023.1c69fb81.ff96e.6a1d@mx.google.com  

M src/bin/psql/describe.c

Ensure correct minimum consistent point on standbys

commit   : c34f8078aa354a9c352b6db488ca1d5aac39560c    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 31 Aug 2018 11:03:55 -0700    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 31 Aug 2018 11:03:55 -0700    

Click here for diff

Startup process has improved its calculation of incorrect minimum  
consistent point in 8d68ee6, which ensures that all WAL available gets  
replayed when doing crash recovery, and has introduced an incorrect  
calculation of the minimum recovery point for non-startup processes,  
which can cause incorrect page references on a standby when for example  
the background writer flushed a couple of pages on-disk but was not  
updating the control file to let a subsequent crash recovery replay to  
where it should have.  
  
The only case where this has been reported to be a problem is when a  
standby needs to calculate the latest removed xid when replaying a btree  
deletion record, so one would need connections on a standby that happen  
just after recovery has thought it reached a consistent point.  Using a  
background worker which is started after the consistent point is reached  
would be the easiest way to get into problems if it connects to a  
database.  Having clients which attempt to connect periodically could  
also be a problem, but the odds of seeing this problem are much lower.  
  
The fix used is pretty simple, as the idea is to give access to the  
minimum recovery point written in the control file to non-startup  
processes so as they use a reference, while the startup process still  
initializes its own references of the minimum consistent point so as the  
original problem with incorrect page references happening post-promotion  
with a crash do not show up.  
  
Reported-by: Alexander Kukushkin  
Diagnosed-by: Alexander Kukushkin  
Author: Michael Paquier  
Reviewed-by: Kyotaro Horiguchi, Alexander Kukushkin  
Discussion: https://postgr.es/m/153492341830.1368.3936905691758473953@wrigleys.postgresql.org  
Backpatch-through: 9.3  

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

Code review for pg_verify_checksums.c.

commit   : d787af7badfe8c4c9afb7f0af9958a69b723a212    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 31 Aug 2018 13:42:18 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 31 Aug 2018 13:42:18 -0400    

Click here for diff

Use postgres_fe.h, since this is frontend code.  Pretend that we've heard  
of project style guidelines for, eg, #include order.  Use BlockNumber not  
int arithmetic for block numbers, to avoid misbehavior with relations  
exceeding 2^31 blocks.  Avoid an unnecessary strict-aliasing warning  
(per report from Michael Banck).  Const-ify assorted stuff.  Avoid  
scribbling on the output of readdir() -- perhaps that's safe in practice,  
but POSIX forbids it, and this code has so far earned exactly zero  
credibility portability-wise.  Editorialize on an ambiguously-worded  
message.  
  
I did not touch the problem of the "buf" local variable being possibly  
insufficiently aligned; that's not specific to this code, and seems like  
it should be fixed as part of a different, larger patch.  
  
Discussion: https://postgr.es/m/1535618100.1286.3.camel@credativ.de  

M src/bin/pg_verify_checksums/pg_verify_checksums.c

Enforce cube dimension limit in all cube construction functions

commit   : 36343e59b51165da542943d2043878737fbe910b    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Thu, 30 Aug 2018 14:18:53 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Thu, 30 Aug 2018 14:18:53 +0300    

Click here for diff

contrib/cube has a limit to 100 dimensions for cube datatype.  However, it's  
not enforced everywhere, and one can actually construct cube with more than  
100 dimensions having then trouble with dump/restore.  This commit add checks  
for dimensions limit in all functions responsible for cube construction.  
Backpatch to all supported versions.  
  
Reported-by: Andrew Gierth  
Discussion: https://postgr.es/m/87va7uybt4.fsf%40news-spur.riddles.org.uk  
Author: Andrey Borodin with small additions by me  
Review: Tom Lane  
Backpatch-through: 9.3  

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

Split contrib/cube platform-depended checks into separate test

commit   : 1668186eb37851df41c9ff4b9ba9b4f71ce4f348    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Thu, 30 Aug 2018 14:09:25 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Thu, 30 Aug 2018 14:09:25 +0300    

Click here for diff

We're currently maintaining two outputs for cube regression test.  But that  
appears to be unsuitable, because these outputs are different in out few checks  
involving scientific notation.  So, split checks involving scientific notation  
into separate test, making contrib/cube easier to maintain.  Backpatch to all  
supported versions in order to make further backpatching easier.  
  
Discussion: https://postgr.es/m/CAPpHfdvJgWjxHsJTtT%2Bo1tz3OR8EFHcLQjhp-d3%2BUcmJLh-fQA%40mail.gmail.com  
Author: Alexander Korotkov  
Backpatch-through: 9.3  

M contrib/cube/Makefile
M contrib/cube/expected/cube.out
D contrib/cube/expected/cube_2.out
A contrib/cube/expected/cube_sci.out
A contrib/cube/expected/cube_sci_1.out
M contrib/cube/sql/cube.sql
A contrib/cube/sql/cube_sci.sql

Make checksum_impl.h safe to compile with -fstrict-aliasing.

commit   : 9daff2fe69dcfaf29c7901b9e6bad285778a45c0    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 31 Aug 2018 12:26:20 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 31 Aug 2018 12:26:20 -0400    

Click here for diff

In general, Postgres requires -fno-strict-aliasing with compilers that  
implement C99 strict aliasing rules.  There's little hope of getting  
rid of that overall.  But it seems like it would be a good idea if  
storage/checksum_impl.h in particular didn't depend on it, because  
that header is explicitly intended to be included by external programs.  
We don't have a lot of control over the compiler switches that an  
external program might use, as shown by Michael Banck's report of  
failure in a privately-modified version of pg_verify_checksums.  
  
Hence, switch to using a union in place of willy-nilly pointer casting  
inside this file.  I think this makes the code a bit more readable  
anyway.  
  
checksum_impl.h hasn't changed since it was introduced in 9.3,  
so back-patch all the way.  
  
Discussion: https://postgr.es/m/1535618100.1286.3.camel@credativ.de  

M src/include/storage/checksum_impl.h

Disable support for partitionwise joins in problematic cases.

commit   : 940487956ede2a6d0fb98b0b92cbf1f4656baaf0    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Fri, 31 Aug 2018 20:47:17 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Fri, 31 Aug 2018 20:47:17 +0900    

Click here for diff

Commit f49842d, which added support for partitionwise joins, built the  
child's tlist by applying adjust_appendrel_attrs() to the parent's.  So in  
the case where the parent's included a whole-row Var for the parent, the  
child's contained a ConvertRowtypeExpr.  To cope with that, that commit  
added code to the planner, such as setrefs.c, but some code paths still  
assumed that the tlist for a scan (or join) rel would only include Vars  
and PlaceHolderVars, which was true before that commit, causing errors:  
  
* When creating an explicit sort node for an input path for a mergejoin  
  path for a child join, prepare_sort_from_pathkeys() threw the 'could not  
  find pathkey item to sort' error.  
* When deparsing a relation participating in a pushed down child join as a  
  subquery in contrib/postgres_fdw, get_relation_column_alias_ids() threw  
  the 'unexpected expression in subquery output' error.  
* When performing set_plan_references() on a local join plan generated by  
  contrib/postgres_fdw for EvalPlanQual support for a pushed down child  
  join, fix_join_expr() threw the 'variable not found in subplan target  
  lists' error.  
  
To fix these, two approaches have been proposed: one by Ashutosh Bapat and  
one by me.  While the former keeps building the child's tlist with a  
ConvertRowtypeExpr, the latter builds it with a whole-row Var for the  
child not to violate the planner assumption, and tries to fix it up later,  
But both approaches need more work, so refuse to generate partitionwise  
join paths when whole-row Vars are involved, instead.  We don't need to  
handle ConvertRowtypeExprs in the child's tlists for now, so this commit  
also removes the changes to the planner.  
  
Previously, partitionwise join computed attr_needed data for each child  
separately, and built the child join's tlist using that data, which also  
required an extra step for adding PlaceHolderVars to that tlist, but it  
would be more efficient to build it from the parent join's tlist through  
the adjust_appendrel_attrs() transformation.  So this commit builds that  
list that way, and simplifies build_joinrel_tlist() and placeholder.c as  
well as part of set_append_rel_size() to basically what they were before  
partitionwise join went in.  
  
Back-patch to PG11 where partitionwise join was introduced.  
  
Report by Rajkumar Raghuwanshi.  Analysis by Ashutosh Bapat, who also  
provided some of regression tests.  Patch by me, reviewed by Robert Haas.  
  
Discussion: https://postgr.es/m/CAKcux6ktu-8tefLWtQuuZBYFaZA83vUzuRd7c1YHC-yEWyYFpg@mail.gmail.com  

M contrib/postgres_fdw/expected/postgres_fdw.out
M contrib/postgres_fdw/sql/postgres_fdw.sql
M src/backend/nodes/outfuncs.c
M src/backend/optimizer/path/allpaths.c
M src/backend/optimizer/path/joinrels.c
M src/backend/optimizer/plan/setrefs.c
M src/backend/optimizer/util/placeholder.c
M src/backend/optimizer/util/relnode.c
M src/include/nodes/relation.h
M src/test/regress/expected/partition_aggregate.out
M src/test/regress/expected/partition_join.out
M src/test/regress/sql/partition_aggregate.sql
M src/test/regress/sql/partition_join.sql

Fix pg_verify_checksums on Windows.

commit   : 762a16572bb5d9be6c9c53c9ecd29288da213d02    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Fri, 31 Aug 2018 15:45:09 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Fri, 31 Aug 2018 15:45:09 +0530    

Click here for diff

To verify the checksums, we open the file in text mode which doesn't work  
on Windows as WIN32 treats Control-Z as EOF in files opened in text mode.  
This leads to "short read of block .." error in some cases.  
  
Fix it by opening the files in the binary mode.  
  
Author: Amit Kapila  
Reviewed-by: Magnus Hagander  
Backpatch-through: 11  
Discussion: https://postgr.es/m/CAA4eK1+LOnzod+h85FGmyjWzXKy-XV1FYwEyP-Tky2WpD5cxwA@mail.gmail.com  

M src/bin/pg_verify_checksums/pg_verify_checksums.c

Remove extra word from src/backend/optimizer/README

commit   : 40e981391395ae93aadfaf08cd343af65cc6252b    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Fri, 31 Aug 2018 16:42:30 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Fri, 31 Aug 2018 16:42:30 +0900    

Click here for diff

M src/backend/optimizer/README

pg_verify_checksums: rename -d to --verbose

commit   : a840a8ac7b8ab5f8cb86627779d7b1250cdaca8d    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 30 Aug 2018 06:31:05 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 30 Aug 2018 06:31:05 -0300    

Click here for diff

Using -d is odd, because we normally reserve that for a database  
argument, so rename it to -v and add long version --verbose.  
  
Also, reduce it to emit one line per file checked rather than one line  
per block.  
  
Per a complaint from Michael Banck.  
  
Author: Yugo Nagata <nagata@sraoss.co.jp>  
Reviewed-by: Michael Banck <michael.banck@credativ.de>  
Discussion: https://postgr.es/m/20180827113411.GA22768@nighthawk.caipicrew.dd-dns.de  

M doc/src/sgml/ref/pg_verify_checksums.sgml
M src/bin/pg_verify_checksums/pg_verify_checksums.c

Mention change of width of values generated by SERIAL sequences

commit   : c731ec455a234bb0b6fd736898d9dddf3e8d517f    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 30 Aug 2018 05:39:56 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 30 Aug 2018 05:39:56 -0300    

Click here for diff

This changed during pg10 development, but had not been documented.  
  
Co-authored-by: Jonathan S. Katz <jkatz@postgresql.org>  
Discussion: https://postgr.es/m/20180828163408.vl44nwetdybwffyk@alvherre.pgsql  

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

Fix IndexInfo comments.

commit   : c1c1bfc500a09eacf90f7d006e645714f0383f98    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 30 Aug 2018 09:08:33 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 30 Aug 2018 09:08:33 +0300    

Click here for diff

Recently, ii_KeyAttrNumbers was renamed to ii_IndexAttrNumbers, and ii_Am  
field was added, but the comments were not updated.  
  
Author: Yugo Nagata  
Discussion: https://www.postgresql.org/message-id/20180830134831.e35a91b8b978b248c16c8f7b@sraoss.co.jp  

M src/include/nodes/execnodes.h

Stop bgworkers during fast shutdown with postmaster in startup phase

commit   : 35622f7d3210f251c507e77730a3f18246629a95    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 29 Aug 2018 17:10:13 -0700    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 29 Aug 2018 17:10:13 -0700    

Click here for diff

When a postmaster gets into its phase PM_STARTUP, it would start  
background workers using BgWorkerStart_PostmasterStart mode immediately,  
which would cause problems for a fast shutdown as the postmaster forgets  
to send SIGTERM to already-started background workers.  With smart and  
immediate shutdowns, this correctly happened, and fast shutdown is the  
only mode missing the shot.  
  
Author: Alexander Kukushkin  
Reviewed-by: Michael Paquier  
Discussion: https://postgr.es/m/CAFh8B=mvnD8+DZUfzpi50DoaDfZRDfd7S=gwj5vU9GYn8UvHkA@mail.gmail.com  
Backpatch-through: 9.5  

M src/backend/postmaster/postmaster.c

Make pg_restore's identify_locking_dependencies() more bulletproof.

commit   : 49841edcc6440ccfe8cab2a2f478edadc9a0b266    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 28 Aug 2018 19:46:59 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 28 Aug 2018 19:46:59 -0400    

Click here for diff

This function had a blacklist of dump object types that it believed  
needed exclusive lock ... but we hadn't maintained that, so that it  
was missing ROW SECURITY, POLICY, and INDEX ATTACH items, all of  
which need (or should be treated as needing) exclusive lock.  
  
Since the same oversight seems likely in future, let's reverse the  
sense of the test so that the code has a whitelist of safe object  
types; better to wrongly assume a command can't be run in parallel  
than the opposite.  Currently the only POST_DATA object type that's  
safe is CREATE INDEX ... and that list hasn't changed in a long time.  
  
Back-patch to 9.5 where RLS came in.  
  
Discussion: https://postgr.es/m/11450.1535483506@sss.pgh.pa.us  

M src/bin/pg_dump/pg_backup_archiver.c

Code review for pg_dump's handling of ALTER INDEX ATTACH PARTITION.

commit   : 18f6258e5ee8ea8d9c06bd58655cf8c6e4f1016f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 28 Aug 2018 19:33:04 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 28 Aug 2018 19:33:04 -0400    

Click here for diff

Ensure the TOC entry is marked with the correct schema, so that its  
name is as unique as the index's is.  
  
Fix the dependencies: we want dependencies from this TOC entry to the  
two indexes it depends on, and we don't care (at least not for this  
purpose) what order the indexes are created in.  Also, add dependencies  
on the indexes' underlying tables.  Those might seem pointless given  
the index dependencies, but they are helpful to cue parallel restore  
to avoid running the ATTACH PARTITION in parallel with other DDL on  
the same tables.  
  
Discussion: https://postgr.es/m/10817.1535494963@sss.pgh.pa.us  

M src/bin/pg_dump/common.c
M src/bin/pg_dump/pg_dump.c

Include contrib modules in the temp installation even without REGRESS.

commit   : 8ede2691d65e4c0aa1ae23453b5bed63f9a36254    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 28 Aug 2018 17:26:09 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 28 Aug 2018 17:26:09 -0400    

Click here for diff

Now that we have TAP tests, a contrib module may have something useful  
to do in "make check" even if it has no pg_regress-style regression  
scripts, and hence no REGRESS setting.  But the TAP tests will fail,  
or else test the wrong installed files, unless we install the contrib  
module into the temp installation.  So move the bit about adding to  
EXTRA_INSTALL so that it applies regardless.  
  
We might want this in back branches in future, but for the moment  
I only risked adding it to v11.  
  
Discussion: https://postgr.es/m/12438.1535488750@sss.pgh.pa.us  

M src/makefiles/pgxs.mk

postgres_fdw: don't push ORDER BY with no vars (bug #15352)

commit   : 8bc6a301b21cc189f5141c45be93938215e21fb7    
  
author   : Andrew Gierth <rhodiumtoad@postgresql.org>    
date     : Tue, 28 Aug 2018 14:43:51 +0100    
  
committer: Andrew Gierth <rhodiumtoad@postgresql.org>    
date     : Tue, 28 Aug 2018 14:43:51 +0100    

Click here for diff

Commit aa09cd242 changed a condition in find_em_expr_for_rel from  
being a bms_equal comparison of relids to bms_is_subset, in order to  
support order by clauses on foreign joins. But this also allows  
through the degenerate case of expressions with no Vars at all (and  
hence empty relids), including integer constants which will be parsed  
unexpectedly on the remote (viz. "ERROR: ORDER BY position 0 is not in  
select list" as in the bug report).  
  
Repair by adding an additional !bms_is_empty test.  
  
Backpatch through to 9.6 where the aforementioned change was made.  
  
Per bug #15352 from Maksym Boguk; analysis and patch by me.  
  
Discussion: https://postgr.es/m/153518420278.1478.14875560810251994661@wrigleys.postgresql.org  

M contrib/postgres_fdw/postgres_fdw.c

Avoid quadratic slowdown in regexp match/split functions.

commit   : bc552b322fd954f8d87aef850b64e0d9ed376cfa    
  
author   : Andrew Gierth <rhodiumtoad@postgresql.org>    
date     : Tue, 28 Aug 2018 09:52:25 +0100    
  
committer: Andrew Gierth <rhodiumtoad@postgresql.org>    
date     : Tue, 28 Aug 2018 09:52:25 +0100    

Click here for diff

regexp_matches, regexp_split_to_table and regexp_split_to_array all  
work by compiling a list of match positions as character offsets (NOT  
byte positions) in the source string.  
  
Formerly, they then used text_substr to extract the matched text; but  
in a multi-byte encoding, that counts the characters in the string,  
and the characters needed to reach the starting byte position, on  
every call. Accordingly, the performance degraded as the product of  
the input string length and the number of match positions, such that  
splitting a string of a few hundred kbytes could take many minutes.  
  
Repair by keeping the wide-character copy of the input string  
available (only in the case where encoding_max_length is not 1) after  
performing the match operation, and extracting substrings from that  
instead. This reduces the complexity to being linear in the number of  
result bytes, discounting the actual regexp match itself (which is not  
affected by this patch).  
  
In passing, remove cleanup using retail pfree() which was obsoleted by  
commit ff428cded (Feb 2008) which made cleanup of SRF multi-call  
contexts automatic. Also increase (to ~134 million) the maximum number  
of matches and provide an error message when it is reached.  
  
Backpatch all the way because this has been wrong forever.  
  
Analysis and patch by me; review by Kaiting Chen.  
  
Discussion: https://postgr.es/m/87pnyn55qh.fsf@news-spur.riddles.org.uk  
  
see also https://postgr.es/m/87lg996g4r.fsf@news-spur.riddles.org.uk  

M src/backend/utils/adt/regexp.c

pg_verify_checksums: Message style improvements and NLS support

commit   : da793baca29fa83e3fb1eb09d2ef9aa863a02f7a    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 28 Aug 2018 11:49:11 +0200    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 28 Aug 2018 11:49:11 +0200    

Click here for diff

The source code was already set up for NLS support, so just a nls.mk  
file needed to be added.  Also, fix the old problem of putting the int64  
format specifier right into the string, which breaks NLS.  

A src/bin/pg_verify_checksums/nls.mk
M src/bin/pg_verify_checksums/pg_verify_checksums.c

Fix snapshot leak warning for some procedures

commit   : 2657d4ea66c775c3334181722115be2d6128c5cd    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 23 Aug 2018 15:13:48 +0200    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 23 Aug 2018 15:13:48 +0200    

Click here for diff

The problem arises with the combination of CALL with output parameters  
and doing a COMMIT inside the procedure.  When a CALL has output  
parameters, the portal uses the strategy PORTAL_UTIL_SELECT instead of  
PORTAL_MULTI_QUERY.  Using PORTAL_UTIL_SELECT causes the portal's  
snapshot to be registered with the current resource  
owner (portal->holdSnapshot); see  
9ee1cf04ab6bcefe03a11837b53f29ca9dc24c7a for the reason.  
  
Normally, PortalDrop() unregisters the snapshot.  If not, then  
ResourceOwnerRelease() will print a warning about a snapshot leak on  
transaction commit.  A transaction commit normally drops all  
portals (PreCommit_Portals()), except the active portal.  So in case of  
the active portal, we need to manually release the snapshot to avoid the  
warning.  
  
Reported-by: Prabhat Sahu <prabhat.sahu@enterprisedb.com>  
Reviewed-by: Jonathan S. Katz <jkatz@postgresql.org>  

M src/backend/utils/mmgr/portalmem.c
M src/pl/plpgsql/src/expected/plpgsql_transaction.out
M src/pl/plpgsql/src/sql/plpgsql_transaction.sql

Fix missing dependency for pg_dump's ENABLE ROW LEVEL SECURITY items.

commit   : c5e235ff8ad0f4907a736a6440dc4be6f939e65c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 27 Aug 2018 15:11:12 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 27 Aug 2018 15:11:12 -0400    

Click here for diff

The archive should show a dependency on the item's table, but it failed  
to include one.  This could cause failures in parallel restore due to  
emitting ALTER TABLE ... ENABLE ROW LEVEL SECURITY before restoring  
the table's data.  In practice the odds of a problem seem low, since  
you would typically need to have set FORCE ROW LEVEL SECURITY as well,  
and you'd also need a very high --jobs count to have any chance of this  
happening.  That probably explains the lack of field reports.  
  
Still, it's a bug, so back-patch to 9.5 where RLS was introduced.  
  
Discussion: https://postgr.es/m/19784.1535390902@sss.pgh.pa.us  

M src/bin/pg_dump/pg_dump.c

Fix typos.

commit   : 9ca2207990002a2fd594fd7f9776d9d91acba189    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Mon, 27 Aug 2018 09:32:59 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Mon, 27 Aug 2018 09:32:59 +1200    

Click here for diff

Author: David Rowley  
Discussion: https://postgr.es/m/CAKJS1f8du35u5DprpykWvgNEScxapbWYJdHq%2Bz06Wj3Y2KFPbw%40mail.gmail.com  

M src/backend/partitioning/partprune.c
M src/backend/statistics/dependencies.c
M src/backend/utils/adt/geo_spgist.c

Make syslogger more robust against failures in opening CSV log files.

commit   : f8fc5f5f50dbabec866dee79cd739bb3f68052a1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 26 Aug 2018 14:21:55 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 26 Aug 2018 14:21:55 -0400    

Click here for diff

The previous coding figured it'd be good enough to postpone opening  
the first CSV log file until we got a message we needed to write there.  
This is unsafe, though, because if the open fails we end up in infinite  
recursion trying to report the failure.  Instead make the CSV log file  
management code look as nearly as possible like the longstanding logic  
for the stderr log file.  In particular, open it immediately at postmaster  
startup (if enabled), or when we get a SIGHUP in which we find that  
log_destination has been changed to enable CSV logging.  
  
It seems OK to fail if a postmaster-start-time open attempt fails, as  
we've long done for the stderr log file.  But we can't die if we fail  
to open a CSV log file during SIGHUP, so we're still left with a problem.  
In that case, write any output meant for the CSV log file to the stderr  
log file.  (This will also cover race-condition cases in which backends  
send CSV log data before or after we have the CSV log file open.)  
  
This patch also fixes an ancient oversight that, if CSV logging was  
turned off during a SIGHUP, we never actually closed the last CSV  
log file.  
  
In passing, remember to reset whereToSendOutput = DestNone during syslogger  
start, since (unlike all other postmaster children) it's forked before the  
postmaster has done that.  This made for a platform-dependent difference  
in error reporting behavior between the syslogger and other children:  
except on Windows, it'd report problems to the original postmaster stderr  
as well as the normal error log file(s).  It's barely possible that that  
was intentional at some point; but it doesn't seem likely to be desirable  
in production, and the platform dependency definitely isn't desirable.  
  
Per report from Alexander Kukushkin.  It's been like this for a long time,  
so back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/CAFh8B==iLUD_gqC-dAENS0V+kVrCeGiKujtKqSQ7++S-caaChw@mail.gmail.com  

M src/backend/postmaster/syslogger.c

doc: "Latest checkpoint location" will not match in pg_upgrade

commit   : 231cf30e984b1501cbe640f567c08919a195d9d1    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Sat, 25 Aug 2018 13:35:14 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Sat, 25 Aug 2018 13:35:14 -0400    

Click here for diff

Mention that "Latest checkpoint location" will not match in pg_upgrade  
if the standby server is still running during the upgrade, which is  
possible.  "Match" text first appeared in PG 9.5.  
  
Reported-by: Paul Bonaud  
  
Discussion: https://postgr.es/m/c7268794-edb4-1772-3bfd-04c54585c24e@trainline.com  
  
Backpatch-through: 9.5  

M doc/src/sgml/ref/pgupgrade.sgml

commit   : 3c712c580e63a983081758059607ca1ee4bc4b6b    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Sat, 25 Aug 2018 13:01:24 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Sat, 25 Aug 2018 13:01:24 -0400    

Click here for diff

Reported-by: Ashutosh Sharma  
  
Discussion: https://postgr.es/m/CAE9k0PnhnL6MNDLuvkk8USzOa_DpzDzFQPAM_uaGuXbh9HMKYw@mail.gmail.com  
  
Author: Ashutosh Sharma  
  
Backpatch-through: 9.3  

M doc/src/sgml/information_schema.sgml

docs: Clarify pg_ctl initdb option text to match options proto.

commit   : 04d36cf44bcc14c649037470e72fb990e794e212    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Sat, 25 Aug 2018 12:01:53 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Sat, 25 Aug 2018 12:01:53 -0400    

Click here for diff

The options string appeared in PG 10.  
  
Reported-by: pgsql-kr@postgresql.kr  
  
Discussion: https://postgr.es/m/153500377658.1378.6587007319641704057@wrigleys.postgresql.org  
  
Backpatch-through: 10  

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

docs: clarify plpython SD and GD dictionary behavior

commit   : 2c852e3e53c8e64b84f518ee2ab04509c3f29b95    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Sat, 25 Aug 2018 11:52:29 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Sat, 25 Aug 2018 11:52:29 -0400    

Click here for diff

Reported-by: Adam Bielański  
  
Discussion: https://postgr.es/m/153484305538.1370.7605856225879294548@wrigleys.postgresql.org  
  
Backpatch-through: 9.3  

M doc/src/sgml/plpython.sgml

LLVMJIT: LLVMGetHostCPUFeatures now is upstream, use LLMV version if available.

commit   : 24f127b0042e6bd70e3076cfe0cf13e3bc481037    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Fri, 24 Aug 2018 10:20:55 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Fri, 24 Aug 2018 10:20:55 -0700    

Click here for diff

Noticed thanks to buildfarm animal seawasp.  
  
Author: Andres Freund  
Backpatch: v11-, where LLVM based JIT compliation was introduced.  

M config/llvm.m4
M configure
M src/backend/jit/llvm/llvmjit_wrap.cpp
M src/include/jit/llvmjit.h
M src/include/pg_config.h.in
M src/include/pg_config.h.win32

Suppress uninitialized-variable warning in new SCRAM code.

commit   : 7ed1db3f4625c4cb873a21c380913433820d50ce    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 24 Aug 2018 10:51:10 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 24 Aug 2018 10:51:10 -0400    

Click here for diff

While we generally don't sweat too much about "may be used uninitialized"  
warnings from older compilers, I noticed that there's a fair number of  
buildfarm animals that are producing such a warning *only* for this  
variable.  So it seems worth silencing.  

M src/backend/libpq/auth.c

Fix lexing of standard multi-character operators in edge cases.

commit   : 5b4555f90c08dd0d31572b22f5b2affdc4304b69    
  
author   : Andrew Gierth <rhodiumtoad@postgresql.org>    
date     : Thu, 23 Aug 2018 18:29:18 +0100    
  
committer: Andrew Gierth <rhodiumtoad@postgresql.org>    
date     : Thu, 23 Aug 2018 18:29:18 +0100    

Click here for diff

Commits c6b3c939b (which fixed the precedence of >=, <=, <> operators)  
and 865f14a2d (which added support for the standard => notation for  
named arguments) created a class of lexer tokens which look like  
multi-character operators but which have their own token IDs distinct  
from Op. However, longest-match rules meant that following any of  
these tokens with another operator character, as in (1<>-1), would  
cause them to be incorrectly returned as Op.  
  
The error here isn't immediately obvious, because the parser would  
usually still find the correct operator via the Op token, but there  
were more subtle problems:  
  
1. If immediately followed by a comment or +-, >= <= <> would be given  
   the old precedence of Op rather than the correct new precedence;  
  
2. If followed by a comment, != would be returned as Op rather than as  
   NOT_EQUAL, causing it not to be found at all;  
  
3. If followed by a comment or +-, the => token for named arguments  
   would be lexed as Op, causing the argument to be mis-parsed as a  
   simple expression, usually causing an error.  
  
Fix by explicitly checking for the operators in the {operator} code  
block in addition to all the existing special cases there.  
  
Backpatch to 9.5 where the problem was introduced.  
  
Analysis and patch by me; review by Tom Lane.  
Discussion: https://postgr.es/m/87va851ppl.fsf@news-spur.riddles.org.uk  

M src/backend/parser/scan.l
M src/fe_utils/psqlscan.l
M src/interfaces/ecpg/preproc/pgc.l
M src/test/regress/expected/create_operator.out
M src/test/regress/expected/polymorphism.out
M src/test/regress/sql/create_operator.sql
M src/test/regress/sql/polymorphism.sql

Reduce an unnecessary O(N^3) loop in lexer.

commit   : 0b42bd459af0532c6894d7699747986eaf4e86b5    
  
author   : Andrew Gierth <rhodiumtoad@postgresql.org>    
date     : Thu, 23 Aug 2018 20:01:03 +0100    
  
committer: Andrew Gierth <rhodiumtoad@postgresql.org>    
date     : Thu, 23 Aug 2018 20:01:03 +0100    

Click here for diff

The lexer's handling of operators contained an O(N^3) hazard when  
dealing with long strings of + or - characters; it seems hard to  
prevent this case from being O(N^2), but the additional N multiplier  
was not needed.  
  
Backpatch all the way since this has been there since 7.x, and it  
presents at least a mild hazard in that trying to do Bind, PREPARE or  
EXPLAIN on a hostile query could take excessive time (without  
honouring cancels or timeouts) even if the query was never executed.  

M src/backend/parser/scan.l
M src/fe_utils/psqlscan.l
M src/interfaces/ecpg/preproc/pgc.l

In libpq, don't look up all the hostnames at once.

commit   : c781a066ea4f0de0dc46e953ba55e10943199d6d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 23 Aug 2018 16:39:19 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 23 Aug 2018 16:39:19 -0400    

Click here for diff

Historically, we looked up the target hostname in connectDBStart, so that  
PQconnectPoll did not need to do DNS name resolution.  The patches that  
added multiple-target-host support to libpq preserved this division of  
labor; but it's really nonsensical now, because it means that if any one  
of the target hosts fails to resolve in DNS, the connection fails.  That  
negates the no-single-point-of-failure goal of the feature.  Additionally,  
DNS lookups aren't exactly cheap, but the code did them all even if the  
first connection attempt succeeds.  
  
Hence, rearrange so that PQconnectPoll does the lookups, and only looks  
up a hostname when it's time to try that host.  This does mean that  
PQconnectPoll could block on a DNS lookup --- but if you wanted to avoid  
that, you should be using hostaddr, as the documentation has always  
specified.  It seems fairly unlikely that any applications would really  
care whether the lookup occurs inside PQconnectStart or PQconnectPoll.  
  
In addition to calling out that fact explicitly, do some other minor  
wordsmithing in the docs around the multiple-target-host feature.  
  
Since this seems like a bug in the multiple-target-host feature,  
backpatch to v10 where that was introduced.  In the back branches,  
avoid moving any existing fields of struct pg_conn, just in case  
any third-party code is looking into that struct.  
  
Tom Lane, reviewed by Fabien Coelho  
  
Discussion: https://postgr.es/m/4913.1533827102@sss.pgh.pa.us  

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

Copy-editing of pg_verify_checksums help and ref page

commit   : 9126b4ee1c59ef07c55227b55c45a8d4bc6590d9    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 23 Aug 2018 20:32:56 +0200    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 23 Aug 2018 20:32:56 +0200    

Click here for diff

Reformat synopsis, put options into better order, make the desciption  
line a bit shorter, and put more details into the description.  

M doc/src/sgml/ref/pg_verify_checksums.sgml
M src/bin/pg_verify_checksums/pg_verify_checksums.c

PL/pgSQL: Extend test case

commit   : ca02434a0b86e7dbc5b790f1a4d6b782ca8f4916    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 23 Aug 2018 17:20:47 +0200    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 23 Aug 2018 17:20:47 +0200    

Click here for diff

This test was supposed to check the interaction of INOUT and default  
parameters in a procedure call, but it only checked the case where the  
parameter was not supplied.  Now it also checks the case where the  
parameter was supplied.  It was already working correctly, so no code  
changes required.  

M src/pl/plpgsql/src/expected/plpgsql_call.out
M src/pl/plpgsql/src/sql/plpgsql_call.sql

Return type of txid_status is text, not txid_status

commit   : c2b5d177182a96aa0f9926c3bee2598253918700    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 23 Aug 2018 11:40:30 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 23 Aug 2018 11:40:30 -0300    

Click here for diff

Thinko in commit 857ee8e39.  
  
Discovered-by: Gianni Ciolli  

M doc/src/sgml/func.sgml

doc: Clarify some wording in PL/pgSQL about transactions

commit   : 17df2a8b3946895c78f4ca088804341172ef27ae    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 22 Aug 2018 15:42:22 +0200    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 22 Aug 2018 15:42:22 +0200    

Click here for diff

Some text was still claiming that committing transactions was not  
possible in PL/pgSQL.  

M doc/src/sgml/plpgsql.sgml

Change PROCEDURE to FUNCTION in CREATE TRIGGER syntax

commit   : e0dc839e72d43e6c299deca892a8209e11dd88f6    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 15 Aug 2018 23:08:34 +0200    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 15 Aug 2018 23:08:34 +0200    

Click here for diff

Since procedures are now a different thing from functions, change the  
CREATE TRIGGER and CREATE EVENT TRIGGER syntax to use FUNCTION in the  
clause that specifies the function.  PROCEDURE is still accepted for  
compatibility.  
  
pg_dump and ruleutils.c output is not changed yet, because that would  
require a change in information_schema.sql and thus a catversion change.  
  
Reported-by: Peter Geoghegan <pg@bowt.ie>  
Reviewed-by: Jonathan S. Katz <jonathan.katz@excoventures.com>  

M doc/src/sgml/ddl.sgml
M doc/src/sgml/event-trigger.sgml
M doc/src/sgml/func.sgml
M doc/src/sgml/information_schema.sgml
M doc/src/sgml/lo.sgml
M doc/src/sgml/plperl.sgml
M doc/src/sgml/plpgsql.sgml
M doc/src/sgml/pltcl.sgml
M doc/src/sgml/ref/create_event_trigger.sgml
M doc/src/sgml/ref/create_trigger.sgml
M doc/src/sgml/tcn.sgml
M doc/src/sgml/textsearch.sgml
M doc/src/sgml/trigger.sgml
M src/backend/parser/gram.y
M src/test/regress/expected/triggers.out
M src/test/regress/sql/triggers.sql

Change PROCEDURE to FUNCTION in CREATE OPERATOR syntax

commit   : fd4417e8ac46ea4cb079ed53f849dc48199506d6    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 15 Aug 2018 18:05:46 +0200    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 15 Aug 2018 18:05:46 +0200    

Click here for diff

Since procedures are now a different thing from functions, change the  
CREATE OPERATOR syntax to use FUNCTION in the clause that specifies the  
function.  PROCEDURE is still accepted for compatibility.  
  
Reported-by: Peter Geoghegan <pg@bowt.ie>  
Reviewed-by: Jonathan S. Katz <jonathan.katz@excoventures.com>  

M doc/src/sgml/extend.sgml
M doc/src/sgml/ref/create_operator.sgml
M doc/src/sgml/xoper.sgml
M src/backend/commands/operatorcmds.c
M src/bin/pg_dump/pg_dump.c
M src/test/regress/expected/create_operator.out
M src/test/regress/sql/create_operator.sql

doc: Update uses of the word "procedure"

commit   : b7b16605db8804161097f80df0fef703a0d19b61    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 15 Aug 2018 17:01:39 +0200    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 15 Aug 2018 17:01:39 +0200    

Click here for diff

Historically, the term procedure was used as a synonym for function in  
Postgres/PostgreSQL.  Now we have procedures as separate objects from  
functions, so we need to clean up the documentation to not mix those  
terms.  
  
In particular, mentions of "trigger procedures" are changed to "trigger  
functions", and access method "support procedures" are changed to  
"support functions".  (The latter already used FUNCTION in the SQL  
syntax anyway.)  Also, the terminology in the SPI chapter has been  
cleaned up.  
  
A few tests, examples, and code comments are also adjusted to be  
consistent with documentation changes, but not everything.  
  
Reported-by: Peter Geoghegan <pg@bowt.ie>  
Reviewed-by: Jonathan S. Katz <jonathan.katz@excoventures.com>  

M doc/src/sgml/brin.sgml
M doc/src/sgml/catalogs.sgml
M doc/src/sgml/event-trigger.sgml
M doc/src/sgml/func.sgml
M doc/src/sgml/plhandler.sgml
M doc/src/sgml/plperl.sgml
M doc/src/sgml/plpgsql.sgml
M doc/src/sgml/pltcl.sgml
M doc/src/sgml/ref/alter_opfamily.sgml
M doc/src/sgml/ref/create_language.sgml
M doc/src/sgml/ref/create_opclass.sgml
M doc/src/sgml/ref/create_operator.sgml
M doc/src/sgml/ref/create_trigger.sgml
M doc/src/sgml/spi.sgml
M doc/src/sgml/xindex.sgml
M doc/src/sgml/xplang.sgml
M src/backend/access/gin/ginvalidate.c
M src/backend/access/gist/gistvalidate.c
M src/backend/access/hash/hashutil.c
M src/backend/access/hash/hashvalidate.c
M src/backend/access/spgist/spgvalidate.c
M src/backend/commands/opclasscmds.c
M src/bin/psql/describe.c
M src/include/access/hash.h
M src/test/regress/expected/alter_generic.out
M src/test/regress/expected/create_operator.out
M src/test/regress/sql/create_operator.sql

Do not dump identity sequences with excluded parent table

commit   : 4ed59e02f5aa97618bb33355dc3accbcc2d5ace1    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 22 Aug 2018 14:22:39 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 22 Aug 2018 14:22:39 +0900    

Click here for diff

This commit prevents a crash of pg_dump caused by the exclusion of a  
table which has identity columns, as the table would be correctly  
excluded but not its identity sequence.  In order to fix that, identity  
sequences are excluded if the parent table is defined as such.  Knowing  
about such sequences has no meaning without their parent table anyway.  
  
Reported-by: Andy Abelisto  
Author: David Rowley  
Reviewed-by: Peter Eisentraut, Michael Paquier  
Discussion: https://postgr.es/m/153479393218.1316.8472285660264976457@wrigleys.postgresql.org  
Backpatch-through: 10  

M src/bin/pg_dump/pg_dump.c

Fix typo

commit   : 561a5ab7514cd38fa7433d2214ce308481b10044    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 21 Aug 2018 17:16:10 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 21 Aug 2018 17:16:10 -0300    

Click here for diff

M src/backend/utils/mmgr/dsa.c

fix typo

commit   : 5065596e510f899122c1189de23af56c4953e2e0    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 21 Aug 2018 17:03:35 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 21 Aug 2018 17:03:35 -0300    

Click here for diff

M src/backend/access/hash/README

Fix typo

commit   : 69183651118e39512f37e9ca246b6bf4c648bb63    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 21 Aug 2018 17:00:54 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 21 Aug 2018 17:00:54 -0300    

Click here for diff

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

Fix set of NLS translation issues

commit   : 3ef153c7157fd679c0acc20433c99d109b16222b    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 21 Aug 2018 15:17:25 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 21 Aug 2018 15:17:25 +0900    

Click here for diff

While monitoring the code, a couple of issues related to string  
translation has showed up:  
- Some routines for auto-updatable views return an error string, which  
sometimes missed the shot.  A comment regarding string translation is  
added for each routine to help with future features.  
- GSSAPI authentication missed two translations.  
- vacuumdb handles non-translated strings.  
  
Reported-by: Kyotaro Horiguchi  
Author: Kyotaro Horiguchi  
Reviewed-by: Michael Paquier, Tom Lane  
Discussion: https://postgr.es/m/20180810.152131.31921918.horiguchi.kyotaro@lab.ntt.co.jp  
Backpatch-through: 9.3  

M src/backend/commands/tablecmds.c
M src/backend/commands/view.c
M src/backend/libpq/auth.c
M src/backend/rewrite/rewriteHandler.c
M src/bin/scripts/vacuumdb.c

Fix typo in description of enable_parallel_hash

commit   : 87c596cda6d7c79266cde44a1e9fc8ea1b8acefa    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 21 Aug 2018 12:13:16 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 21 Aug 2018 12:13:16 +0900    

Click here for diff

Author: Kyotaro Horiguchi  
Discussion: https://postgr.es/m/20180821.115841.93250330.horiguchi.kyotaro@lab.ntt.co.jp  

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

Clarify comment about assignment and reset of temp namespace ID in MyProc

commit   : 9fc9933695af4e233c2da704be4ad5c681cf7104    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 21 Aug 2018 08:37:01 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 21 Aug 2018 08:37:01 +0900    

Click here for diff

The new wording comes from Álvaro, which I modified a bit.  
  
Reported-by: Andres Freund, Álvaro Herrera  
Author: Álvaro Herrera, Michael Paquier  
Discussion: https://postgr.es/m/20180809165047.GK13638@paquier.xyz  
Backpatch-through: 11  

M src/backend/catalog/namespace.c

MSVC: Finish clean.bat tmp_check coverage.

commit   : 8fb9aa08742038765b94a8be614a9eb0908f825d    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sun, 19 Aug 2018 01:12:22 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sun, 19 Aug 2018 01:12:22 -0700    

Click here for diff

Use wildcards, so one can add a TAP test suite without updating this  
file.  Back-patch to v11, which omitted multiple new suites.  

M src/tools/msvc/clean.bat

MSVC: Remove any tmp_check directory before running a TAP test suite.

commit   : 4cd8479369ee3d366a8014593e6a3405eb9952a9    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sun, 19 Aug 2018 01:12:22 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sun, 19 Aug 2018 01:12:22 -0700    

Click here for diff

Back-patch to v11, where commit 90627cf98a8e7d0531789391fd798c9bfcc3bc1a  
made the GNU make build system do likewise.  Without this, when a  
typical PostgresNode-using test failed, subsequent runs bailed out with  
a "File exists" error.  

M src/tools/msvc/vcregress.pl

Improve error messages for CREATE OR REPLACE PROCEDURE

commit   : 49c1a4da641d52effb403bf79798975975b725a9    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 8 Aug 2018 20:39:26 +0200    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 8 Aug 2018 20:39:26 +0200    

Click here for diff

Change the hint to recommend DROP PROCEDURE instead of FUNCTION.  Also  
make the error message when changing the return type more specific to  
the case of procedures.  
  
Reported-by: Jeremy Evans <code@jeremyevans.net>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  

M src/backend/catalog/pg_proc.c

Ensure schema qualification in pg_restore DISABLE/ENABLE TRIGGER commands.

commit   : d73093c4ffefebadd25ea855bd8745f4fcb4462a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 17 Aug 2018 17:12:21 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 17 Aug 2018 17:12:21 -0400    

Click here for diff

Previously, this code blindly followed the common coding pattern of  
passing PQserverVersion(AH->connection) as the server-version parameter  
of fmtQualifiedId.  That works as long as we have a connection; but in  
pg_restore with text output, we don't.  Instead we got a zero from  
PQserverVersion, which fmtQualifiedId interpreted as "server is too old to  
have schemas", and so the name went unqualified.  That still accidentally  
managed to work in many cases, which is probably why this ancient bug went  
undetected for so long.  It only became obvious in the wake of the changes  
to force dump/restore to execute with restricted search_path.  
  
In HEAD/v11, let's deal with this by ripping out fmtQualifiedId's server-  
version behavioral dependency, and just making it schema-qualify all the  
time.  We no longer support pg_dump from servers old enough to need the  
ability to omit schema name, let alone restoring to them.  (Also, the few  
callers outside pg_dump already didn't work with pre-schema servers.)  
  
In older branches, that's not an acceptable solution, so instead just  
tweak the DISABLE/ENABLE TRIGGER logic to ensure it will schema-qualify  
its output regardless of server version.  
  
Per bug #15338 from Oleg somebody.  Back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/153452458706.1316.5328079417086507743@wrigleys.postgresql.org  

M src/bin/pg_dump/parallel.c
M src/bin/pg_dump/pg_backup_archiver.c
M src/bin/pg_dump/pg_dump.c
M src/bin/scripts/common.c
M src/bin/scripts/vacuumdb.c
M src/fe_utils/string_utils.c
M src/include/fe_utils/string_utils.h

Set scan direction appropriately for SubPlans (bug #15336)

commit   : 67b161eae32b0e900f74a2fe0b3f01667ca70850    
  
author   : Andrew Gierth <rhodiumtoad@postgresql.org>    
date     : Fri, 17 Aug 2018 15:04:26 +0100    
  
committer: Andrew Gierth <rhodiumtoad@postgresql.org>    
date     : Fri, 17 Aug 2018 15:04:26 +0100    

Click here for diff

When executing a SubPlan in an expression, the EState's direction  
field was left alone, resulting in an attempt to execute the subplan  
backwards if it was encountered during a backwards scan of a cursor.  
Also, though much less likely, it was possible to reach the execution  
of an InitPlan while in backwards-scan state.  
  
Repair by saving/restoring estate->es_direction and forcing forward  
scan mode in the relevant places.  
  
Backpatch all the way, since this has been broken since 8.3 (prior to  
commit c7ff7663e, SubPlans had their own EStates rather than sharing  
the parent plan's, so there was no confusion over scan direction).  
  
Per bug #15336 reported by Vladimir Baranoff; analysis and patch by  
me, review by Tom Lane.  
  
Discussion: https://postgr.es/m/153449812167.1304.1741624125628126322@wrigleys.postgresql.org  

M src/backend/executor/nodeSubplan.c
M src/test/regress/expected/subselect.out
M src/test/regress/sql/subselect.sql

pg_upgrade: issue helpful error message for use on standbys

commit   : 45d74631b3973390ff02cd765a674e6322e1c8db    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Fri, 17 Aug 2018 10:25:48 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Fri, 17 Aug 2018 10:25:48 -0400    

Click here for diff

Commit 777e6ddf1723306bd2bf8fe6f804863f459b0323 checked for a shut down  
message from a standby and allowed it to continue.  This patch reports a  
helpful error message in these cases, suggesting to use rsync as  
documented.  
  
Diagnosed-by: Martín Marqués  
  
Discussion: https://postgr.es/m/CAPdiE1xYCow-reLjrhJ9DqrMu-ppNq0ChUUEvVdxhdjGRD5_eA@mail.gmail.com  
  
Backpatch-through: 9.3  

M src/bin/pg_upgrade/controldata.c

Mention ownership requirements for REFRESH MATERIALIZED VIEW in docs

commit   : b43cf1dcded905abeceefc74fe44bbffc52ac96d    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 17 Aug 2018 11:29:15 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 17 Aug 2018 11:29:15 +0900    

Click here for diff

Author: Dian Fay  
Discussion: https://postgr.es/m/745abbd2-a1a0-ead8-2cb2-768c16747d97@gmail.com  
Backpatch-through: 9.3  

M doc/src/sgml/ref/refresh_materialized_view.sgml

Proof-reading for documentation.

commit   : dedc6a2bb15d1b62485840ad871902137d74c9a1    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Fri, 17 Aug 2018 11:32:55 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Fri, 17 Aug 2018 11:32:55 +1200    

Click here for diff

Somebody accidentally a word.  Back-patch to 9.6.  
  
Reported-by: Justin Pryzby  
Discussion: https://postgr.es/m/20180816195431.GA23707%40telsasoft.com  

M doc/src/sgml/parallel.sgml

Fix executor prune failure when plan already pruned

commit   : 6589a435d83ba0b22cb56381fc5b410eb0e27834    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 16 Aug 2018 12:43:04 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 16 Aug 2018 12:43:04 -0300    

Click here for diff

In a multi-layer partitioning setup, if at plan time all the  
sub-partitions are pruned but the intermediate one remains, the executor  
later throws a spurious error that there's nothing to prune.  That is  
correct, but there's no reason to throw an error.  Therefore, don't.  
  
Reported-by: Andreas Seltenreich <seltenreich@gmx.de>  
Author: David Rowley <david.rowley@2ndquadrant.com>  
Discussion: https://postgr.es/m/87in4h98i0.fsf@ansel.ydns.eu  

M src/backend/executor/execPartition.c
M src/test/regress/expected/partition_prune.out
M src/test/regress/sql/partition_prune.sql

Close the file descriptor in ApplyLogicalMappingFile

commit   : 43ba5ac6aa4879eea2d16f7f531b256c8203a3c3    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Thu, 16 Aug 2018 16:49:10 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Thu, 16 Aug 2018 16:49:10 +0200    

Click here for diff

The function was forgetting to close the file descriptor, resulting  
in failures like this:  
  
  ERROR:  53000: exceeded maxAllocatedDescs (492) while trying to open  
  file "pg_logical/mappings/map-4000-4eb-1_60DE1E08-5376b5-537c6b"  
  LOCATION:  OpenTransientFile, fd.c:2161  
  
Simply close the file at the end, and backpatch to 9.4 (where logical  
decoding was introduced). While at it, fix a nearby typo.  
  
Discussion: https://www.postgresql.org/message-id/flat/738a590a-2ce5-9394-2bef-7b1caad89b37%402ndquadrant.com  

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

Make snprintf.c follow the C99 standard for snprintf's result value.

commit   : 36147ec9f1e2dcbe35fc813825242d72d1c57b70    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 15 Aug 2018 17:25:23 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 15 Aug 2018 17:25:23 -0400    

Click here for diff

C99 says that the result should be the number of bytes that would have  
been emitted given a large enough buffer, not the number we actually  
were able to put in the buffer.  It's time to make our substitute  
implementation comply with that.  Not doing so results in inefficiency  
in buffer-enlargement cases, and also poses a portability hazard for  
third-party code that might expect C99-compliant snprintf behavior  
within Postgres.  
  
In passing, remove useless tests for str == NULL; neither C99 nor  
predecessor standards ever allowed that except when count == 0,  
so I see no reason to expend cycles on making that a non-crash case  
for this implementation.  Also, don't waste a byte in pg_vfprintf's  
local I/O buffer; this might have performance benefits by allowing  
aligned writes during flushbuffer calls.  
  
Back-patch of commit 805889d7d.  There was some concern about this  
possibly breaking code that assumes pre-C99 behavior, but there is  
much more risk (and reality, in our own code) of code that assumes  
C99 behavior and hence fails to detect buffer overrun without this.  
  
Discussion: https://postgr.es/m/17245.1534289329@sss.pgh.pa.us  

M src/port/snprintf.c

Update FSM on WAL replay of page all-visible/frozen

commit   : 6872c2be6a97057aa736110e31f0390a53305c9e    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 15 Aug 2018 18:09:29 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 15 Aug 2018 18:09:29 -0300    

Click here for diff

We aren't very strict about keeping FSM up to date on WAL replay,  
because per-page freespace values aren't critical in replicas (can't  
write to heap in a replica; and if the replica is promoted, the values  
would be updated by VACUUM anyway).  However, VACUUM since 9.6 can skip  
processing pages marked all-visible or all-frozen, and if such pages are  
recorded in FSM with wrong values, those values are blindly propagated  
to FSM's upper layers by VACUUM's FreeSpaceMapVacuum.  (This rationale  
assumes that crashes are not very frequent, because those would cause  
outdated FSM to occur in the primary.)  
  
Even when the FSM is outdated in standby, things are not too bad  
normally, because, most per-page FSM values will be zero (other than  
those propagated with the base-backup that created the standby); only  
once the remaining free space is less than 0.2*BLCKSZ the per-page value  
is maintained by WAL replay of heap ins/upd/del.  However, if  
wal_log_hints=on causes complete FSM pages to be propagated to a standby  
via full-page images, many too-optimistic per-page values can end up  
being registered in the standby.  
  
Incorrect per-page values aren't critical in most cases, since an  
inserter that is given a page that doesn't actually contain the claimed  
free space will update FSM with the correct value, and retry until it  
finds a usable page.  However, if there are many such updates to do, an  
inserter can spend a long time doing them before a usable page is found;  
in a heavily trafficked insert-only table with many concurrent inserters  
this has been observed to cause several second stalls, causing visible  
application malfunction.  
  
To fix this problem, it seems sufficient to have heap_xlog_visible  
(replay of setting all-visible and all-frozen VM bits for a heap page)  
update the FSM value for the page being processed.  This fixes the  
per-page counters together with making the page skippable to vacuum, so  
when vacuum does FreeSpaceMapVacuum, the values propagated to FSM upper  
layers are the correct ones, avoiding the problem.  
  
While at it, apply the same fix to heap_xlog_clean (replay of tuple  
removal by HOT pruning and vacuum).  This makes any space freed by the  
cleaning available earlier than the next vacuum in the promoted replica.  
  
Backpatch to 9.6, where this problem was diagnosed on an insert-only  
table with all-frozen pages, which were introduced as a concept in that  
release.  Theoretically it could apply with all-visible pages to older  
branches, but there's been no report of that and it doesn't backpatch  
cleanly anyway.  
  
Author: Álvaro Herrera <alvherre@alvh.no-ip.org>  
Discussion: https://postgr.es/m/20180802172857.5skoexsilnjvgruk@alvherre.pgsql  

M src/backend/access/heap/heapam.c

Clean up assorted misuses of snprintf()'s result value.

commit   : d7ed4eea539dbd6bf89163213ea6068b4ef0fe11    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 15 Aug 2018 16:29:32 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 15 Aug 2018 16:29:32 -0400    

Click here for diff

Fix a small number of places that were testing the result of snprintf()  
but doing so incorrectly.  The right test for buffer overrun, per C99,  
is "result >= bufsize" not "result > bufsize".  Some places were also  
checking for failure with "result == -1", but the standard only says  
that a negative value is delivered on failure.  
  
(Note that this only makes these places correct if snprintf() delivers  
C99-compliant results.  But at least now these places are consistent  
with all the other places where we assume that.)  
  
Also, make psql_start_test() and isolation_start_test() check for  
buffer overrun while constructing their shell commands.  There seems  
like a higher risk of overrun, with more severe consequences, here  
than there is for the individual file paths that are made elsewhere  
in the same functions, so this seemed like a worthwhile change.  
  
Also fix guc.c's do_serialize() to initialize errno = 0 before  
calling vsnprintf.  In principle, this should be unnecessary because  
vsnprintf should have set errno if it returns a failure indication ...  
but the other two places this coding pattern is cribbed from don't  
assume that, so let's be consistent.  
  
These errors are all very old, so back-patch as appropriate.  I think  
that only the shell command overrun cases are even theoretically  
reachable in practice, but there's not much point in erroneous error  
checks.  
  
Discussion: https://postgr.es/m/17245.1534289329@sss.pgh.pa.us  

M src/backend/postmaster/pgstat.c
M src/backend/utils/misc/guc.c
M src/common/ip.c
M src/interfaces/ecpg/pgtypeslib/common.c
M src/port/getaddrinfo.c
M src/test/isolation/isolation_main.c
M src/test/regress/pg_regress.c
M src/test/regress/pg_regress_main.c

pg_upgrade: fix shutdown check for standby servers

commit   : 995133410de7c0f3670022d0d7d982f6e8f81bc0    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 14 Aug 2018 17:19:02 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 14 Aug 2018 17:19:02 -0400    

Click here for diff

Commit 244142d32afd02e7408a2ef1f249b00393983822 only tested for the  
pg_controldata output for primary servers, but standby servers have  
different "Database cluster state" output, so check for that too.  
  
Diagnosed-by: Michael Paquier  
  
Discussion: https://postgr.es/m/20180810164240.GM13638@paquier.xyz  
  
Backpatch-through: 9.3  

M src/bin/pg_upgrade/controldata.c

commit   : c6eedb4d86dfdf5cf526af4df696e73dc8a5c275    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 14 Aug 2018 22:54:52 +0200    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 14 Aug 2018 22:54:52 +0200    

Click here for diff

Discussion: https://www.postgresql.org/message-id/flat/153044458767.13254.16049977382403131287%40wrigleys.postgresql.org  

M doc/src/sgml/libpq.sgml
M doc/src/sgml/pgcrypto.sgml
M doc/src/sgml/runtime.sgml

Remove duplicate function declarations.

commit   : d39079a8b2d6d860a1ab7484ef19c31261c6b099    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 14 Aug 2018 14:25:14 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 14 Aug 2018 14:25:14 -0400    

Click here for diff

Christoph Berg  
  
Discussion: https://postgr.es/m/20180814165536.GB21152@msg.df7cb.de  

M src/include/libpq/pqformat.h

Remove obsolete comment

commit   : 4c9611e576e8b70abe14a616d776670339f956c5    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 13 Aug 2018 21:07:31 +0200    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 13 Aug 2018 21:07:31 +0200    

Click here for diff

The sequence name is no longer stored in the sequence relation, since  
1753b1b027035029c2a2a1649065762fafbf63f3.  

M src/backend/commands/tablecmds.c

Fix libpq's implementation of per-host connection timeouts.

commit   : 998c7366414ad6f93c2643339499ce9e6ab007eb    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 13 Aug 2018 13:07:52 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 13 Aug 2018 13:07:52 -0400    

Click here for diff

Commit 5f374fe7a attempted to turn the connect_timeout from an overall  
maximum time limit into a per-host limit, but it didn't do a great job of  
that.  The timer would only get restarted if we actually detected timeout  
within connectDBComplete(), not if we changed our attention to a new host  
for some other reason.  In that case the old timeout continued to run,  
possibly causing a premature timeout failure for the new host.  
  
Fix that, and also tweak the logic so that if we do get a timeout,  
we advance to the next available IP address, not to the next host name.  
There doesn't seem to be a good reason to assume that all the IP  
addresses supplied for a given host name will necessarily fail the  
same way as the current one.  Moreover, this conforms better to the  
admittedly-vague documentation statement that the timeout is "per  
connection attempt".  I changed that to "per host name or IP address"  
to be clearer.  (Note that reconnections to the same server, such as for  
switching protocol version or SSL status, don't get their own separate  
timeout; that was true before and remains so.)  
  
Also clarify documentation about the interpretation of connect_timeout  
values less than 2.  
  
This seems like a bug, so back-patch to v10 where this logic came in.  
  
Tom Lane, reviewed by Fabien Coelho  
  
Discussion: https://postgr.es/m/5735.1533828184@sss.pgh.pa.us  

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

Make autovacuum more aggressive to remove orphaned temp tables

commit   : 943576bddcb52971041d9f5f806789921fa107ee    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 13 Aug 2018 11:49:12 +0200    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 13 Aug 2018 11:49:12 +0200    

Click here for diff

Commit dafa084, added in 10, made the removal of temporary orphaned  
tables more aggressive.  This commit makes an extra step into the  
aggressiveness by adding a flag in each backend's MyProc which tracks  
down any temporary namespace currently in use.  The flag is set when the  
namespace gets created and can be reset if the temporary namespace has  
been created in a transaction or sub-transaction which is aborted.  The  
flag value assignment is assumed to be atomic, so this can be done in a  
lock-less fashion like other flags already present in PGPROC like  
databaseId or backendId, still the fact that the temporary namespace and  
table created are still locked until the transaction creating those  
commits acts as a barrier for other backends.  
  
This new flag gets used by autovacuum to discard more aggressively  
orphaned tables by additionally checking for the database a backend is  
connected to as well as its temporary namespace in-use, removing  
orphaned temporary relations even if a backend reuses the same slot as  
one which created temporary relations in a past session.  
  
The base idea of this patch comes from Robert Haas, has been written in  
its first version by Tsunakawa Takayuki, then heavily reviewed by me.  
  
Author: Tsunakawa Takayuki  
Reviewed-by: Michael Paquier, Kyotaro Horiguchi, Andres Freund  
Discussion: https://postgr.es/m/0A3221C70F24FB45833433255569204D1F8A4DC6@G01JPEXMBYT05  
Backpatch: 11-, as PGPROC gains a new flag and we don't want silent ABI  
breakages on already released versions.  

M src/backend/access/transam/twophase.c
M src/backend/catalog/namespace.c
M src/backend/postmaster/autovacuum.c
M src/backend/storage/lmgr/proc.c
M src/include/catalog/namespace.h
M src/include/storage/proc.h

Adjust comment atop ExecShutdownNode.

commit   : f34d4b79fab42de09b43a1aa54dc2d77150ed94a    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Mon, 13 Aug 2018 10:12:39 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Mon, 13 Aug 2018 10:12:39 +0530    

Click here for diff

After commits a315b967cc and b805b63ac2, part of the comment atop  
ExecShutdownNode is redundant.  Adjust it.  
  
Author: Amit Kapila  
Backpatch-through: 10 where both the mentioned commits are present.  
Discussion: https://postgr.es/m/86137f17-1dfb-42f9-7421-82fd786b04a1@anayrat.info  

M src/backend/executor/execProcnode.c

Prohibit shutting down resources if there is a possibility of back up.

commit   : c054afd0a22c75acec8f85872ae1036bd8519132    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Mon, 13 Aug 2018 08:33:55 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Mon, 13 Aug 2018 08:33:55 +0530    

Click here for diff

Currently, we release the asynchronous resources as soon as it is evident  
that no more rows will be needed e.g. when a Limit is filled.  This can be  
problematic especially for custom and foreign scans where we can scan  
backward.  Fix that by disallowing the shutting down of resources in such  
cases.  
  
Reported-by: Robert Haas  
Analysed-by: Robert Haas and Amit Kapila  
Author: Amit Kapila  
Reviewed-by: Robert Haas  
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/execMain.c
M src/backend/executor/nodeLimit.c

Avoid query-lifetime memory leaks in XMLTABLE (bug #15321)

commit   : 78f70e07e2cf42b95c9f0adb57e37cf6c1274ec3    
  
author   : Andrew Gierth <rhodiumtoad@postgresql.org>    
date     : Mon, 13 Aug 2018 01:45:35 +0100    
  
committer: Andrew Gierth <rhodiumtoad@postgresql.org>    
date     : Mon, 13 Aug 2018 01:45:35 +0100    

Click here for diff

Multiple calls to XMLTABLE in a query (e.g. laterally applying it to a  
table with an xml column, an important use-case) were leaking large  
amounts of memory into the per-query context, blowing up memory usage.  
  
Repair by reorganizing memory context usage in nodeTableFuncscan; use  
the usual per-tuple context for row-by-row evaluations instead of  
perValueCxt, and use the explicitly created context -- renamed from  
perValueCxt to perTableCxt -- for arguments and state for each  
individual table-generation operation.  
  
Backpatch to PG10 where this code was introduced.  
  
Original report by IRC user begriffs; analysis and patch by me.  
Reviewed by Tom Lane and Pavel Stehule.  
  
Discussion: https://postgr.es/m/153394403528.10284.7530399040974170549@wrigleys.postgresql.org  

M src/backend/executor/nodeTableFuncscan.c
M src/include/nodes/execnodes.h

Fix bogus loop logic in 013_crash_restart test's pump_until subroutine.

commit   : badaa0c50de0e1c8b1deb27d0a1ee00498e40002    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 12 Aug 2018 18:05:49 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 12 Aug 2018 18:05:49 -0400    

Click here for diff

The pump_nb() step might've already received the desired data, so we must  
check for that at the top of the loop not the bottom.  Otherwise, the  
call to pump() will sit with nothing to do until the timeout elapses.  
pump_until then falls out with apparent success ... but the timeout has  
been used up, causing the next call of pump_until to report a timeout  
failure.  I believe this explains the intermittent timeout failures  
we've seen in the buildfarm ever since this test went in.  I was able  
to reproduce the problem on gaur semi-repeatably, and this appears to  
fix it.  
  
In passing, remove a duplicate assignment, fix one stdin-assignment to  
look like the rest, and document the test's dependency on test_decoding.  

M src/test/recovery/README
M src/test/recovery/t/013_crash_restart.pl

Fix wrong order of operations in inheritance_planner.

commit   : 0ff8f521d40f271c57f29f0ca773981e4465b35b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 11 Aug 2018 15:53:20 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 11 Aug 2018 15:53:20 -0400    

Click here for diff

When considering a partitioning parent rel, we should stop processing that  
subroot as soon as we've done adjust_appendrel_attrs and any securityQuals  
updates.  The rest of this is unnecessary, and indeed adding duplicate  
subquery RTEs to the subroot is *wrong*.  As the code stood, the children  
of that partition ended up with two sets of copied subquery RTEs, confusing  
matters greatly.  Even more hilarity ensued if all of the children got  
excluded by constraint exclusion, so that the extra RTEs didn't make it  
back into the parent rtable.  
  
Per fuzz testing by Andreas Seltenreich.  Back-patch to v11 where this  
got broken (by commit 0a480502b, it looks like).  
  
Discussion: https://postgr.es/m/87va8g7vq0.fsf@ansel.ydns.eu  

M src/backend/optimizer/plan/planner.c
M src/test/regress/expected/partition_join.out
M src/test/regress/sql/partition_join.sql

Revert changes in execMain.c from commit 16828d5c0273b

commit   : afff44303cc316d2fe8ad15ac5a5fc90d59dcd67    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 10 Aug 2018 16:05:54 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 10 Aug 2018 16:05:54 -0400    

Click here for diff

These changes were put in at some stage of the development process, but  
are unnecessary and should not have made it into the final patch. Mea  
culpa.  
  
Per gripe from Andreas Freund  
  
Backpatch to REL_11_STABLE  

M src/backend/executor/execMain.c

Handle parallel index builds on mapped relations.

commit   : 9353d94a9b70c6cbe181f78e49b2e8c1dc38eada    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Fri, 10 Aug 2018 13:01:33 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Fri, 10 Aug 2018 13:01:33 -0700    

Click here for diff

Commit 9da0cc35284, which introduced parallel CREATE INDEX, failed to  
propagate relmapper.c backend local cache state to parallel worker  
processes.  This could result in parallel index builds against mapped  
catalog relations where the leader process (participating as a worker)  
scans the new, pristine relfilenode, while worker processes scan the  
obsolescent relfilenode.  When this happened, the final index structure  
was typically not consistent with the owning table's structure.  The  
final index structure could contain entries formed from both heap  
relfilenodes.  Only rebuilds on mapped catalog relations that occur as  
part of a VACUUM FULL or CLUSTER could become corrupt in practice, since  
their mapped relation relfilenode swap is what allows the inconsistency  
to arise.  
  
On master, fix the problem by propagating the required relmapper.c  
backend state as part of standard parallel initialization (Cf. commit  
29d58fd3).  On v11, simply disallow builds against mapped catalog  
relations by deeming them parallel unsafe.  
  
Author: Peter Geoghegan  
Reported-By: "death lock"  
Reviewed-By: Tom Lane, Amit Kapila  
Bug: #15309  
Discussion: https://postgr.es/m/153329671686.1405.18298309097348420351@wrigleys.postgresql.org  
Backpatch: 11-, where parallel CREATE INDEX was introduced.  

M src/backend/optimizer/plan/planner.c
M src/backend/utils/cache/relmapper.c

Fix typo in SP-GiST error message

commit   : 1b9d1b08fe5972f06f0eee41f7d8040c740aaa6b    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Fri, 10 Aug 2018 17:28:48 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Fri, 10 Aug 2018 17:28:48 +0300    

Click here for diff

Error message didn't match the actual check.  Fix that.  Compression of leaf  
SP-GiST values was introduced in 11.  So, backpatch.  
  
Discussion: https://postgr.es/m/20180810.100742.15469435.horiguchi.kyotaro%40lab.ntt.co.jp  
Author: Kyotaro Horiguchi  
Backpatch-through: 11  

M src/backend/access/spgist/spgutils.c

Add missing documentation for argument of amcostestimate()

commit   : dc444801ba692f773836308a44b2c0ed88af87e5    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Fri, 10 Aug 2018 14:14:36 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Fri, 10 Aug 2018 14:14:36 +0300    

Click here for diff

5262f7a4fc44 have introduced parallel index scan.  In order to estimate the  
number of parallel workers, it adds extra argument to amcostestimate() index  
access method API function.  However, this extra argument was missed in the  
documentation.  This commit fixes that.  
  
Discussion: https://postgr.es/m/4128fdb4-8b63-2e05-38f6-3125f8c27263%40lab.ntt.co.jp  
Author: Tatsuro Yamada, Alexander Korotkov  
Backpatch-through: 10  

M doc/src/sgml/indexam.sgml

Add RECURSIVE to documentation index

commit   : 58a36f91b36f30603e5983f19d26c67941cefd3a    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 9 Aug 2018 16:19:32 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 9 Aug 2018 16:19:32 -0400    

Click here for diff

Author: Daniel Vérité <daniel@manitou-mail.org>  
Reviewed-by: Fabien COELHO <coelho@cri.ensmp.fr>  
Discussion: https://postgr.es/m/76d905d7-7eb7-4574-b6ec-a0ca3a1523c0@manitou-mail.org  

M doc/src/sgml/queries.sgml
M doc/src/sgml/ref/create_view.sgml

Document need to clear MAKELEVEL when invoking PG build from a makefile.

commit   : a015ae54a7fd5d613470033d624879804f629fae    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 9 Aug 2018 15:21:09 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 9 Aug 2018 15:21:09 -0400    

Click here for diff

Since commit 3b8f6e75f, failure to do this would lead to  
submake-generated-headers not doing anything, so that references to  
generated or symlinked headers would fail.  Previous to that, the  
omission only led to temp-install not doing anything, which apparently  
affects many fewer people (doesn't anybody use "make check" in their  
build rules??).  Hence, backpatch to v11 but not further.  
  
Per complaints from Christoph Berg, Jakob Egger, and others.  

M doc/src/sgml/installation.sgml

docs: Only first instance of a PREPARE parameter sets data type

commit   : 8c92638c008b074df9cf3087816e3aa8c01177a5    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Thu, 9 Aug 2018 10:13:15 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Thu, 9 Aug 2018 10:13:15 -0400    

Click here for diff

If the first reference to $1 is "($1 = col) or ($1 is null)", the data  
type can be determined, but not for "($1 is null) or ($1 = col)".  This  
change documents this.  
  
Reported-by: Morgan Owens  
  
Discussion: https://postgr.es/m/153233728858.1404.15268121695358514937@wrigleys.postgresql.org  
  
Backpatch-through: 9.3  

M doc/src/sgml/ref/prepare.sgml

Spell "partitionwise" consistently.

commit   : 83f2691a3f2bafa397ff1dcca94c4d059df0e056    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 9 Aug 2018 10:41:28 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 9 Aug 2018 10:41:28 +0300    

Click here for diff

I'm not sure which spelling is better, "partitionwise" or "partition-wise",  
but everywhere else we spell it "partitionwise", so be consistent.  
  
Tatsuro Yamada reported the one in README, I found the other one with grep.  
  
Discussion: https://www.postgresql.org/message-id/d25ebf36-5a6d-8b2c-1ff3-d6f022a56000@lab.ntt.co.jp  

M contrib/postgres_fdw/expected/postgres_fdw.out
M contrib/postgres_fdw/sql/postgres_fdw.sql
M src/backend/optimizer/README

Restrict access to reindex of shared catalogs for non-privileged users

commit   : 87330e21c32793237791756ddffae676775e3aaa    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 9 Aug 2018 09:40:27 +0200    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 9 Aug 2018 09:40:27 +0200    

Click here for diff

A database owner running a database-level REINDEX has the possibility to  
also do the operation on shared system catalogs without being an owner  
of them, which allows him to block resources it should not have access  
to.  The same goes for a schema owner.  For example, PostgreSQL would go  
unresponsive and even block authentication if a lock is waited for  
pg_authid.  This commit makes sure that a user running a REINDEX SYSTEM,  
DATABASE or SCHEMA only works on the following relations:  
- The user is a superuser  
- The user is the table owner  
- The user is the database/schema owner, only if the relation worked on  
is not shared.  
  
Robert has worded most the documentation changes, and I have coded the  
core part.  
  
Reported-by: Lloyd Albin, Jeremy Schneider  
Author: Michael Paquier, Robert Haas  
Reviewed by: Nathan Bossart, Kyotaro Horiguchi  
Discussion: https://postgr.es/m/152512087100.19803.12733865831237526317@wrigleys.postgresql.org  
Discussion: https://postgr.es/m/20180805211059.GA2185@paquier.xyz  
Backpatch-through: 11- as the current behavior has been around for a  
very long time and could be disruptive for already released branches.  

M doc/src/sgml/ref/reindex.sgml
M src/backend/commands/indexcmds.c

Remove bogus Assert in make_partitionedrel_pruneinfo().

commit   : 69d0e7e6b81db733971508da0e512115930edf1e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 8 Aug 2018 20:02:10 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 8 Aug 2018 20:02:10 -0400    

Click here for diff

This Assert thought that a given rel couldn't be both leaf and  
non-leaf, but it turns out that in some unusual plan trees  
that's wrong, so remove it.  
  
The lack of testing for cases like that is quite concerning ---  
there is little reason for confidence that there aren't other  
bugs in the area.  But developing a stable test case seems  
rather difficult, and in any case we don't need this Assert.  
  
David Rowley  
  
Discussion: https://postgr.es/m/CAJGNTeOkdk=UVuMugmKL7M=owgt4nNr1wjxMg1F+mHsXyLCzFA@mail.gmail.com  

M src/backend/partitioning/partprune.c

Doc: Correct description of amcheck example query.

commit   : 393e539c54d14ecd2b7d15b4cf2ac4a858ec451b    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Wed, 8 Aug 2018 12:56:23 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Wed, 8 Aug 2018 12:56:23 -0700    

Click here for diff

The amcheck documentation incorrectly claimed that its example query  
verifies every catalog index in the database.  In fact, the query only  
verifies the 10 largest indexes (as determined by pg_class.relpages).  
Adjust the description accordingly.  
  
Backpatch: 10-, where contrib/amcheck was introduced.  

M doc/src/sgml/amcheck.sgml

Don't run atexit callbacks in quickdie signal handlers.

commit   : 79f17d45e82f3648c2459b8128ab4d516fb7640a    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 8 Aug 2018 19:08:10 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 8 Aug 2018 19:08:10 +0300    

Click here for diff

exit() is not async-signal safe. Even if the libc implementation is, 3rd  
party libraries might have installed unsafe atexit() callbacks. After  
receiving SIGQUIT, we really just want to exit as quickly as possible, so  
we don't really want to run the atexit() callbacks anyway.  
  
The original report by Jimmy Yih was a self-deadlock in startup_die().  
However, this patch doesn't address that scenario; the signal handling  
while waiting for the startup packet is more complicated. But at least this  
alleviates similar problems in the SIGQUIT handlers, like that reported  
by Asim R P later in the same thread.  
  
Backpatch to 9.3 (all supported versions).  
  
Discussion: https://www.postgresql.org/message-id/CAOMx_OAuRUHiAuCg2YgicZLzPVv5d9_H4KrL_OFsFP%3DVPekigA%40mail.gmail.com  

M src/backend/postmaster/bgworker.c
M src/backend/postmaster/bgwriter.c
M src/backend/postmaster/checkpointer.c
M src/backend/postmaster/startup.c
M src/backend/postmaster/walwriter.c
M src/backend/replication/walreceiver.c
M src/backend/tcop/postgres.c

Match RelOptInfos by relids not pointer equality.

commit   : a3deecb1c9af1e3d210a321401e40f22db859290    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 8 Aug 2018 11:44:50 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 8 Aug 2018 11:44:50 -0400    

Click here for diff

Commit 1c2cb2744 added some code that tried to detect whether two  
RelOptInfos were the "same" rel by pointer comparison; but it turns  
out that inheritance_planner breaks that, through its shenanigans  
with copying some relations forward into new subproblems.  Compare  
relid sets instead.  Add a regression test case to exercise this  
area.  
  
Problem reported by Rushabh Lathia; diagnosis and fix by Amit Langote,  
modified a bit by me.  
  
Discussion: https://postgr.es/m/CAGPqQf3anJGj65bqAQ9edDr8gF7qig6_avRgwMT9MsZ19COUPw@mail.gmail.com  

M src/backend/partitioning/partprune.c
M src/test/regress/expected/partition_prune.out
M src/test/regress/sql/partition_prune.sql

Don't record FDW user mappings as members of extensions.

commit   : ea1b659710663240a6c41b57ba10a37f3f82eb23    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 7 Aug 2018 16:32:50 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 7 Aug 2018 16:32:50 -0400    

Click here for diff

CreateUserMapping has a recordDependencyOnCurrentExtension call that's  
been there since extensions were introduced (very possibly my fault).  
However, there's no support anywhere else for user mappings as members  
of extensions, nor are they listed as a possible member object type in  
the documentation.  Nor does it really seem like a good idea for user  
mappings to belong to extensions when roles don't.  Hence, remove the  
bogus call.  
  
(As we saw in bug #15310, the lack of any pg_dump support for this case  
ensures that any such membership record would silently disappear during  
pg_upgrade.  So there's probably no need for us to do anything else  
about cleaning up after this mistake.)  
  
Discussion: https://postgr.es/m/27952.1533667213@sss.pgh.pa.us  

M src/backend/commands/foreigncmds.c

Fix incorrect initialization of BackendActivityBuffer.

commit   : 1b5438ec2a4ddb2bc632916efc1ec89f593dac06    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 7 Aug 2018 16:00:44 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 7 Aug 2018 16:00:44 -0400    

Click here for diff

Since commit c8e8b5a6e, this has been zeroed out using the wrong length.  
In practice the length would always be too small, leading to not zeroing  
the whole buffer rather than clobbering additional memory; and that's  
pretty harmless, both because shmem would likely start out as zeroes  
and because we'd reinitialize any given entry before use.  Still,  
it's bogus, so fix it.  
  
Reported by Petru-Florin Mihancea (bug #15312)  
  
Discussion: https://postgr.es/m/153363913073.1303.6518849192351268091@wrigleys.postgresql.org  

M src/backend/postmaster/pgstat.c

Fix pg_upgrade to handle event triggers in extensions correctly.

commit   : 187331fefdb0b4cc2c2aaab42c754dcafa2a0f08    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 7 Aug 2018 15:43:48 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 7 Aug 2018 15:43:48 -0400    

Click here for diff

pg_dump with --binary-upgrade must emit ALTER EXTENSION ADD commands  
for all objects that are members of extensions.  It forgot to do so for  
event triggers, as per bug #15310 from Nick Barnes.  Back-patch to 9.3  
where event triggers were introduced.  
  
Haribabu Kommi  
  
Discussion: https://postgr.es/m/153360083872.1395.4593932457718151600@wrigleys.postgresql.org  

M src/bin/pg_dump/pg_dump.c

Ensure pg_dump_sort.c sorts null vs non-null namespace consistently.

commit   : f7364300667befd892667d54414268aafc24377e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 7 Aug 2018 13:13:42 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 7 Aug 2018 13:13:42 -0400    

Click here for diff

The original coding here (which is, I believe, my fault) supposed that  
it didn't need to concern itself with the possibility that one object  
of a given type-priority has a namespace while another doesn't.  But  
that's not reliably true anymore, if it ever was; and if it does happen  
then it's possible that DOTypeNameCompare returns self-inconsistent  
comparison results.  That leads to unspecified behavior in qsort()  
and a resultant weird output order from pg_dump.  
  
This should end up being only a cosmetic problem, because any ordering  
constraints that actually matter should be enforced by the later  
dependency-based sort.  Still, it's a bug, so back-patch.  
  
Report and fix by Jacob Champion, though I editorialized on his  
patch to the extent of making NULL sort after non-NULL, for consistency  
with our usual sorting definitions.  
  
Discussion: https://postgr.es/m/CABAq_6Hw+V-Kj7PNfD5tgOaWT_-qaYkc+SRmJkPLeUjYXLdxwQ@mail.gmail.com  

M src/bin/pg_dump/pg_dump_sort.c

Stamp 11beta3.

commit   : e62cc60fb97ae49f8a892cf98675c36727830cba    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 6 Aug 2018 16:02:42 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 6 Aug 2018 16:02:42 -0400    

Click here for diff

M configure
M configure.in
M doc/bug.template
M src/include/pg_config.h.win32

Translation updates

commit   : 10dc69ef8f7e82079738e96ca171fd0e513e72ad    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 6 Aug 2018 20:09:07 +0200    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 6 Aug 2018 20:09:07 +0200    

Click here for diff

Source-Git-URL: https://git.postgresql.org/git/pgtranslation/messages.git  
Source-Git-Hash: 9706d37387722f17626b41da7b83ea02691f735c  

M src/backend/nls.mk
M src/backend/po/sv.po
A src/backend/po/tr.po
M src/bin/initdb/po/cs.po
M src/bin/initdb/po/es.po
M src/bin/initdb/po/ja.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_config/po/cs.po
M src/bin/pg_controldata/po/cs.po
M src/bin/pg_ctl/po/cs.po
M src/bin/pg_dump/po/cs.po
M src/bin/pg_dump/po/sv.po
M 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_rewind/po/de.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_upgrade/po/sv.po
M src/bin/pg_waldump/nls.mk
A src/bin/pg_waldump/po/cs.po
M src/bin/psql/nls.mk
M src/bin/psql/po/cs.po
M src/bin/psql/po/ja.po
M src/bin/psql/po/sv.po
A src/bin/psql/po/tr.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/es.po
M src/interfaces/libpq/po/cs.po
M src/interfaces/libpq/po/es.po
M src/pl/plperl/po/cs.po
M src/pl/plpgsql/src/po/cs.po
M src/pl/plpgsql/src/po/sv.po
M src/pl/plpython/po/cs.po
M src/pl/tcl/po/cs.po

Last-minute updates for release notes.

commit   : 749839c4d53c60de2e51ef82a03f1084e3ec1f6c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 6 Aug 2018 13:13:40 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 6 Aug 2018 13:13:40 -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   : f6f735f78d9e05b757c96b036dfd31b1f9f77312    
  
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

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

commit   : c6db605c3ee5664327dc5444dc7e76e013e631fe    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 5 Aug 2018 16:38:42 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 5 Aug 2018 16:38:42 -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   : 1d6c93f8f412c135550748afa22f447809baf424    
  
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

Remove now unused check for HAVE_X509_GET_SIGNATURE_NID in test.

commit   : a2441558a66669744cfeb03b921e915ce59283ce    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Sun, 5 Aug 2018 17:16:12 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Sun, 5 Aug 2018 17:16:12 +0300    

Click here for diff

I removed the code that used this in the previous commit.  
  
Spotted by Michael Paquier.  

M src/test/ssl/t/002_scram.pl

Remove support for tls-unique channel binding.

commit   : 1b7378b3d6894466d6b38bf93c7fe11ef7449226    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Sun, 5 Aug 2018 13:44:21 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Sun, 5 Aug 2018 13:44:21 +0300    

Click here for diff

There are some problems with the tls-unique channel binding type. It's not  
supported by all SSL libraries, and strictly speaking it's not defined for  
TLS 1.3 at all, even though at least in OpenSSL, the functions used for it  
still seem to work with TLS 1.3 connections. And since we had no  
mechanism to negotiate what channel binding type to use, there would be  
awkward interoperability issues if a server only supported some channel  
binding types. tls-server-end-point seems feasible to support with any SSL  
library, so let's just stick to that.  
  
This removes the scram_channel_binding libpq option altogether, since there  
is now only one supported channel binding type.  
  
This also removes all the channel binding tests from the SSL test suite.  
They were really just testing the scram_channel_binding option, which  
is now gone. Channel binding is used if both client and server support it,  
so it is used in the existing tests. It would be good to have some tests  
specifically for channel binding, to make sure it really is used, and the  
different combinations of a client and a server that support or doesn't  
support it. The current set of settings we have make it hard to write such  
tests, but I did test those things manually, by disabling  
HAVE_BE_TLS_GET_CERTIFICATE_HASH and/or  
HAVE_PGTLS_GET_PEER_CERTIFICATE_HASH.  
  
I also removed the SCRAM_CHANNEL_BINDING_TLS_END_POINT constant. This is a  
matter of taste, but IMO it's more readable to just use the  
"tls-server-end-point" string.  
  
Refactor the checks on whether the SSL library supports the functions  
needed for tls-server-end-point channel binding. Now the server won't  
advertise, and the client won't choose, the SCRAM-SHA-256-PLUS variant, if  
compiled with an OpenSSL version too old to support it.  
  
In the passing, add some sanity checks to check that the chosen SASL  
mechanism, SCRAM-SHA-256 or SCRAM-SHA-256-PLUS, matches whether the SCRAM  
exchange used channel binding or not. For example, if the client selects  
the non-channel-binding variant SCRAM-SHA-256, but in the SCRAM message  
uses channel binding anyway. It's harmless from a security point of view,  
I believe, and I'm not sure if there are some other conditions that would  
cause the connection to fail, but it seems better to be strict about these  
things and check explicitly.  
  
Discussion: https://www.postgresql.org/message-id/ec787074-2305-c6f4-86aa-6902f98485a4%40iki.fi  

M doc/src/sgml/libpq.sgml
M doc/src/sgml/protocol.sgml
M doc/src/sgml/release-11.sgml
M src/backend/libpq/auth-scram.c
M src/backend/libpq/auth.c
M src/backend/libpq/be-secure-openssl.c
M src/include/common/scram-common.h
M src/include/libpq/libpq-be.h
M src/include/libpq/scram.h
M src/interfaces/libpq/fe-auth-scram.c
M src/interfaces/libpq/fe-auth.c
M src/interfaces/libpq/fe-connect.c
M src/interfaces/libpq/fe-secure-openssl.c
M src/interfaces/libpq/libpq-int.h
M src/test/ssl/t/002_scram.pl

Update version 11 release notes.

commit   : 87790fd1eaa5d2cd50c15ac55bfbcda602dfd272    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 4 Aug 2018 23:49:53 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 4 Aug 2018 23:49:53 -0400    

Click here for diff

Remove description of commit 1944cdc98, which has now been back-patched  
so it's not relevant to v11 any longer.  Add descriptions of other  
recent commits that seemed worth mentioning.  
  
I marked the update as stopping at 2018-07-30, because it's unclear  
whether d06eebce5 will be allowed to stay in v11, and I didn't feel like  
putting effort into writing a description of it yet.  If it does stay,  
I think it will deserve mention in the Source Code section.  

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

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

commit   : e7154b6acfeb70cb079cfa17c8d22725f77455b4    
  
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   : 58673b4a5fdff4d0d327c2d07e0cf8743f86f44c    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sun, 5 Aug 2018 05:31:56 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sun, 5 Aug 2018 05:31:56 +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

Make "kerberos" test suite independent of "localhost" name resolution.

commit   : 75224ac20e90d2a9ba18ead1af62c74858d48c41    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Fri, 3 Aug 2018 20:53:25 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Fri, 3 Aug 2018 20:53:25 -0700    

Click here for diff

This suite malfunctioned if the canonical name of "localhost" was  
something other than "localhost", such as "localhost.localdomain".  Use  
hostaddr=127.0.0.1 and a fictitious host=, so the resolver's answers for  
"localhost" don't affect the outcome.  Back-patch to v11, which  
introduced this test suite.  
  
Discussion: https://postgr.es/m/20180801050903.GA1392916@rfd.leadboat.com  

M src/test/kerberos/t/001_auth.pl

Add table relcache invalidation to index builds.

commit   : b9612e5cfab828e496108c8e5379fdfac625ae01    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Fri, 3 Aug 2018 14:45:02 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Fri, 3 Aug 2018 14:45:02 -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   : a3958178935a0258a1850a9f4ac710fbaaa3344f    
  
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   : d25c48d0c9f09355eaee4bb8f2c21c354ac47358    
  
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   : d8b2beb269c9606513a1693ac2e21586aa693e1a    
  
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   : 6efc30167188f2adea8741dc1b69f6536b2c9b44    
  
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-common.c

Fix buffer usage stats for parallel nodes.

commit   : dac7fe13bbf10c249a519d6a41c683c42c7e3312    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Fri, 3 Aug 2018 11:16:25 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Fri, 3 Aug 2018 11:16:25 +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   : ef305bd59d9828805bfdbf33ff4003bb74a63865    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Fri, 3 Aug 2018 09:29:45 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Fri, 3 Aug 2018 09:29:45 +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 run-time partition pruning for appends with multiple source rels.

commit   : 1b54e91faabf3764b6786915881e514e42dccf89    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 1 Aug 2018 19:42:46 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 1 Aug 2018 19:42:46 -0400    

Click here for diff

The previous coding here supposed that if run-time partitioning applied to  
a particular Append/MergeAppend plan, then all child plans of that node  
must be members of a single partitioning hierarchy.  This is totally wrong,  
since an Append could be formed from a UNION ALL: we could have multiple  
hierarchies sharing the same Append, or child plans that aren't part of any  
hierarchy.  
  
To fix, restructure the related plan-time and execution-time data  
structures so that we can have a separate list or array for each  
partitioning hierarchy.  Also track subplans that are not part of any  
hierarchy, and make sure they don't get pruned.  
  
Per reports from Phil Florent and others.  Back-patch to v11, since  
the bug originated there.  
  
David Rowley, with a lot of cosmetic adjustments by me; thanks also  
to Amit Langote for review.  
  
Discussion: https://postgr.es/m/HE1PR03MB17068BB27404C90B5B788BCABA7B0@HE1PR03MB1706.eurprd03.prod.outlook.com  

M src/backend/executor/execPartition.c
M src/backend/executor/nodeAppend.c
M src/backend/nodes/copyfuncs.c
M src/backend/nodes/outfuncs.c
M src/backend/nodes/readfuncs.c
M src/backend/optimizer/path/allpaths.c
M src/backend/optimizer/plan/createplan.c
M src/backend/optimizer/plan/planner.c
M src/backend/partitioning/partprune.c
M src/include/executor/execPartition.h
M src/include/nodes/nodes.h
M src/include/nodes/plannodes.h
M src/include/partitioning/partprune.h
M src/test/regress/expected/partition_prune.out
M src/test/regress/sql/partition_prune.sql

Fix logical replication slot initialization

commit   : 7326a7d63801673d3569def65cb7955d6486f254    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 1 Aug 2018 17:39:07 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 1 Aug 2018 17:39:07 -0400    

Click here for diff

This was broken in commit 9c7d06d60680, which inadvertently gave the  
wrong value to fast_forward in one StartupDecodingContext call.  Fix by  
flipping the value.  Add a test for the obvious error, namely trying to  
initialize a replication slot with an nonexistent output plugin.  
  
While at it, move the CreateDecodingContext call earlier, so that any  
errors are reported before sending the CopyBoth message.  
  
Author: Dave Cramer <davecramer@gmail.com>  
Reviewed-by: Andres Freund <andres@anarazel.de>  
Discussion: https://postgr.es/m/CADK3HHLVkeRe1v4P02-5hj55H3_yJg3AEtpXyEY5T3wuzO2jSg@mail.gmail.com  

M contrib/test_decoding/expected/slot.out
M contrib/test_decoding/sql/slot.sql
M src/backend/replication/logical/logical.c
M src/backend/replication/walsender.c

Fix per-tuple memory leak in partition tuple routing

commit   : 34295b87fbbcbaf26280f53f006b20971dbad1f3    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 1 Aug 2018 15:06:47 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 1 Aug 2018 15:06:47 -0400    

Click here for diff

Some operations were being done in a longer-lived memory context,  
causing intra-query leaks.  It's not noticeable unless you're doing a  
large COPY, but if you are, it eats enough memory to cause a problem.  
  
Co-authored-by: Kohei KaiGai <kaigai@heterodb.com>  
Co-authored-by: Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>  
Co-authored-by: Álvaro Herrera <alvherre@alvh.no-ip.org>  
Discussion: https://postgr.es/m/CAOP8fzYtVFWZADq4c=KoTAqgDrHWfng+AnEPEZccyxqxPVbbWQ@mail.gmail.com  

M src/backend/executor/execPartition.c

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

commit   : e9bbfe60882e037b4bddddc5077d19c1a9762e58    
  
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

Update parallel.sgml for Parallel Append

commit   : ac535cd478060f84b67d08c54e482bd373bf1779    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Wed, 1 Aug 2018 08:14:05 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Wed, 1 Aug 2018 08:14:05 -0400    

Click here for diff

Patch by me, reviewed by Thomas Munro, in response to a complaint  
from Adrien Nayrat.  
  
Discussion: http://postgr.es/m/baa0d036-7349-f722-ef88-2d8bb3413045@anayrat.info  

M doc/src/sgml/parallel.sgml

pg_upgrade: fix --check for live source server checks

commit   : 9200016335a030d70907dfa9bcb680681a61608e    
  
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

Provide for contrib and pgxs modules to install include files.

commit   : d06eebce5fa4aece311d4042362d1652b484c52c    
  
author   : Andrew Gierth <rhodiumtoad@postgresql.org>    
date     : Tue, 31 Jul 2018 19:58:39 +0100    
  
committer: Andrew Gierth <rhodiumtoad@postgresql.org>    
date     : Tue, 31 Jul 2018 19:58:39 +0100    

Click here for diff

This allows out-of-tree PLs and similar code to get access to  
definitions needed to work with extension data types.  
  
The following existing modules now install headers: contrib/cube,  
contrib/hstore, contrib/isn, contrib/ltree, contrib/seg.  
  
Discussion: https://postgr.es/m/87y3euomjh.fsf%40news-spur.riddles.org.uk  

M contrib/cube/Makefile
M contrib/hstore/Makefile
M contrib/isn/Makefile
M contrib/ltree/Makefile
M contrib/seg/Makefile
M doc/src/sgml/extend.sgml
M src/makefiles/pgxs.mk
M src/tools/msvc/Install.pm

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

commit   : a56c11d44dfcce1cbed3a6ed243ae43e001dfb9f    
  
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/include/utils/varlena.h
M src/test/regress/expected/rules.out
M src/test/regress/sql/rules.sql

Remove dead code left behind by 1b6801051.

commit   : 5a71d3e58333f764b4fc34f3cf93521c964f64f6    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 30 Jul 2018 19:11:02 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 30 Jul 2018 19:11:02 -0400    

Click here for diff

M src/backend/nodes/bitmapset.c

Verify range bounds to bms_add_range when necessary

commit   : a0655ba68fb54a011b1c57901ad66764b1e5473f    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 30 Jul 2018 17:03:19 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 30 Jul 2018 17:03:19 -0400    

Click here for diff

Now that the bms_add_range boundary protections are gone, some  
alternative ones are needed in a few places.  
  
Author: Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>  
Discussion: https://postgr.es/m/3437ccf8-a144-55ff-1e2f-fc16b437823b@lab.ntt.co.jp  

M src/backend/executor/nodeAppend.c
M src/backend/partitioning/partprune.c

Change bms_add_range to be a no-op for empty ranges

commit   : 192d1bbf99699de76473184c57fff9ff4b4246f4    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 30 Jul 2018 17:18:42 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 30 Jul 2018 17:18:42 -0400    

Click here for diff

In commit 84940644de93, bms_add_range was added with an API to fail with  
an error if an empty range was specified.  This seems arbitrary and  
unhelpful, so turn that case into a no-op instead.  Callers that require  
further verification on the arguments or result can apply them by  
themselves.  
  
This fixes the bug that partition pruning throws an API error for a case  
involving the default partition of a default partition, as in the  
included test case.  
  
Reported-by: Rajkumar Raghuwanshi <rajkumar.raghuwanshi@enterprisedb.com>  
Diagnosed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/16590.1532622503@sss.pgh.pa.us  

M src/backend/nodes/bitmapset.c
M src/test/regress/expected/partition_prune.out
M src/test/regress/sql/partition_prune.sql

Ensure we build generated headers at the start of some more cases.

commit   : 739d9b29948bb508656d7f6c779630788abac560    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 30 Jul 2018 18:04:39 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 30 Jul 2018 18:04:39 -0400    

Click here for diff

"make installcheck" and some related cases, when invoked from the toplevel  
directory, start out by doing "make all" in src/test/regress.  Since that's  
one make recursion level down, the submake-generated-headers target will  
do nothing, causing us to fail to create/update generated headers before  
building pg_regress.  This is, I believe, a new failure mode induced by  
commit 3b8f6e75f, so let's fix it.  To do so, we have to invoke  
submake-generated-headers at the top level.  
  
Discussion: https://postgr.es/m/0401efec-68f1-679d-3ea3-21d4e8dd11af@gmail.com  

M GNUmakefile.in
M src/Makefile.global.in

Set ActiveSnapshot when logically replaying inserts

commit   : 5dbd0beb8a95fa1de3a931d20102cc9f273fceef    
  
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   : f6ef3ed43669350e0d5fd5a02ae3be6ec150a64e    
  
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   : 506bbbf02e8c045b6d35dc3b0083e5a12f7b3837    
  
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   : 5ed0b6daec542ea1787ed4265fb75448e8f27e66    
  
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   : a117c7a7b62f8978052b69e8e3bfdf8f8099a61d    
  
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   : 9a513f8f9e87462ec63a9f08bcd2d4a7e1f6fa4d    
  
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   : 113224848aa010ce03431c76198bfdac871e8a0e    
  
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   : f0aff14d43394c669747af244e3c47fb8020cc77    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Sat, 28 Jul 2018 11:35:53 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Sat, 28 Jul 2018 11:35:53 -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   : 09a5be587b6546aa10a71b112683c115d0b11586    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Fri, 27 Jul 2018 10:56:07 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Fri, 27 Jul 2018 10:56:07 +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

Fix handling of pgbench's hash when no argument is provided

commit   : c2e5f60db160d74ba862023ec460ace938f4fb1c    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 27 Jul 2018 13:43:36 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 27 Jul 2018 13:43:36 +0900    

Click here for diff

Depending on the platform used, this can cause a crash in the worst  
case, or an unhelpful error message, so fail gracefully.  
  
Author: Fabien Coelho  
Discussion: https://postgr.es/m/alpine.DEB.2.21.1807262302550.29874@lancre  
Backpatch: 11-, where hash() has been added in pgbench.  

M src/bin/pgbench/exprparse.y
M src/bin/pgbench/t/002_pgbench_no_server.pl

Provide plpgsql tests for cases involving record field changes.

commit   : c606f10ff832fc54258bb8a259a8e0daa46468ee    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 26 Jul 2018 18:18:37 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 26 Jul 2018 18:18:37 -0400    

Click here for diff

We suppressed one of these test cases in commit feb1cc559 because  
it was failing to produce the expected results on CLOBBER_CACHE_ALWAYS  
buildfarm members.  But now we need another test with similar behavior,  
so let's set up a test file that is expected to vary between regular and  
CLOBBER_CACHE_ALWAYS cases, and provide variant expected files.  
  
Someday we should fix plpgsql's failure for change-of-field-type, and  
then the discrepancy will go away and we can fold these tests back  
into plpgsql_record.sql.  But today is not that day.  
  
Discussion: https://postgr.es/m/87wotkfju1.fsf@news-spur.riddles.org.uk  

M src/pl/plpgsql/src/Makefile
A src/pl/plpgsql/src/expected/plpgsql_cache.out
A src/pl/plpgsql/src/expected/plpgsql_cache_1.out
M src/pl/plpgsql/src/expected/plpgsql_record.out
A src/pl/plpgsql/src/sql/plpgsql_cache.sql
M src/pl/plpgsql/src/sql/plpgsql_record.sql

Avoid crash in eval_const_expressions if a Param's type changes.

commit   : 9207a64e1496d9be8b7f33f2ac30052c130c61c3    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 26 Jul 2018 16:08:45 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 26 Jul 2018 16:08:45 -0400    

Click here for diff

Since commit 6719b238e it's been possible for the values of plpgsql  
record field variables to be exposed to the planner as Params.  
(Before that, plpgsql never supplied values for such variables during  
planning, so that the problematic code wasn't reached.)  Other places  
that touch potentially-type-mutable Params either cope gracefully or  
do runtime-test-and-ereport checks that the type is what they expect.  
But eval_const_expressions() just had an Assert, meaning that it either  
failed the assertion or risked crashes due to using an incompatible  
value.  
  
In this case, rather than throwing an ereport immediately, we can just  
not perform a const-substitution in case of a mismatch.  This seems  
important for the same reason that the Param fetch was speculative:  
we might not actually reach this part of the expression at runtime.  
  
Test case will follow in a separate commit.  
  
Patch by me, pursuant to bug report from Andrew Gierth.  
Back-patch to v11 where the previous commit appeared.  
  
Discussion: https://postgr.es/m/87wotkfju1.fsf@news-spur.riddles.org.uk  

M src/backend/optimizer/util/clauses.c

LLVMJIT: Release JIT context after running ExprContext shutdown callbacks.

commit   : ed7e319eb41361250ccb19379ef206b4a6d866de    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Wed, 25 Jul 2018 16:31:49 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Wed, 25 Jul 2018 16:31:49 -0700    

Click here for diff

Due to inlining it previously was possible that an ExprContext's  
shutdown callback pointed to a JITed function. As the JIT context  
previously was shut down before the shutdown callbacks were called,  
that could lead to segfaults.  Fix the ordering.  
  
Reported-By: Dmitry Dolgov  
Author: Andres Freund  
Discussion: https://postgr.es/m/CA+q6zcWO7CeAJtHBxgcHn_hj+PenM=tvG0RJ93X1uEJ86+76Ug@mail.gmail.com  
Backpatch: 11-, where JIT compilation was added  

M src/backend/executor/execMain.c
M src/backend/executor/execUtils.c

LLVMJIT: Check for 'noinline' attribute in recursively inlined functions.

commit   : 1cfa69dcd8eff4a9611bf726bb90e89b77922a61    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Wed, 25 Jul 2018 16:23:59 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Wed, 25 Jul 2018 16:23:59 -0700    

Click here for diff

Previously the attribute was only checked for external functions  
inlined, not "static" functions that had to be inlined as  
dependencies.  
  
This isn't really a bug, but makes debugging a bit harder. The new  
behaviour also makes more sense. Therefore backpatch.  
  
Author: Andres Freund  
Backpatch: 11-, where JIT compilation was added  

M src/backend/jit/llvm/llvmjit_inline.cpp

Pad semaphores to avoid false sharing.

commit   : f2db5f3bb0b5d429e9fa5b093936f8524e4192b1    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Wed, 25 Jul 2018 10:58:44 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Wed, 25 Jul 2018 10:58:44 +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   : e0a2a4c87f22a9031fd5af7ca70fa76809609c12    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Tue, 24 Jul 2018 10:51:06 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Tue, 24 Jul 2018 10:51:06 -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

psql: Add option for procedures to \df

commit   : 07055a2c8cbfb772d3c7c114cfe12dddae0f90fe    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Sat, 14 Jul 2018 12:17:49 +0200    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Sat, 14 Jul 2018 12:17:49 +0200    

Click here for diff

M doc/src/sgml/ref/psql-ref.sgml
M src/bin/psql/command.c
M src/bin/psql/describe.c
M src/bin/psql/help.c
M src/test/regress/expected/create_procedure.out
M src/test/regress/sql/create_procedure.sql

Fix calculation for WAL segment recycling and removal

commit   : 9915735ebbc5c5362f5834f6ad7b86394ded4a85    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 24 Jul 2018 10:33:07 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 24 Jul 2018 10:33:07 +0900    

Click here for diff

Commit 4b0d28de06 has removed the prior checkpoint and related  
facilities but has left WAL recycling based on the LSN of the prior  
checkpoint, which causes incorrect calculations for WAL removal and  
recycling for max_wal_size and min_wal_size.  This commit changes things  
so as the base calculation point is the last checkpoint generated.  
  
Reported-by: Kyotaro Horiguchi  
Author: Kyotaro Horiguchi  
Reviewed-by: Michael Paquier  
Discussion: https://postgr.es/m/20180723.135748.42558387.horiguchi.kyotaro@lab.ntt.co.jp  
Backpatch: 11-, where the prior checkpoint has been removed.  

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

pgbench: Remove duplicate entries from table of builtin functions.

commit   : 14ca287bcf329b26a6a8041ba69cc12332aba22c    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Mon, 23 Jul 2018 11:48:38 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Mon, 23 Jul 2018 11:48:38 -0400    

Click here for diff

Fabien Coelho  
  
Discussion: http://postgr.es/m/alpine.DEB.2.21.1807221822320.19939@lancre  

M src/bin/pgbench/exprparse.y

LLVMJIT: Adapt to API changes in gdb and perf support.

commit   : 1b957e59b92dc44c14708762f882d7910463a9ac    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Sun, 22 Jul 2018 21:13:20 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Sun, 22 Jul 2018 21:13:20 -0700    

Click here for diff

During the work of upstreaming my previous patches for gdb and perf  
support the API changed. Adapt.  Normally this wouldn't necessarily be  
something to backpatch, but the previous API wasn't upstream, and at  
least the gdb support is quite useful for debugging.  
  
Author: Andres Freund  
Backpatch: 11, where LLVM based JIT support was added.  

M config/llvm.m4
M configure
M src/backend/jit/llvm/llvmjit.c
M src/include/pg_config.h.in
M src/include/pg_config.h.win32

LLVMJIT: Fix LLVM build for LLVM > 7.

commit   : 9820f5c41edfd17abc4faab80e54bbd933817d01    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Sun, 22 Jul 2018 21:05:06 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Sun, 22 Jul 2018 21:05:06 -0700    

Click here for diff

The location of LLVMAddPromoteMemoryToRegisterPass moved.  
  
Author: Andres Freund  
Backpatch: 11, where LLVM based JIT support was added.  

M src/backend/jit/llvm/llvmjit.c

Reset context at the tail end of JITed EEOP_AGG_PLAIN_TRANS.

commit   : 0171ad9308ac232d5934d548a2adc898b794c5e0    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Sun, 22 Jul 2018 20:31:22 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Sun, 22 Jul 2018 20:31:22 -0700    

Click here for diff

While no negative consequences are currently known, it's clearly wrong  
to not reset the context in one of the branches.  
  
Reported-By: Dmitry Dolgov  
Author: Dmitry Dolgov  
Discussion: https://postgr.es/m/CAGPqQf165-=+Drw3Voim7M5EjHT1zwPF9BQRjLFQzCzYnNZEiQ@mail.gmail.com  
Backpatch: 11-, where JIT compilation support was added  

M src/backend/jit/llvm/llvmjit_expr.c

Fix JITed EEOP_AGG_INIT_TRANS, which missed some state.

commit   : a9a0a4d3f88b87564533b87af64d3282ca417dc6    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Sun, 22 Jul 2018 16:47:00 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Sun, 22 Jul 2018 16:47:00 -0700    

Click here for diff

The JIT compiled implementation missed maintaining  
AggState->{current_set,curaggcontext}. That could lead to trouble  
because the transition value could be allocated in the wrong context.  
  
Reported-By: Rushabh Lathia  
Diagnosed-By: Dmitry Dolgov  
Author: Dmitry Dolgov, with minor changes by me  
Discussion: https://postgr.es/m/CAGPqQf165-=+Drw3Voim7M5EjHT1zwPF9BQRjLFQzCzYnNZEiQ@mail.gmail.com  
Backpatch: 11-, where JIT compilation support was added  

M src/backend/jit/llvm/llvmjit_expr.c

Further portability hacking in pg_upgrade's test script.

commit   : 04e3492c5c46822c756f575d6105a8a6ff76d4f2    
  
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

Be more paranoid about quoting in pg_upgrade's test script.

commit   : 5e5d131202c3494f4360f001b4805c8944e9600c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 21 Jul 2018 12:05:25 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 21 Jul 2018 12:05:25 -0400    

Click here for diff

Double-quote $PGDATA in "find" commands introduced by commit da9b580d8,  
in case that path contains spaces or other special characters.  
  
Adjust a few other places so that quoting is done more consistently.  
None of the others are actual bugs AFAICS, but it's confusing to readers  
if the same thing is done differently in different places.  
  
Noted by Tels.  
  
Discussion: https://postgr.es/m/c96303c04c360bbedaa04f90f515745b.squirrel@sm.webmail.pair.com  

M src/bin/pg_upgrade/test.sh

Avoid unportable shell syntax in pg_upgrade's test script.

commit   : e6105686dcfa5b3b0a3937f9b6c4d44a865adc17    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 20 Jul 2018 13:59:27 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 20 Jul 2018 13:59:27 -0400    

Click here for diff

Most of test.sh uses traditional backtick syntax for command substitution,  
but commit da9b580d8 introduced two uses of $(...) syntax, which is not  
recognized by very old shells.  Bring those into line with the rest.  
  
Victor Wagner  
  
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   : 1f919e663ee20430dfde5614a025ac2dbd0f4bfb    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Fri, 20 Jul 2018 08:57:08 +0100    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Fri, 20 Jul 2018 08:57:08 +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

Fix handling of empty uncompressed posting list pages in GIN

commit   : 608793266dbbc4f9064e6737ab3363adf9584892    
  
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

Remove undocumented restriction against duplicate partition key columns.

commit   : b1af4bcc42f7e95abb9e8bceb894e0ef2acfc55a    
  
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

Improve psql's \d command to show whether index columns are key columns.

commit   : f4a5ce359587257c6d14b8e746889077c649439a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 19 Jul 2018 14:53:41 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 19 Jul 2018 14:53:41 -0400    

Click here for diff

This is essential information when looking at an index that has  
"included" columns.  Per discussion, follow the style used in \dC  
and some other places: column header is "Key?" and values are "yes"  
or "no" (all translatable).  
  
While at it, revise describeOneTableDetails to be a bit more maintainable:  
avoid hard-wired column numbers and multiple repetitions of what needs  
to be identical test logic.  This also results in the emitted catalog  
query corresponding more closely to what we print, which should be a  
benefit to users of ECHO_HIDDEN mode, and perhaps a bit faster too  
(the old logic sometimes asked for values it would not print, even  
ones that are fairly expensive to get).  
  
Discussion: https://postgr.es/m/21724.1531943735@sss.pgh.pa.us  

M src/bin/psql/describe.c
M src/test/regress/expected/alter_table.out
M src/test/regress/expected/create_index.out
M src/test/regress/expected/index_including.out
M src/test/regress/output/tablespace.source

Fix pg_get_indexdef()'s behavior for included index columns.

commit   : 0f49a2de96e7b58e15899b2639e096b771e45886    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 19 Jul 2018 13:48:05 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 19 Jul 2018 13:48:05 -0400    

Click here for diff

The multi-argument form of pg_get_indexdef() failed to print anything when  
asked to print a single index column that is an included column rather than  
a key column.  This seems an unintentional result of someone having tried  
to take a short-cut and use the attrsOnly flag for two different purposes.  
To fix, split said flag into two flags, attrsOnly which suppresses  
non-attribute info, and keysOnly which suppresses included columns.  
Add a test case using psql's \d command, which relies on that function.  
  
(It's mighty tempting at this point to replace pg_get_indexdef_worker's  
mess of boolean flag arguments with a single bitmask-of-flags argument,  
which would allow making the call sites much more self-documenting.  
But I refrained for the moment.)  
  
Discussion: https://postgr.es/m/21724.1531943735@sss.pgh.pa.us  

M src/backend/utils/adt/ruleutils.c
M src/test/regress/expected/index_including.out
M src/test/regress/sql/index_including.sql

Rewrite comments in replication slot advance implementation

commit   : 96bd49437cca5d7a6e4024c602a9fdbdbf7c7433    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 19 Jul 2018 14:15:44 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 19 Jul 2018 14:15:44 -0400    

Click here for diff

The code added by 9c7d06d60680 was a bit obscure; clarify that by  
rewriting the comments.  Lack of clarity has already caused bugs, so  
it's a worthy goal.  
  
Co-authored-by: Arseny Sher <a.sher@postgrespro.ru>  
Co-authored-by: Michaël Paquier <michael@paquier.xyz>  
Co-authored-by: Álvaro Herrera <alvherre@alvh.no-ip.org>  
Reviewed-by: Petr Jelínek <petr.jelinek@2ndquadrant.com>  
Discussion: https://postgr.es/m/87y3fgoyrn.fsf@ars-thinkpad  

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

Fix error message when a hostaddr cannot be parsed.

commit   : dc961e5822343c8b22371a78ded4d6263418de61    
  
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   : 45fcd758a07fef44a8773202b13f469c9636dffc    
  
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   : bc62aef53d686b282f164277da0f2405a4fd0ac3    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 19 Jul 2018 09:55:02 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 19 Jul 2018 09:55:02 +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

Fix re-parameterize of MergeAppendPath

commit   : 6365ebacdd08f988cd31572c7190c8f08194bf5d    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 19 Jul 2018 09:02:09 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 19 Jul 2018 09:02:09 +0900    

Click here for diff

Instead of MergeAppendPath, MergeAppend nodes were considered.  This  
code is not covered by any tests now, which should be addressed at some  
point.  
  
This is an oversight from f49842d, which introduced partition-wise joins  
in v11, so back-patch down to that.  
  
Author: Michael Paquier  
Reviewed-by: Ashutosh Bapat  
Discussion: https://postgr.es/m/20180718062202.GC8565@paquier.xyz  

M src/backend/optimizer/util/pathnode.c

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

commit   : ade18277a0dc6a5981f8c189ed7743b48d3a1516    
  
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

Drop the rule against included index columns duplicating key columns.

commit   : eb00eb4e8c529ee0783c1b3052cfa736d457cbb5    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 18 Jul 2018 14:43:03 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 18 Jul 2018 14:43:03 -0400    

Click here for diff

The initial version of the included-index-column feature stated that  
included columns couldn't be the same as any key column of the index.  
While it'd be pretty silly to do that, since the included column would be  
entirely redundant, we've never prohibited redundant index columns before  
so it's not very consistent to do so here.  Moreover, the prohibition  
was itself badly implemented, so that it failed to reject columns that  
were effectively identical but not spelled quite alike, as reported by  
Aditya Toshniwal.  
  
(Moreover, it's not hard to imagine that for some non-btree index types,  
such cases would be non-silly anyhow: the index might use a lossy  
representation for key columns but be able to support retrieval of the  
original form of included columns.)  
  
Hence, let's just drop the prohibition.  
  
In passing, do some copy-editing on the documentation for the  
included-column feature.  
  
Yugo Nagata; documentation and test corrections by me  
  
Discussion: https://postgr.es/m/CAM9w-_mhBCys4fQNfaiQKTRrVWtoFrZ-wXmDuE9Nj5y-Y7aDKQ@mail.gmail.com  

M doc/src/sgml/catalogs.sgml
M doc/src/sgml/indexam.sgml
M doc/src/sgml/indices.sgml
M doc/src/sgml/ref/create_index.sgml
M doc/src/sgml/ref/create_table.sgml
M src/backend/commands/indexcmds.c
M src/test/regress/expected/index_including.out
M src/test/regress/sql/index_including.sql

Fix misc typos, mostly in comments.

commit   : 65976cd86a9bdeec5a5277545e5efa33724102c8    
  
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/commands/explain.c
M src/backend/executor/nodeModifyTable.c
M src/backend/optimizer/plan/planner.c
M src/backend/parser/parse_func.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/execnodes.h
M src/include/nodes/parsenodes.h
M src/include/port/pg_bswap.h
M src/include/storage/latch.h
M src/include/utils/rel.h
M src/interfaces/ecpg/ecpglib/execute.c
M src/interfaces/ecpg/preproc/parse.pl
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

doc: move PARTITION OF stanza to just below PARTITION BY

commit   : 07f303ab6076c10e36ebcf46155e6ca66fcfe56e    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 17 Jul 2018 00:54:53 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 17 Jul 2018 00:54:53 -0400    

Click here for diff

It's more logical this way, since the new ordering matches the way the  
tables are created; but in any case, the previous location of PARTITION OF  
did not appear carefully chosen anyway (since it didn't match the  
location in which it appears in the synopsys either, which is what we  
normally do.)  
  
In the PARTITION BY stanza, add a link to the partitioning section in  
the DDL chapter, too.  
  
Suggested-by: David G. Johnston  
Discussion: https://postgr.es/m/CAKFQuwY4Ld7ecxL_KAmaxwt0FUu5VcPPN2L4dh+3BeYbrdBa5g@mail.gmail.com  

M doc/src/sgml/ref/create_table.sgml

Fix ALTER TABLE...SET STATS error message for included columns

commit   : 802b04cb3fadeb381001611f3ffa3c2762bdcc25    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 16 Jul 2018 20:00:24 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 16 Jul 2018 20:00:24 -0400    

Click here for diff

The existing error message was complaining that the column is not an  
expression, which is not correct.  Introduce a suitable wording  
variation and a test.  
  
Co-authored-by: Yugo Nagata <nagata@sraoss.co.jp>  
Discussion: https://postgr.es/m/20180628182803.e4632d5a.nagata@sraoss.co.jp  
Reviewed-by: Álvaro Herrera <alvherre@alvh.no-ip.org>  

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

Fix partition pruning with IS [NOT] NULL clauses

commit   : fb2b61a21e141843697de7982c9f6485effcd915    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 16 Jul 2018 18:38:09 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 16 Jul 2018 18:38:09 -0400    

Click here for diff

The original code was unable to prune partitions that could not possibly  
contain NULL values, when the query specified less than all columns in a  
multicolumn partition key.  Reorder the if-tests so that it is, and add  
more commentary and regression tests.  
  
Reported-by: Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>  
Co-authored-by: Dilip Kumar <dilipbalaut@gmail.com>  
Co-authored-by: Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>  
Co-authored-by: Álvaro Herrera <alvherre@alvh.no-ip.org>  
Reviewed-by: Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>  
Reviewed-by: amul sul <sulamul@gmail.com>  
Discussion: https://postgr.es/m/CAFjFpRc7qjLUfXLVBBC_HAnx644sjTYM=qVoT3TJ840HPbsTXw@mail.gmail.com  

M src/backend/partitioning/partprune.c
M src/test/regress/expected/partition_prune.out
M src/test/regress/sql/partition_prune.sql

Add subtransaction handling for table synchronization workers.

commit   : 9ec9f8f6833db5bafc30c480f96f06bdf5c012e6    
  
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

commit   : e716dc3fc4cdfbc53d65e93ab9c6600c32f824ae    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 16 Jul 2018 10:44:06 +0200    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 16 Jul 2018 10:44:06 +0200    

Click here for diff

Update links that resulted in redirects.  Most are changes from http to  
https, but there are also some other minor edits.  (There are still some  
redirects where the target URL looks less elegant than the one we  
currently have.  I have left those as is.)  

M doc/src/sgml/acronyms.sgml
M doc/src/sgml/bloom.sgml
M doc/src/sgml/client-auth.sgml
M doc/src/sgml/docguide.sgml
M doc/src/sgml/external-projects.sgml
M doc/src/sgml/history.sgml
M doc/src/sgml/install-windows.sgml
M doc/src/sgml/installation.sgml
M doc/src/sgml/isn.sgml
M doc/src/sgml/nls.sgml
M doc/src/sgml/passwordcheck.sgml
M doc/src/sgml/pgcrypto.sgml
M doc/src/sgml/plpython.sgml
M doc/src/sgml/problems.sgml
M doc/src/sgml/release.sgml
M doc/src/sgml/runtime.sgml
M doc/src/sgml/spgist.sgml
M doc/src/sgml/textsearch.sgml
M doc/src/sgml/wal.sgml
M src/backend/lib/bipartite_match.c
M src/backend/utils/adt/numeric.c
M src/bin/pgbench/pgbench.c

Fix hashjoin costing mistake introduced with inner_unique optimization.

commit   : 704e393190725f54ddaaaee2cda1a6f3a26bff6d    
  
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   : dbd7f4e7c433b4fc202e9520d2bd360200f07805    
  
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

Update documentation editor setup instructions

commit   : bc4e355f013d6122e4ae17fa99e9db20babbb86a    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 13 Jul 2018 21:23:41 +0200    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 13 Jul 2018 21:23:41 +0200    

Click here for diff

Now that the documentation sources are in XML rather than SGML, some of  
the documentation about the editor, or more specifically Emacs, setup  
needs updating.  The updated instructions recommend using nxml-mode,  
which works mostly out of the box, with some small tweaks in  
emacs.samples and .dir-locals.el.  
  
Also remove some obsolete stuff in .dir-locals.el.  I did, however,  
leave the sgml-mode settings in there so that someone using Emacs  
without emacs.samples gets those settings when editing a *.sgml file.  

M .dir-locals.el
M doc/src/sgml/docguide.sgml
M src/tools/editors/emacs.samples

Fix crash in json{b}_populate_recordset() and json{b}_to_recordset().

commit   : 9a5e8ed283e583782b3f40e6ededcb005d5c0333    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 13 Jul 2018 14:16:47 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 13 Jul 2018 14:16:47 -0400    

Click here for diff

As of commit 37a795a60, populate_recordset_worker() tried to pass back  
(as rsi.setDesc) a tupdesc that it also had cached in its fn_extra.  
But the core executor would free the passed-back tupdesc, risking a  
crash if the function were called again in the same query.  The safest  
and least invasive way to fix that is to make an extra tupdesc copy  
to pass back.  
  
While at it, I failed to resist the temptation to get rid of unnecessary  
get_fn_expr_argtype() calls here and in populate_record_worker().  
  
Per report from Dmitry Dolgov; thanks to Michael Paquier and  
Andrew Gierth for investigation and discussion.  
  
Discussion: https://postgr.es/m/CA+q6zcWzN9ztCfR47ZwgTr1KLnuO6BAY6FurxXhovP4hxr+yOQ@mail.gmail.com  

M src/backend/utils/adt/jsonfuncs.c
M src/test/regress/expected/json.out
M src/test/regress/expected/jsonb.out
M src/test/regress/sql/json.sql
M src/test/regress/sql/jsonb.sql

Dump foreign keys on partitioned tables

commit   : 2af39c39df94096ecc593f5a162947e1e994cab3    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 13 Jul 2018 13:13:26 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 13 Jul 2018 13:13:26 -0400    

Click here for diff

The patch that ended up as commit 3de241dba86f ("Foreign keys on  
partitioned tables") lacked pg_dump tests, so the pg_dump code that was  
there to support it inadvertently stopped working when in later  
development I modified the backend code not to emit pg_trigger rows for  
the partitioned table itself.  
  
Bug analysis and code fix is by Michaël.  I (Álvaro) added the test.  
  
Reported-by: amul sul <sulamul@gmail.com>  
Co-authored-by: Michaël Paquier <michael@paquier.xyz>  
Co-authored-by: Álvaro Herrera <alvherre@alvh.no-ip.org>  
Discussion: https://postgr.es/m/CAAJ_b94n=UsNVhgs97vCaWEZAMe-tGDRVuZ73oePQH=eaJKGSA@mail.gmail.com  

M src/bin/pg_dump/pg_dump.c
M src/bin/pg_dump/t/002_pg_dump.pl

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

commit   : 5586e42b349346df5d88f71a5a41d8cb76b8c491    
  
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   : 4980f51845278afba8d382c3b294741c3efed168    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Fri, 13 Jul 2018 11:16:56 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Fri, 13 Jul 2018 11:16:56 -0400    

Click here for diff

Backpatch-through: 9.3  

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

Prohibit transaction commands in security definer procedures

commit   : 3804e89bd0e94fb412d3eecb2113cc97e0f7310b    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 4 Jul 2018 09:26:19 +0200    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 4 Jul 2018 09:26:19 +0200    

Click here for diff

Starting and aborting transactions in security definer procedures  
doesn't work.  StartTransaction() insists that the security context  
stack is empty, so this would currently cause a crash, and  
AbortTransaction() resets it.  This could be made to work by  
reorganizing the code, but right now we just prohibit it.  
  
Reported-by: amul sul <sulamul@gmail.com>  
Discussion: https://www.postgresql.org/message-id/flat/CAAJ_b96Gupt_LFL7uNyy3c50-wbhA68NUjiK5%3DrF6_w%3Dpq_T%3DQ%40mail.gmail.com  

M doc/src/sgml/ref/create_procedure.sgml
M src/backend/commands/functioncmds.c
M src/pl/plpgsql/src/expected/plpgsql_transaction.out
M src/pl/plpgsql/src/sql/plpgsql_transaction.sql

Reset shmem_exit_inprogress after shmem_exit()

commit   : 39035a52894a419ae1b905adfdb0bad72ee19a36    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 12 Jul 2018 20:22:17 +0200    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 12 Jul 2018 20:22:17 +0200    

Click here for diff

In ad9a274778d2d88c46b90309212b92ee7fdf9afe, shmem_exit_inprogress was  
introduced.  But we need to reset it after shmem_exit(), because unlike  
the similar proc_exit(), shmem_exit() can also be called for cleanup  
when the process will not exit.  
  
Reported-by: Andrew Gierth <andrew@tao11.riddles.org.uk>  

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

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

commit   : aacdf9a06966d57bb8f6968a41e0690a31d35a51    
  
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

Fix FK checks of TRUNCATE involving partitioned tables

commit   : 727196ced2423008bb25d7775c4e3b7fca063c8b    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 12 Jul 2018 12:09:08 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 12 Jul 2018 12:09:08 -0400    

Click here for diff

When truncating a table that is referenced by foreign keys in  
partitioned tables, the check to ensure the referencing table are also  
truncated spuriously failed.  This is because it was relying on  
relhastriggers as a proxy for the table having FKs, and that's wrong for  
partitioned tables.  Fix it to consider such tables separately.  There  
may be a better way ... but this code is pretty inefficient already.  
  
Author: Álvaro Herrera <alvherre@alvh.no-ip.org>  
Reviewed-by: Michael Paquiër <michael@paquier.xyz>  
Discussion: https://postgr.es/m/20180711000624.zmeizicibxeehhsg@alvherre.pgsql  

M src/backend/catalog/heap.c
M src/backend/commands/tablecmds.c
M src/test/regress/expected/truncate.out
M src/test/regress/sql/truncate.sql

Doc: clarify release note text about v11's new window function features.

commit   : 510421c45fb41869969a708a8c03c12798a724ec    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 12 Jul 2018 11:13:41 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 12 Jul 2018 11:13:41 -0400    

Click here for diff

Jonathan S. Katz  
  
Discussion: https://postgr.es/m/30468663-E67D-4753-8269-7E6A4001A281@excoventures.com  

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

Doc: update documentation for requirement of ORDER BY in GROUPS mode.

commit   : 663060e8c3832ea8388e4ae128420f76680e5fe9    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 12 Jul 2018 11:10:24 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 12 Jul 2018 11:10:24 -0400    

Click here for diff

Commit ff4f88916 adjusted the code to enforce the SQL spec's requirement  
that a window using GROUPS mode must have an ORDER BY clause.  But I missed  
that the documentation explicitly said you didn't have to have one.  
  
Also minor wordsmithing in the window-function section of select.sgml.  
  
Per Masahiko Sawada, though I didn't use his patch.  

M doc/src/sgml/ref/select.sgml
M doc/src/sgml/syntax.sgml

Allow using the updated tuple while moving it to a different partition.

commit   : 0527df732beb8c2d584c7e4ea5aeb05cf92e14a2    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Thu, 12 Jul 2018 12:17:27 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Thu, 12 Jul 2018 12:17:27 +0530    

Click here for diff

An update that causes the tuple to be moved to a different partition was  
missing out on re-constructing the to-be-updated tuple, based on the latest  
tuple in the update chain.  Instead, it's simply deleting the latest tuple  
and inserting a new tuple in the new partition based on the old tuple.  
Commit 2f17844104 didn't consider this case, so some of the updates were  
getting lost.  
  
In passing, change the argument order for output parameter in ExecDelete  
and add some commentary about it.  
  
Reported-by: Pavan Deolasee  
Author: Amit Khandekar, with minor changes by me  
Reviewed-by: Dilip Kumar, Amit Kapila and Alvaro Herrera  
Backpatch-through: 11  
Discussion: https://postgr.es/m/CAJ3gD9fRbEzDqdeDq1jxqZUb47kJn+tQ7=Bcgjc8quqKsDViKQ@mail.gmail.com  

M src/backend/commands/trigger.c
M src/backend/executor/execReplication.c
M src/backend/executor/nodeModifyTable.c
M src/include/commands/trigger.h
A src/test/isolation/expected/partition-key-update-4.out
M src/test/isolation/isolation_schedule
A src/test/isolation/specs/partition-key-update-4.spec

Make logical WAL sender report streaming state appropriately

commit   : 0414ac6a1eb2e457c8019c5a558bd72b37dede89    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 12 Jul 2018 10:19:51 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 12 Jul 2018 10:19:51 +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
M src/test/perl/PostgresNode.pm
M src/test/subscription/t/001_rep_changes.pl

Fix create_scan_plan's handling of sortgrouprefs for physical tlists.

commit   : 5b762d96e8c602434bc7e56f910c23c54e95f80d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 11 Jul 2018 15:25:28 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 11 Jul 2018 15:25:28 -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

Fix bugs with degenerate window ORDER BY clauses in GROUPS/RANGE mode.

commit   : 8893d48e7fbfacb77fee0080faf7b4228c33ce35    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 11 Jul 2018 12:07:21 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 11 Jul 2018 12:07:21 -0400    

Click here for diff

nodeWindowAgg.c failed to cope with the possibility that no ordering  
columns are defined in the window frame for GROUPS mode or RANGE OFFSET  
mode, leading to assertion failures or odd errors, as reported by Masahiko  
Sawada and Lukas Eder.  In RANGE OFFSET mode, an ordering column is really  
required, so add an Assert about that.  In GROUPS mode, the code would  
work, except that the node initialization code wasn't in sync with the  
execution code about when to set up tuplestore read pointers and spare  
slots.  Fix the latter for consistency's sake (even though I think the  
changes described below make the out-of-sync cases unreachable for now).  
  
Per SQL spec, a single ordering column is required for RANGE OFFSET mode,  
and at least one ordering column is required for GROUPS mode.  The parser  
enforced the former but not the latter; add a check for that.  
  
We were able to reach the no-ordering-column cases even with fully spec  
compliant queries, though, because the planner would drop partitioning  
and ordering columns from the generated plan if they were redundant with  
earlier columns according to the redundant-pathkey logic, for instance  
"PARTITION BY x ORDER BY y" in the presence of a "WHERE x=y" qual.  
While in principle that's an optimization that could save some pointless  
comparisons at runtime, it seems unlikely to be meaningful in the real  
world.  I think this behavior was not so much an intentional optimization  
as a side-effect of an ancient decision to construct the plan node's  
ordering-column info by reverse-engineering the PathKeys of the input  
path.  If we give up redundant-column removal then it takes very little  
code to generate the plan node info directly from the WindowClause,  
ensuring that we have the expected number of ordering columns in all  
cases.  (If anyone does complain about this, the planner could perhaps  
be taught to remove redundant columns only when it's safe to do so,  
ie *not* in RANGE OFFSET mode.  But I doubt anyone ever will.)  
  
With these changes, the WindowAggPath.winpathkeys field is not used for  
anything anymore, so remove it.  
  
The test cases added here are not actually very interesting given the  
removal of the redundant-column-removal logic, but they would represent  
important corner cases if anyone ever tries to put that back.  
  
Tom Lane and Masahiko Sawada.  Back-patch to v11 where RANGE OFFSET  
and GROUPS modes were added.  
  
Discussion: https://postgr.es/m/CAD21AoDrWqycq-w_+Bx1cjc+YUhZ11XTj9rfxNiNDojjBx8Fjw@mail.gmail.com  
Discussion: https://postgr.es/m/153086788677.17476.8002640580496698831@wrigleys.postgresql.org  

M src/backend/executor/nodeWindowAgg.c
M src/backend/nodes/outfuncs.c
M src/backend/optimizer/plan/createplan.c
M src/backend/optimizer/plan/planner.c
M src/backend/optimizer/util/pathnode.c
M src/backend/parser/parse_clause.c
M src/include/nodes/relation.h
M src/include/optimizer/pathnode.h
M src/test/regress/expected/window.out
M src/test/regress/sql/window.sql

Block replication slot advance for these not yet reserving WAL

commit   : 9069eb95f48c8200f8589faf7adc5e324eed25cd    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 11 Jul 2018 08:57:18 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 11 Jul 2018 08:57:18 +0900    

Click here for diff

Such replication slots are physical slots freshly created without WAL  
being reserved, which is the default behavior, which have not been used  
yet as WAL consumption resources to retain WAL.  This prevents advancing  
a slot to a position older than any WAL available, which could falsify  
calculations for WAL segment recycling.  
  
This also cleans up a bit the code, as ReplicationSlotRelease() would be  
called on ERROR, and improves error messages.  
  
Reported-by: Kyotaro Horiguchi  
Author: Michael Paquier  
Reviewed-by: Andres Freund, Álvaro Herrera, Kyotaro Horiguchi  
Discussion: https://postgr.es/m/20180626071305.GH31353@paquier.xyz  

M contrib/test_decoding/expected/slot.out
M contrib/test_decoding/sql/slot.sql
M doc/src/sgml/catalogs.sgml
M src/backend/replication/slotfuncs.c

Better handle pseudotypes as partition keys

commit   : e7df94f317c979ad176adc0155a3e8af63e68ac9    
  
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/partitioning/partbounds.c
M src/test/regress/expected/create_table.out
M src/test/regress/expected/partition_prune.out
M src/test/regress/sql/partition_prune.sql

Fix typos

commit   : 4cf30f6fdeed4977dfe52bf1d4fda74c883d3760    
  
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

Fix typo

commit   : 1287c051723261ac197d3cb0d3c753b045908202    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 4 Jul 2018 22:13:16 +0200    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 4 Jul 2018 22:13:16 +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   : cfcfbd39b182c989b59c7b3787e7d528ef9b29ce    
  
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

Flip argument order in XLogSegNoOffsetToRecPtr

commit   : 52b4854a9afd82fa4d7a707f589a5740e854b42a    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 9 Jul 2018 14:28:21 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 9 Jul 2018 14:28:21 -0400    

Click here for diff

Commit fc49e24fa69a added an input argument after the existing output  
argument.  Flip those.  
  
Author: Álvaro Herrera <alvherre@alvh.no-ip.org>  
Reviewed-by: Andres Freund <andres@anarazel.de>  
Discussion: https://postgr.es/m/20180708182345.imdgovmkffgtihhk@alvherre.pgsql  

M src/backend/access/transam/xlog.c
M src/backend/access/transam/xlogreader.c
M src/backend/replication/logical/reorderbuffer.c
M src/bin/pg_basebackup/pg_receivewal.c
M src/bin/pg_resetwal/pg_resetwal.c
M src/bin/pg_rewind/parsexlog.c
M src/bin/pg_waldump/pg_waldump.c
M src/include/access/xlog_internal.h

Fix yet more problems with incorrectly-constructed zero-length arrays.

commit   : 95cce84c16ca9d1477ef9e2d35bb688173142461    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Jul 2018 14:28:04 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Jul 2018 14:28:04 -0400    

Click here for diff

Commit 716ea626a attempted to fix the problem of building 1-D zero-size  
arrays once and for all.  But it turns out that contrib/intarray has some  
code that doesn't use construct_array() but just builds arrays by hand,  
so it didn't get the memo.  This appears to affect all of subarray(),  
intset_subtract(), inner_int_union(), inner_int_inter(), and  
intarray_concat_arrays().  
  
Back-patch into v11.  In the past we've not back-patched this type of  
change, but since v11 is still in beta it seems all right to include  
this fix in it.  Besides it's more consistent to make the fix in v11  
where 716ea626a appeared.  
  
Report and patch by Alexey Kryuchkov, some cosmetic adjustments by me  
  
Report: https://postgr.es/m/153053285112.13258.434620894305716755@wrigleys.postgresql.org  
Discussion: https://postgr.es/m/CAN85JcYphDLYt4CpMDLZjjNVqGDrFJ5eS3YF=wLAhFoDQuBsyg@mail.gmail.com  

M contrib/intarray/_int_tool.c
M contrib/intarray/expected/_int.out
M contrib/intarray/sql/_int.sql

rel notes: mention enabling of parallelism in PG 10

commit   : b4f0d738c3c33752f82398f5e6d0db09e7c862cb    
  
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

Add UtilityReturnsTuples() support for CALL

commit   : 59a85323d9d5927a852939fa93f09d142c72c91a    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 9 Jul 2018 13:58:08 +0200    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 9 Jul 2018 13:58:08 +0200    

Click here for diff

This ensures that prepared statements for CALL can return tuples.  

M src/backend/commands/functioncmds.c
M src/backend/tcop/utility.c
M src/include/commands/defrem.h

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

commit   : 5d7c9347e427cf50ea5d87877fbf89acb235e5a2    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 9 Jul 2018 10:25:40 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 9 Jul 2018 10:25:40 +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 separate error message for procedure does not exist

commit   : e8137295b3fe8a38a579b402512a4442bc992250    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Sat, 7 Jul 2018 11:17:04 +0200    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Sat, 7 Jul 2018 11:17:04 +0200    

Click here for diff

While we probably don't want to split up all error messages into  
function and procedure variants, this one is a very prominent one, so  
it's helpful to be more specific here.  

M src/backend/parser/parse_func.c
M src/test/regress/expected/create_procedure.out

Add note in pg_rewind documentation about read-only files

commit   : 0e4a46670e3a731eae177d8fa961f97b89298922    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sat, 7 Jul 2018 08:10:32 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sat, 7 Jul 2018 08:10:32 +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

Fix assert in nested SQL procedure call

commit   : d89348976c51952293ffe35845c372ffa7e93b47    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 29 Jun 2018 13:28:39 +0200    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 29 Jun 2018 13:28:39 +0200    

Click here for diff

When executing CALL in PL/pgSQL, we need to set a snapshot before  
invoking the to-be-called procedure.  Otherwise, the to-be-called  
procedure might end up running without a snapshot.  For LANGUAGE SQL  
procedures, this would result in an assertion failure.  (For most other  
languages, this is usually not a problem, because those use SPI and SPI  
sets snapshots in most cases.)  Setting the snapshot restores the  
behavior of how CALL worked when it was handled as a generic SQL  
statement in PL/pgSQL (exec_stmt_execsql()).  
  
This change revealed another problem:  In SPI_commit(), we popped the  
active snapshot before committing the transaction, to avoid "snapshot %p  
still active" errors.  However, there is no particular reason why only  
at most one snapshot should be on the stack.  So change this to pop all  
active snapshots instead of only one.  

M src/backend/executor/spi.c
M src/pl/plpgsql/src/expected/plpgsql_transaction.out
M src/pl/plpgsql/src/pl_exec.c
M src/pl/plpgsql/src/sql/plpgsql_transaction.sql

Allow CALL with polymorphic type arguments

commit   : 6f50b1c70fe04dc0b08f58e87dd982d50e0edd22    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 6 Jul 2018 22:27:42 +0200    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 6 Jul 2018 22:27:42 +0200    

Click here for diff

In order to be able to resolve polymorphic types, we need to set fn_expr  
before invoking the procedure.  

M src/backend/commands/functioncmds.c
M src/test/regress/expected/create_procedure.out
M src/test/regress/sql/create_procedure.sql

Allow replication slots to be dropped in single-user mode

commit   : ef64645950163e472729eef3af22bfafc477b040    
  
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

doc: Reword old inheritance partitioning documentation

commit   : 77cb7eaa78cdc9bd63236aca7f16f1af31b17c98    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 6 Jul 2018 15:26:04 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 6 Jul 2018 15:26:04 -0400    

Click here for diff

Prefer to use phrases like "child" instead of "partition" when  
describing the legacy inheritance-based partitioning.  The word  
"partition" now has a fixed meaning for the built-in partitioning, so  
keeping it out of the documentation of the old method makes things  
clearer.  
  
Author: Justin Pryzby <pryzby@telsasoft.com>  
Committer: Peter Eisentraut <peter_e@gmx.net>  
Backpatch of: 0c06534bd63b  

M doc/src/sgml/ddl.sgml

logical decoding: beware of an unset specinsert change

commit   : 05c7426bac43aa3f07c32f40c16a78712d1f0c87    
  
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

doc: Fix typos

commit   : d5176fa1e3c38ee651c9937b33e673db7cd4d9e8    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 5 Jul 2018 22:51:56 +0200    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 5 Jul 2018 22:51:56 +0200    

Click here for diff

Author: Justin Pryzby <pryzby@telsasoft.com>  

M doc/src/sgml/ddl.sgml

Reduce cost of test_decoding's new oldest_xmin test

commit   : aba2184bed64ef3b6f01465df940eb560d5f772d    
  
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

Prevent references to invalid relation pages after fresh promotion

commit   : 9a1bd8271172b0dd353fc946857a8ca29e8b828d    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 5 Jul 2018 10:46:43 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 5 Jul 2018 10:46:43 +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/015_promotion_pages.pl

Use context with correct lifetime in hypothetical_dense_rank_final.

commit   : e60cfcefe635b90bab60e885be689700759a01c6    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Wed, 4 Jul 2018 17:36:01 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Wed, 4 Jul 2018 17:36:01 -0700    

Click here for diff

The query lifetime expression context created in  
hypothetical_dense_rank_final() was buggily allocated in the calling  
memory context. I (Andres) broke that in bf6c614a2f2.  
  
Reported-By: Rajkumar Raghuwanshi  
Author: Amit Langote  
Discussion:  https://postgr.es/m/CAKcux6kmzWmur5HhA_aU6gYVFu0RLQdgJJ+aC9SLdcOvBSrpfA@mail.gmail.com  
Backpatch: 11-  

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

Check for interrupts inside the nbtree page deletion code.

commit   : 0c69db762d886ce2c2b0cb311e24ab76c4740c0b    
  
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   : 9e53171b1057ddb50063a58651aff45f8fc339d7    
  
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

Remove dead code for temporary relations in partition planning

commit   : 5fca035903a2ad2fd143b14eccf5a58af85c189d    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 4 Jul 2018 10:41:44 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 4 Jul 2018 10:41:44 +0900    

Click here for diff

Since recent commit 1c7c317c, temporary relations cannot be mixed with  
permanent relations within the same partition tree, and the same counts  
for temporary relations created by other sessions, which the planner  
simply discarded.  Instead be paranoid and issue an error, as those  
should be blocked at definition time, at least for now.  
  
At the same time, a test case is added to stress what has been moved  
when expand_partitioned_rtentry gets called recursively but bumps on a  
partitioned relation with no partitions which should be handled the same  
way as the non-inheritance case.  This code may be reworked in a close  
future, and covering this code path will limit surprises.  
  
Reported-by: David Rowley  
Author: David Rowley  
Reviewed-by: Amit Langote, Robert Haas, Michael Paquier  
Discussion: https://postgr.es/m/CAKJS1f_HyV1txn_4XSdH5EOhBMYaCwsXyAj6bHXk9gOu4JKsbw@mail.gmail.com  

M src/backend/optimizer/prep/prepunion.c
M src/test/regress/expected/select.out
M src/test/regress/sql/select.sql

Correct comment

commit   : 31658f794370547eb19b233956afe92a07cd6fdd    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 3 Jul 2018 18:33:30 +0200    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 3 Jul 2018 18:33:30 +0200    

Click here for diff

M src/bin/pgbench/t/001_pgbench_with_server.pl

Fix libpq example programs

commit   : 8bfe83628b5135492fc8731a86b84887b2f7c904    
  
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

perltidy run prior to branching

commit   : d8421390996dcd762383a28e57d1f3f16cc5f76f    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Sat, 30 Jun 2018 12:28:55 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Sat, 30 Jun 2018 12:28:55 -0400    

Click here for diff

M src/bin/pg_basebackup/t/010_pg_basebackup.pl
M src/test/ssl/ServerSetup.pm
M src/tools/msvc/MSBuildProject.pm
M src/tools/msvc/Solution.pm
M src/tools/msvc/VCBuildProject.pm
M src/tools/msvc/VSObjectFactory.pm
M src/tools/msvc/builddoc.pl
M src/tools/msvc/dummylib/Win32/Registry.pm
M src/tools/msvc/dummylib/Win32API/File.pm

pgindent run prior to branching

commit   : 1e9c8580904625576871eeb2efec7f04d4c3bc1c    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Sat, 30 Jun 2018 12:25:49 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Sat, 30 Jun 2018 12:25:49 -0400    

Click here for diff

M contrib/postgres_fdw/postgres_fdw.c
M src/backend/access/gin/ginfast.c
M src/backend/access/gin/ginget.c
M src/backend/access/nbtree/nbtree.c
M src/backend/access/nbtree/nbtutils.c
M src/backend/access/transam/xlog.c
M src/backend/access/transam/xlogreader.c
M src/backend/commands/indexcmds.c
M src/backend/executor/execMain.c
M src/backend/replication/logical/reorderbuffer.c
M src/backend/storage/ipc/procarray.c
M src/backend/storage/ipc/standby.c
M src/backend/tcop/utility.c
M src/backend/utils/adt/jsonb.c
M src/bin/pg_dump/pg_dump.h
M src/bin/psql/tab-complete.c
M src/include/access/xlogreader.h
M src/include/replication/reorderbuffer.h

Update typedefs list

commit   : 2c64d200484c40c1bfbd532bf140bea672f267a1    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Sat, 30 Jun 2018 12:07:27 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Sat, 30 Jun 2018 12:07:27 -0400    

Click here for diff

M src/tools/pgindent/typedefs.list

Documentation spell checking and markup improvements

commit   : f7481d2c3c52042030269b91bfeb00f120adb618    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 29 Jun 2018 21:26:41 +0200    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 29 Jun 2018 21:26:41 +0200    

Click here for diff

M doc/src/sgml/config.sgml
M doc/src/sgml/func.sgml
M doc/src/sgml/jit.sgml
M doc/src/sgml/libpq.sgml
M doc/src/sgml/ref/create_statistics.sgml
M doc/src/sgml/ref/pgbench.sgml
M doc/src/sgml/ref/psql-ref.sgml
M doc/src/sgml/release-11.sgml
M doc/src/sgml/user-manag.sgml

doc: Replace non-ASCII lines in psql example output

commit   : 539f32bdd6915e950d225e732959a1b068598993    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 29 Jun 2018 21:23:23 +0200    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 29 Jun 2018 21:23:23 +0200    

Click here for diff

M doc/src/sgml/ddl.sgml

psql: show cloned triggers in partitions

commit   : bc87f22ef6ef1137909ed7363976c67cf1efa7da    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 29 Jun 2018 11:40:36 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 29 Jun 2018 11:40:36 -0400    

Click here for diff

In a partition, row triggers that had been cloned from their parent  
partitioned table would not be listed at all in psql's \d, which could  
surprise users, per insistent complaint from Ashutosh Bapat (though his  
aim was elsewhere).  The simplest possible fix, suggested by Peter  
Eisentraut, seems to be to list triggers marked as internal if they have  
a row in pg_depend that points to some other trigger.  
  
Author: Álvaro Herrera  
Discussion: https://postgr.es/m/20180618165910.p26vhk7dpq65ix54@alvherre.pgsql  

M src/bin/psql/describe.c

Fix crash when ALTER TABLE recreates indexes on partitions

commit   : 41372071dfaab97a1a8dca83e32b88413460f477    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 29 Jun 2018 11:27:57 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 29 Jun 2018 11:27:57 -0400    

Click here for diff

The skip_build flag was not being passed correctly when recursing to  
indexes on partitions, leading to attempts to rebuild indexes when they  
were not yet ready to be rebuilt.  
  
Reported-by: Rajkumar Raghuwanshi  
Discussion: https://postgr.es/m/CAKcux6mxNCGsgATwf5CGMF8g4WSupCXicCVMeKUTuWbyxHOMsQ@mail.gmail.com  

M src/backend/commands/indexcmds.c
M src/test/regress/expected/indexing.out
M src/test/regress/sql/indexing.sql

Replace search.cpan.org with metacpan.org

commit   : dad335b89f2e1d543ef8226b7de4b191246a06dd    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 29 Jun 2018 22:02:20 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 29 Jun 2018 22:02:20 +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 contrib/fuzzystrmatch/dmetaphone.c
M doc/src/sgml/acronyms.sgml
M doc/src/sgml/external-projects.sgml
M doc/src/sgml/install-windows.sgml
M src/test/perl/PostgresNode.pm

Make capitalization of term "OpenSSL" more consistent

commit   : dad5f8a3d51c8b12bfa0d2c635639fff9fad5155    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 29 Jun 2018 09:45:44 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 29 Jun 2018 09:45:44 +0900    

Click here for diff

This includes code comments and documentation.  No backpatch as this is  
cosmetic even if there are documentation changes which are user-facing.  
  
Author: Daniel Gustafsson  
Discussion: https://postgr.es/m/BB89928E-2BC7-489E-A5E4-6D204B3954CF@yesql.se  

M contrib/pgcrypto/openssl.c
M doc/src/sgml/install-windows.sgml
M doc/src/sgml/release-8.2.sgml
M doc/src/sgml/release-8.3.sgml
M doc/src/sgml/release-8.4.sgml
M doc/src/sgml/release-9.2.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
M src/backend/libpq/be-secure-openssl.c
M src/interfaces/libpq/fe-secure-openssl.c
M src/test/ssl/Makefile

Fix typo in comment

commit   : f5545287dc5f565b091f2312684d14fda0705a9a    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 27 Jun 2018 15:40:24 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 27 Jun 2018 15:40:24 -0400    

Click here for diff

Author: Amit Langote  
Discussion: https://postgr.es/m/b23dc88b-df41-ef07-22c5-12f77cf73b57@lab.ntt.co.jp  

M src/include/nodes/relation.h

Fix thinko in comments.

commit   : 2e61c50785a0dca6ed30a1a5522457b18bbb5498    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Wed, 27 Jun 2018 18:05:24 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Wed, 27 Jun 2018 18:05:24 +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

Change pqformat.h's integer handling functions to take unsigned integers.

commit   : 42121790ca9b27e01fd0471fdac28ec4a381eaee    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Tue, 26 Jun 2018 23:40:32 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Tue, 26 Jun 2018 23:40:32 -0700    

Click here for diff

As added in 1de09ad8eb1fa673ee7899d6dfbb2b49ba204818 the new functions  
all accept signed integers as parameters. That's not great, because  
it's perfectly reasonable to call them with unsigned parameters.  
Unfortunately unsigned to signed conversion is not well defined, when  
exceeding the range of the signed value.  That's presently not a  
practical issue in postgres (among other reasons because we force  
gcc's hand with -fwrapv).  But it's clearly not quite right.  
  
Thus change the signatures to accept unsigned integers instead, signed  
to unsigned conversion is always well defined. Also change the  
backward compat pq_sendint() - while it's deprecated it seems better  
to be consistent.  
  
Per discussion between Andrew Gierth, Michael Paquier, Alvaro Herrera  
and Tom Lane.  
  
Reported-By: Andrew Gierth  
Author: Andres Freund  
Discussion: https://postgr.es/m/87r2m10zm2.fsf@news-spur.riddles.org.uk  

M src/include/libpq/pqformat.h

Remove duplicated return statement from llvmjit code.

commit   : 986070872ffaae5d9d0e39eddcc952bc261982a2    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Tue, 26 Jun 2018 23:16:50 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Tue, 26 Jun 2018 23:16:50 -0700    

Click here for diff

The duplicated return clearly doesn't make sense / isn't  
reachable. Likely introduced by me (Andres), while revising the code.  
  
Author: Rushabh Lathia  
Discussion: https://postgr.es/m/CAGPqQf2raxWOcbuTP36M1rEF3=Rfo7oD29K3psdyHMeE5swBRg@mail.gmail.com  

M src/backend/jit/llvm/llvmjit.c

Fix whitespace

commit   : 0fcf5e0e6e7a353f862504da0a321f148ad2de03    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 27 Jun 2018 08:03:54 +0200    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 27 Jun 2018 08:03:54 +0200    

Click here for diff

M src/test/perl/TestLib.pm
M src/tools/perlcheck/find_perl_files
M src/tools/perlcheck/perlcriticrc

doc: Improve wording and fix whitespace

commit   : ae5ed75ed4a951c58ec6a76362241b6ac32be61c    
  
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

doc: Document some nuances of logical replication of TRUNCATE

commit   : c9d6a45724d642a00bd2b4c0f082cf4e1eb76e29    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 27 Jun 2018 07:40:18 +0200    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 27 Jun 2018 07:40:18 +0200    

Click here for diff

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

Cosmetic improvements for faster column addition.

commit   : 8121ab88e7dfe6ebe56c58257733354cb85f092c    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Wed, 27 Jun 2018 08:16:13 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Wed, 27 Jun 2018 08:16:13 +0530    

Click here for diff

Changed the name of few structure members for the sake of clarity and  
removed spurious whitespace.  
  
Reported-by: Amit Kapila  
Author: Amit Kapila, based on suggestion by Andrew Dunstan  
Reviewed-by: Alvaro Herrera  
Discussion: https://postgr.es/m/CAA4eK1K2znsFpC+NQ9A4vxT4uDxADN4RmvHX0L6Y=aHVo9gB4Q@mail.gmail.com  

M src/backend/access/common/heaptuple.c
M src/backend/access/common/tupdesc.c
M src/backend/utils/cache/relcache.c
M src/include/access/tupdesc_details.h

Fix "base" snapshot handling in logical decoding

commit   : f49a80c481f74fa81407dce8e51dea6956cb64f8    
  
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

Fix upper limit for vacuum_cleanup_index_scale_factor

commit   : 4d54543efa5eb074ead4d0fadb2af4161c943044    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Tue, 26 Jun 2018 21:55:59 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Tue, 26 Jun 2018 21:55:59 +0300    

Click here for diff

6ca33a88 sets upper limit for vacuum_cleanup_index_scale_factor to  
DBL_MAX.  DBL_MAX appears to be platform-dependent. That causes  
many buildfarm animals to fail, because we check boundaries of  
vacuum_cleanup_index_scale_factor in regression tests.  
  
This commit changes upper limit from DBL_MAX to just "large enough"  
limit, which was arbitrary selected as 1e10.  
  
Author: Alexander Korotkov  
Reported-by: Tom Lane, Darafei Praliaskouski  
Discussion: https://postgr.es/m/CAPpHfdvewmr4PcpRjrkstoNn1n2_6dL-iHRB21CCfZ0efZdBTg%40mail.gmail.com  
Discussion: https://postgr.es/m/CAC8Q8tLYFOpKNaPS_E7V8KtPdE%3D_TnAn16t%3DA3LuL%3DXjfOO-BQ%40mail.gmail.com  

M doc/src/sgml/config.sgml
M src/backend/access/common/reloptions.c
M src/backend/utils/misc/guc.c
M src/test/regress/expected/btree_index.out

|--- gitweb/email subject limit -----------------|-------------|

commit   : a89357e2f7839f5bc0815f4cf9e565cd3ad7a185    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 26 Jun 2018 14:31:57 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 26 Jun 2018 14:31:57 -0400    

Click here for diff

doc:  PG 11 relnotes: remove channel binding from major features  
  
Also move to the source code section, and expand the paragraph  

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

Correct a comment on logtape.c's leader tape.

commit   : aefb0a382c10877867d831afe8a292aa355c5a68    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Tue, 26 Jun 2018 11:16:20 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Tue, 26 Jun 2018 11:16:20 -0700    

Click here for diff

randomAccess parallel tuplesorts are disallowed because the leader would  
try to write to its own leader tape, not because the leader would try to  
write to a worker tape directly.  
  
Cleanup from commit 9da0cc35284.  

M src/backend/utils/sort/logtape.c

Remove obsolete comment block in nbtsort.c.

commit   : cdc2693a11b341043f33e1efc36debe0348fb361    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Tue, 26 Jun 2018 10:08:44 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Tue, 26 Jun 2018 10:08:44 -0700    

Click here for diff

Building a new nbtree index through incremental insertions would always  
be slower than our actual approach of sorting using tuplesort,  
assembling leaf pages from tuplesort output, and writing and WAL-logging  
whole pages.  Remove a comment block from the Berkeley days claiming  
that incremental insertions might be slightly faster with presorted  
input.  
  
Discussion: https://postgr.es/m/CAH2-WzmKs4mLAoFgJ3yHMRYc849efc=dw+pNRb3NEog2oJoCNw@mail.gmail.com  

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

Enable failure to rename a partitioned index

commit   : 040da42367a5de448ddecf6ee7c09f73580a6b28    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 26 Jun 2018 11:28:41 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 26 Jun 2018 11:28:41 -0400    

Click here for diff

Concurrently with partitioned index development (commit 8b08f7d4820f),  
the code to handle failure to rename indexes was refactored (commit  
8b9e9644dc6a).  Turns out that that particular case was untested, which  
naturally led it to be broken.  Add tests and the missing code line.  
  
Co-authored-by: David Rowley <dgrowley@gmail.com>  
Co-authored-by: Álvaro Herrera <alvherre@alvh.no-ip.org>  
Reported-by: Rajkumar Raghuwanshi <rajkumar.raghuwanshi@enterprisedb.com>  
Discussion: https://postgr.es/m/CAKcux6mfYMS3OX0ywjOiWiGSEKhJf-1zdeTceHFbd0mScUzU5A@mail.gmail.com  

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

commit   : bbbbc2f8f3f7d628c74317959a2cfe71fea05575    
  
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

Allow direct lookups of AppendRelInfo by child relid

commit   : 7d872c91a3f9d49b56117557cdbb0c3d4c620687    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 26 Jun 2018 10:35:26 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 26 Jun 2018 10:35:26 -0400    

Click here for diff

find_appinfos_by_relids had quite a large overhead when the number of  
items in the append_rel_list was high, as it had to trawl through the  
append_rel_list looking for AppendRelInfos belonging to the given  
childrelids.  Since there can only be a single AppendRelInfo for each  
child rel, it seems much better to store an array in PlannerInfo which  
indexes these by child relid, making the function O(1) rather than O(N).  
This function was only called once inside the planner, so just replace  
that call with a lookup to the new array.  find_childrel_appendrelinfo  
is now unused and thus removed.  
  
This fixes a planner performance regression new to v11 reported by  
Thomas Reiss.  
  
Author: David Rowley  
Reported-by: Thomas Reiss  
Reviewed-by: Ashutosh Bapat  
Reviewed-by: Álvaro Herrera  
Discussion: https://postgr.es/m/94dd7a4b-5e50-0712-911d-2278e055c622@dalibo.com  

M src/backend/optimizer/plan/planmain.c
M src/backend/optimizer/plan/planner.c
M src/backend/optimizer/prep/prepunion.c
M src/backend/optimizer/util/relnode.c
M src/include/nodes/relation.h
M src/include/optimizer/pathnode.h

Increase upper limit for vacuum_cleanup_index_scale_factor

commit   : 6ca33a885bf892a7fa34020a2620c83ccec3cdd7    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Tue, 26 Jun 2018 15:00:51 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Tue, 26 Jun 2018 15:00:51 +0300    

Click here for diff

Upper limits for vacuum_cleanup_index_scale_factor GUC and reloption  
were initially set to 100.0 in 857f9c36.  However, after further  
discussion, it appears that some users like to disable B-tree cleanup  
index scan completely (assuming there are no deleted pages).  
  
vacuum_cleanup_index_scale_factor is used barely to protect against  
stalled index statistics.  And after detailed consideration it appears  
that risk of stalled index statistics is low.  And it would be nice to  
allow advanced users setting higher values of  
vacuum_cleanup_index_scale_factor.  So, set upper limit for these  
GUC and reloption to DBL_MAX.  
  
Author: Alexander Korotkov  
Reviewed-by: Masahiko Sawada  
Discussion: https://postgr.es/m/CAC8Q8tJCb%3DgxhzcV7T6ctx7PY-Ux1oA-AsTJc6cAVNsQiYcCzA%40mail.gmail.com  

M doc/src/sgml/config.sgml
M src/backend/access/common/reloptions.c
M src/backend/access/nbtree/nbtree.c
M src/backend/utils/misc/guc.c
M src/test/regress/expected/btree_index.out

Reword SPI_ERROR_TRANSACTION errors in PL/pgSQL

commit   : c9301deb9bf86aaf9144a66026bc121a3eededee    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 26 Jun 2018 11:38:46 +0200    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 26 Jun 2018 11:38:46 +0200    

Click here for diff

The previous message for SPI_ERROR_TRANSACTION claimed "cannot begin/end  
transactions in PL/pgSQL", but that is no longer true.  Nevertheless,  
the error can still happen, so reword the messages.  The error cases in  
exec_prepare_plan() could never happen, so remove them.  

M src/pl/plpgsql/src/expected/plpgsql_transaction.out
M src/pl/plpgsql/src/pl_exec.c
M src/pl/plpgsql/src/sql/plpgsql_transaction.sql

Move RecoveryLockList into a hash table.

commit   : a40cff8956e842f737739d93a7b160f0b4a03d13    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Tue, 26 Jun 2018 17:16:34 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Tue, 26 Jun 2018 17:16:34 +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

commit   : c672d709b089f919381a2c36eea32a29d8de4198    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 26 Jun 2018 14:57:53 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 26 Jun 2018 14:57:53 +0900    

Click here for diff

These descriptions have been referring to object dump, but a restore  
operation is done.  
  
Reported-by: Andrey Lizenko  
Author: Andrey Lizenko  
Discussion: https://postgr.es/m/152992021588.1268.16786093506650391435@wrigleys.postgresql.org  

M doc/src/sgml/ref/pg_restore.sgml
M src/bin/pg_dump/pg_restore.c

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

commit   : d08c3d5197fac1f49cedbd8417e685479ad7439a    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 26 Jun 2018 09:41:58 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 26 Jun 2018 09:41:58 +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   : 322548a8abe225f2cfd6a48e07b99e2711d28ef7    
  
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

Stamp 11beta2.

commit   : 1d4e5edc1dc22f00a0abb00ed9b56c08c4a1f599    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 25 Jun 2018 11:09:49 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 25 Jun 2018 11:09:49 -0400    

Click here for diff

M configure
M configure.in
M doc/bug.template
M src/include/pg_config.h.win32

Translation updates

commit   : 299addd592ccf36d495319bda0f14049548ee130    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 25 Jun 2018 12:37:18 +0200    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 25 Jun 2018 12:37:18 +0200    

Click here for diff

Source-Git-URL: https://git.postgresql.org/git/pgtranslation/messages.git  
Source-Git-Hash: 884f33d735870f94357820800840af3e93ff4628  

M src/backend/nls.mk
M src/backend/po/fr.po
M src/backend/po/it.po
A src/backend/po/sv.po
M src/bin/pg_basebackup/po/de.po
M src/bin/pg_basebackup/po/it.po
M src/bin/pg_basebackup/po/sv.po
M src/bin/pg_controldata/po/de.po
M src/bin/pg_controldata/po/sv.po
M src/bin/psql/po/sv.po
M src/interfaces/ecpg/preproc/po/pt_BR.po
M src/interfaces/libpq/po/de.po

Address set of issues with errno handling

commit   : 6cb3372411fd6ed8ba0f8d36ae578a2daa517c16    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 25 Jun 2018 11:19:05 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 25 Jun 2018 11:19:05 +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   : 370e68ae1c0a8504a10b211a9c1d9e0ffa101259    
  
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   : b6e94b820a21146b898232bc3e3920b31198e637    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Sat, 23 Jun 2018 23:32:42 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Sat, 23 Jun 2018 23:32:42 -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

doc: update PG 11 release notes, mostly typo fixes

commit   : 2d502b81289f679a8244a0b6c94a4d294968bde1    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Sat, 23 Jun 2018 17:15:34 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Sat, 23 Jun 2018 17:15:34 -0400    

Click here for diff

Discussion: https://postgr.es/m/CAJnrtny0mYCMoRanZ1wvGqcPV-UDBoPetavDM1SqxnGVfZRV3g@mail.gmail.com  
  
Author: Brad DeJong  

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

doc: mention use of cross platform logical replication

commit   : 21c1f0c607f0344ae8f71ecaae1fe6f58cf7ff9a    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Sat, 23 Jun 2018 16:35:25 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Sat, 23 Jun 2018 16:35:25 -0400    

Click here for diff

Discussion: https://postgr.es/m/CAJrrPGfdknoqZcMipPy8XnH3hO3uRic6JTD=jv35oj1DWqL07g@mail.gmail.com  
  
Author: Haribabu Kommi  

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

Mark binary_upgrade_set_missing_value as parallel_unsafe

commit   : 123efbccea694626b36ad952086d883fa7469aa9    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Sat, 23 Jun 2018 08:43:05 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Sat, 23 Jun 2018 08:43:05 -0400    

Click here for diff

per buildfarm.  
  
Bump catalog version again although in practice nobody is going to use  
this in a parallel query.  

M src/include/catalog/catversion.h
M src/include/catalog/pg_proc.dat

When index recurses to a partition, map columns numbers

commit   : 475be5e790e2db4c5c18a2d378c4498ffccb6289    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 22 Jun 2018 15:12:53 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 22 Jun 2018 15:12:53 -0400    

Click here for diff

Two out of three code paths were mapping column numbers correctly if a  
partition had different column numbers than parent table, but the most  
commonly used one (recursing in CREATE INDEX to a new index on a  
partition) failed to map attribute numbers in expressions.  Oddly  
enough, attnums in WHERE clauses are already handled correctly  
everywhere.  
  
Reported-by: Amit Langote  
Author: Amit Langote  
Discussion: https://postgr.es/m/dce1fda4-e0f0-94c9-6abb-f5956a98c057@lab.ntt.co.jp  
Reviewed-by: Álvaro Herrera  

M src/backend/commands/indexcmds.c
M src/test/regress/expected/indexing.out
M src/test/regress/sql/indexing.sql

Avoid generating bogus paths with partitionwise aggregate.

commit   : c6f28af5d7af87d7370e5f169251d91437f100a2    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 22 Jun 2018 09:14:34 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 22 Jun 2018 09:14:34 -0400    

Click here for diff

Previously, if some or all partitions had no partially aggregated path,  
we would still try to generate a partially aggregated path for the  
parent, leading to assertion failures or wrong answers.  
  
Report by Rajkumar Raghuwanshi.  Patch by Jeevan Chalke, reviewed  
by Ashutosh Bapat.  A few changes by me.  
  
Discussion: http://postgr.es/m/CAKcux6=q4+Mw8gOOX16ef6ZMFp9Cve7KWFstUsrDa4GiFaXGUQ@mail.gmail.com  

M src/backend/optimizer/plan/planner.c
M src/test/regress/expected/partition_aggregate.out
M src/test/regress/sql/partition_aggregate.sql

Allow for pg_upgrade of attributes with missing values

commit   : 2448adf29c543befbac59f1ecfbb3ef4b0d808ce    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 22 Jun 2018 08:42:36 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 22 Jun 2018 08:42:36 -0400    

Click here for diff

Commit 16828d5c02 neglected to do this, so upgraded databases would  
silently get null instead of the specified default in rows without the  
attribute defined.  
  
A new binary upgrade function is provided to perform this and pg_dump is  
adjusted to output a call to the function if required in binary upgrade  
mode.  
  
Also included is code to drop missing attribute values for dropped  
columns. That way if the type is later dropped the missing value won't  
have a dangling reference to the type.  
  
Finally the regression tests are adjusted to ensure that there is a row  
with a missing value so that this code is exercised in upgrade testing.  
  
Catalog version unfortunately bumped.  
  
Regression test changes from Tom Lane.  
Remainder from me, reviewed by Tom Lane, Andres Freund, Alvaro Herrera  
  
Discussion: https://postgr.es/m/19987.1529420110@sss.pgh.pa.us  

M src/backend/catalog/heap.c
M src/backend/utils/adt/pg_upgrade_support.c
M src/bin/pg_dump/pg_dump.c
M src/bin/pg_dump/pg_dump.h
M src/include/catalog/catversion.h
M src/include/catalog/heap.h
M src/include/catalog/pg_proc.dat
M src/test/regress/expected/fast_default.out
M src/test/regress/sql/fast_default.sql

Fixes for vacuum_cleanup_index_scale_factor GUC option

commit   : 9a994e37e08df3578f52011543dc28085dc18e21    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Fri, 22 Jun 2018 12:17:56 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Fri, 22 Jun 2018 12:17:56 +0300    

Click here for diff

vacuum_cleanup_index_scale_factor was located in autovacuum group of  
GUCs.  However, it affects not only autovacuum, but also manually run  
VACUUM.  It appears that "client connection defaults" group of GUCs  
is more appropriate for vacuum_cleanup_index_scale_factor, because  
vacuum_*_age options are already located there.  
  
Also, vacuum_cleanup_index_scale_factor was missed in  
postgresql.conf.sample.  So, add it there with appropriate comment.  
  
Author: Masahiko Sawada with minor editorization by me  
Discussion: https://postgr.es/m/CAD21AoArsoXMLKudXSKN679FRzs6oubEchM53bHwn8Tp%3D2boNg%40mail.gmail.com  

M doc/src/sgml/config.sgml
M src/backend/utils/misc/guc.c
M src/backend/utils/misc/postgresql.conf.sample

Fix typo in comment of commit_ts.c for incorrect reference to CLOG

commit   : 0aa5e65ab4fd2695f0e4108b9ec53a0546261e1f    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 22 Jun 2018 13:30:26 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 22 Jun 2018 13:30:26 +0900    

Click here for diff

Author: Shao Bret  

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

Improve coding pattern in Parallel Append code.

commit   : 98d476a965eefb52af53f4fb55dbfead0ede9282    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Fri, 22 Jun 2018 08:43:36 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Fri, 22 Jun 2018 08:43:36 +0530    

Click here for diff

The create_append_path code didn't consider that list_concat will  
modify it's first argument leading to inconsistent traversal of  
resulting list.  In practice, it won't lead to any user-visible bug  
but changing it for making the code behave consistently.  
  
Reported-by: Tom Lane  
Author: Tom Lane  
Reviewed-by: Amit Khandekar and Amit Kapila  
Discussion: https://postgr.es/m/32365.1528994120@sss.pgh.pa.us  

M src/backend/optimizer/util/pathnode.c

Disclaim support for default namespace in XMLTABLE

commit   : c7048977a73b4ab3b38b9a28bc58e600b598c176    
  
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   : ec4719cd155d1d58c8aa7c06c7ef24aef6e67622    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 21 Jun 2018 16:18:33 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 21 Jun 2018 16:18:33 -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

Set correct context for XPath evaluation

commit   : e474c2b7e4b656895d6afcbd36857c9ebb0fcedd    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 21 Jun 2018 15:56:11 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 21 Jun 2018 15:56:11 -0400    

Click here for diff

According to the SQL standard, the context of XMLTABLE's XPath  
row_expression is the document node of the XML input document, not the  
root node.  This becomes visible when a relative path rather than  
absolute is used as row expression.  Absolute paths is what was used in  
original tests and docs (and the most common form used in examples  
throughout the interwebs), which explains why this wasn't noticed  
before.  
  
Other functions such as xpath() and xpath_exists() also have this  
problem.  While not specified by the SQL standard, it would be pretty  
odd to leave those functions to behave differently than XMLTABLE, so  
change them too.  However, this is a backwards-incompatible change.  
  
No backpatch, out of fear of breaking code depending on the original  
broken behavior.  
  
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_1.out
M src/test/regress/expected/xml_2.out
M src/test/regress/sql/xml.sql

Improve requirements documentation for ldap test suite.

commit   : 425b4c082c82672c646ed8bc9e140b4112899fe4    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 21 Jun 2018 12:37:21 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 21 Jun 2018 12:37:21 -0400    

Click here for diff

Text by me; data contributed by me, Thomas Munro, Michael Paquier.  
  
Discussion: https://postgr.es/m/20180521013425.GA4476@paquier.xyz  

M src/test/ldap/README

Fix mishandling of sortgroupref labels while splitting SRF targetlists.

commit   : 07e5a213524853c06684155d4af5a0291d95d25a    
  
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

Improve wording of release notes item

commit   : bee6a683a5c35ddcdb8253771450c6cf641f3d60    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Thu, 21 Jun 2018 15:49:19 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Thu, 21 Jun 2018 15:49:19 +0300    

Click here for diff

PostgreSQL 11 introduces compress method for SP-GiST opclasses.  That  
was mistakenly interpreted as compression support for SP-GiST while  
actually that allows lossy representation of leaf keys.  
  
Author: Alexander Korotkov, based on proposal by Darafei Praliaskouski  
Discussion: https://postgr.es/m/CAC8Q8tKbYmNdiyWr7hE4GfMY4fbqHKkFziKgrUuWHH6HJQs3og%40mail.gmail.com  

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

Update expected XML output with disabled XML

commit   : 9cd929d36079e30cd43a85dd23e771d25c5f7b14    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 20 Jun 2018 13:05:44 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 20 Jun 2018 13:05:44 -0400    

Click here for diff

Should have been done in previous commit.  

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

Accept TEXT and CDATA nodes in XMLTABLE's column_expression.

commit   : b7f0be9a7e7ec1eb7b9780b169366495f24bf975    
  
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

Add missing include

commit   : 3adcad45588bff17b1253f60cf51c440e87df997    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Wed, 20 Jun 2018 18:19:16 +0200    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Wed, 20 Jun 2018 18:19:16 +0200    

Click here for diff

Per buildfarm  

M src/bin/pg_verify_checksums/pg_verify_checksums.c

Consistently use the term 'partitioned rel' in partprune comments

commit   : 8f97af60d19a46b37fe998be38df4e6dd0760e45    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 20 Jun 2018 11:43:01 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 20 Jun 2018 11:43:01 -0400    

Click here for diff

We were using 'partition rel' in a few places, which is quite confusing.  
  
Author: Amit Langote  
Reviewed-by: David Rowley  
Reviewed-by: Michaël Paquier  
Discussion: https://postgr.es/m/fd256561-31a2-4b7e-cd84-d8241e7ebc3f@lab.ntt.co.jp  

M src/backend/partitioning/partprune.c
M src/include/partitioning/partprune.h

Fix typo

commit   : 74cfbc8efd3f2f34d05e5c28a0299c2a7bc9c56d    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Wed, 20 Jun 2018 16:06:03 +0200    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Wed, 20 Jun 2018 16:06:03 +0200    

Click here for diff

Reported using the website comment form  

M doc/src/sgml/dml.sgml

Fix a number of typos

commit   : d9443d9608a872b1aa8697fa6f40a41573a35f9d    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Wed, 20 Jun 2018 16:01:18 +0200    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Wed, 20 Jun 2018 16:01:18 +0200    

Click here for diff

Author: Liudmila Mantrova <l.mantrova@postgrespro.ru>  

M doc/src/sgml/cube.sgml
M doc/src/sgml/pgtrgm.sgml
M doc/src/sgml/ref/pgbench.sgml
M doc/src/sgml/release-11.sgml

Support long option for --pgdata in pg_verify_checksums

commit   : 741ee9dc819dd90270e66ab9bc254eeb7fda7100    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Wed, 20 Jun 2018 14:33:48 +0200    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Wed, 20 Jun 2018 14:33:48 +0200    

Click here for diff

Author: Daniel Gustafsson <daniel@yesql.se>  

M doc/src/sgml/ref/pg_verify_checksums.sgml
M src/bin/pg_verify_checksums/pg_verify_checksums.c

Document the -D and $PGDATA switch/env for pg_verify_checksums

commit   : d73300a28683fb1723ecda1a3fa767dbe8be6502    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Wed, 20 Jun 2018 14:32:51 +0200    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Wed, 20 Jun 2018 14:32:51 +0200    

Click here for diff

Author: Daniel Gustafsson <daniel@yesql.se>  

M doc/src/sgml/ref/pg_verify_checksums.sgml

Move pg_verify_checksum docs to Server utils

commit   : b92ef305c3eebc379af7af52ff03f75c67d39e8f    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Wed, 20 Jun 2018 14:28:56 +0200    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Wed, 20 Jun 2018 14:28:56 +0200    

Click here for diff

Author: Daniel Gustafsson <daniel@yesql.se>  

M doc/src/sgml/reference.sgml

Don't consider parallel append for parallel unsafe paths.

commit   : 403318b71f7058ecbfb65bcc7de1eec96cd35d3f    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Wed, 20 Jun 2018 07:51:42 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Wed, 20 Jun 2018 07:51:42 +0530    

Click here for diff

Commit ab72716778 allowed Parallel Append paths to be generated for a  
relation that is not parallel safe.  Prevent that from happening.  
  
Initial analysis by Tom Lane.  
  
Reported-by: Rajkumar Raghuwanshi  
Author: Amit Kapila and Rajkumar Raghuwanshi  
Reviewed-by: Amit Khandekar and Robert Haas  
Discussion:https://postgr.es/m/CAKcux6=tPJ6nJ08r__nU_pmLQiC0xY15Fn0HvG1Cprsjdd9s_Q@mail.gmail.com  

M src/backend/optimizer/path/allpaths.c
M src/test/regress/expected/select_parallel.out
M src/test/regress/sql/select_parallel.sql

Clarify use of temporary tables within partition trees

commit   : 1c7c317cd9d1e5647454deed11b55dae764c83bf    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 20 Jun 2018 10:42:25 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 20 Jun 2018 10:42:25 +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/expected/partition_prune.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
M src/test/regress/sql/partition_prune.sql

Clarify the README files for the various separate TAP-based test suites.

commit   : c992dca26e2b7d02ec7d43f2b71ff23d77e39f27    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 19 Jun 2018 19:30:50 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 19 Jun 2018 19:30:50 -0400    

Click here for diff

Explain the difference between "make check" and "make installcheck".  
Mention the need for --enable-tap-tests (only some of these did so  
before).  Standardize their wording about how to run the tests.  

M src/test/authentication/README
M src/test/kerberos/README
M src/test/ldap/README
M src/test/recovery/README
M src/test/ssl/README
M src/test/subscription/README

README: add URLs for openldap installation

commit   : 9bab9cb36ad9186c9898703106b545d6dbb2aa24    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 19 Jun 2018 15:52:17 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 19 Jun 2018 15:52:17 -0400    

Click here for diff

Reported-by: Michael Paquier  
  
Discussion: https://postgr.es/m/20180521013425.GA4476@paquier.xyz  
  
Backpatch-through: head  

M src/test/ldap/README

doc: explain use of json_populate_record{set}()

commit   : 87a19eb9bf373f51e966ab496cce6bf3ee9cd909    
  
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 typos in release notes

commit   : fb6accd27b99f5f91a7e9e5bd32b98a53fc6d6b8    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Tue, 19 Jun 2018 18:32:20 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Tue, 19 Jun 2018 18:32:20 +0300    

Click here for diff

Author: Daniel Gustafsson  
Discussion: https://postgr.es/m/8E8CF1F8-BCB2-4D86-A059-4BF5138F6D87%40yesql.se  

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

Track new configure flags introduced for version 11 in pg_config.h.win32

commit   : bde64eb6107622e8438dd61b93afd4d1adf178b3    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 19 Jun 2018 09:00:33 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 19 Jun 2018 09:00:33 +0900    

Click here for diff

The following set of flags mainly matter when building Postgres code  
with MSVC and those have been forgotten with latest developments:  
- HAVE_LDAP_INITIALIZE, added by 35c0754f, and marked as disabled.  
ldap_initialize() is a non-standard extension that provides a way to use  
"ldaps" with OpenLDAP, but it is not supported on Windows, and instead  
the non-standard ldap_sslinit() is used if WIN32 is defined.  Per input  
from Thomas Munro.  
- HAVE_X509_GET_SIGNATURE_NID, added by 054e8c6c, which is used by  
SCRAM's channel binding tls-server-end-point.  Having this flag disabled  
would cause this channel binding type to be unsupported for Windows  
builds.  
- HAVE_SSL_CLEAR_OPTIONS, added recently as of a364dfa4 to disable SSL  
compression.  
- HAVE_ASN1_STRING_GET0_DATA, added by 5c6df67, which is used to track  
a new compatibility with OpenSSL 1.1.0.  This was missing from  
pg_config.win32.h and is not enabled by default.  HAVE_BIO_GET_DATA,  
HAVE_OPENSSL_INIT_SSL and HAVE_BIO_METH_NEW gain the same treatment.  
  
The second and third flags are enabled with this commit, which raises  
the bar of OpenSSL support to 1.0.2 on Windows as a minimum.  As this  
is the LTS (long-time support) version of OpenSSL community and knowing  
that all recent installers referred by OpenSSL upstream don't have  
anymore 1.0.1 or older, we could live with that requirement.  In order  
to allow the code to compile with OpenSSL 1.1.0, all the flags mentioned  
above need to be enabled in pg_config.h.win32.  
  
Author: Michael Paquier  
Reviewed-by: Andrew Dunstan  
Discussion: https://postgr.es/m/20180529211559.GF6632@paquier.xyz  

M src/include/pg_config.h.win32

Fix jsonb_plperl to convert Perl UV values correctly.

commit   : 93b6e03ab4794272986a11a427c6c391eafa5dea    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 18 Jun 2018 17:39:57 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 18 Jun 2018 17:39:57 -0400    

Click here for diff

Values greater than IV_MAX were incorrectly converted to SQL,  
for instance ~0 would become -1 rather than 18446744073709551615  
(on a 64-bit machine).  
  
Dagfinn Ilmari Mannsåker, adjusted a bit by me  
  
Discussion: https://postgr.es/m/d8jtvskjzzs.fsf@dalvik.ping.uio.no  

M contrib/jsonb_plperl/expected/jsonb_plperl.out
M contrib/jsonb_plperl/expected/jsonb_plperlu.out
M contrib/jsonb_plperl/jsonb_plperl.c
M contrib/jsonb_plperl/sql/jsonb_plperl.sql
M contrib/jsonb_plperl/sql/jsonb_plperlu.sql

Fix contrib/hstore_plperl to look through scalar refs.

commit   : e3b7f7cc50630dac958a48b533cce04e4222892b    
  
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

Allow plperl_sv_to_datum to look through scalar refs.

commit   : 3a382983d142ca270fe49c63fa6d4a95037ebee3    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 18 Jun 2018 15:31:57 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 18 Jun 2018 15:31:57 -0400    

Click here for diff

There seems little reason for the policy of throwing error if we  
find a ref to something other than a hash or array.   Recursively  
look through the ref, instead.  This makes the behavior in non-transform  
cases comparable to what was already instantiated for jsonb_plperl.  
  
Note that because we invoke any available transform function before  
considering the ref case, it's up to each transform function whether  
it wants to play along with this behavior or do something different.  
  
Because the previous behavior was just to throw a useless error,  
this seems unlikely to create any compatibility issues.  Still, given  
the lack of field complaints so far, seems best not to back-patch.  
  
Discussion: https://postgr.es/m/28336.1528393969@sss.pgh.pa.us  

M src/pl/plperl/expected/plperl.out
M src/pl/plperl/plperl.c
M src/pl/plperl/sql/plperl.sql

Avoid platform-dependent output from Data::Dumper.

commit   : e4300a3552b104f54ec781dd23cfcf96252ec5c1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 18 Jun 2018 14:53:21 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 18 Jun 2018 14:53:21 -0400    

Click here for diff

Per buildfarm, the output from Data::Dumper for an IEEE infinity  
is platform-dependent (e.g. "inf" vs "Inf").  Just skip that one  
test case in the plperlu test; testing it on the plperl side is  
coverage enough.  Fixes issue in commit 1731e3741.  

M contrib/jsonb_plperl/expected/jsonb_plperlu.out
M contrib/jsonb_plperl/sql/jsonb_plperlu.sql

Fix excessive enreferencing in jsonb-to-plperl transform.

commit   : 1731e3741cbbf8e0b4481665d7d523bc55117f63    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 18 Jun 2018 14:31:42 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 18 Jun 2018 14:31:42 -0400    

Click here for diff

We want, say, 2 to be transformed as 2, not \\2 which is what the  
original coding produced.  Perl's standard seems to be to add an RV  
wrapper only for hash and array SVs, so do it like that.  
  
This was missed originally because the test cases only checked what came  
out of a round trip back to SQL, and the strip-all-dereferences loop at  
the top of SV_to_JsonbValue hides the extra refs from view.  As a better  
test, print the Perl value with Data::Dumper, like the hstore_plperlu  
tests do.  While we can't do that in the plperl test, only plperlu,  
that should be good enough because this code is the same for both PLs.  
But also add a simplistic test for extra REFs, which we can do in both.  
  
That strip-all-dereferences behavior is now a bit dubious; it's unlike  
what happens for other Perl-to-SQL conversions.  However, the best  
thing to do seems to be to leave it alone and make the other conversions  
act similarly.  That will be done separately.  
  
Dagfinn Ilmari Mannsåker, adjusted a bit by me  
  
Discussion: https://postgr.es/m/d8jlgbq66t9.fsf@dalvik.ping.uio.no  

M contrib/jsonb_plperl/expected/jsonb_plperl.out
M contrib/jsonb_plperl/expected/jsonb_plperlu.out
M contrib/jsonb_plperl/jsonb_plperl.c
M contrib/jsonb_plperl/sql/jsonb_plperl.sql
M contrib/jsonb_plperl/sql/jsonb_plperlu.sql

Remove obsolete prohibition on function name matching a column name.

commit   : 45e98ee730621fd34d0a132343cb3f906ccc8416    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 18 Jun 2018 11:57:33 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 18 Jun 2018 11:57:33 -0400    

Click here for diff

ProcedureCreate formerly threw an error if the function to be created  
has one argument of composite type and the function name matches some  
column of the composite type.  This was a (very non-bulletproof) defense  
against creating situations where f(x) and x.f are ambiguous.  But we  
don't really need such a defense in the wake of commit b97a3465d, which  
allows us to deal with such situations fairly cleanly.  This behavior  
also created a dump-and-reload hazard, since a function might be  
rejected if a conflicting column name had been added to the input  
composite type later.  Hence, let's just drop the check.  
  
Discussion: https://postgr.es/m/CAOW5sYa3Wp7KozCuzjOdw6PiOYPi6D=VvRybtH2S=2C0SVmRmA@mail.gmail.com  

M src/backend/catalog/pg_proc.c

Consider syntactic form when disambiguating function vs column reference.

commit   : b97a3465d73bfc2a9f5bcf5def1983dbaa0a26f8    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 18 Jun 2018 11:39:33 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 18 Jun 2018 11:39:33 -0400    

Click here for diff

Postgres has traditionally considered the syntactic forms f(x) and x.f  
to be equivalent, allowing tricks such as writing a function and then  
using it as though it were a computed-on-demand column.  However, our  
behavior when both interpretations are feasible left something to be  
desired: we always chose the column interpretation.  This could lead  
to very surprising results, as in a recent bug report from Neil Conway.  
It also created a dump-and-reload hazard, since what was a function  
call in a dumped view could get interpreted as a column reference  
at reload, if a matching column name had been added to the underlying  
table since the view was created.  
  
What seems better, in ambiguous situations, is to prefer the choice  
matching the syntactic form of the reference.  This seems much less  
astonishing in general, and it fixes the dump/reload hazard.  
  
Although this could be called a bug fix, there have been few complaints  
and there's some small risk of breaking applications that depend on the  
old behavior, so no back-patch.  It does seem reasonable to slip it  
into v11, though.  
  
Discussion: https://postgr.es/m/CAOW5sYa3Wp7KozCuzjOdw6PiOYPi6D=VvRybtH2S=2C0SVmRmA@mail.gmail.com  

M doc/src/sgml/rowtypes.sgml
M src/backend/parser/parse_func.c
M src/test/regress/expected/rowtypes.out
M src/test/regress/sql/rowtypes.sql

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

commit   : 4c8156d87108fa1f245bee13775e76819cd46a90    
  
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

Prevent hard failures of standbys caused by recycled WAL segments

commit   : 70b4f82a4b5cab5fc12ff876235835053e407155    
  
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

Suppress -Wshift-negative-value warnings.

commit   : 9b53d966847c55fbd2bff63b3e1a1c37fc694071    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 17 Jun 2018 16:15:11 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 17 Jun 2018 16:15:11 -0400    

Click here for diff

Clean up four places that result in compiler warnings when using recent  
gcc with this warning class enabled (as seen on buildfarm members  
calliphoridae, skink, and others).  In all these places, this is purely  
cosmetic, because the shift distance could not be large enough to risk  
a change of sign, so there's no chance of implementation-dependent  
behavior.  Still, it's easy enough to avoid the warning by casting the  
shifted value to unsigned, so let's do that.  
  
Patch HEAD only, this isn't worth a back-patch.  

M src/backend/utils/adt/inet_cidr_ntop.c
M src/backend/utils/adt/network.c
M src/backend/utils/adt/varbit.c

Remove INCLUDE attributes section from docs.

commit   : 514d4a1338d5409431d644eaf453193ac362ef16    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Sat, 16 Jun 2018 15:28:50 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Sat, 16 Jun 2018 15:28:50 -0700    

Click here for diff

Discussing covering indexes in a chapter that is mostly about the  
behavior of B-Tree operator classes is unnecessary.  The CREATE INDEX  
documentation's handling of covering indexes seems sufficient.  
  
Discussion: https://postgr.es/m/CAH2-WzmpU=L_6VjhhOAMfoyHLr-pZd1kDc+jpa3c3a8EOmtcXA@mail.gmail.com  

M doc/src/sgml/btree.sgml

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

commit   : e716585235b175de767d3b210f0a963457dfa77f    
  
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   : 6b74f5eaadc4489e08a23686f99f096ad0e08936    
  
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   : 5d923eb29bb643e311680bab329363d8a9a9768a    
  
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

Fix some minor error-checking oversights in ParseFuncOrColumn().

commit   : 0dcf68e5a1f1c600bdf29b47cab30a62301a7af1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 16 Jun 2018 14:10:17 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 16 Jun 2018 14:10:17 -0400    

Click here for diff

Recent additions to ParseFuncOrColumn to make it reject non-procedure  
functions in CALL were neither adequate nor documented.  Reorganize  
the code to ensure uniform results for all the cases that should be  
rejected.  Also, use ERRCODE_WRONG_OBJECT_TYPE for this case as well  
as the converse case of a procedure in a non-CALL context.  The  
original coding used ERRCODE_UNDEFINED_FUNCTION which seems wrong,  
and is certainly inconsistent with the adjacent wrong-kind-of-routine  
errors.  
  
This reorganization also causes the checks for aggregate decoration with  
a non-aggregate function to be made in the FUNCDETAIL_COERCION case;  
that they were not is a long-standing oversight.  
  
Discussion: https://postgr.es/m/14497.1529089235@sss.pgh.pa.us  

M src/backend/parser/parse_func.c
M src/test/regress/expected/create_procedure.out

Remove AELs from subxids correctly on standby

commit   : 15378c1a15390a2b4c315f19f1644af46c7e3a15    
  
author   : Simon Riggs <simon@2ndQuadrant.com>    
date     : Sat, 16 Jun 2018 14:03:29 +0100    
  
committer: Simon Riggs <simon@2ndQuadrant.com>    
date     : Sat, 16 Jun 2018 14:03:29 +0100    

Click here for diff

Issues relate only to subtransactions that hold AccessExclusiveLocks  
when replayed on standby.  
  
Prior to PG10, aborting subtransactions that held an  
AccessExclusiveLock failed to release the lock until top level commit or  
abort. 49bff5300d527 fixed that.  
  
However, 49bff5300d527 also introduced a similar bug where subtransaction  
commit would fail to release an AccessExclusiveLock, leaving the lock to  
be removed sometimes early and sometimes late. This commit fixes  
that bug also. Backpatch to PG10 needed.  
  
Tested by observation. Note need for multi-node isolationtester to improve  
test coverage for this and other HS cases.  
  
Reported-by: Simon Riggs  
Author: Simon Riggs  

M src/backend/access/transam/xact.c
M src/backend/storage/ipc/procarray.c
M src/backend/storage/ipc/standby.c
M src/include/storage/standby.h

Fix memory leak in BufFileCreateShared().

commit   : 1cfdb1cb0e3f0acd0fac11537410c48dfd6d9075    
  
author   : Tatsuo Ishii <ishii@postgresql.org>    
date     : Sat, 16 Jun 2018 14:21:08 +0900    
  
committer: Tatsuo Ishii <ishii@postgresql.org>    
date     : Sat, 16 Jun 2018 14:21:08 +0900    

Click here for diff

Also this commit unifies some duplicated code in makeBufFile() and  
BufFileOpenShared() into new function makeBufFileCommon().  
  
Author: Antonin Houska  
Reviewed-By: Thomas Munro, Tatsuo Ishii  
Discussion: https://postgr.es/m/16139.1529049566%40localhost  

M src/backend/storage/file/buffile.c

Fix off-by-one bug in XactLogCommitRecord

commit   : ff03112bdc70541382b39fa4e36b9a9ad93b4b73    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 15 Jun 2018 15:00:41 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 15 Jun 2018 15:00:41 -0400    

Click here for diff

Commit 1eb6d6527aae introduced zeroed alignment bytes in the GID field  
of commit/abort WAL records.  Fixup commit cf5a1890592b later changed  
that representation into a regular cstring with a single terminating  
zero byte, but it also introduced an off-by-one mistake.  Fix that.  
  
Author: Nikhil Sontakke  
Reported-by: Nikhil Sontakke  
Discussion: https://postgr.es/m/CAMGcDxey6dG1DP34_tJMoWPcp5sPJUAL4K5CayUUXLQSx2GQpA@mail.gmail.com  

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

Fix memory leak in PLySequence_ToJsonbValue()

commit   : dad8bed04ab98ada84ecd58ace6f59839aa161c4    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Fri, 15 Jun 2018 15:01:46 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Fri, 15 Jun 2018 15:01:46 +0300    

Click here for diff

PyObject returned from PySequence_GetItem() is not released.  Similar code in PLyMapping_ToJsonbValue() is correct, because according to Python documentation  
PyList_GetItem() and PyTuple_GetItem() return a borrowed reference while  
PySequence_GetItem() returns new reference.  contrib/jsonb_plpython is new  
in PostgreSQL 11, no backpatch is needed.  
  
Author: Nikita Glukhov  
Discussion: https://postgr.es/m/6001af16-b242-2527-bc7e-84b8a959163b%40postgrespro.ru  

M contrib/jsonb_plpython/jsonb_plpython.c

Fix memory leak.

commit   : 969274d813018b08389956e493f691671f0d84f1    
  
author   : Tatsuo Ishii <ishii@postgresql.org>    
date     : Fri, 15 Jun 2018 16:32:59 +0900    
  
committer: Tatsuo Ishii <ishii@postgresql.org>    
date     : Fri, 15 Jun 2018 16:32:59 +0900    

Click here for diff

Memory is allocated twice for "file" and "files" variables in  
BufFileOpenShared().  
  
Author: Antonin Houska  
Discussion: https://postgr.es/m/11329.1529045692%40localhost  

M src/backend/storage/file/buffile.c

Fail BRIN control functions during recovery explicitly

commit   : 74da7cda31c07122257c527d9fd068dc28493fc8    
  
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

commit   : dc878ffedf2aa461b11b617094101e3c4cf48daa    
  
author   : Simon Riggs <simon@2ndQuadrant.com>    
date     : Thu, 14 Jun 2018 12:17:51 +0100    
  
committer: Simon Riggs <simon@2ndQuadrant.com>    
date     : Thu, 14 Jun 2018 12:17:51 +0100    

Click here for diff

GetRunningTransactionData() suggested that subxids were not worth  
optimizing away if overflowed, yet they have already been removed  
for that case.  
  
Changes to LogAccessExclusiveLock() API forgot to remove the  
prior comment when it was copied to LockAcquire().  

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

Remove cut-off bug from RunningTransactionData

commit   : 802bde87ba3c64b28d019e8265c2d8948a027c9c    
  
author   : Simon Riggs <simon@2ndQuadrant.com>    
date     : Thu, 14 Jun 2018 12:02:41 +0100    
  
committer: Simon Riggs <simon@2ndQuadrant.com>    
date     : Thu, 14 Jun 2018 12:02:41 +0100    

Click here for diff

32ac7a118fc17f5 tried to fix a Hot Standby issue  
reported by Greg Stark, but in doing so caused  
a different bug to appear, noted by Andres Freund.  
  
Revoke the core changes from 32ac7a118fc17f5,  
leaving in its place a minor change in code  
ordering and comments to explain for the future.  

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

Code review for match_clause_to_partition_key().

commit   : 91781335ede4db549a28ffb8e84d3b592eef9f2f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 13 Jun 2018 16:10:30 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 13 Jun 2018 16:10:30 -0400    

Click here for diff

Fix inconsistent decisions about NOMATCH vs UNSUPPORTED result codes.  
If we're going to cater for partkeys that have the same expression and  
different collations, surely we should also support partkeys with the  
same expression and different opclasses.  
  
Clean up shaky handling of commuted opclauses, eg checking the wrong  
operator to see what its negator is.  This wouldn't cause any actual  
bugs given a sane opclass definition, but it doesn't seem helpful to  
expend more code to be less correct.  
  
Improve handling of null elements in ScalarArrayOp arrays: in the  
"op ALL" case, we can conclude they result in an unsatisfiable clause.  
  
Minor cosmetic changes and comment improvements.  

M src/backend/partitioning/partprune.c

Fix some ill-chosen names for globally-visible partition support functions.

commit   : 19832753f1bb052c5fe10328939b670507df7a93    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 13 Jun 2018 13:18:02 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 13 Jun 2018 13:18:02 -0400    

Click here for diff

"compute_hash_value" is particularly gratuitously generic, but IMO  
all of these ought to have names clearly related to partitioning.  

M src/backend/commands/tablecmds.c
M src/backend/executor/execPartition.c
M src/backend/partitioning/partbounds.c
M src/backend/partitioning/partprune.c
M src/backend/utils/cache/partcache.c
M src/include/partitioning/partbounds.h

Fix up run-time partition pruning's use of relcache's partition data.

commit   : e23bae82cf3d76365d48b1204ca4c631bac7550d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 13 Jun 2018 12:03:19 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 13 Jun 2018 12:03:19 -0400    

Click here for diff

The previous coding saved pointers into the partitioned table's relcache  
entry, but then closed the relcache entry, causing those pointers to  
nominally become dangling.  Actual trouble would be seen in the field  
only if a relcache flush occurred mid-query, but that's hardly out of  
the question.  
  
While we could fix this by copying all the data in question at query  
start, it seems better to just hold the relcache entry open for the  
whole query.  
  
While at it, improve the handling of support-function lookups: do that  
once per query not once per pruning test.  There's still something to be  
desired here, in that we fail to exploit the possibility of caching data  
across queries in the fn_extra fields of the relcache's FmgrInfo structs,  
which could happen if we just used those structs in-place rather than  
copying them.  However, combining that with the possibility of per-query  
lookups of cross-type comparison functions seems to require changes in the  
APIs of a lot of the pruning support functions, so it's too invasive to  
consider as part of this patch.  A win would ensue only for complex  
partition key data types (e.g. arrays), so it may not be worth the  
trouble.  
  
David Rowley and Tom Lane  
  
Discussion: https://postgr.es/m/17850.1528755844@sss.pgh.pa.us  

M src/backend/executor/execPartition.c
M src/backend/executor/nodeAppend.c
M src/backend/partitioning/partprune.c
M src/backend/utils/cache/relcache.c
M src/include/executor/execPartition.h
M src/include/partitioning/partprune.h

Documentation improvement for pg_trgm

commit   : e146e4d02dbc241b6091596331fb1bdf0fb1c081    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Wed, 13 Jun 2018 18:23:00 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Wed, 13 Jun 2018 18:23:00 +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

Exclude files in .git from list of perl files

commit   : e3eb8be77ef82ccc8f87c515f96d01bf7c726ca8    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Tue, 12 Jun 2018 14:54:43 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Tue, 12 Jun 2018 14:54:43 -0400    

Click here for diff

The .git directory might contain perl files, as hooks, for example.  
Since we have no control over these they should be excluded from things  
like our perlcritic checks.  
  
Per offline report from Mike Blackwell.  

M src/tools/perlcheck/find_perl_files

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

commit   : a54e1f1587793b5bf926630ec9ce142e4578d7a0    
  
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

Convert debug message from ereport to elog

commit   : 8a07ebb3c172374aa2c83df61c4e05c059511c9a    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 12 Jun 2018 11:33:39 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 12 Jun 2018 11:33:39 -0400    

Click here for diff

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

doc: Replace non-ASCII lines in psql example output

commit   : b5d099f82ae6e7c49c397bd85832f13729626035    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 12 Jun 2018 08:19:52 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 12 Jun 2018 08:19:52 -0400    

Click here for diff

We normally use the default line mode in examples.  

M doc/src/sgml/jit.sgml

doc: Suggest logical replication more prominently for upgrading

commit   : 8f6c94272c485bb812aebe063fc412326a17b880    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 11 Jun 2018 21:34:32 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 11 Jun 2018 21:34:32 -0400    

Click here for diff

The previous wording suggested only Slony, and there are more options  
available.  

M doc/src/sgml/runtime.sgml

Fix access to just-closed relcache entry.

commit   : bdc643e5e46f84d55d989980e4ff5f8e2da103c6    
  
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

Fix oversight from 9e149c8 with spin-lock handling

commit   : f8795d2ec8632a7242896e0f8322d13bfe922512    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 12 Jun 2018 06:52:34 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 12 Jun 2018 06:52:34 +0900    

Click here for diff

Calling an external function while a pin-lock is held is a bad idea as  
those are designed to be short-lived.  The stress of a first commit into  
a large git history may contribute to that.  
  
Reported-by: Andres Freund  
Discussion: https://postgr.es/m/20180611164952.vmxdpdpirdtkdsz6@alap3.anarazel.de  

M src/backend/replication/slot.c

Improve ExecFindInitialMatchingSubPlans's subplan renumbering logic.

commit   : 69025c5a07a10c842bfbcb62d4af1221e5ce7e85    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 11 Jun 2018 17:35:43 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 11 Jun 2018 17:35:43 -0400    

Click here for diff

We don't need two passes if we scan child partitions before parents,  
as that way the children's present_parts are up to date before they're  
needed.  I (tgl) think there's actually a bug being fixed here, for the  
case of an intermediate partitioned table with no direct leaf children,  
but haven't attempted to construct a test case to prove it.  
  
David Rowley  
  
Discussion: https://postgr.es/m/CAKJS1f-6GODRNgEtdPxCnAPme2h2hTztB6LmtfdmcYAAOE0kQg@mail.gmail.com  

M src/backend/executor/execPartition.c

Improve commentary about run-time partition pruning data structures.

commit   : 4e23236403336052a000c8bf85720e9d65ba8036    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 11 Jun 2018 17:14:46 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 11 Jun 2018 17:14:46 -0400    

Click here for diff

No code changes except for a couple of new Asserts.  
  
David Rowley and Tom Lane  
  
Discussion: https://postgr.es/m/CAKJS1f-6GODRNgEtdPxCnAPme2h2hTztB6LmtfdmcYAAOE0kQg@mail.gmail.com  

M src/backend/optimizer/path/allpaths.c
M src/backend/partitioning/partprune.c
M src/include/executor/execPartition.h
M src/include/nodes/plannodes.h
M src/include/nodes/relation.h

Adjust error message

commit   : e5d11b91e42e20ff80effb946cb461c490d491ba    
  
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

Don't needlessly check the partition contraint twice

commit   : 5b0c7e2f757a2cbdd8e0c478de51bcb5606d3a93    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 11 Jun 2018 16:53:33 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 11 Jun 2018 16:53:33 -0400    

Click here for diff

Starting with commit f0e44751d717, ExecConstraints was in charge of  
running the partition constraint; commit 19c47e7c8202 modified that so  
that caller could request to skip that checking depending on some  
conditions, but that commit and 15ce775faa42 together introduced a small  
bug there which caused ExecInsert to request skipping the constraint  
check but have this not be honored -- in effect doing the check twice.  
This could have been fixed in a very small patch, but on further  
analysis of the involved function and its callsites, it turns out to be  
simpler to give the responsibility of checking the partition constraint  
fully to the caller, and return ExecConstraints to its original  
(pre-partitioning) shape where it only checked tuple descriptor-related  
constraints.  Each caller must do partition constraint checking on its  
own schedule, which is more convenient after commit 2f178441044 anyway.  
  
Reported-by: David Rowley  
Author: David Rowley, Álvaro Herrera  
Reviewed-by: Amit Langote, Amit Khandekar, Simon Riggs  
Discussion: https://postgr.es/m/CAKJS1f8w8+awsxgea8wt7_UX8qzOQ=Tm1LD+U1fHqBAkXxkW2w@mail.gmail.com  

M src/backend/commands/copy.c
M src/backend/executor/execMain.c
M src/backend/executor/execPartition.c
M src/backend/executor/execReplication.c
M src/backend/executor/nodeModifyTable.c
M src/include/executor/executor.h

Move perlcritic files to new perlcheck directory

commit   : 85dd744a70d167ca86e83ea38f5ac3e1449bb028    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 11 Jun 2018 14:54:28 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 11 Jun 2018 14:54:28 -0400    

Click here for diff

R091 src/tools/pgperlcritic/perlcriticrc src/tools/perlcheck/perlcriticrc
R055 src/tools/pgperlcritic/pgperlcritic src/tools/perlcheck/pgperlcritic

Add a script to detect perl compile time errors and warnings

commit   : af616ce48347c68af7bdcfe0e62d9ad601cb8d75    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 11 Jun 2018 14:47:20 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 11 Jun 2018 14:47:20 -0400    

Click here for diff

Also add a function that centralizes the logic for locating all our perl  
files and use it in pgperlcritic and pgperltidy as well as the new  
pgperlcheck.  

A src/tools/perlcheck/find_perl_files
A src/tools/perlcheck/pgperlsyncheck
M src/tools/pgindent/pgperltidy
M src/tools/pgperlcritic/pgperlcritic

Fix run-time partition pruning code to handle NULL values properly.

commit   : be3d90026a3c17c7e6cc23d52430c37df403d869    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 11 Jun 2018 12:08:09 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 11 Jun 2018 12:08:09 -0400    

Click here for diff

The previous coding just ignored pruning constraints that compare a  
partition key to a null-valued expression.  This is silly, since really  
what we can do there is conclude that all partitions are rejected: the  
pruning operator is known strict so the comparison must always fail.  
  
This also fixes the logic to not ignore constisnull for a Const comparison  
value.  That's probably an unreachable case, since the planner would  
normally have simplified away a strict operator with a constant-null input.  
But this code has no business assuming that.  
  
David Rowley, per a gripe from me  
  
Discussion: https://postgr.es/m/26279.1528670981@sss.pgh.pa.us  

M src/backend/partitioning/partprune.c
M src/test/regress/expected/partition_prune.out
M src/test/regress/sql/partition_prune.sql

Make new error code name match SQL standard more closely

commit   : 387543f7bdf0f1ca3dc06e6bb5c9ef7980cf9f44    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 11 Jun 2018 11:15:28 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 11 Jun 2018 11:15:28 -0400    

Click here for diff

Discussion: https://www.postgresql.org/message-id/dff3d555-bea4-ac24-29b2-29521b9d08e8%402ndquadrant.com  

M doc/src/sgml/btree.sgml
M src/backend/executor/nodeWindowAgg.c
M src/backend/utils/adt/date.c
M src/backend/utils/adt/float.c
M src/backend/utils/adt/int.c
M src/backend/utils/adt/int8.c
M src/backend/utils/adt/numeric.c
M src/backend/utils/adt/timestamp.c
M src/backend/utils/errcodes.txt

Update config.guess and config.sub

commit   : bfbb13264ae76a952a8312091d600db110b1c0eb    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 11 Jun 2018 08:54:58 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 11 Jun 2018 08:54:58 -0400    

Click here for diff

M config/config.guess
M config/config.sub

commit   : d61bfdda8c2cae671ca4a252993bb8feaa619285    
  
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 a couple of bugs with replication slot advancing feature

commit   : f731cfa94c00164814625d5753d376a4a7c43fff    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 11 Jun 2018 09:26:13 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 11 Jun 2018 09:26:13 +0900    

Click here for diff

A review of the code has showed up a couple of issues fixed by this  
commit:  
- Physical slots have been using the confirmed LSN position as a start  
comparison point which is always 0/0, instead use the restart LSN  
position (logical slots need to use the confirmed LSN position, which  
was correct).  
- The actual slot update was incorrect for both physical and logical  
slots.  Physical slots need to use their restart_lsn as base comparison  
point (confirmed_flush was used because of previous point), and logical  
slots need to begin reading WAL from restart_lsn (confirmed_flush was  
used as well), while confirmed_flush is compiled depending on the  
decoding context and record read, and is the LSN position returned back  
to the caller.  
- Never return 0/0 if a slot cannot be advanced.  This way, if a slot is  
advanced while the activity is idle, then the same position is returned  
to the caller over and over without raising an error.  Instead return  
the LSN the slot has been advanced to.  With repetitive calls, the same  
position is returned hence caller can directly monitor the difference in  
progress in bytes by doing simply LSN difference calculations, which  
should be monotonic.  
  
Note that as the slot is owned by the backend advancing it, then the  
read of those fields is fine lock-less, while updates need to happen  
while the slot mutex is held, so fix that on the way as well.  Other  
locks for in-memory data of replication slots have been already fixed  
previously.  
  
Some of those issues have been pointed out by Petr and Simon during the  
patch, while I noticed some of them after looking at the code.  This  
also visibly takes of a recently-discovered bug causing assertion  
failures which can be triggered by a two-step slot forwarding which  
first advanced the slot to a WAL page boundary and secondly advanced it  
to the latest position, say 'FF/FFFFFFF' to make sure that the newest  
LSN is used as forward point.  It would have been nice to drop a test  
for that, but the set of operators working on pg_lsn limits it, so this  
is left for a future exercise.  
  
Author: Michael Paquier  
Reviewed-by: Petr Jelinek, Simon Riggs  
Discussion: https://postgr.es/m/CANP8+jLyS=X-CAk59BJnsxKQfjwrmKicHQykyn52Qj-Q=9GLCw@mail.gmail.com  
Discussion: https://www.postgresql.org/message-id/2840048a-1184-417a-9da8-3299d207a1d7%40postgrespro.ru  

M src/backend/replication/slotfuncs.c

Assorted cosmetic cleanup of run-time-partition-pruning code.

commit   : 321f648a312bd188b7a5c33a0548a57f45dfbf42    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 10 Jun 2018 18:24:34 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 10 Jun 2018 18:24:34 -0400    

Click here for diff

Use "subplan" rather than "subnode" to refer to the child plans of  
a partitioning Append; this seems a bit more specific and hence  
clearer.  Improve assorted comments.  No non-cosmetic changes.  
  
David Rowley and Tom Lane  
  
Discussion: https://postgr.es/m/CAFj8pRBjrufA3ocDm8o4LPGNye9Y+pm1b9kCwode4X04CULG3g@mail.gmail.com  

M src/backend/executor/execPartition.c
M src/backend/nodes/copyfuncs.c
M src/backend/nodes/outfuncs.c
M src/backend/nodes/readfuncs.c
M src/backend/partitioning/partprune.c
M src/include/executor/execPartition.h
M src/include/nodes/plannodes.h

Relocate partition pruning structs to a saner place.

commit   : 939449de0e571b8c0b07674bb7095e06e93cc059    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 10 Jun 2018 16:30:14 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 10 Jun 2018 16:30:14 -0400    

Click here for diff

These struct definitions were originally dropped into primnodes.h,  
which is a poor choice since that's mainly intended for primitive  
expression node types; these are not in that category.  What they  
are is auxiliary info in Plan trees, so move them to plannodes.h.  
  
For consistency, also relocate some related code that was apparently  
placed with the aid of a dartboard.  
  
There's no interesting code changes in this commit, just reshuffling.  
  
David Rowley and Tom Lane  
  
Discussion: https://postgr.es/m/CAFj8pRBjrufA3ocDm8o4LPGNye9Y+pm1b9kCwode4X04CULG3g@mail.gmail.com  

M src/backend/executor/execPartition.c
M src/backend/nodes/copyfuncs.c
M src/backend/nodes/outfuncs.c
M src/backend/nodes/readfuncs.c
M src/backend/optimizer/plan/createplan.c
M src/include/nodes/nodes.h
M src/include/nodes/plannodes.h
M src/include/nodes/primnodes.h

Improve run-time partition pruning to handle any stable expression.

commit   : 73b7f48f78d27b1baf1a6541cbaae0fe6bd6186d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 10 Jun 2018 15:22:25 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 10 Jun 2018 15:22:25 -0400    

Click here for diff

The initial coding of the run-time-pruning feature only coped with cases  
where the partition key(s) are compared to Params.  That is a bit silly;  
we can allow it to work with any non-Var-containing stable expression, as  
long as we take special care with expressions containing PARAM_EXEC Params.  
The code is hardly any longer this way, and it's considerably clearer  
(IMO at least).  Per gripe from Pavel Stehule.  
  
David Rowley, whacked around a bit by me  
  
Discussion: https://postgr.es/m/CAFj8pRBjrufA3ocDm8o4LPGNye9Y+pm1b9kCwode4X04CULG3g@mail.gmail.com  

M src/backend/executor/execPartition.c
M src/backend/executor/nodeAppend.c
M src/backend/nodes/copyfuncs.c
M src/backend/nodes/outfuncs.c
M src/backend/nodes/readfuncs.c
M src/backend/partitioning/partprune.c
M src/include/executor/execPartition.h
M src/include/nodes/primnodes.h
M src/include/partitioning/partprune.h
M src/test/regress/expected/partition_prune.out
M src/test/regress/sql/partition_prune.sql

Fix grammar in REVOKE documentation

commit   : c83e2029909c5411ca11fd841851016f1f9810e6    
  
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

Fix and document lock handling for in-memory replication slot data

commit   : 9e149c847f398793ec1641885434dcd10837d89d    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 1 Jun 2018 14:30:55 -0400    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 1 Jun 2018 14:30:55 -0400    

Click here for diff

While debugging issues on HEAD for the new slot forwarding feature of  
Postgres 11, some monitoring of the code surrounding in-memory slot data  
has proved that the lock handling may cause inconsistent data to be read  
by read-only callers of slot functions, particularly  
pg_get_replication_slots() which fetches data for the system view  
pg_replication_slots, or modules looking directly at slot information.  
  
The code paths involved in those problems concern logical decoding  
initialization (down to 9.4) and WAL reservation for slots (new as of  
10).  
  
A set of comments documenting all the lock handlings, particularly the  
dependency with LW locks for slots and the in_use flag as well as the  
internal mutex lock is added, based on a suggested by Simon Riggs.  
  
Some of the fixed code exists down to 9.4 where WAL decoding has been  
introduced, but as those race conditions are really unlikely going to  
happen as those concern code paths for slot and decoding creation, just  
fix the problem on HEAD.  
  
Author: Michael Paquier  
  
Discussion: https://postgr.es/m/20180528085747.GA27845@paquier.xyz  

M src/backend/replication/logical/logical.c
M src/backend/replication/slot.c
M src/include/replication/slot.h

Limit Parallel Hash's bucket array to MaxAllocSize.

commit   : 86a2218eb00eb6f97898945967c5f9c95c72b4c6    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Sun, 10 Jun 2018 20:30:25 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Sun, 10 Jun 2018 20:30:25 +1200    

Click here for diff

Make sure that we don't exceed MaxAllocSize when increasing the number of  
buckets.  Perhaps later we'll remove that limit and use DSA_ALLOC_HUGE, but  
for now just prevent further increases like the non-parallel code.  This  
change avoids the error from bug report #15225.  
  
Author: Thomas Munro  
Reviewed-By: Tom Lane  
Reported-by: Frits Jalvingh  
Discussion: https://postgr.es/m/152802081668.26724.16985037679312485972%40wrigleys.postgresql.org  

M src/backend/executor/nodeHash.c

Fix typo in JIT README.

commit   : f6b95ff434bff28c0d9b390d5a0ff316847c4fb7    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Sat, 9 Jun 2018 09:33:53 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Sat, 9 Jun 2018 09:33:53 -0700    

Click here for diff

Author: Daniel Gustafsson  
Discussion: https://postgr.es/m/3747D478-41F9-439F-8074-AC81A5C76346@yesql.se  

M src/backend/jit/README

Teach SHOW ALL to honor pg_read_all_settings membership

commit   : 0c8910a0cab7c1e439bf5f5850122c36359e6799    
  
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   : acad8b409add4bde37e3882c1680a7bd26289f03    
  
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

Add missing serial commas

commit   : 25cf4ed1dc4e16da042e73ef5090e54bcf271f45    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 7 Jun 2018 23:37:09 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 7 Jun 2018 23:37:09 -0400    

Click here for diff

M src/backend/libpq/hba.c
M src/backend/utils/adt/jsonfuncs.c
M src/test/regress/expected/json.out
M src/test/regress/expected/jsonb.out

doc: Move some new options into better positions on man pages

commit   : 5efbdd36f1584d5e6e3870a05dc5f53692b18df6    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 7 Jun 2018 23:36:04 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 7 Jun 2018 23:36:04 -0400    

Click here for diff

M doc/src/sgml/ref/initdb.sgml
M doc/src/sgml/ref/pg_dump.sgml
M doc/src/sgml/ref/pg_dumpall.sgml

ecpg: Document new compatibility option

commit   : 3b9b7516f42b72589951bb8d47a0220c67fb70de    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 7 Jun 2018 23:33:24 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 7 Jun 2018 23:33:24 -0400    

Click here for diff

It's listed in --help, so it should be listed in the man page as well.  

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

Exclude VACUUMs from RunningXactData

commit   : 32ac7a118fc17f5baac1b370f50d759c30bee00a    
  
author   : Simon Riggs <simon@2ndQuadrant.com>    
date     : Thu, 7 Jun 2018 20:38:12 +0100    
  
committer: Simon Riggs <simon@2ndQuadrant.com>    
date     : Thu, 7 Jun 2018 20:38:12 +0100    

Click here for diff

GetRunningTransactionData() should ignore VACUUM procs because in some  
cases they are assigned xids. This could lead to holding back xmin via  
the route of passing the xid to standby and then having that hold back  
xmin on master via feedback.  
  
Backpatch to 9.1 needed, but will only do so on supported versions.  
Backpatch once proven on the buildfarm.  
  
Reported-by: Greg Stark  
Author: Simon Riggs  
Reviewed-by: Amit Kapila  
Discussion: https://postgr.es/m/CANP8+jJBYt=4PpTfiPb0UrH1_iPhzsxKH5Op_Wec634F0ohnAw@mail.gmail.com  

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

Fix typo in README

commit   : 848b1f3e358f4a1bb98d8c4a07ff8ee5fd7ea9a0    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Thu, 7 Jun 2018 14:40:38 +0200    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Thu, 7 Jun 2018 14:40:38 +0200    

Click here for diff

Author: Daniel Gustafsson <daniel@yesql.se>  

M src/backend/optimizer/README

Fix obsolete comment.

commit   : 57f06a7611cc4806f581ae838f145181164056d4    
  
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   : eee381ef5ec4b16cff37865ccd70510e1e1abcdc    
  
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 spurious non-ASCII bytes

commit   : 3f85c62d9e825eedd1315d249ef1ad793ca78ed4    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 4 Jun 2018 16:17:34 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 4 Jun 2018 16:17:34 -0400    

Click here for diff

M src/backend/catalog/heap.c

Fix typo

commit   : 2241ad1556b3734b4867117bee8d78ef9577fceb    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 4 Jun 2018 15:34:42 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 4 Jun 2018 15:34:42 -0400    

Click here for diff

M src/backend/utils/misc/postgresql.conf.sample

Put new command-line options into alphabetical order

commit   : 4d6a854f176dbb48e62f017d8234f4736cb48d24    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 4 Jun 2018 15:03:15 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 4 Jun 2018 15:03:15 -0400    

Click here for diff

M doc/src/sgml/ref/pg_dump.sgml
M doc/src/sgml/ref/pg_dumpall.sgml
M src/bin/pg_dump/pg_dump.c
M src/bin/pg_dump/pg_dumpall.c
M src/bin/pg_dump/pg_restore.c

Tweak partitioning documentation wording

commit   : 12b9affb32a636777062b3feb5816621363fc108    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 1 Jun 2018 14:54:43 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 1 Jun 2018 14:54:43 -0400    

Click here for diff

For clarity, precision, grammar.  
  
Author: Justin Pryzby  
Reviewed-by: Amit Langote, Álvaro Herrera  
Discussion: https://postgr.es/m/20180523213513.GM30060@telsasoft.com  

M doc/src/sgml/ddl.sgml

Reconcile nodes/*funcs.c with PostgreSQL 11 work.

commit   : ef3109500030030b0e8d3c1d7f2b409d702cc49a    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Thu, 31 May 2018 16:07:13 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Thu, 31 May 2018 16:07:13 -0700    

Click here for diff

This covers new fields in two outfuncs.c functions having no readfuncs.c  
counterpart.  Thus, this changes only debugging output.  

M src/backend/nodes/outfuncs.c

Fix compile-time warnings on all perl code

commit   : 0039049fb1d76afef05d550823b27731ad7d7b3d    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Thu, 31 May 2018 08:13:02 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Thu, 31 May 2018 08:13:02 -0400    

Click here for diff

This patch does two things. First, it silences a number of compile-time  
warnings in the msvc tools files, mainly those due to the fact that in  
some cases we have more than one package per file. Second it supplies a  
dummy Perl library with just enough of the Windows API referred to in  
our code to let it run these checks cleanly, even on Unix machines where  
the code is never supposed to run. The dummy library should only be used  
for that purpose, as its README notes.  

M src/tools/msvc/MSBuildProject.pm
M src/tools/msvc/Project.pm
M src/tools/msvc/Solution.pm
M src/tools/msvc/VCBuildProject.pm
M src/tools/msvc/VSObjectFactory.pm
A src/tools/msvc/dummylib/README
A src/tools/msvc/dummylib/Win32.pm
A src/tools/msvc/dummylib/Win32/Registry.pm
A src/tools/msvc/dummylib/Win32API/File.pm

Fix grammar

commit   : d3b10f0d64e90e9c78b8adc24ab3e38b30ef60bd    
  
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

Move _bt_upgrademetapage() into critical section.

commit   : 08186dc05b3eed9c1f29b3349b122487d84ef3eb    
  
author   : Teodor Sigaev <teodor@sigaev.ru>    
date     : Wed, 30 May 2018 19:45:39 +0300    
  
committer: Teodor Sigaev <teodor@sigaev.ru>    
date     : Wed, 30 May 2018 19:45:39 +0300    

Click here for diff

Any changes on page should be done in critical section, so move  
_bt_upgrademetapage into critical section. Improve comment. Found by Amit  
Kapila during post-commit review of 857f9c36.  
  
Author: Amit Kapila  

M src/backend/access/nbtree/nbtinsert.c
M src/backend/access/nbtree/nbtpage.c
M src/include/access/nbtree.h

Initialize new jsonb iterator to zero

commit   : 3c9cf069454d80b0b4a54a0a90941a88a97b1122    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 28 May 2018 23:53:43 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 28 May 2018 23:53:43 -0400    

Click here for diff

Use palloc0() instead of palloc() to create a new JsonbIterator.  
Otherwise, the isScalar field is sometimes not initialized.  There is  
probably no impact in practice, but it's cleaner this way and it avoids  
future problems.  

M src/backend/utils/adt/jsonb_util.c

Return a value from Install.pm's lcopy function

commit   : 01deec5f8ae64b5120cc8c93d54fe0e19e477b02    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 28 May 2018 16:44:13 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 28 May 2018 16:44:13 -0400    

Click here for diff

Commit 3a7cc727c was a little over eager about adding an explicit return  
to this function, whose value is checked in most call sites. This change  
reverses that and returns the expected value explicitly. It also adds a  
check to the one call site lacking one.  

M src/tools/msvc/Install.pm

doc: mark 'replaceable' parameter for backup program listing

commit   : 6a75b58065c8da69a259657fc40d18e76157f265    
  
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   : 99164e6952917009929026a9a11e4a500f599c40    
  
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

Avoid use of unportable hex constant in convutils.pm

commit   : f963f80970641246cbba172e197068193ad65189    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Sun, 27 May 2018 10:41:19 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Sun, 27 May 2018 10:41:19 -0400    

Click here for diff

Discussion: https://postgr.es/m/5a6d6de8-cff8-1ffb-946c-ccf381800ea1@2ndQuadrant.com  

M src/backend/utils/mb/Unicode/convutils.pm

Don't fall off the end of perl functions

commit   : 3a7cc727c7c502353dbb730a0db793abec4de44b    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Sun, 27 May 2018 09:08:42 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Sun, 27 May 2018 09:08:42 -0400    

Click here for diff

This complies with the perlcritic policy  
Subroutines::RequireFinalReturn, which is a severity 4 policy. Since we  
only currently check at severity level 5, the policy is raised to that  
level until we move to level 4 or lower, so that any new infringements  
will be caught.  
  
A small cosmetic piece of tidying of the pgperlcritic script is  
included.  
  
Mike Blackwell  
  
Discussion: https://postgr.es/m/CAESHdJpfFm_9wQnQ3koY3c91FoRQsO-fh02za9R3OEMndOn84A@mail.gmail.com  

M contrib/bloom/t/001_wal.pl
M contrib/intarray/bench/create_test.pl
M src/backend/catalog/Catalog.pm
M src/backend/catalog/genbki.pl
M src/backend/parser/check_keywords.pl
M src/backend/utils/mb/Unicode/convutils.pm
M src/backend/utils/sort/gen_qsort_tuple.pl
M src/bin/pg_archivecleanup/t/010_pg_archivecleanup.pl
M src/bin/pg_rewind/RewindTest.pm
M src/bin/pg_rewind/t/001_basic.pl
M src/bin/pg_rewind/t/002_databases.pl
M src/bin/pg_rewind/t/003_extrafiles.pl
M src/bin/pg_rewind/t/004_pg_xlog_symlink.pl
M src/bin/pgbench/t/001_pgbench_with_server.pl
M src/bin/pgbench/t/002_pgbench_no_server.pl
M src/include/catalog/reformat_dat_file.pl
M src/interfaces/ecpg/preproc/parse.pl
M src/pl/plperl/plc_perlboot.pl
M src/pl/plperl/text2macro.pl
M src/test/authentication/t/001_password.pl
M src/test/authentication/t/002_saslprep.pl
M src/test/kerberos/t/001_auth.pl
M src/test/ldap/t/001_auth.pl
M src/test/perl/PostgresNode.pm
M src/test/perl/SimpleTee.pm
M src/test/perl/TestLib.pm
M src/test/recovery/t/001_stream_rep.pl
M src/test/recovery/t/003_recovery_targets.pl
M src/test/recovery/t/007_sync_rep.pl
M src/test/recovery/t/009_twophase.pl
M src/test/ssl/ServerSetup.pm
M src/tools/copyright.pl
M src/tools/git_changelog
M src/tools/msvc/Install.pm
M src/tools/msvc/MSBuildProject.pm
M src/tools/msvc/Mkvcbuild.pm
M src/tools/msvc/Project.pm
M src/tools/msvc/Solution.pm
M src/tools/msvc/VCBuildProject.pm
M src/tools/msvc/builddoc.pl
M src/tools/msvc/gendef.pl
M src/tools/msvc/vcregress.pl
M src/tools/pginclude/pgcheckdefines
M src/tools/pgindent/pgindent
M src/tools/pgperlcritic/perlcriticrc
M src/tools/pgperlcritic/pgperlcritic
M src/tools/version_stamp.pl

Don't force a blank line before comments in perl code

commit   : 8a56ff484808e9c05df9656cf4244229e8c7960d    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Sun, 27 May 2018 08:53:54 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Sun, 27 May 2018 08:53:54 -0400    

Click here for diff

Suggestion from Bruce Momjian  
  
Discussion: https://postgr.es/m/20180525190445.GA2213@momjian.us  

M src/tools/pgindent/perltidyrc

Update a couple of long-obsolete comments in pg_type.h.

commit   : 71b349aef4c4eb766e556360cfb5f5190c02b9c1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 26 May 2018 13:47:26 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 26 May 2018 13:47:26 -0400    

Click here for diff

M src/include/catalog/pg_type.h

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

commit   : 9a8aa25ccc6c285cd4f02afe4718eafd20dc34c5    
  
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   : 7019c21c1bf51eafb56595b916c216ca860ad499    
  
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

Update non-default collation tests for getObjectDescription() changes.

commit   : 2eb809ad7e71737b1a1ef5679d8e4c88e785669e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 24 May 2018 17:41:52 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 24 May 2018 17:41:52 -0400    

Click here for diff

Sigh, also missed in commit b86b7bfa3.  Per buildfarm.  

M src/test/regress/expected/collate.icu.utf8.out
M src/test/regress/expected/collate.linux.utf8.out

Update sepgsql regression test output for getObjectDescription() changes.

commit   : f248453b7a1b0590b3c7cf32a958573b70e23b09    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 24 May 2018 16:11:25 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 24 May 2018 16:11:25 -0400    

Click here for diff

Missed in commit b86b7bfa3.  Per buildfarm.  

M contrib/sepgsql/expected/alter.out
M contrib/sepgsql/expected/misc.out

Improve English wording of some other getObjectDescription() messages.

commit   : b86b7bfa3e8b3e4255352ca564b3f1270e708274    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 24 May 2018 14:01:10 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 24 May 2018 14:01:10 -0400    

Click here for diff

Print columns as "column C of <relation>" rather than "<relation> column  
C".  This seems to read noticeably better in English, as evidenced by the  
regression test output changes, and the code change also makes it possible  
for translators to adjust the phrase order in other languages.  
  
Also change the output for OCLASS_DEFAULT from "default for %s" to  
"default value for %s".  This seems to read better and is also more  
consistent with the output of, for instance, getObjectTypeDescription().  
  
Kyotaro Horiguchi, per a complaint from me  
  
Discussion: https://postgr.es/m/20180522.182020.114074746.horiguchi.kyotaro@lab.ntt.co.jp  

M contrib/earthdistance/expected/earthdistance.out
M contrib/postgres_fdw/expected/postgres_fdw.out
M src/backend/catalog/objectaddress.c
M src/test/regress/expected/alter_table.out
M src/test/regress/expected/collate.out
M src/test/regress/expected/domain.out
M src/test/regress/expected/sequence.out
M src/test/regress/expected/triggers.out

Improve translatability of some getObjectDescription() messages.

commit   : 7c89eb750d0cc4e33c46c62154c461be57883b72    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 24 May 2018 13:20:16 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 24 May 2018 13:20:16 -0400    

Click here for diff

Refactor some cases in getObjectDescription so that the translator has  
more control over phrase order in the translated messages.  This doesn't  
cause any changes in the English results.  (I was sorely tempted to  
reorder "... belonging to role %s in schema %s" into "... in schema %s  
belonging to role %s", but refrained.)  
  
In principle we could back-patch this, but since translators have not  
complained about these cases previously, it seems better not to thrash  
the translatable strings in back branches.  
  
Kyotaro Horiguchi, tweaked a bit by me  
  
Discussion: https://postgr.es/m/20180522.182020.114074746.horiguchi.kyotaro@lab.ntt.co.jp  

M src/backend/catalog/objectaddress.c

Fix objectaddress.c code for publication relations.

commit   : 1a31baf61ed81a13d034bd50db19473ad67acc52    
  
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   : 056f52d9c3ee2dd85b5f1acdbb4e0497f82725b3    
  
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

Preserve information on use of git-external-diff

commit   : 4431c94c3606ab54594b15ad89c7e71e46b4fb6a    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Thu, 24 May 2018 23:45:31 +0930    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Thu, 24 May 2018 23:45:31 +0930    

Click here for diff

Now that the Working with git wiki page no longer suggests producing  
context diffs, we should preserve the information on how to use  
git-external-diff for those people who want to view context format  
diffs. The most obvious place is in the script itself, so that's what's  
done here.  

M src/tools/git-external-diff

doc: PG 11 rel notes: add PL/pgSQL composite DDL item

commit   : 0c7e6b791a316431fb206a9ae2184377c4296995    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 23 May 2018 22:06:31 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 23 May 2018 22:06:31 -0400    

Click here for diff

Reported-by: Tom Lane  

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

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

commit   : 50485b3e201dda8498e799b769e624db20e86cff    
  
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

Remove configure's check for nonstandard "long long" printf modifiers.

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

Click here for diff

We used to claim to support platforms using 'q' or 'I64' as the printf  
length modifier for long long int, by dint of replacing snprintf with  
our own code which uses the C99 standard 'll' modifier.  But that is  
only adequate if we use INT64_MODIFIER only in snprintf-based calls,  
not directly with the platform's native printf or fprintf.  Which  
hasn't been the case for years.  We had not noticed, partially because  
of inadequate test coverage, and partially because the buildfarm is  
almost completely bare of machines that won't take 'll'.  The last  
one seems to have been frogmouth, which was adjusted recently so that  
it will take 'll'.  We might as well just give up on the pretense  
that anything else works, and save ourselves some configure cycles.  
  
Discussion: https://postgr.es/m/13103.1526749980@sss.pgh.pa.us  
Discussion: https://postgr.es/m/24769.1526772680@sss.pgh.pa.us  

M config/c-library.m4
M configure
M configure.in
M src/include/pg_config.h.in
M src/include/pg_config.h.win32

Fix incorrect ordering of operations in pg_resetwal and pg_rewind.

commit   : 1d96c1b91a4b7da6288ee63671a234b557ff5ccf    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 23 May 2018 10:59:55 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 23 May 2018 10:59:55 -0400    

Click here for diff

Commit c37b3d08c dropped its added GetDataDirectoryCreatePerm call into  
the wrong place in pg_resetwal.c, namely after the chdir to DataDir.  
That broke invocations using a relative path, as reported by Tushar Ahuja.  
We could have left it where it was and changed the argument to be ".",  
but that'd result in a rather confusing error message in event of a  
failure, so re-ordering seems like a better solution.  
  
Similarly reorder operations in pg_rewind.c.  The issue there is that  
it doesn't seem like a good idea to do any actual operations before the  
not-root check (on Unix) or the restricted token acquisition (on Windows).  
I don't know that this is an actual bug, but I'm definitely not convinced  
that it isn't, either.  
  
Assorted other code review for c37b3d08c and da9b580d8: fix some  
misspelled or otherwise badly worded comments, put the #include for  
<sys/stat.h> where it actually belongs, etc.  
  
Discussion: https://postgr.es/m/aeb9c3a7-3c3f-a57f-1a18-c8d4fcdc2a1f@enterprisedb.com  

M src/backend/storage/file/fd.c
M src/backend/utils/init/globals.c
M src/bin/pg_resetwal/pg_resetwal.c
M src/bin/pg_rewind/pg_rewind.c
M src/common/file_perm.c
M src/include/common/file_perm.h

Accept "B" in all memory-unit GUCs, and improve error messages.

commit   : b06d8e58b5ac257c2119312c47c4a0f233c5e0ca    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 23 May 2018 10:02:40 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 23 May 2018 10:02:40 +0300    

Click here for diff

Commit 6e7baa3227 added support for "B" unit, for specifying config options  
in bytes. However, it was only accepted in GUC_UNIT_BYTE settings,  
wal_segment_size and track_activity_query_size, and not e.g. in work_mem.  
This patch makes it consistent, so that "B" accepted in all the same  
contexts where "kB", "MB", and so forth are accepted.  
  
Add "B" to the list of accepted units in the error hint, along with "kB",  
"MB", etc.  
  
Add an entry in the conversion table for "TB" to "B" conversion. A terabyte  
is out of range for any GUC_UNIT_BYTE option, so you always get an "out of  
range" error with that, but without it, you get a confusing error message  
that claims that "TB" is not an accepted unit, with a hint that nevertheless  
lists "TB" as an accepted unit.  
  
Reviewed-by: Alexander Korotkov, Andres Freund  
Discussion: https://www.postgresql.org/message-id/1bfe7f4a-7e22-aa6e-7b37-f4d222ed2d67@iki.fi  

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

doc: PG 11 release notes fix for pg_dump --create, author

commit   : e41c2b057f92c3824ffe0157e83ee43624487035    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 22 May 2018 22:39:48 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 22 May 2018 22:39:48 -0400    

Click here for diff

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

doc: PG 11 release notes, add third author

commit   : fd287b4669cd728d6b436fac32a9b7ff26608248    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 22 May 2018 21:42:25 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 22 May 2018 21:42:25 -0400    

Click here for diff

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

doc: PG 11 release note fixes: PGhost, typo

commit   : 9490c2da28662ca2b0f60d09e83d278d00f20501    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 22 May 2018 21:40:55 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 22 May 2018 21:40:55 -0400    

Click here for diff

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

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

commit   : ecac23511e04d96b94705731873fa3d238c41f8d    
  
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

Add missing files to src/backend/lib/README.

commit   : 17f188cf000787236b4099242300cda4df0af6c0    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 22 May 2018 13:17:33 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 22 May 2018 13:17:33 +0300    

Click here for diff

The README lists all the files available in the directory, along with short  
descriptions of each, but a few newly added ones were missing. While we're  
at it, reorder the list into alphabetical order.  
  
Author: Takeshi Ideriha  
Discussion: https://www.postgresql.org/message-id/4E72940DA2BF16479384A86D54D0988A56793487@G01JPEXMBKW04  

M src/backend/lib/README

Fix typo in comment.

commit   : a0b37684ba1c7ce6380db6ff6817cf9f3a85b94c    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 22 May 2018 11:15:00 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 22 May 2018 11:15:00 +0300    

Click here for diff

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

Stamp 11beta1.

commit   : 586e4e6df5b85ddd28c9e881d237bd7380ffeb8e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 21 May 2018 17:08:10 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 21 May 2018 17:08:10 -0400    

Click here for diff

M configure
M configure.in
M doc/bug.template
M src/include/pg_config.h.win32

Update SQL features list

commit   : 4f72ca14de87eccd2bc622fcbc109a3e7bfccb77    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 21 May 2018 15:29:22 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 21 May 2018 15:29:22 -0400    

Click here for diff

M src/backend/catalog/sql_features.txt

doc: Use = after long options in documentation

commit   : ca797f5c049db4adf27495adef1d91b71f0d481c    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 21 May 2018 14:54:24 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 21 May 2018 14:54:24 -0400    

Click here for diff

It's good for consistency and makes the examples easier to read.  

M doc/src/sgml/logicaldecoding.sgml

doc: Fix some trailing whitespace

commit   : f037de6aeb6a4203d15b2b16dfaa194e952dffea    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 21 May 2018 14:49:53 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 21 May 2018 14:49:53 -0400    

Click here for diff

M doc/src/sgml/ecpg.sgml
M doc/src/sgml/ref/alter_index.sgml
M doc/src/sgml/ref/pgbench.sgml
M doc/src/sgml/runtime.sgml
M doc/src/sgml/spgist.sgml

doc: Whitespace fixes in man pages

commit   : 477d243b0f1fb4dfb3ca9e478824ccb7bcda72db    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 21 May 2018 14:41:27 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 21 May 2018 14:41:27 -0400    

Click here for diff

M doc/src/sgml/ref/alter_index.sgml
M doc/src/sgml/ref/alter_table.sgml
M doc/src/sgml/ref/create_policy.sgml
M doc/src/sgml/ref/pg_ctl-ref.sgml

Doc: preliminary list of PG11 major features.

commit   : 4aad161c9a6de56ceb470277038d9583e4260425    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 21 May 2018 12:36:59 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 21 May 2018 12:36:59 -0400    

Click here for diff

This might get bike-shedded a bit later, but it's better than shipping  
beta1 with no list.  
  
Jonathan Katz  
  
Discussion: https://postgr.es/m/D73971C5-8277-44F2-95D9-C0B6E46EB55B@postgresql.org  

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

Translation updates

commit   : 917a68f010eb4c7e91b11ae1abe229cad722f675    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 21 May 2018 12:27:42 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 21 May 2018 12:27:42 -0400    

Click here for diff

Source-Git-URL: git://git.postgresql.org/git/pgtranslation/messages.git  
Source-Git-Hash: 3a5a71cccad5c68e01008e9e3a4f06930197a05e  

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

Fix SQL:2008 FETCH FIRST syntax to allow parameters.

commit   : 1da162e1f5a783bd0ce26e6a07c0138dc8a47d44    
  
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

Update key words table for version 11

commit   : 806d08c0489f72282e0a25629e0d6054176e0c9d    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 21 May 2018 12:14:46 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 21 May 2018 12:14:46 -0400    

Click here for diff

M doc/src/sgml/keywords.sgml

doc: Fix some whitespace issues

commit   : 17485552ec3a7f9a19d568e4bb9b4affae4efdfa    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 21 May 2018 11:41:37 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 21 May 2018 11:41:37 -0400    

Click here for diff

M doc/src/sgml/jit.sgml
M doc/src/sgml/textsearch.sgml

Improve spelling of new FINALFUNC_MODIFY aggregate attribute.

commit   : f755a152d4e3e6f913c6b7b6afe1785b1171c1cb    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 21 May 2018 11:41:42 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 21 May 2018 11:41:42 -0400    

Click here for diff

I'd used SHARABLE as a value originally, but Peter Eisentraut points out  
that dictionaries agree that SHAREABLE is the preferred spelling.  
Run around and change that before it's too late.  
  
Discussion: https://postgr.es/m/d2e1afd4-659c-50d6-1b20-7cfd3675e909@2ndquadrant.com  

M doc/src/sgml/ref/create_aggregate.sgml
M doc/src/sgml/xaggr.sgml
M src/backend/commands/aggregatecmds.c
M src/backend/executor/nodeAgg.c
M src/bin/pg_dump/pg_dump.c
M src/bin/pg_dump/t/002_pg_dump.pl
M src/include/catalog/pg_aggregate.h
M src/include/executor/nodeAgg.h
M src/test/regress/expected/create_aggregate.out
M src/test/regress/sql/create_aggregate.sql

commit   : 3f5e3a98443c7f437465d79e4b99a0a661ae1b9b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 21 May 2018 11:21:08 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 21 May 2018 11:21:08 -0400    

Click here for diff

An xref to a <para>'s ID isn't very helpful because paras don't have  
names.  This causes a warning while building PDFs, though for some  
reason not while building HTML.  The link arguably went to the wrong  
place, too.  
  
To fix, introduce a sub-section we can reference.  

M doc/src/sgml/jit.sgml
M doc/src/sgml/storage.sgml

pg_basebackup: Remove short option -k

commit   : 3ce7f72529f5829f73e18240740bafc939b650b5    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 21 May 2018 10:01:49 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 21 May 2018 10:01:49 -0400    

Click here for diff

-k meant --no-verify-checksums, which is the opposite of what initdb  
uses -k for.  After discussion, a short option does not seem necessary,  
so just keep the long option.  
  
Discussion: https://www.postgresql.org/message-id/flat/d510f8aa-19e1-d06e-7630-ad27f7441d68%402ndquadrant.com  

M doc/src/sgml/ref/pg_basebackup.sgml
M src/bin/pg_basebackup/pg_basebackup.c
M src/bin/pg_basebackup/t/010_pg_basebackup.pl

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

commit   : 81256cd05f0745353c6572362155b57250a0d2a0    
  
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

Fix unportable usage of printf("%m").

commit   : a13b47a59ffce6f3c13c8b777738a3aab1db10d3    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 20 May 2018 18:06:00 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 20 May 2018 18:06:00 -0400    

Click here for diff

While glibc's version of printf accepts %m, most others do not;  
to be portable, we have to do it the hard way with strerror(errno).  
pg_verify_checksums evidently did not get that memo.  
  
Noted while fooling around with NetBSD-current, which generates  
a compiler warning for this mistake.  

M src/bin/pg_verify_checksums/pg_verify_checksums.c

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

commit   : c6e846446d17db40883eed91fa448e65333a0ae1    
  
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 contrib/pageinspect/btreefuncs.c
M doc/src/sgml/ecpg.sgml
M src/backend/access/rmgrdesc/nbtdesc.c
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

Assorted minor cleanups for bootstrap-data Perl scripts.

commit   : e7a808f947c66e2e2186c9495359865dadaf511a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 19 May 2018 16:04:47 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 19 May 2018 16:04:47 -0400    

Click here for diff

FindDefinedSymbol was intended to take an array of possible include  
paths, but it never actually worked correctly for any but the first  
array element.  Since there's no use-case for more than one path  
anyway, let's just simplify this code and its callers by redefining  
it as taking only one include path.  
  
Minor other code-beautification without functional effects, except  
that in one place we format the output as pgindent would do.  
  
John Naylor  
  
Discussion: https://postgr.es/m/CAJVSVGXM_n32hTTkircW4_K1LQFsJNb6xjs0pAP4QC0ZpyJfPQ@mail.gmail.com  

M src/backend/catalog/Catalog.pm
M src/backend/catalog/genbki.pl
M src/backend/utils/Gen_fmgrtab.pl
M src/include/catalog/reformat_dat_file.pl
M src/include/catalog/unused_oids

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

commit   : 06f66cff9e0b93db81db1595156b2aff8ba1786e    
  
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   : a6228128fc48c222953dfd41fd438522a184054c    
  
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

Fix for globals.c- c.h must come first

commit   : e2b83ff556deb9a0001bdf6b511f8cfc9189ac10    
  
author   : Stephen Frost <sfrost@snowman.net>    
date     : Fri, 18 May 2018 21:20:27 -0400    
  
committer: Stephen Frost <sfrost@snowman.net>    
date     : Fri, 18 May 2018 21:20:27 -0400    

Click here for diff

Commit da9b580 mistakenly put a system header before postgres.h (which  
includes c.h).  That can cause portability issues and broke (at least)  
builds with older Windows compilers.  
  
Discovered by Mark Dilger.  
  
Discussion: https://postgr.es/m/BF04A27A-D132-4927-A80A-BAD18695E954@gmail.com  

M src/backend/utils/init/globals.c

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

commit   : 5e79405d82992efce15c27694f10fb4e1ac32657    
  
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

Further adjust comment in get_partition_dispatch_recurse.

commit   : b949bbcb7eaf3719b541cbae99ef6c4b031174a1    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 18 May 2018 16:09:14 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 18 May 2018 16:09:14 -0400    

Click here for diff

In editing 09b12d52db1cf1a4c72d876f3fb6c9d06919e51a I made it wrong;  
fix that and try to more clearly explain the situation.  
  
Patch by me, reviewed by David Rowley and Amit Langote  
  
Discussion: http://postgr.es/m/CA+TgmobAq+mA5hzm0a5OS38qQY5758DDDGqa3sBJN4hvir-H9w@mail.gmail.com  

M src/backend/executor/execPartition.c

Add some test coverage for ecpg's "long long" support.

commit   : dbccdd375b41618ca4ee3d1ea7109ab7f95d0865    
  
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   : f586f8638929b54de9e7f6b65fe6916b8cee38fe    
  
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

Small improvement for plpgsql regression test.

commit   : 7d5b403b8d418742b734f85fda32b0eca8ee4113    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 18 May 2018 12:10:19 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 18 May 2018 12:10:19 -0400    

Click here for diff

Use DISCARD PLANS instead of a reconnect to force reconstruction of  
a cached plan; this corresponds more nearly to what people might  
actually do in practice.  

M src/pl/plpgsql/src/expected/plpgsql_record.out
M src/pl/plpgsql/src/sql/plpgsql_record.sql

Fix error message on short read of pg_control

commit   : cfb758b6d9c1df58fb1dfd5d3f6e70393fb17869    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Fri, 18 May 2018 17:52:18 +0200    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Fri, 18 May 2018 17:52:18 +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

MSVC builds must use a separate stamp file for copying generated headers.

commit   : a194106c1b4468c74dbf6e83d845be86239844aa    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 18 May 2018 11:53:18 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 18 May 2018 11:53:18 -0400    

Click here for diff

Commit bad51a49a tried to use a shortcut with just one stamp file  
recording the actions of generating the pg_*_d.h headers and copying  
them to the src/include/catalog/ directory.  That doesn't work in all  
scenarios though, so we must use two stamp files like the Makefiles do.  
  
John Naylor  
  
Discussion: https://postgr.es/m/CANFyU944GdHr=puPbA78STnqr=8kgMrGF-VDHck6aO_-qNDALg@mail.gmail.com  

M src/tools/msvc/Solution.pm
M src/tools/msvc/clean.bat

Prevent possibly spurious error when running perl -cw

commit   : 3dacd9bf32873c80045a2b758d64c031d70dac83    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 18 May 2018 10:46:38 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 18 May 2018 10:46:38 -0400    

Click here for diff

M src/tools/msvc/Mkvcbuild.pm

Message wording and pluralization improvements

commit   : 9effb63e0dd12b0704cd8e11106fe08ff5c9d685    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 17 May 2018 23:05:27 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 17 May 2018 23:05:27 -0400    

Click here for diff

M src/backend/access/transam/xlog.c
M src/backend/bootstrap/bootstrap.c
M src/bin/pg_basebackup/pg_basebackup.c
M src/bin/pg_basebackup/pg_receivewal.c
M src/bin/pg_basebackup/streamutil.c
M src/bin/pg_controldata/pg_controldata.c
M src/bin/pg_resetwal/pg_resetwal.c
M src/bin/pg_rewind/pg_rewind.c
M src/bin/pg_upgrade/pg_upgrade.c
M src/bin/pg_waldump/pg_waldump.c

Fix whitespace

commit   : 6b30d1386fa37d8ae45e2d30e22771244afd13c3    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 9 May 2018 14:25:04 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 9 May 2018 14:25:04 -0400    

Click here for diff

M src/bin/pg_basebackup/streamutil.c
M src/test/isolation/specs/predicate-gin.spec
M src/test/isolation/specs/predicate-hash.spec
M src/test/regress/sql/func_index.sql
M src/test/regress/sql/index_including.sql

doc: fix description of backward_scan

commit   : 93f6c6328dcf74d1e42162e8f712c23fe16a8cf8    
  
author   : Andrew Gierth <rhodiumtoad@postgresql.org>    
date     : Thu, 17 May 2018 21:23:48 +0100    
  
committer: Andrew Gierth <rhodiumtoad@postgresql.org>    
date     : Thu, 17 May 2018 21:23:48 +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

doc: fix PG 11 attribution

commit   : 91ff29f036349f07b4b48856667735e51ef795a1    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Thu, 17 May 2018 14:23:22 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Thu, 17 May 2018 14:23:22 -0400    

Click here for diff

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

Make numeric power() handle NaNs according to the modern POSIX spec.

commit   : d1fc750b5199837a330c10d542191c8ab03a7dc8    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 17 May 2018 11:10:50 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 17 May 2018 11:10:50 -0400    

Click here for diff

In commit 6bdf1303b, we ensured that power()/^ for float8 would honor  
the NaN behaviors specified by POSIX standards released in this century,  
ie NaN ^ 0 = 1 and 1 ^ NaN = 1.  However, numeric_power() was not  
touched and continued to follow the once-common behavior that every  
case involving NaN input produces NaN.  For consistency, let's switch  
the numeric behavior to the modern spec in the same release that ensures  
that behavior for float8.  
  
(Note that while 6bdf1303b was initially back-patched, we later undid  
that, concluding that any behavioral change should appear only in v11.)  
  
Discussion: https://postgr.es/m/10898.1526421338@sss.pgh.pa.us  

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

doc: PG 11 release notes adjustments

commit   : b2b82228ee5dc08f0341b5480546479c19e84baf    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 16 May 2018 20:36:22 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 16 May 2018 20:36:22 -0400    

Click here for diff

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

Detoast plpgsql variables if they might live across a transaction boundary.

commit   : 2efc924180f096070d684a712d6c162b6ae0a5e7    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 16 May 2018 14:56:52 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 16 May 2018 14:56:52 -0400    

Click here for diff

Up to now, it's been safe for plpgsql to store TOAST pointers in its  
variables because the ActiveSnapshot for whatever query called the plpgsql  
function will surely protect such TOAST values from being vacuumed away,  
even if the owning table rows are committed dead.  With the introduction of  
procedures, that assumption is no longer good in "non atomic" executions  
of plpgsql code.  We adopt the slightly brute-force solution of detoasting  
all TOAST pointers at the time they are stored into variables, if we're in  
a non-atomic context, just in case the owning row goes away.  
  
Some care is needed to avoid long-term memory leaks, since plpgsql tends  
to run with CurrentMemoryContext pointing to its call-lifespan context,  
but we shouldn't assume that no memory is leaked by heap_tuple_fetch_attr.  
In plpgsql proper, we can do the detoasting work in the "eval_mcontext".  
  
Most of the code thrashing here is due to the need to add this capability  
to expandedrecord.c as well as plpgsql proper.  In expandedrecord.c,  
we can't assume that the caller's context is short-lived, so make use of  
the short-term sub-context that was already invented for checking domain  
constraints.  In view of this repurposing, it seems good to rename that  
variable and associated code from "domain_check_cxt" to "short_term_cxt".  
  
Peter Eisentraut and Tom Lane  
  
Discussion: https://postgr.es/m/5AC06865.9050005@anastigmatix.net  

M src/backend/utils/adt/expandedrecord.c
M src/include/postgres.h
M src/include/utils/expandedrecord.h
M src/pl/plpgsql/src/pl_exec.c
A src/test/isolation/expected/plpgsql-toast.out
M src/test/isolation/isolation_schedule
A src/test/isolation/specs/plpgsql-toast.spec

Fix misprocessing of equivalence classes involving record_eq().

commit   : a11b3bd37f14386310f25e89529bd3de8cd64383    
  
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

Pass the correct PlannerInfo to PlanForeignModify/PlanDirectModify.

commit   : 7fc7dac1a711d0dbd01d2daf6dc97d27d6c6409c    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Wed, 16 May 2018 11:32:38 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Wed, 16 May 2018 11:32:38 -0400    

Click here for diff

Previously, we passed the toplevel PlannerInfo, but we actually want  
to pass the relevant subroot.  One problem with passing the toplevel  
PlannerInfo is that the FDW which wants to push down an UPDATE or  
DELETE against a join won't find the relevant joinrel there.  
As of commit 1bc0100d270e5bcc980a0629b8726a32a497e788, postgres_fdw  
tries to do exactly this and can be made to fail an assertion as a  
result.  
  
It's possible that this should be regarded as a bug fix and  
back-patched to earlier releases, but for lack of a test case that  
fails in earlier releases, no back-patch for now.  
  
Etsuro Fujita, reviewed by Amit Langote.  
  
Discussion: http://postgr.es/m/5AF43E02.30000@lab.ntt.co.jp  

M contrib/postgres_fdw/expected/postgres_fdw.out
M contrib/postgres_fdw/sql/postgres_fdw.sql
M src/backend/optimizer/plan/createplan.c

Improve comment in get_partition_dispatch_recurse.

commit   : 09b12d52db1cf1a4c72d876f3fb6c9d06919e51a    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Wed, 16 May 2018 10:46:55 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Wed, 16 May 2018 10:46:55 -0400    

Click here for diff

David Rowley, reviewed by Amit Langote, and revised a bit by me.  
  
Discussion: http://postgr.es/m/CAKJS1f9yyimYyFzbHM4EwE+tkj4jvrHqSH0H4S4Kbas=UFpc9Q@mail.gmail.com  

M src/backend/executor/execPartition.c

docs: add space in PG 11 release notes, huge/large

commit   : 6bd1b4c31b56b5d0bbd50c6df7f49c5812174a43    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 15 May 2018 20:03:42 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 15 May 2018 20:03:42 -0400    

Click here for diff

Reported-by: Tatsuo Ishii  

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

docs: PG 11 rel notes, 'ps' display/background worker item

commit   : 7a4a37542311720e0c4e47dc0e7a94254eaf47bf    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 15 May 2018 19:57:40 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 15 May 2018 19:57:40 -0400    

Click here for diff

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

doc: adjust Extended Query PG 11 release note item

commit   : 3b07f6dadb359e88c5a4b8375765d2c10d9eabce    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 15 May 2018 19:12:16 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 15 May 2018 19:12:16 -0400    

Click here for diff

Reported-by: Tatsuo Ishii  

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

docs: update PG 11 release notes based on feedback

commit   : 3122e320913db0288d0b96a7eb65401962c4781b    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 15 May 2018 15:55:53 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 15 May 2018 15:55:53 -0400    

Click here for diff

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

Fix type checking for support functions of parallel VARIADIC aggregates.

commit   : 05ca21b878a9e483a4635ba4b23e0f45d5442fc3    
  
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: clarify SCRAM channel binding

commit   : 185f4f84d5952e5692bd2712dd32288fcbb7fa71    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 14 May 2018 20:45:35 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 14 May 2018 20:45:35 -0400    

Click here for diff

Discussion: https://postgr.es/m/20180514231020.GB1600@paquier.xyz  
  
Reviewed-by: Michael Paquier  

M doc/src/sgml/libpq.sgml
M doc/src/sgml/protocol.sgml

doc: update PG 11 release notes with suggested changes

commit   : cf9c75ccea0bc15ce54c6fb017cd3edba03da743    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 14 May 2018 16:41:49 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 14 May 2018 16:41:49 -0400    

Click here for diff

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

Don't allow partitioned index on foreign-table partitions

commit   : 4eaa53727542c39cca71b80e8ff3e1f742d64452    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 14 May 2018 13:09:32 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 14 May 2018 13:09:32 -0400    

Click here for diff

Creating indexes on foreign tables is already forbidden, but local  
partitioned indexes (commit 8b08f7d4820f) forgot to check for them.  Add  
a preliminary check to prevent wasting time.  
  
Another school of thought says to allow the index to be created if it's  
not a unique index; but it's possible to do better in the future (enable  
indexing of foreign tables, somehow), so we avoid painting ourselves in  
a corner by rejecting all cases, to avoid future grief (a.k.a. backward  
incompatible changes).  
  
Reported-by: Arseny Sher  
Author: Amit Langote, Álvaro Herrera  
Discussion: https://postgr.es/m/87sh71cakz.fsf@ars-thinkpad  

M src/backend/tcop/utility.c
M src/test/regress/expected/foreign_data.out
M src/test/regress/sql/foreign_data.sql

Fix file paths in comments

commit   : fc2a41e23e10f2338be4907f71c277ea09526680    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Mon, 14 May 2018 18:59:43 +0200    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Mon, 14 May 2018 18:59:43 +0200    

Click here for diff

Author: Daniel Gustafsson <daniel@yesql.se>  

M src/backend/utils/adt/inet_cidr_ntop.c
M src/port/inet_net_ntop.c

psql: have \d show FKs on partitioned tables

commit   : 93316299d6a185bed0a4be5376508fe2f7e6b2d6    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 14 May 2018 11:43:14 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 14 May 2018 11:43:14 -0400    

Click here for diff

Commit 3de241dba86f missed to update psql to display foreign keys on  
partitioned tables.  Add that.  
  
Reported-by: Amit Langote  
Author: Amit Langote  
Reviewed-by: Álvaro Herrera  
Discussion: https://postgr.es/m/a66879e5-636f-d4dd-b4a4-92bdca5a828f@lab.ntt.co.jp  

M src/bin/psql/describe.c

Doc: fix minor release-note typo.

commit   : 60e2d9ab1437c8e4b12e7766198cf2e84f7d267e    
  
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

doc: update PG 11 rel. notes for ALTER TABLE's non-null default

commit   : 8c6227a2f3cdf144c4de135329fd76eb66f5684a    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Sat, 12 May 2018 20:46:37 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Sat, 12 May 2018 20:46:37 -0400    

Click here for diff

Reported-by: Peter Geoghegan  

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

docs: Rework sections on partition pruning/exclusion

commit   : bebc46931a1215567d4aabaebb406848f5a82340    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Sat, 12 May 2018 12:08:17 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Sat, 12 May 2018 12:08:17 -0300    

Click here for diff

Explain partition pruning more thoroughly, in a section above the one  
that explains constraint exclusion, since the new feature is the one  
that will be used more extensively from now on.  Move some of the  
material from the constraint exclusion subsection to the one on  
partition pruning, so that we can explain the legacy method by  
explaining the differences with the new one instead of repeating it.  
  
Author: David Rowley, Álvaro Herrera  
Reviewed-by: Amit Langote, David G. Johnston, Justin Pryzby  
Discussion: https://postgr.es/m/CAKJS1f8PECxEi1YQ9nhVtshtfOMHUzAMm_Zp4gGCOCnMPjEKJA@mail.gmail.com  

M doc/src/sgml/config.sgml
M doc/src/sgml/ddl.sgml

Doc: fix overenthusiastic markup.

commit   : d9fcf7f5e387c29427ff37b5e0fb0763f9a2b10a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 11 May 2018 17:19:21 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 11 May 2018 17:19:21 -0400    

Click here for diff

I get "WARNING: nested link may be undefined in output: <xref @linkend =  
'pgbench'> nested inside parent element link" from this.  
  
Also remove some trailing whitespace.  

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

docs: more PG 11 markup and email suggestions

commit   : fb68638ae8af3d5f5a9dcddb8e513f21b2797361    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Fri, 11 May 2018 17:06:22 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Fri, 11 May 2018 17:06:22 -0400    

Click here for diff

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

doc: markup for PG 11 release notes and included email tips

commit   : 6186d0bd615ed2eb921ad13ccdf4ceed19d3f7a8    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Fri, 11 May 2018 14:47:26 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Fri, 11 May 2018 14:47:26 -0400    

Click here for diff

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

docs: initial draft of PG 11 release notes

commit   : 5631c99d2a374e17abcb2ff63f58fcaf5c3a5248    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Fri, 11 May 2018 10:54:03 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Fri, 11 May 2018 10:54:03 -0400    

Click here for diff

M doc/src/sgml/filelist.sgml
A doc/src/sgml/release-11.sgml
M doc/src/sgml/release.sgml

docs: clarify that CREATE TABLE ... _AS_ can be parallelized

commit   : 25468994cab87ab7e946b6866937ee642fc1261d    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Thu, 10 May 2018 22:37:26 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Thu, 10 May 2018 22:37:26 -0400    

Click here for diff

CREATE TABLE without AS doesn't have anything to parallelize.  

M doc/src/sgml/parallel.sgml

Various improvements of skipping index scan during vacuum technics

commit   : 8e12f4a250d250a89153da2eb9b91c31bb80c483    
  
author   : Teodor Sigaev <teodor@sigaev.ru>    
date     : Thu, 10 May 2018 13:31:47 +0300    
  
committer: Teodor Sigaev <teodor@sigaev.ru>    
date     : Thu, 10 May 2018 13:31:47 +0300    

Click here for diff

- Change vacuum_cleanup_index_scale_factor GUC to PGC_USERSET.  
  vacuum_cleanup_index_scale_factor GUC was defined as PGC_SIGHUP.  But this  
  GUC affects not only autovacuum.  So it might be useful to change it from user  
  session in order to influence manually runned VACUUM.  
- Add missing tab-complete support for vacuum_cleanup_index_scale_factor  
  reloption.  
- Fix condition for B-tree index cleanup.  
  Zero value of vacuum_cleanup_index_scale_factor means that user wants B-tree  
  index cleanup to be never skipped.  
- Documentation and comment improvements  
  
Authors: Justin Pryzby, Alexander Korotkov, Liudmila Mantrova  
Reviewed by: all authors and Robert Haas  
Discussion: https://www.postgresql.org/message-id/flat/20180502023025.GD7631%40telsasoft.com  

M doc/src/sgml/config.sgml
M src/backend/access/nbtree/nbtpage.c
M src/backend/access/nbtree/nbtree.c
M src/backend/utils/misc/guc.c
M src/bin/psql/tab-complete.c

doc: Restrictions on InitPlans in parallel queries relaxed.

commit   : ddc1f32ee5073503a396c7a4df32865205dd3970    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Wed, 9 May 2018 15:15:03 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Wed, 9 May 2018 15:15:03 -0400    

Click here for diff

This updates the documentation for changes originally made in commit  
e89a71fb449af2ef74f47be1175f99956cf21524.  
  
Patch by me, reviewed (but not entirely endorsed) by Amit Kapila.  
  
Discussion: http://postgr.es/m/CA+Tgmoa+vupW8V_gBonz6hU7WwN2zJ=UTsVWCVB+rN6vaaXfZw@mail.gmail.com  

M doc/src/sgml/parallel.sgml

Update time zone data files to tzdata release 2018e.

commit   : 234bb985c574d1ed9e63d382b327ac3d3e329c56    
  
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

pgstatindex, pageinspect: handle partitioned indexes

commit   : bef5fcc36be3d08ec123889a0c82f5e07a63ff88    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 9 May 2018 14:03:43 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 9 May 2018 14:03:43 -0300    

Click here for diff

Commit 8b08f7d4820f failed to update these modules to at least give  
non-broken error messages for partitioned indexes.  Add appropriate  
error support to them.  
  
Peter G. was complaining about a problem of unfriendly error messages;  
while we haven't fixed that yet, subsequent discussion let to discovery  
of these unhandled cases.  
  
Author: Michaël Paquier  
Reported-by: Peter Geoghegan  
Discussion: https://postgr.es/m/CAH2-WzkOKptQiE51Bh4_xeEHhaBwHkZkGtKizrFMgEkfUuRRQg@mail.gmail.com  

M contrib/pageinspect/expected/page.out
M contrib/pageinspect/rawpage.c
M contrib/pageinspect/sql/page.sql
M contrib/pgstattuple/expected/pgstattuple.out
M contrib/pgstattuple/pgstatindex.c
M contrib/pgstattuple/pgstattuple.c
M contrib/pgstattuple/sql/pgstattuple.sql

pgstatindex: HASH -> hash

commit   : c8478f4fd908b5a122b5638018bbb749ac0e862f    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 9 May 2018 13:44:50 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 9 May 2018 13:44:50 -0300    

Click here for diff

Fix the lone error message in the whole source tree to use capitalized  
HASH when referring to hash indexes, making it look like all the other  
messages.  
  
Someday it would be good to standardize 'B-Tree', 'B-tree', 'btree', and  
random other spellings, too, but that's a larger patch ...  
  
Author: Álvaro Herrera  

M contrib/pgstattuple/expected/pgstattuple.out
M contrib/pgstattuple/pgstatindex.c

Add relkind 'I' to catalog.sgml's list relkinds

commit   : 550091f218ce9bff92e3753332142ed6917c27d5    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 9 May 2018 13:32:50 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 9 May 2018 13:32:50 -0300    

Click here for diff

Commit 8b08f7d4820f added a relkind for local partitioned indexes, but  
failed to add it to pg_class's list of possible relkinds.  Repair.  
  
Author: Peter Geoghegan, Michaël Paquier  
Discussion: https://postgr.es/m/CAH2-WzkOKptQiE51Bh4_xeEHhaBwHkZkGtKizrFMgEkfUuRRQg@mail.gmail.com  

M doc/src/sgml/catalogs.sgml

Fix assorted partition pruning bugs

commit   : d758d9702e2f64f08565e18eb6cb7991efa2dc16    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 9 May 2018 10:51:23 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 9 May 2018 10:51:23 -0300    

Click here for diff

match_clause_to_partition_key failed to consider COERCION_PATH_ARRAYCOERCE  
cases in scalar-op-array expressions, so it was possible to crash the  
server easily.  To handle this case properly (ie. prune partitions) we  
would need to run a bit of executor code during planning.  Maybe it can  
be improved, but for now let's just not crash.  Add a test case that  
used to trigger the crash.  
Author: Michaël Paquier  
  
match_clause_to_partition_key failed to indicate that operators that  
don't have a commutator in a btree opclass are unsupported.  It is  
possible for this to cause a crash later if such an operator is used in  
a scalar-op-array expression.  Add a test case that used to the crash.  
Author: Amit Langote  
  
One caller of gen_partprune_steps_internal in  
match_clause_to_partition_key was too optimistic about the former never  
returning an empty step list.  Rid it of its innocence.  (Having fixed  
the bug above, I no longer know how to exploit this, so no test case for  
it, but it remained a bug.)  Revise code flow a little bit, for  
succintness.  
Author: Álvaro Herrera  
  
Reported-by: Marina Polyakova  
Reviewed-by: Michaël Paquier  
Reviewed-by: Amit Langote  
Reviewed-by: Álvaro Herrera  
Discussion: https://postgr.es/m/ff8f9bfa485ff961d6bb43e54120485b@postgrespro.ru  

M src/backend/partitioning/partprune.c
M src/test/regress/expected/partition_prune.out
M src/test/regress/sql/partition_prune.sql

Restrict vertical tightness to parentheses in Perl code

commit   : 35361ee78890ce5b559a710c8fa2fdfa843eb280    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Wed, 9 May 2018 10:14:46 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Wed, 9 May 2018 10:14:46 -0400    

Click here for diff

The vertical tightness settings collapse vertical whitespace between  
opening and closing brackets (parentheses, square brakets and braces).  
This can make data structures in particular harder to read, and is not  
very consistent with our style in non-Perl code. This patch restricts  
that setting to parentheses only, and reformats all the perl code  
accordingly. Not applying this to parentheses has some unfortunate  
effects, so the consensus is to keep the setting for parentheses and not  
for the others.  
  
The diff for this patch does highlight some places where structures  
should have trailing commas. They can be added manually, as there is no  
automatic tool to do so.  
  
Discussion: https://postgr.es/m/a2f2b87c-56be-c070-bfc0-36288b4b41c1@2ndQuadrant.com  

M src/backend/catalog/Catalog.pm
M src/backend/utils/Gen_fmgrtab.pl
M src/backend/utils/mb/Unicode/UCS_to_BIG5.pl
M src/backend/utils/mb/Unicode/UCS_to_EUC_CN.pl
M src/backend/utils/mb/Unicode/UCS_to_EUC_JIS_2004.pl
M src/backend/utils/mb/Unicode/UCS_to_EUC_JP.pl
M src/backend/utils/mb/Unicode/UCS_to_EUC_KR.pl
M src/backend/utils/mb/Unicode/UCS_to_EUC_TW.pl
M src/backend/utils/mb/Unicode/UCS_to_GB18030.pl
M src/backend/utils/mb/Unicode/UCS_to_JOHAB.pl
M src/backend/utils/mb/Unicode/UCS_to_SHIFT_JIS_2004.pl
M src/backend/utils/mb/Unicode/UCS_to_SJIS.pl
M src/backend/utils/mb/Unicode/UCS_to_UHC.pl
M src/backend/utils/mb/Unicode/convutils.pm
M src/bin/pg_archivecleanup/t/010_pg_archivecleanup.pl
M src/bin/pg_basebackup/t/010_pg_basebackup.pl
M src/bin/pg_basebackup/t/020_pg_receivewal.pl
M src/bin/pg_basebackup/t/030_pg_recvlogical.pl
M src/bin/pg_controldata/t/001_pg_controldata.pl
M src/bin/pg_ctl/t/001_start_stop.pl
M src/bin/pg_dump/t/002_pg_dump.pl
M src/bin/pg_dump/t/010_dump_connstr.pl
M src/bin/pg_resetwal/t/002_corrupted.pl
M src/bin/pg_rewind/RewindTest.pm
M src/bin/pg_rewind/t/003_extrafiles.pl
M src/bin/pgbench/t/001_pgbench_with_server.pl
M src/bin/pgbench/t/002_pgbench_no_server.pl
M src/bin/psql/create_help.pl
M src/test/kerberos/t/001_auth.pl
M src/test/modules/test_pg_dump/t/001_base.pl
M src/test/perl/PostgresNode.pm
M src/test/perl/TestLib.pm
M src/test/recovery/t/006_logical_decoding.pl
M src/test/recovery/t/011_crash_recovery.pl
M src/test/recovery/t/013_crash_restart.pl
M src/test/ssl/ServerSetup.pm
M src/tools/git_changelog
M src/tools/msvc/Install.pm
M src/tools/msvc/MSBuildProject.pm
M src/tools/msvc/Mkvcbuild.pm
M src/tools/msvc/Project.pm
M src/tools/msvc/Solution.pm
M src/tools/msvc/VCBuildProject.pm
M src/tools/pgindent/perltidyrc
M src/tools/pgindent/pgindent
M src/tools/win32tzlist.pl

perltidy some recent code changes before changing perltidy settings

commit   : 286bb240e1c8e279efa2d805c7f700abfb771925    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Wed, 9 May 2018 10:04:17 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Wed, 9 May 2018 10:04:17 -0400    

Click here for diff

M src/backend/catalog/Catalog.pm
M src/tools/msvc/Install.pm
M src/tools/msvc/vcregress.pl

Make gen_partprune_steps static

commit   : d1e2cac5ff7eaf3e9feac419205b3e08052be961    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 9 May 2018 10:40:21 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 9 May 2018 10:40:21 -0300    

Click here for diff

There's no need to export this function, so don't.  Michaël didn't  
actually write the patch, but we list him as first author because with a  
trivial one like this, intellectual authorship is as important (if not  
more) as bit shovelling.  
  
Author: Michaël Paquier, Amit Langote  
Discussion: https://postgr.es/m/c91299c4-199b-0f16-339b-a29d6d2a39ee@lab.ntt.co.jp  

M src/backend/partitioning/partprune.c
M src/include/partitioning/partprune.h

Remove useless 'default' clause

commit   : c775fb9e18ace94e61d5d9587b5667f7baaca459    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 9 May 2018 10:33:55 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 9 May 2018 10:33:55 -0300    

Click here for diff

Author: Michael Paquier  
Reviewed-by: Amit Langote  
Reviewed-by: Álvaro Herrera  
Discussion: https://postgr.es/m/20180424012042.GD1570@paquier.xyz  
Discussion: https://postgr.es/m/20180509061039.GC11897@paquier.xyz  

M src/backend/partitioning/partprune.c

Add a script and a config file to run perlcritic

commit   : 91703ca2144e58d041c132fb7ff06a6d1721e904    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Wed, 9 May 2018 07:55:23 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Wed, 9 May 2018 07:55:23 -0400    

Click here for diff

This is similar to what we do to run perltidy. For now we only run at  
severity level 5. Over time we can improve our perl code and reduce the  
severity level.  
  
Discussion: https://postgr.es/m/86aa2a3a-0c68-21fb-9560-84ad6914d561@2ndQuadrant.com  

A src/tools/pgperlcritic/perlcriticrc
A src/tools/pgperlcritic/pgperlcritic

Improve jsonb cast error message

commit   : cb5d94295986298af666534970f9bb3715574646    
  
author   : Teodor Sigaev <teodor@sigaev.ru>    
date     : Wed, 9 May 2018 13:23:16 +0300    
  
committer: Teodor Sigaev <teodor@sigaev.ru>    
date     : Wed, 9 May 2018 13:23:16 +0300    

Click here for diff

Initial variant of error message didn't follow style of another casting error  
messages and wasn't informative. Per gripe from Robert Haas.  
  
Reviewer: Tom Lane  
Discussion: https://www.postgresql.org/message-id/flat/CA%2BTgmob08StTV9yu04D0idRFNMh%2BUoyKax5Otvrix7rEZC8rMw%40mail.gmail.com#CA+Tgmob08StTV9yu04D0idRFNMh+UoyKax5Otvrix7rEZC8rMw@mail.gmail.com  

M src/backend/utils/adt/jsonb.c
M src/test/regress/expected/jsonb.out

Improve inefficient regexes in vacuumdb TAP test.

commit   : c63913ca7d1df241149a02fddf9819952b998028    
  
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

Improve initdb's query for generating default descriptions a little.

commit   : dec10340d5ba63cf338dea256ac0fa66c649bf9e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 8 May 2018 15:59:01 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 8 May 2018 15:59:01 -0400    

Click here for diff

While poking into initdb's performance, I noticed that this query  
wasn't being done very intelligently.  By forcing it to execute  
obj_description() for each pg_proc/pg_operator join row, we were  
essentially setting up a nestloop join to pg_description, which  
is not a bright query plan when there are hundreds of outer rows.  
Convert the check for a "deprecated" operator into a NOT EXISTS  
so that it can be done as a hashed antijoin.  On my workstation  
this reduces the time for this query from ~ 35ms to ~ 10ms.  
Which is not a huge win, but it adds up over buildfarm runs.  
  
In passing, insert forced query breaks (\n\n, in single-user mode)  
after each SQL-query file that initdb sources, and after some  
relatively new queries in setup_privileges().  This doesn't make  
a lot of difference normally, but it will result in briefer, saner  
error messages if anything goes wrong.  

M src/bin/initdb/initdb.c

Refine error messages

commit   : 831f5d11ec7bb8a693c581720d014b3a5ad7d446    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 8 May 2018 14:36:31 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 8 May 2018 14:36:31 -0400    

Click here for diff

"JSON" when not referring to a data type should be upper case.  

M src/backend/utils/adt/jsonfuncs.c
M src/test/regress/expected/json.out
M src/test/regress/expected/jsonb.out

Count heap tuples in non-SnapshotAny path in IndexBuildHeapRangeScan().

commit   : 3a675f729ea96c8bf3e764996a0c743500e564ef    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 8 May 2018 00:20:19 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 8 May 2018 00:20:19 -0400    

Click here for diff

Brown-paper-bag bug in commit 7c91a0364: when we rearranged the placement  
of "reltuples += 1" statements, we missed including one in this code path.  
  
The net effect of that was that CREATE INDEX CONCURRENTLY would set the  
table's pg_class.reltuples to zero, as would index builds done during  
bootstrap mode.  (It seems like parallel index builds ought to fail  
similarly, but they don't, perhaps because reltuples is computed in some  
other way.  You certainly couldn't figure that out from the abysmally  
underdocumented parallelism code in this area.)  
  
I was led to this by wondering why initdb seemed to have slowed down as  
a result of 7c91a0364, as is evident in the buildfarm's timing history.  
The reason is that every system catalog with indexes had pg_class.reltuples  
= 0 after bootstrap, causing the planner to make some terrible choices for  
queries in the post-bootstrap steps.  On my workstation, this fix causes  
the runtime of "initdb -N" to drop from ~2.0 sec to ~1.4 sec, which is  
almost though not quite back to where it was in v10.  That's not much of  
a deal for production use perhaps, but it makes a noticeable difference  
for buildfarm and "make check-world" runs, which do a lot of initdbs.  

M src/backend/catalog/index.c

Clean up some perlcritic warnings

commit   : d2c1512ac48c1c25dfec07d341e9b74e57f6fbc4    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 7 May 2018 15:21:00 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 7 May 2018 15:21:00 -0400    

Click here for diff

In Catalog.pm, mark eval of a string instead of a block as allowed.  
Disallow perlcritic completely in Gen_dummy_probes.pl, as it's  
generated code.  
Protect a couple of lines in plperl code from  perltidy, so that the  
annotation for perlcritic stays on the same line as the construct it  
would otherwise object to.  

M src/backend/catalog/Catalog.pm
M src/backend/utils/Gen_dummy_probes.pl
M src/pl/plperl/plc_perlboot.pl
M src/pl/plperl/plc_trusted.pl

Undo extra chattiness of postmaster logs in TAP tests.

commit   : 17551f1a21fa8e70aa0bca1153de03460742565c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 7 May 2018 15:12:01 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 7 May 2018 15:12:01 -0400    

Click here for diff

Commit 6271fceb8 changed PostgresNode.pm to force log_min_messages = debug1  
in all TAP tests, without any discussion and without a concrete need for  
it.  This makes some of the TAP tests noticeably slower (although much of  
that may be due to poorly-written regexes), and for certain it's bloating  
the buildfarm logs.  Revert the change.  
  
Discussion: https://postgr.es/m/32459.1525657786@sss.pgh.pa.us  

M src/test/perl/PostgresNode.pm

Update oidjoins regression test for v11.

commit   : fbb99e5883d88687de4dbd832c2843f600ab3dd8    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 7 May 2018 14:32:04 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 7 May 2018 14:32:04 -0400    

Click here for diff

Commit 86f575948 already manually updated the oidjoins test for the  
new pg_constraint.conparentid => pg_constraint.oid relationship, but  
failed to update findoidjoins/README, thus the apparent inconsistency  
here.  
  
Michael Paquier  
  
Discussion: https://postgr.es/m/20180507001811.GA27389@paquier.xyz  

M src/test/regress/expected/oidjoins.out
M src/test/regress/sql/oidjoins.sql
M src/tools/findoidjoins/README

Suppress compiler warnings when building with --enable-dtrace.

commit   : 513ff52e81675f26ceb91e8301019546439d73c9    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 7 May 2018 13:44:09 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 7 May 2018 13:44:09 -0400    

Click here for diff

Most versions of "dtrace -h" drop const qualifiers from the declarations  
of probe functions (though macOS gets it right).  This causes compiler  
warnings when we pass in pointers to const.  Repair by extending our  
existing post-processing of the probes.h file.  To do so, assume that all  
"char *" arguments should be "const char *"; that seems reasonably safe.  
  
Thomas Munro  
  
Discussion: https://postgr.es/m/CAEepm=2j1pWSruQJqJ91ZDzD8w9ZZDsM4j2C6x75C-VryWg-_w@mail.gmail.com  

M src/backend/utils/Makefile

Last-minute updates for release notes.

commit   : f34f0e4c58a31e5edd3aa8a23e171fbcf7e01ff2    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 7 May 2018 13:13:27 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 7 May 2018 13:13:27 -0400    

Click here for diff

The set of functions that need parallel-safety adjustments isn't the  
same in 9.6 as 10, so I shouldn't have blindly back-patched that list.  
Adjust as needed.  Also, provide examples of the commands to issue.  

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

Last-minute updates for release notes.

commit   : b56d5f230fae5fccf4fb9f255dfa78b01afed0d9    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 7 May 2018 11:50:05 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 7 May 2018 11:50:05 -0400    

Click here for diff

Security: CVE-2018-1115  

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

doc: Improve spelling and wording a bit

commit   : a43a4509f8a9249ba6c2734596c029f0430a75bc    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 7 May 2018 11:05:19 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 7 May 2018 11:05:19 -0400    

Click here for diff

M doc/src/sgml/config.sgml

doc: Fix minor markup issue

commit   : baf21b922a18c2809068238503ebb3797994e615    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 7 May 2018 10:16:17 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 7 May 2018 10:16:17 -0400    

Click here for diff

There shouldn't be a line break between two adjacent tags, because that  
will appear as whitespace in the output.  (The rendering engine might in  
turn collapse that whitespace away, so it might not actually make a  
difference, but it's more correct this way.)  

M doc/src/sgml/config.sgml

adminpack: Revoke EXECUTE on pg_logfile_rotate()

commit   : 7b347409fa2776fbaa4ec9c57365f48a2bbdb80c    
  
author   : Stephen Frost <sfrost@snowman.net>    
date     : Mon, 7 May 2018 10:10:33 -0400    
  
committer: Stephen Frost <sfrost@snowman.net>    
date     : Mon, 7 May 2018 10:10:33 -0400    

Click here for diff

In 9.6, we moved a number of functions over to using the GRANT system to  
control access instead of having hard-coded superuser checks.  
  
As it turns out, adminpack was creating another function in the catalog  
for one of those backend functions where the superuser check was  
removed, specifically pg_rotate_logfile(), but it didn't get the memo  
about having to REVOKE EXECUTE on the alternative-name function  
(pg_logfile_rotate()), meaning that in any installations with adminpack  
on 9.6 and higher, any user is able to run the pg_logfile_rotate()  
function, which then calls pg_rotate_logfile() and rotates the logfile.  
  
Fix by adding a new version of adminpack (1.1) which handles the REVOKE.  
As this function should have only been available to the superuser, this  
is a security issue, albeit a minor one.  
  
In HEAD, move the changes implemented for adminpack up to be adminpack  
2.0 instead of 1.1.  
  
Security: CVE-2018-1115  

M contrib/adminpack/Makefile
M contrib/adminpack/adminpack–1.0–1.1.sql
A contrib/adminpack/adminpack–1.1–2.0.sql
M contrib/adminpack/adminpack.control

Documentation updates for partitioning.

commit   : f955d7ee166dfa053caa6d1bdb2a28b28b212fe3    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Mon, 7 May 2018 09:48:47 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Mon, 7 May 2018 09:48:47 -0400    

Click here for diff

Takayuki Tsunakawa  
  
Discussion: http://postgr.es/m/0A3221C70F24FB45833433255569204D1F965627@G01JPEXMBYT05  

M doc/src/sgml/catalogs.sgml
M doc/src/sgml/ref/create_table.sgml

Remove unused macro

commit   : 659442e40d57af5ea00dfc3d31266ef0cfb8278e    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Sun, 6 May 2018 20:10:05 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Sun, 6 May 2018 20:10:05 -0400    

Click here for diff

left behind by db3af9feb19f39827e916145f88fa5eca3130cb2  

M src/test/regress/regress.c

Release notes for 10.4, 9.6.9, 9.5.13, 9.4.18, 9.3.23.

commit   : 2667e019c61f392c6af28afeee43dbfdcc943d28    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 6 May 2018 15:30:44 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 6 May 2018 15:30:44 -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

Clear severity 5 perlcritic warnings from vcregress.pl

commit   : 2b9bdda74485909a4a3067bf0ba3f0821e82660e    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Sun, 6 May 2018 07:37:05 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Sun, 6 May 2018 07:37:05 -0400    

Click here for diff

My recent update for python3 support used some idioms that are  
unapproved. This fixes them. Backpatch to all live branches like the  
original.  

M src/tools/msvc/vcregress.pl

Fix bootstrap parser so that its keywords are unreserved words.

commit   : d160882a17403d61bc04c5745493e027e60165ce    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 5 May 2018 16:23:07 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 5 May 2018 16:23:07 -0400    

Click here for diff

Mark Dilger pointed out that the bootstrap parser does not allow  
any of its keywords to appear as column values unless they're quoted,  
and proposed dealing with that by quoting such values in genbki.pl.  
Looking closer, though, we also have that problem with respect to table,  
column, and type names appearing in the .bki file: the parser would fail  
if any of those matched any of its keywords.  While so far there have  
been no conflicts (that I've heard of), this seems like a booby trap  
waiting to catch somebody.  Rather than clutter genbki.pl with enough  
quoting logic to handle all that, let's make the bootstrap parser grow  
up a little bit and treat its keywords as unreserved.  
  
Experimentation shows that it's fairly easy to do so with the exception  
of _null_, which I don't have a big problem with keeping as a reserved  
word.  The only change needed is that we can't have the "close" command  
take an optional table name: it has to either require or forbid the  
table name to avoid shift/reduce conflicts.  genbki.pl has historically  
always included the table name, so I took that option.  
  
The implementation has bootscanner.l passing forward the string value  
of each keyword, in case bootparse.y needs that.  This avoids needing to  
know the precise spelling of each keyword in bootparse.y, which is good  
because that's not always obvious from the token name.  
  
Discussion: https://postgr.es/m/3024FC91-DB6D-4732-B31C-DF772DF039A0@gmail.com  

M doc/src/sgml/bki.sgml
M src/backend/bootstrap/bootparse.y
M src/backend/bootstrap/bootscanner.l

Revert "Test conversion of NaN between float4 and float8."

commit   : 5c4c771dafefa7d0ee80a6bd6955b7a3940452a1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 5 May 2018 13:22:11 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 5 May 2018 13:22:11 -0400    

Click here for diff

This reverts commit 55e0e458170c76c1a0074cd550a13ec47e38a3fa.  
It's served its purpose of demonstrating what was wrong on  
buildfarm member opossum.  We could consider putting some kind  
of single-purpose hack into ftod() to make the test pass there;  
but I don't think it's worth the trouble, since there are surely  
many other places whether this platform bug could manifest.  

M src/test/regress/expected/float4-exp-three-digits.out
M src/test/regress/expected/float4.out
M src/test/regress/sql/float4.sql

Put in_range_float4_float8's work in-line.

commit   : cb3e9e40bc993128cd51795ea60ff7bed78cebb5    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 5 May 2018 13:21:50 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 5 May 2018 13:21:50 -0400    

Click here for diff

In commit 8b29e88cd, I'd dithered about whether to make  
in_range_float4_float8 be a standalone copy of the float in-range logic  
or have it punt to in_range_float8_float8.  I went with the latter, which  
saves code space though at the cost of performance and readability.  
  
However, it emerges that this tickles a compiler or hardware bug on  
buildfarm member opossum.  Test results from commit 55e0e4581 show  
conclusively that widening a float4 NaN to float8 produces Inf, not NaN,  
on that machine; which accounts perfectly for the window RANGE test  
failures it's been showing.  We can dodge this problem by making  
in_range_float4_float8 be an independent function, so that it checks  
for NaN inputs before widening them.  
  
Ordinarily I'd not be very excited about working around such obviously  
broken functionality; but given that this was a judgment call to begin  
with, I don't mind reversing it.  

M src/backend/utils/adt/float.c

Remove extra newlines after PQerrorMessage()

commit   : 2f52518773bb01384ef20831fd9d8c76dbd59dc5    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Sat, 5 May 2018 10:51:38 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Sat, 5 May 2018 10:51:38 -0400    

Click here for diff

M src/bin/pg_basebackup/streamutil.c
M src/bin/pg_dump/pg_dumpall.c

First-draft release notes for 10.4.

commit   : 488ccfe40a865e3f3c6343e2de026c37ba5a7d50    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 4 May 2018 18:56:50 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 4 May 2018 18:56:50 -0400    

Click here for diff

As usual, the release notes for other branches will be made by cutting  
these down, but put them up for community review first.  

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

Fix scenario where streaming standby gets stuck at a continuation record.

commit   : 0668719801838aa6a8bda330ff9b3d20097ea844    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Sat, 5 May 2018 01:34:53 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Sat, 5 May 2018 01:34:53 +0300    

Click here for diff

If a continuation record is split so that its first half has already been  
removed from the master, and is only present in pg_wal, and there is a  
recycled WAL segment in the standby server that looks like it would  
contain the second half, recovery would get stuck. The code in  
XLogPageRead() incorrectly started streaming at the beginning of the  
WAL record, even if we had already read the first page.  
  
Backpatch to 9.4. In principle, older versions have the same problem, but  
without replication slots, there was no straightforward mechanism to  
prevent the master from recycling old WAL that was still needed by standby.  
Without such a mechanism, I think it's reasonable to assume that there's  
enough slack in how many old segments are kept around to not run into this,  
or you have a WAL archive.  
  
Reported by Jonathon Nelson. Analysis and patch by Kyotaro HORIGUCHI, with  
some extra comments by me.  
  
Discussion: https://www.postgresql.org/message-id/CACJqAM3xVz0JY1XFDKPP%2BJoJAjoGx%3DGNuOAshEDWCext7BFvCQ%40mail.gmail.com  

M src/backend/access/transam/xlog.c
M src/backend/access/transam/xlogreader.c
M src/include/access/xlogreader.h

Don't mark pages all-visible spuriously

commit   : d2599ecfcc74fea9fad1720a70210a740c716730    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 4 May 2018 15:24:44 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 4 May 2018 15:24:44 -0300    

Click here for diff

Dan Wood diagnosed a long-standing problem that pages containing tuples  
that are locked by multixacts containing live lockers may spuriously end  
up as candidates for getting their all-visible flag set.  This has the  
long-term effect that multixacts remain unfrozen; this may previously  
pass undetected, but since commit XYZ it would be reported as  
  "ERROR: found multixact 134100944 from before relminmxid 192042633"  
because when a later vacuum tries to freeze the page it detects that a  
multixact that should have gotten frozen, wasn't.  
  
Dan proposed a (correct) patch that simply sets a variable to its  
correct value, after a bogus initialization.  But, per discussion, it  
seems better coding to avoid the bogus initializations altogether, since  
they could give rise to more bugs later.  Therefore this fix rewrites  
the logic a little bit to avoid depending on the bogus initializations.  
  
This bug was part of a family introduced in 9.6 by commit a892234f830e;  
later, commit 38e9f90a227d fixed most of them, but this one was  
unnoticed.  
  
Authors: Dan Wood, Pavan Deolasee, Álvaro Herrera  
Reviewed-by: Masahiko Sawada, Pavan Deolasee, Álvaro Herrera  
Discussion: https://postgr.es/m/84EBAC55-F06D-4FBE-A3F3-8BDA093CE3E3@amazon.com  

M src/backend/access/heap/heapam.c

Provide for testing on python3 modules when under MSVC

commit   : 966268c7621c4bca534961440b497a3270395fc2    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 4 May 2018 15:22:48 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 4 May 2018 15:22:48 -0400    

Click here for diff

This should have been done some years ago as promised in commit  
c4dcdd0c2. However, better late than never.  
  
Along the way do a little housekeeping, including using a simpler test  
for the python version being tested, and removing a redundant subroutine  
parameter. These changes only apply back to release 9.5.  
  
Backpatch to all live releases.  

M src/tools/msvc/Install.pm
M src/tools/msvc/vcregress.pl

Allow MSYS as well as MINGW in Msys uname

commit   : 608a710195a4be20ad5f3e97b24db76aebe02808    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 4 May 2018 14:54:04 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 4 May 2018 14:54:04 -0400    

Click here for diff

Msys2's uname -s outputs a string beginning MSYS rather than MINGW as is  
output by Msys. Allow either in pg_upgrade's test.sh.  
  
Backpatch to all live branches.  

M src/bin/pg_upgrade/test.sh

Sync our copy of the timezone library with IANA release tzcode2018e.

commit   : b45f6613e0a475f908d93dbaa8612ccb9395f666    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 4 May 2018 12:26:25 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 4 May 2018 12:26:25 -0400    

Click here for diff

The non-cosmetic changes involve teaching the "zic" tzdata compiler about  
negative DST.  While I'm not currently intending that we start using  
negative-DST data right away, it seems possible that somebody would try  
to use our copy of zic with bleeding-edge IANA data.  So we'd better be  
out in front of this change code-wise, even though it doesn't matter for  
the data file we're shipping.  
  
Discussion: https://postgr.es/m/30996.1525445902@sss.pgh.pa.us  

M src/timezone/README
M src/timezone/localtime.c
M src/timezone/strftime.c
M src/timezone/zic.c

Fix precedence problem in new Perl code.

commit   : 59cb323053f4ed582d4e71acaeb5770603f074db    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 4 May 2018 09:46:31 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 4 May 2018 09:46:31 -0400    

Click here for diff

I think this bit of commit 1f1cd9b5d didn't do quite what I meant :-(  

M src/backend/catalog/Catalog.pm

pg_dump: Use current_database() instead of PQdb()

commit   : 1cd2445c9985719ea1bb9f644373481c8702af64    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 10 Apr 2018 12:32:05 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 10 Apr 2018 12:32:05 -0400    

Click here for diff

For querying pg_database about information about the database being  
dumped, look up by using current_database() instead of the value  
obtained from PQdb().  When using a connection proxy, the value from  
PQdb() might not be the real name of the database.  

M src/bin/pg_dump/pg_dump.c

commit   : 2a9e04f0a8ada12d4af4f095e4dbe164e2983bce    
  
author   : Teodor Sigaev <teodor@sigaev.ru>    
date     : Fri, 4 May 2018 12:38:23 +0300    
  
committer: Teodor Sigaev <teodor@sigaev.ru>    
date     : Fri, 4 May 2018 12:38:23 +0300    

Click here for diff

nbtsort.c does not need to truncate away non-key attributes for the  
minimum key of the leftmost page on a level, since this is only used to  
build a minus infinity downlink for the level's leftmost page.  
Truncating away non-key attributes in advance of truncating away all  
attributes in _bt_sortaddtup() does not affect the correctness of CREATE  
INDEX, but it is misleading.  
  
Author: Peter Geoghegan  
Discussion: https://www.postgresql.org/message-id/CAH2-WzkAS2M3ussHG-s_Av=Zo6dPjOxyu5fNRkYnxQV+YzGQ4w@mail.gmail.com  

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

Re-think predicate locking on GIN indexes.

commit   : 0bef1c0678d94436f80450d562a866bb6fa5e509    
  
author   : Teodor Sigaev <teodor@sigaev.ru>    
date     : Fri, 4 May 2018 11:27:50 +0300    
  
committer: Teodor Sigaev <teodor@sigaev.ru>    
date     : Fri, 4 May 2018 11:27:50 +0300    

Click here for diff

The principle behind the locking was not very well thought-out, and not  
documented. Add a section in the README to explain how it's supposed to  
work, and change the code so that it actually works that way.  
  
This fixes two bugs:  
  
1. If fast update was turned on concurrently, subsequent inserts to the  
   pending list would not conflict with predicate locks that were acquired  
   earlier, on entry pages. The included 'predicate-gin-fastupdate' test  
   demonstrates that. To fix, make all scans acquire a predicate lock on  
   the metapage. That lock represents a scan of the pending list, whether  
   or not there is a pending list at the moment. Forget about the  
   optimization to skip locking/checking for locks, when fastupdate=off.  
2. If a scan finds no match, it still needs to lock the entry page. The  
   point of predicate locks is to lock the gabs between values, whether  
   or not there is a match. The included 'predicate-gin-nomatch' test  
   tests that case.  
  
In addition to those two bug fixes, this removes some unnecessary locking,  
following the principle laid out in the README. Because all items in  
a posting tree have the same key value, a lock on the posting tree root is  
enough to cover all the items. (With a very large posting tree, it would  
possibly be better to lock the posting tree leaf pages instead, so that a  
"skip scan" with a query like "A & B", you could avoid unnecessary conflict  
if a new tuple is inserted with A but !B. But let's keep this simple.)  
  
Also, some spelling  fixes.  
  
Author: Heikki Linnakangas with some editorization by me  
Review: Andrey Borodin, Alexander Korotkov  
Discussion: https://www.postgresql.org/message-id/0b3ad2c2-2692-62a9-3a04-5724f2af9114@iki.fi  

M src/backend/access/gin/README
M src/backend/access/gin/ginbtree.c
M src/backend/access/gin/gindatapage.c
M src/backend/access/gin/ginfast.c
M src/backend/access/gin/ginget.c
M src/backend/access/gin/gininsert.c
M src/backend/access/gin/ginutil.c
M src/backend/access/gin/ginvacuum.c
M src/backend/access/gist/gist.c
M src/backend/storage/lmgr/README-SSI
M src/include/access/gin_private.h
A src/test/isolation/expected/predicate-gin-fastupdate.out
A src/test/isolation/expected/predicate-gin-nomatch.out
M src/test/isolation/expected/predicate-gin.out
M src/test/isolation/isolation_schedule
A src/test/isolation/specs/predicate-gin-fastupdate.spec
A src/test/isolation/specs/predicate-gin-nomatch.spec
M src/test/isolation/specs/predica