PostgreSQL 10.0 commit log

Stamp 10.0.

  
commit   : 5df0e99bea1c3e5fbffa7fbd0982da88ea149bb6    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 2 Oct 2017 17:09:15 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 2 Oct 2017 17:09:15 -0400    

Click here for diff

  
  

Translation updates

  
commit   : 1f19550a874d02c6e9f6192ed1a97995f9598f53    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 2 Oct 2017 12:03:01 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 2 Oct 2017 12:03:01 -0400    

Click here for diff

  
Source-Git-URL: git://git.postgresql.org/git/pgtranslation/messages.git  
Source-Git-Hash: 4eb5acee0bc0ba7b40220367dfc44bb4af188c88  
  

Expand collation documentation

  
commit   : b6cbd30582a5a58ef0ce7a16c2b003b318d63619    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 22 Sep 2017 13:51:01 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 22 Sep 2017 13:51:01 -0400    

Click here for diff

  
Document better how to create custom collations and what locale strings  
ICU accepts.  Explain the ICU examples in more detail.  Also update the  
text on the CREATE COLLATION reference page a bit to take ICU more into  
account.  
  

Update v10 release notes, and set the official release date.

  
commit   : 086fda9073d37b519519926136c9fe5418451c0e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 1 Oct 2017 13:32:26 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 1 Oct 2017 13:32:26 -0400    

Click here for diff

  
Last(?) round of changes for 10.0.  
  

Use a longer connection timeout in pg_isready test.

  
commit   : 1a6b2b16565aa70f663f83aa6c47b4cbc545eeb2    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 1 Oct 2017 12:43:47 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 1 Oct 2017 12:43:47 -0400    

Click here for diff

  
Buildfarm members skink and sungazer have both recently failed this  
test, with symptoms indicating that the default 3-second timeout  
isn't quite enough for those very slow systems.  There's no reason  
to be miserly with this timeout, so boost it to 60 seconds.  
  
Back-patch to all versions containing this test.  That may be overkill,  
because the failure has only been observed in the v10 branch, but  
I don't feel like having to revisit this later.  
  

Add list of acknowledgments to release notes

  
commit   : e775dd6a4b1b87cd367a725f8840f068f2daae27    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Sun, 1 Oct 2017 08:51:20 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Sun, 1 Oct 2017 08:51:20 -0400    

Click here for diff

  
This contains all individuals mentioned in the commit messages during  
PostgreSQL 10 development.  
  
current through babf18579455e85269ad75e1ddb03f34138f77b6  
  
Discussion: https://www.postgresql.org/message-id/flat/54ad0e42-770e-dfe1-123e-bce9361ad452%402ndquadrant.com  
  

Fix busy-wait in pgbench, with –rate.

  
commit   : babf18579455e85269ad75e1ddb03f34138f77b6    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Sun, 1 Oct 2017 09:29:27 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Sun, 1 Oct 2017 09:29:27 +0300    

Click here for diff

  
If --rate was used to throttle pgbench, it failed to sleep when it had  
nothing to do, leading to a busy-wait with 100% CPU usage. This bug was  
introduced in the refactoring in v10. Before that, sleep() was called with  
a timeout, even when there were no file descriptors to wait for.  
  
Reported by Jeff Janes, patch by Fabien COELHO. Backpatch to v10.  
  
Discussion: https://www.postgresql.org/message-id/CAMkU%3D1x5hoX0pLLKPRnXCy0T8uHoDvXdq%2B7kAM9eoC9_z72ucw%40mail.gmail.com  
  

Fix inadequate locking during get_rel_oids().

  
commit   : 2aab70205be012d06f7d077dd1fa5e6afea9d19c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 29 Sep 2017 16:26:21 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 29 Sep 2017 16:26:21 -0400    

Click here for diff

  
get_rel_oids used to not take any relation locks at all, but that stopped  
being a good idea with commit 3c3bb9933, which inserted a syscache lookup  
into the function.  A concurrent DROP TABLE could now produce "cache lookup  
failed", which we don't want to have happen in normal operation.  The best  
solution seems to be to transiently take a lock on the relation named by  
the RangeVar (which also makes the result of RangeVarGetRelid a lot less  
spongy).  But we shouldn't hold the lock beyond this function, because we  
don't want VACUUM to lock more than one table at a time.  (That would not  
be a big problem right now, but it will become one after the pending  
feature patch to allow multiple tables to be named in VACUUM.)  
  
In passing, adjust vacuum_rel and analyze_rel to document that we don't  
trust the passed RangeVar to be accurate, and allow the RangeVar to  
possibly be NULL --- which it is anyway for a whole-database VACUUM,  
though we accidentally didn't crash for that case.  
  
The passed RangeVar is in fact inaccurate when dealing with a child  
partition, as of v10, and it has been wrong for a whole long time in the  
case of vacuum_rel() recursing to a TOAST table.  None of these things  
present visible bugs up to now, because the passed RangeVar is in fact  
only consulted for autovacuum logging, and in that particular context it's  
always accurate because autovacuum doesn't let vacuum.c expand partitions  
nor recurse to toast tables.  Still, this seems like trouble waiting to  
happen, so let's nail the door at least partly shut.  (Further cleanup  
is planned, in HEAD only, as part of the pending feature patch.)  
  
Fix some sadly inaccurate/obsolete comments too.  Back-patch to v10.  
  
Michael Paquier and Tom Lane  
  
Discussion: https://postgr.es/m/25023.1506107590@sss.pgh.pa.us  
  

pgbench: If we fail to send a command to the server, fail.

  
commit   : 434146d21666dd2023705fb26582918212e124d1    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 29 Sep 2017 13:51:14 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 29 Sep 2017 13:51:14 -0400    

Click here for diff

  
This beats the old behavior of busy-waiting hands down.  
  
Oversight in commit 12788ae49e1933f463bc59a6efe46c4a01701b76.  
  
Report by Pavan Deolasee. Patch by Fabien Coelho.  Reviewed by  
Pavan Deolasee.  
  
Discussion: http://postgr.es/m/CABOikdPhfXTypckMC1Ux6Ko+hKBWwUBA=EXsvamXYSg8M9J94w@mail.gmail.com  
  

psql: Update \d sequence display

  
commit   : 5cc5987cedd8c60c738135abcb25df5247db7d1e    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 25 Sep 2017 11:59:46 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 25 Sep 2017 11:59:46 -0400    

Click here for diff

  
For \d sequencename, the psql code just did SELECT * FROM sequencename  
to get the information to display, but this does not contain much  
interesting information anymore in PostgreSQL 10, because the metadata  
has been moved to a separate system catalog.  
  
This patch creates a newly designed sequence display that is not merely  
an extension of the general relation/table display as it was previously.  
  
Example:  
  
PostgreSQL 9.6:  
  
=> \d foobar  
           Sequence "public.foobar"  
    Column     |  Type   |        Value  
---------------+---------+---------------------  
 sequence_name | name    | foobar  
 last_value    | bigint  | 1  
 start_value   | bigint  | 1  
 increment_by  | bigint  | 1  
 max_value     | bigint  | 9223372036854775807  
 min_value     | bigint  | 1  
 cache_value   | bigint  | 1  
 log_cnt       | bigint  | 0  
 is_cycled     | boolean | f  
 is_called     | boolean | f  
  
PostgreSQL 10 before this change:  
  
=> \d foobar  
   Sequence "public.foobar"  
   Column   |  Type   | Value  
------------+---------+-------  
 last_value | bigint  | 1  
 log_cnt    | bigint  | 0  
 is_called  | boolean | f  
  
New:  
  
=> \d foobar  
                           Sequence "public.foobar"  
  Type  | Start | Minimum |       Maximum       | Increment | Cycles? | Cache  
--------+-------+---------+---------------------+-----------+---------+-------  
 bigint |     1 |       1 | 9223372036854775807 |         1 | no      |     1  
  
Reviewed-by: Fabien COELHO <coelho@cri.ensmp.fr>  
  

Fix freezing of a dead HOT-updated tuple

  
commit   : 46c35116ae1acc8826705ef2a7b5d9110f9d6e84    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 28 Sep 2017 16:44:01 +0200    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 28 Sep 2017 16:44:01 +0200    

Click here for diff

  
Vacuum calls page-level HOT prune to remove dead HOT tuples before doing  
liveness checks (HeapTupleSatisfiesVacuum) on the remaining tuples.  But  
concurrent transaction commit/abort may turn DEAD some of the HOT tuples  
that survived the prune, before HeapTupleSatisfiesVacuum tests them.  
This happens to activate the code that decides to freeze the tuple ...  
which resuscitates it, duplicating data.  
  
(This is especially bad if there's any unique constraints, because those  
are now internally violated due to the duplicate entries, though you  
won't know until you try to REINDEX or dump/restore the table.)  
  
One possible fix would be to simply skip doing anything to the tuple,  
and hope that the next HOT prune would remove it.  But there is a  
problem: if the tuple is older than freeze horizon, this would leave an  
unfrozen XID behind, and if no HOT prune happens to clean it up before  
the containing pg_clog segment is truncated away, it'd later cause an  
error when the XID is looked up.  
  
Fix the problem by having the tuple freezing routines cope with the  
situation: don't freeze the tuple (and keep it dead).  In the cases that  
the XID is older than the freeze age, set the HEAP_XMAX_COMMITTED flag  
so that there is no need to look up the XID in pg_clog later on.  
  
An isolation test is included, authored by Michael Paquier, loosely  
based on Daniel Wood's original reproducer.  It only tests one  
particular scenario, though, not all the possible ways for this problem  
to surface; it be good to have a more reliable way to test this more  
fully, but it'd require more work.  
In message https://postgr.es/m/20170911140103.5akxptyrwgpc25bw@alvherre.pgsql  
I outlined another test case (more closely matching Dan Wood's) that  
exposed a few more ways for the problem to occur.  
  
Backpatch all the way back to 9.3, where this problem was introduced by  
multixact juggling.  In branches 9.3 and 9.4, this includes a backpatch  
of commit e5ff9fefcd50 (of 9.5 era), since the original is not  
correctable without matching the coding pattern in 9.5 up.  
  
Reported-by: Daniel Wood  
Diagnosed-by: Daniel Wood  
Reviewed-by: Yi Wen Wong, Michaël Paquier  
Discussion: https://postgr.es/m/E5711E62-8FDF-4DCA-A888-C200BF6B5742@amazon.com  
  

Fix behavior when converting a float infinity to numeric.

  
commit   : 07ea925e20ee80898638800c8479b48e7e97d431    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 27 Sep 2017 17:05:53 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 27 Sep 2017 17:05:53 -0400    

Click here for diff

  
float8_numeric() and float4_numeric() failed to consider the possibility  
that the input is an IEEE infinity.  The results depended on the  
platform-specific behavior of sprintf(): on most platforms you'd get  
something like  
  
ERROR:  invalid input syntax for type numeric: "inf"  
  
but at least on Windows it's possible for the conversion to succeed and  
deliver a finite value (typically 1), due to a nonstandard output format  
from sprintf and lack of syntax error checking in these functions.  
  
Since our numeric type lacks the concept of infinity, a suitable conversion  
is impossible; the best thing to do is throw an explicit error before  
letting sprintf do its thing.  
  
While at it, let's use snprintf not sprintf.  Overrunning the buffer  
should be impossible if sprintf does what it's supposed to, but this  
is cheap insurance against a stack smash if it doesn't.  
  
Problem reported by Taiki Kondo.  Patch by me based on fix suggestion  
from KaiGai Kohei.  Back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/12A9442FBAE80D4E8953883E0B84E088C8C7A2@BPXM01GP.gisp.nec.co.jp  
  

Revert to 9.6 treatment of ALTER TYPE enumtype ADD VALUE.

  
commit   : 93a1af0b3f63838774a9e524589344c3d44c867d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 27 Sep 2017 16:14:37 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 27 Sep 2017 16:14:37 -0400    

Click here for diff

  
This reverts commit 15bc038f9, along with the followon commits 1635e80d3  
and 984c92074 that tried to clean up the problems exposed by bug #14825.  
The result was incomplete because it failed to address parallel-query  
requirements.  With 10.0 release so close upon us, now does not seem like  
the time to be adding more code to fix that.  I hope we can un-revert this  
code and add the missing parallel query support during the v11 cycle.  
  
Back-patch to v10.  
  
Discussion: https://postgr.es/m/20170922185904.1448.16585@wrigleys.postgresql.org  
  

Improve the CREATE POLICY documentation.

  
commit   : 4d5d08c1cd52add02bdfadc00854135a3b6c88f6    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Wed, 27 Sep 2017 17:13:37 +0100    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Wed, 27 Sep 2017 17:13:37 +0100    

Click here for diff

  
Provide a correct description of how multiple policies are combined,  
clarify when SELECT permissions are required, mention SELECT FOR  
UPDATE/SHARE, and do some other more minor tidying up.  
  
Reviewed by Stephen Frost  
  
Discussion: https://postgr.es/m/CAEZATCVrxyYbOFU8XbGHicz%2BmXPYzw%3DhfNL2XTphDt-53TomQQ%40mail.gmail.com  
  
Back-patch to 9.5.  
  

Don’t recommend “DROP SCHEMA information_schema CASCADE”.

  
commit   : bfd551570265049ea17f18f65a156c1d8ba66a23    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Tue, 26 Sep 2017 22:39:44 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Tue, 26 Sep 2017 22:39:44 -0700    

Click here for diff

  
It drops objects outside information_schema that depend on objects  
inside information_schema.  For example, it will drop a user-defined  
view if the view query refers to information_schema.  
  
Discussion: https://postgr.es/m/20170831025345.GE3963697@rfd.leadboat.com  
  

Improve wording of error message added in commit 714805010.

  
commit   : 9ebc7781444fd15d56ed16e5312a954483e85cd9    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 26 Sep 2017 15:25:56 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 26 Sep 2017 15:25:56 -0400    

Click here for diff

  
Per suggestions from Peter Eisentraut and David Johnston.  
Back-patch, like the previous commit.  
  
Discussion: https://postgr.es/m/E1dv9jI-0006oT-Fn@gemulon.postgresql.org  
  

Fix failure-to-read-man-page in commit 899bd785c.

  
commit   : d29f30d8c3b2a9d8c57324355df8a8d9da1d9c12    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 26 Sep 2017 13:42:53 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 26 Sep 2017 13:42:53 -0400    

Click here for diff

  
posix_fallocate() is not quite a drop-in replacement for fallocate(),  
because it is defined to return the error code as its function result,  
not in "errno".  I (tgl) missed this because RHEL6's version seems  
to set errno as well.  That is not the case on more modern Linuxen,  
though, as per buildfarm results.  
  
Aside from fixing the return-convention confusion, remove the test  
for ENOSYS; we expect that glibc will mask that for posix_fallocate,  
though it does not for fallocate.  Keep the test for EINTR, because  
POSIX specifies that as a possible result, and buildfarm results  
suggest that it can happen in practice.  
  
Back-patch to 9.4, like the previous commit.  
  
Thomas Munro  
  
Discussion: https://postgr.es/m/1002664500.12301802.1471008223422.JavaMail.yahoo@mail.yahoo.com  
  

Remove heuristic same-transaction test from check_safe_enum_use().

  
commit   : 01c5de88ff242b379a033e46e4da6476f2213029    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 26 Sep 2017 13:12:13 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 26 Sep 2017 13:12:13 -0400    

Click here for diff

  
The blacklist mechanism added by the preceding commit directly fixes  
most of the practical cases that the same-transaction test was meant  
to cover.  What remains is use-cases like  
  
	begin;  
	create type e as enum('x');  
	alter type e add value 'y';  
	-- use 'y' somehow  
	commit;  
  
However, because the same-transaction test is heuristic, it fails on  
small variants of that, such as renaming the type or changing its  
owner.  Rather than try to explain the behavior to users, let's  
remove it and just have a rule that the newly added value can't be  
used before being committed, full stop.  Perhaps later it will be  
worth the implementation effort and overhead to have a more accurate  
test for type-was-created-in-this-transaction.  We'll wait for some  
field experience with v10 before deciding to do that.  
  
Back-patch to v10.  
  
Discussion: https://postgr.es/m/20170922185904.1448.16585@wrigleys.postgresql.org  
  

Use a blacklist to distinguish original from add-on enum values.

  
commit   : 175774d2932d969875b0709ec5f400ba19000c99    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 26 Sep 2017 13:12:03 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 26 Sep 2017 13:12:03 -0400    

Click here for diff

  
Commit 15bc038f9 allowed ALTER TYPE ADD VALUE to be executed inside  
transaction blocks, by disallowing the use of the added value later  
in the same transaction, except under limited circumstances.  However,  
the test for "limited circumstances" was heuristic and could reject  
references to enum values that were created during CREATE TYPE AS ENUM,  
not just later.  This breaks the use-case of restoring pg_dump scripts  
in a single transaction, as reported in bug #14825 from Balazs Szilfai.  
  
We can improve this by keeping a "blacklist" table of enum value OIDs  
created by ALTER TYPE ADD VALUE during the current transaction.  Any  
visible-but-uncommitted value whose OID is not in the blacklist must  
have been created by CREATE TYPE AS ENUM, and can be used safely  
because it could not have a lifespan shorter than its parent enum type.  
  
This change also removes the restriction that a renamed enum value  
can't be used before being committed (unless it was on the blacklist).  
  
Andrew Dunstan, with cosmetic improvements by me.  
Back-patch to v10.  
  
Discussion: https://postgr.es/m/20170922185904.1448.16585@wrigleys.postgresql.org  
  

Handle heap rewrites better in logical replication

  
commit   : 1a499c252049dad9016a04bcbab27b8c616d4d03    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 26 Sep 2017 10:03:56 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 26 Sep 2017 10:03:56 -0400    

Click here for diff

  
A FOR ALL TABLES publication naturally considers all base tables to be a  
candidate for replication.  This includes transient heaps that are  
created during a table rewrite during DDL.  This causes failures on the  
subscriber side because it will not have a table like pg_temp_16386 to  
receive data (and if it did, it would be the wrong table).  
  
The prevent this problem, we filter out any tables that match this  
naming pattern and match an actual table from FOR ALL TABLES  
publications.  This is only a heuristic, meaning that user tables that  
match that naming could accidentally be omitted.  A more robust solution  
might require an explicit marking of such tables in pg_class somehow.  
  
Reported-by: yxq <yxq@o2.pl>  
Bug: #14785  
Reviewed-by: Andres Freund <andres@anarazel.de>  
Reviewed-by: Petr Jelinek <petr.jelinek@2ndquadrant.com>  
  

Avoid SIGBUS on Linux when a DSM memory request overruns tmpfs.

  
commit   : 4621c7f7a432fbb24b69c5cf0c877c17832c26ac    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 25 Sep 2017 16:09:19 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 25 Sep 2017 16:09:19 -0400    

Click here for diff

  
On Linux, shared memory segments created with shm_open() are backed by  
swap files created in tmpfs.  If the swap file needs to be extended,  
but there's no tmpfs space left, you get a very unfriendly SIGBUS trap.  
To avoid this, force allocation of the full request size when we create  
the segment.  This adds a few cycles, but none that we wouldn't expend  
later anyway, assuming the request isn't hugely bigger than the actual  
need.  
  
Make this code #ifdef __linux__, because (a) there's not currently a  
reason to think the same problem exists on other platforms, and (b)  
applying posix_fallocate() to an FD created by shm_open() isn't very  
portable anyway.  
  
Back-patch to 9.4 where the DSM code came in.  
  
Thomas Munro, per a bug report from Amul Sul  
  
Discussion: https://postgr.es/m/1002664500.12301802.1471008223422.JavaMail.yahoo@mail.yahoo.com  
  

Support building with Visual Studio 2017

  
commit   : 99e90bac4f9f3bd8d7b285a6f4095c2089e09efe    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 25 Sep 2017 08:03:05 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 25 Sep 2017 08:03:05 -0400    

Click here for diff

  
Haribabu Kommi, reviewed by Takeshi Ideriha and Christian Ullrich  
  
Backpatch to 9.6  
  

Allow ICU to use SortSupport on Windows with UTF-8

  
commit   : 29923859f91f94c97417b8417ff8475cf4261be1    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Sun, 24 Sep 2017 00:56:31 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Sun, 24 Sep 2017 00:56:31 -0400    

Click here for diff

  
There is no reason to ever prevent the use of SortSupport on Windows  
when ICU locales are used.  We previously avoided SortSupport on Windows  
with UTF-8 server encoding and a non C-locale due to restrictions in  
Windows' libc functionality.  
  
This is now considered to be a restriction in one platform's libc  
collation provider, and not a more general platform restriction.  
  
Reported-by: Peter Geoghegan <pg@bowt.ie>  
  

doc: Expand user documentation on SCRAM

  
commit   : 33e2f346b0689cf7631fcfe7db91dc56767f2659    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Sun, 24 Sep 2017 00:29:59 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Sun, 24 Sep 2017 00:29:59 -0400    

Click here for diff

  
Explain more about how the different password authentication methods and  
the password_encryption settings relate to each other, give some  
upgrading advice, and set a better link from the release notes.  
  
Reviewed-by: Jeff Janes <jeff.janes@gmail.com>  
  

Fix pg_basebackup test to original intent

  
commit   : 7c8ce791d4b3e774ffe4c7c987a7055619663818    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Sat, 23 Sep 2017 22:59:26 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Sat, 23 Sep 2017 22:59:26 -0400    

Click here for diff

  
One test case was meant to check that pg_basebackup does not succeed  
when a slot is specified with -S but WAL streaming is not selected,  
which used to require specifying -X stream.  Since -X stream is the  
default in PostgreSQL 10, this test case no longer covers that meaning,  
but the pg_basebackup invocation happened to fail anyway for the  
unrelated reason that the specified replication slot does not exist.  To  
fix, move the test case to later in the file where the slot does exist,  
and add -X none to the invocation so that it covers the originally meant  
behavior.  
  
extracted from a patch by Michael Banck <michael.banck@credativ.de>  
  

Fix saving and restoring umask

  
commit   : 3d7f11a0fabb038ce5c630b87dfadd8b625347fe    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 22 Sep 2017 16:50:59 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 22 Sep 2017 16:50:59 -0400    

Click here for diff

  
In two cases, we set a different umask for some piece of code and  
restore it afterwards.  But if the contained code errors out, the umask  
is not restored.  So add TRY/CATCH blocks to fix that.  
  

Test BRIN autosummarization

  
commit   : 3571a53345bb4d3d055d8a720e9817038927877e    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Sat, 23 Sep 2017 14:05:57 +0200    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Sat, 23 Sep 2017 14:05:57 +0200    

Click here for diff

  
There was no coverage for this code.  
  
Reported-by: Nikolay Shaplov, Tom Lane  
Discussion: https://postgr.es/m/2700647.XEouBYNZic@x200m  
	https://postgr.es/m/13849.1506114543@sss.pgh.pa.us  
  

doc: Document commands that cannot be run in a transaction block

  
commit   : e114289e1e4774dfc3371372e36b3f0fed66b741    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 22 Sep 2017 15:01:13 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 22 Sep 2017 15:01:13 -0400    

Click here for diff

  
Mainly covering the new CREATE SUBSCRIPTION and DROP SUBSCRIPTION, but  
ALTER DATABASE SET TABLESPACE was also missing.  
  

For wal_consistency_checking, mask page checksum as well as page LSN.

  
commit   : 1a44df007c9b9adc5e6082fc90fe68e615d38ecd    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 22 Sep 2017 14:28:22 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 22 Sep 2017 14:28:22 -0400    

Click here for diff

  
If the LSN is different, the checksum will be different, too.  
  
Ashwin Agrawal, reviewed by Michael Paquier and Kuntal Ghosh  
  
Discussion: http://postgr.es/m/CALfoeis5iqrAU-+JAN+ZzXkpPr7+-0OAGv7QUHwFn=-wDy4o4Q@mail.gmail.com  
  

Fix build with !USE_WIDE_UPPER_LOWER

  
commit   : c08c98df3d30c0d773d5624860145fb4215b84fb    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 21 Sep 2017 14:42:10 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 21 Sep 2017 14:42:10 -0400    

Click here for diff

  
The placement of the ifdef blocks in formatting.c was pretty bogus, so  
the code failed to compile if USE_WIDE_UPPER_LOWER was not defined.  
  
Reported-by: Peter Geoghegan <pg@bowt.ie>  
Reported-by: Noah Misch <noah@leadboat.com>  
  

Document further existing locks as wait events

  
commit   : e9c9ba7845c1d5a59d5f9d2429fd81638ae48a19    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 22 Sep 2017 13:35:54 +0200    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 22 Sep 2017 13:35:54 +0200    

Click here for diff

  
Reported-by: Jeremy Schneider  
Author: Michael Paquier  
Discussion: https://postgr.es/m/CA+fnDAZaPCwfY8Lp-pfLnUGFAXRu1VfLyRgdup-L-kwcBj8MqQ@mail.gmail.com  
  

Sync our copy of the timezone library with IANA tzcode master.

  
commit   : 3876b16ce3f30fcd8e10738d4449f8c51a695b17    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 22 Sep 2017 00:04:21 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 22 Sep 2017 00:04:21 -0400    

Click here for diff

  
This patch absorbs a few unreleased fixes in the IANA code.  
It corresponds to commit 2d8b944c1cec0808ac4f7a9ee1a463c28f9cd00a  
in https://github.com/eggert/tz.  Non-cosmetic changes include:  
  
TZDEFRULESTRING is updated to match current US DST practice,  
rather than what it was over ten years ago.  This only matters  
for interpretation of POSIX-style zone names (e.g., "EST5EDT"),  
and only if the timezone database doesn't include either an exact  
match for the zone name or a "posixrules" entry.  The latter  
should not be true in any current Postgres installation, but  
this could possibly matter when using --with-system-tzdata.  
  
Get rid of a nonportable use of "++var" on a bool var.  
This is part of a larger fix that eliminates some vestigial  
support for consecutive leap seconds, and adds checks to  
the "zic" compiler that the data files do not specify that.  
  
Remove a couple of ancient compatibility hacks.  The IANA  
crew think these are obsolete, and I tend to agree.  But  
perhaps our buildfarm will think different.  
  
Back-patch to all supported branches, in line with our policy  
that all branches should be using current IANA code.  Before v10,  
this includes application of current pgindent rules, to avoid  
whitespace problems in future back-patches.  
  
Discussion: https://postgr.es/m/E1dsWhf-0000pT-F9@gemulon.postgresql.org  
  

Give a better error for duplicate entries in VACUUM/ANALYZE column list.

  
commit   : a2b1eb23496e9abd695036e3cbb1d39c05618692    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 21 Sep 2017 18:13:11 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 21 Sep 2017 18:13:11 -0400    

Click here for diff

  
Previously, the code didn't think about this case and would just try to  
analyze such a column twice.  That would fail at the point of inserting  
the second version of the pg_statistic row, with obscure error messsages  
like "duplicate key value violates unique constraint" or "tuple already  
updated by self", depending on context and PG version.  We could allow  
the case by ignoring duplicate column specifications, but it seems better  
to reject it explicitly.  
  
The bogus error messages seem like arguably a bug, so back-patch to  
all supported versions.  
  
Nathan Bossart, per a report from Michael Paquier, and whacked  
around a bit by me.  
  
Discussion: https://postgr.es/m/E061A8E3-5E3D-494D-94F0-E8A9B312BBFC@amazon.com  
  

Improve dubious memory management in pg_newlocale_from_collation().

  
commit   : 97514bf88bd96a4f213fbe6ae6911ba1dd033b8b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 20 Sep 2017 13:52:36 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 20 Sep 2017 13:52:36 -0400    

Click here for diff

  
pg_newlocale_from_collation() used malloc() and strdup() directly,  
which is generally not per backend coding style, and it didn't bother  
to check for failure results, but would just SIGSEGV instead.  Also,  
if one of the numerous error checks in the middle of the function  
failed, the already-allocated memory would be leaked permanently.  
Admittedly, it's not a lot of memory, but it could build up if this  
function were called repeatedly for a bad collation.  
  
The first two problems are easily cured by palloc'ing in TopMemoryContext  
instead of calling libc directly.  We can fairly easily dodge the leakage  
problem for the struct pg_locale_struct by filling in a temporary variable  
and allocating permanent storage only once we reach the bottom of the  
function.  It's harder to get rid of the potential leakage for ICU's copy  
of the collcollate string, but at least that's only allocated after most  
of the error checks; so live with that aspect.  
  
Back-patch to v10 where this code came in, with one or another of the  
ICU patches.  
  

Fix instability in subscription regression test.

  
commit   : ee266774454d5cce3375145e2f86a99910eb263f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 20 Sep 2017 11:28:34 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 20 Sep 2017 11:28:34 -0400    

Click here for diff

  
005_encoding.pl neglected to wait for the subscriber's initial  
synchronization to happen.  While we have not seen this fail in  
the buildfarm, it's pretty easy to demonstrate there's an issue  
by hacking logicalrep_worker_launch() to fail most of the time.  
  
Michael Paquier  
  
Discussion: https://postgr.es/m/27032.1505749806@sss.pgh.pa.us  
  

Fix erroneous documentation about noise word GROUP.

  
commit   : e77730721f5faddb28fd11912f7968ddfd8b58c2    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 20 Sep 2017 11:10:42 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 20 Sep 2017 11:10:42 -0400    

Click here for diff

  
GRANT, REVOKE, and some allied commands allow the noise word GROUP  
before a role name (cf. grantee production in gram.y).  This option  
does not exist elsewhere, but it had nonetheless snuck into the  
documentation for ALTER ROLE, ALTER USER, and CREATE SCHEMA.  
  
Seems to be a copy-and-pasteo in commit 31eae6028, which did expand the  
syntax choices here, but not in that way.  Back-patch to 9.5 where that  
came in.  
  
Discussion: https://postgr.es/m/20170916123750.8885.66941@wrigleys.postgresql.org  
  

docs: re-add instructions on setting wal_level for rsync use

  
commit   : 4131cc6b90ce274a44462627a1c878bf1950838b    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 20 Sep 2017 09:36:19 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 20 Sep 2017 09:36:19 -0400    

Click here for diff

  
This step was erroneously removed four days ago by me.  
  
Reported-by: Magnus via IM  
  
Backpatch-through: 9.5  
  

Mention need for –no-inc-recursive in rsync command

  
commit   : 0017aa981fef11f48a4c347b512d21f41d6e1ee1    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Wed, 20 Sep 2017 14:09:05 +0200    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Wed, 20 Sep 2017 14:09:05 +0200    

Click here for diff

  
Since rsync 3.0.0 (released in 2008), the default way to enumerate  
changes was changed in a way that makes it less likely that the hardlink  
sync mode works. Since the whole point of the documented procedure is  
for the hardlinks to work, change our docs to suggest using the  
backwards compatibility switch.  
  

doc: add example of % substitution for connection URIs

  
commit   : ba01ef267ee48e86566886376c41d0a20551713c    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 19 Sep 2017 12:23:18 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 19 Sep 2017 12:23:18 -0400    

Click here for diff

  
Reported-by: Zhou Digoal  
  
Discussion: https://postgr.es/m/20170912133722.25637.91@wrigleys.postgresql.org  
  
Backpatch-through: 10  
  

Stamp 10rc1.

  
commit   : dc28213c3e0b8f2b71d75bb8c779b9dd0fce5670    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 18 Sep 2017 17:28:38 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 18 Sep 2017 17:28:38 -0400    

Click here for diff

  
  

Fixed ECPG to correctly handle out-of-scope cursor declarations with pointers or array variables.

  
commit   : 75fbf8ad1209e3711704dd6194926a2d60a8d849    
  
author   : Michael Meskes <meskes@postgresql.org>    
date     : Mon, 11 Sep 2017 21:10:36 +0200    
  
committer: Michael Meskes <meskes@postgresql.org>    
date     : Mon, 11 Sep 2017 21:10:36 +0200    

Click here for diff

  
  

Fix, or at least ameliorate, bugs in logicalrep_worker_launch().

  
commit   : c1bde0747983993a695d12c4403a730b2be579d2    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 18 Sep 2017 11:39:44 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 18 Sep 2017 11:39:44 -0400    

Click here for diff

  
If we failed to get a background worker slot, the code just walked  
away from the logicalrep-worker slot it already had, leaving that  
looking like the worker is still starting up.  This led to an indefinite  
hang in subscription startup, as reported by Thomas Munro.  We must  
release the slot on failure.  
  
Also fix a thinko: we must capture the worker slot's generation before  
releasing LogicalRepWorkerLock the first time, else testing to see if  
it's changed is pretty meaningless.  
  
BTW, the CHECK_FOR_INTERRUPTS() in WaitForReplicationWorkerAttach is a  
ticking time bomb, even without considering the possibility of elog(ERROR)  
in one of the other functions it calls.  Really, this entire business needs  
a redesign with some actual thought about error recovery.  But for now  
I'm just band-aiding the case observed in testing.  
  
Back-patch to v10 where this code was added.  
  
Discussion: https://postgr.es/m/CAEepm=2bP3TBMFBArP6o20AZaRduWjMnjCjt22hSdnA-EvrtCw@mail.gmail.com  
  

  
commit   : 90906b855e8867f001339259ae5abd2048b92ac6    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 18 Sep 2017 11:09:15 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 18 Sep 2017 11:09:15 -0400    

Click here for diff

  
  

  
commit   : 4f75e3bbd96fcb73e4995428c595b2698471871a    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 18 Sep 2017 10:41:48 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 18 Sep 2017 10:41:48 -0400    

Click here for diff

  
  

Translation updates

  
commit   : b2800df278b3914044285980826b5c9db308971f    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 18 Sep 2017 09:09:36 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 18 Sep 2017 09:09:36 -0400    

Click here for diff

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

Fix DROP SUBSCRIPTION hang

  
commit   : 522b028a0000d08c6d113c2334e669dd31a6b1cd    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Sun, 17 Sep 2017 21:37:02 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Sun, 17 Sep 2017 21:37:02 -0400    

Click here for diff

  
When ALTER SUBSCRIPTION DISABLE is run in the same transaction before  
DROP SUBSCRIPTION, the latter will hang because workers will still be  
running, not having seen the DISABLE committed, and DROP SUBSCRIPTION  
will wait until the workers have vacated the replication origin slots.  
  
Previously, DROP SUBSCRIPTION killed the logical replication workers  
immediately only if it was going to drop the replication slot, otherwise  
it scheduled the worker killing for the end of the transaction, as a  
result of 7e174fa793a2df89fe03d002a5087ef67abcdde8.  This, however,  
causes the present problem.  To fix, kill the workers immediately in all  
cases.  This covers all cases: A subscription that doesn't have a  
replication slot must be disabled.  It was either disabled in the same  
transaction, or it was already disabled before the current transaction,  
but then there shouldn't be any workers left and this won't make a  
difference.  
  
Reported-by: Arseny Sher <a.sher@postgrespro.ru>  
Discussion: https://www.postgresql.org/message-id/flat/87mv6av84w.fsf%40ars-thinkpad  
  

Doc: update v10 release notes through today.

  
commit   : 90cebfa9ee3a4110c83c6b012ec523adcc1c2468    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 17 Sep 2017 17:04:21 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 17 Sep 2017 17:04:21 -0400    

Click here for diff

  
Add item about number of times statement-level triggers will be fired.  
Rearrange the compatibility items into (what seems to me) a less  
random ordering.  
  

Allow rel_is_distinct_for() to look through RelabelType below OpExpr.

  
commit   : 244b4a37eb8e253e5221477534c2a2f0a9c23630    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 17 Sep 2017 15:28:51 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 17 Sep 2017 15:28:51 -0400    

Click here for diff

  
This lets it do the right thing for, eg, varchar columns.  
Back-patch to 9.5 where this logic appeared.  
  
David Rowley, per report from Kim Rose Carlsen  
  
Discussion: https://postgr.es/m/VI1PR05MB17091F9A9876528055D6A827C76D0@VI1PR05MB1709.eurprd05.prod.outlook.com  
  

Fix possible dangling pointer dereference in trigger.c.

  
commit   : 66fe509be0166058f53bf857b21eae125de30fc5    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 17 Sep 2017 14:50:01 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 17 Sep 2017 14:50:01 -0400    

Click here for diff

  
AfterTriggerEndQuery correctly notes that the query_stack could get  
repalloc'd during a trigger firing, but it nonetheless passes the address  
of a query_stack entry to afterTriggerInvokeEvents, so that if such a  
repalloc occurs, afterTriggerInvokeEvents is already working with an  
obsolete dangling pointer while it scans the rest of the events.  Oops.  
The only code at risk is its "delete_ok" cleanup code, so we can  
prevent unsafe behavior by passing delete_ok = false instead of true.  
  
However, that could have a significant performance penalty, because the  
point of passing delete_ok = true is to not have to re-scan possibly  
a large number of dead trigger events on the next time through the loop.  
There's more than one way to skin that cat, though.  What we can do is  
delete all the "chunks" in the event list except the last one, since  
we know all events in them must be dead.  Deleting the chunks is work  
we'd have had to do later in AfterTriggerEndQuery anyway, and it ends  
up saving rescanning of just about the same events we'd have gotten  
rid of with delete_ok = true.  
  
In v10 and HEAD, we also have to be careful to mop up any per-table  
after_trig_events pointers that would become dangling.  This is slightly  
annoying, but I don't think that normal use-cases will traverse this code  
path often enough for it to be a performance problem.  
  
It's pretty hard to hit this in practice because of the unlikelihood  
of the query_stack getting resized at just the wrong time.  Nonetheless,  
it's definitely a live bug of ancient standing, so back-patch to all  
supported branches.  
  
Discussion: https://postgr.es/m/2891.1505419542@sss.pgh.pa.us  
  

Ensure that BEFORE STATEMENT triggers fire the right number of times.

  
commit   : 5cc23493195cbd2205d5e476e725657c0a29ea34    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 17 Sep 2017 12:16:38 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 17 Sep 2017 12:16:38 -0400    

Click here for diff

  
Commit 0f79440fb introduced mechanism to keep AFTER STATEMENT triggers  
from firing more than once per statement, which was formerly possible  
if more than one FK enforcement action had to be applied to a given  
table.  Add a similar mechanism for BEFORE STATEMENT triggers, so that  
we don't have the unexpected situation of firing BEFORE STATEMENT  
triggers more often than AFTER STATEMENT.  
  
As with the previous patch, back-patch to v10.  
  
Discussion: https://postgr.es/m/22315.1505584992@sss.pgh.pa.us  
  

Doc: add example of transition table use in a trigger.

  
commit   : 0749ef8e9eceb04dd8c365443d0d994f7ad34c17    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 16 Sep 2017 15:31:26 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 16 Sep 2017 15:31:26 -0400    

Click here for diff

  
I noticed that there were exactly no complete examples of use of  
a transition table in a trigger function, and no clear description  
of just how you'd do it either.  Improve that.  
  

Fix SQL-spec incompatibilities in new transition table feature.

  
commit   : 54d4d0ff6cd40638d026c01e46deb102e7951ba6    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 16 Sep 2017 13:20:32 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 16 Sep 2017 13:20:32 -0400    

Click here for diff

  
The standard says that all changes of the same kind (insert, update, or  
delete) caused in one table by a single SQL statement should be reported  
in a single transition table; and by that, they mean to include foreign key  
enforcement actions cascading from the statement's direct effects.  It's  
also reasonable to conclude that if the standard had wCTEs, they would say  
that effects of wCTEs applying to the same table as each other or the outer  
statement should be merged into one transition table.  We weren't doing it  
like that.  
  
Hence, arrange to merge tuples from multiple update actions into a single  
transition table as much as we can.  There is a problem, which is that if  
the firing of FK enforcement triggers and after-row triggers with  
transition tables is interspersed, we might need to report more tuples  
after some triggers have already seen the transition table.  It seems like  
a bad idea for the transition table to be mutable between trigger calls.  
There's no good way around this without a major redesign of the FK logic,  
so for now, resolve it by opening a new transition table each time this  
happens.  
  
Also, ensure that AFTER STATEMENT triggers fire just once per statement,  
or once per transition table when we're forced to make more than one.  
Previous versions of Postgres have allowed each FK enforcement query  
to cause an additional firing of the AFTER STATEMENT triggers for the  
referencing table, but that's certainly not per spec.  (We're still  
doing multiple firings of BEFORE STATEMENT triggers, though; is that  
something worth changing?)  
  
Also, forbid using transition tables with column-specific UPDATE triggers.  
The spec requires such transition tables to show only the tuples for which  
the UPDATE trigger would have fired, which means maintaining multiple  
transition tables or else somehow filtering the contents at readout.  
Maybe someday we'll bother to support that option, but it looks like a  
lot of trouble for a marginal feature.  
  
The transition tables are now managed by the AfterTriggers data structures,  
rather than being directly the responsibility of ModifyTable nodes.  This  
removes a subtransaction-lifespan memory leak introduced by my previous  
band-aid patch 3c4359521.  
  
In passing, refactor the AfterTriggers data structures to reduce the  
management overhead for them, by using arrays of structs rather than  
several parallel arrays for per-query-level and per-subtransaction state.  
  
I failed to resist the temptation to do some copy-editing on the SGML  
docs about triggers, above and beyond merely documenting the effects  
of this patch.  
  
Back-patch to v10, because we don't want the semantics of transition  
tables to change post-release.  
  
Patch by me, with help and review from Thomas Munro.  
  
Discussion: https://postgr.es/m/20170909064853.25630.12825@wrigleys.postgresql.org  
  

docs: clarify pg_upgrade docs regarding standbys and rsync

  
commit   : d2bbd6104096b1559c1683d39e2c4e4cfbcada1c    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Sat, 16 Sep 2017 11:58:00 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Sat, 16 Sep 2017 11:58:00 -0400    

Click here for diff

  
Document that rsync is an _optional_ way to upgrade standbys, suggest  
rsync option --dry-run, and mention a way of upgrading one standby from  
another using rsync.  Also clarify some instructions by specifying if  
they operate on the old or new clusters.  
  
Reported-by: Stephen Frost, Magnus Hagander  
  
Discussion: https://postgr.es/m/20170914191250.GB6595@momjian.us  
  
Backpatch-through: 9.5  
  

After a MINVALUE/MAXVALUE bound, allow only more of the same.

  
commit   : e8b65986ba0de2daeb5bcedc02fb936b04fe464c    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 15 Sep 2017 21:15:55 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 15 Sep 2017 21:15:55 -0400    

Click here for diff

  
In the old syntax, which used UNBOUNDED, we had a similar restriction,  
but commit d363d42bb9a4399a0207bd3b371c966e22e06bd3, which changed the  
syntax, eliminated it.  Put it back.  
  
Patch by me, reviewed by Dean Rasheed.  
  
Discussion: http://postgr.es/m/CA+Tgmobs+pLPC27tS3gOpEAxAffHrq5w509cvkwTf9pF6cWYbg@mail.gmail.com  
  

Apply pg_get_serial_sequence() to identity column sequences as well

  
commit   : f830183492d3a3b74cbd33645db19b8b5b5a2622    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 15 Sep 2017 14:04:51 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 15 Sep 2017 14:04:51 -0400    

Click here for diff

  
Bug: #14813  
  

Add missing tags to GetCommandLogLevel.

  
commit   : a2a61f633e36445d7a15baad22d4d1db102e4a7e    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Thu, 14 Sep 2017 16:25:19 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Thu, 14 Sep 2017 16:25:19 -0400    

Click here for diff

  
Otherwise, log_statement = 'ddl' causes errors if those statement  
types are used.  
  
Michael Paquier, reviewed by Ashutosh Sharma  
  
Discussion: http://postgr.es/m/CAB7nPqStC3HkE76Q1MnHsVd1vF1Td9zXApzYadzDMyLMRkkGrw@mail.gmail.com  
  

Fix inconsistent capitalization.

  
commit   : 29f021160ea7bfbc02600e651cf3588bb4ce8e78    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Thu, 14 Sep 2017 11:11:12 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Thu, 14 Sep 2017 11:11:12 -0400    

Click here for diff

  
Amit Langote  
  
Discussion: http://postgr.es/m/a83a0899-19f5-594c-9aac-3ba0f16989a1@lab.ntt.co.jp  
  

Set partitioned_rels appropriately when UNION ALL is used.

  
commit   : 448aa36e8b969da257bb58a6fe3db6498d48d4e8    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Thu, 14 Sep 2017 10:43:44 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Thu, 14 Sep 2017 10:43:44 -0400    

Click here for diff

  
In most cases, this omission won't matter, because the appropriate  
locks will have been acquired during parse/plan or by AcquireExecutorLocks.  
But it's a bug all the same.  
  
Report by Ashutosh Bapat.  Patch by me, reviewed by Amit Langote.  
  
Discussion: http://postgr.es/m/CAFjFpRdHb_ZnoDTuBXqrudWXh3H1ibLkr6nHsCFT96fSK4DXtA@mail.gmail.com  
  

Properly check interrupts in execScan.c.

  
commit   : 253c8afc9eb178b7241b4cc571acf7fb6ac6f976    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Thu, 14 Sep 2017 01:53:10 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Thu, 14 Sep 2017 01:53:10 -0700    

Click here for diff

  
During the development of d47cfef711 the CFI()s in ExecScan() were  
moved back and forth, ending up in the wrong place. Thus queries that  
largely spend their time in ExecScan(), and have neither projection  
nor a qual, can't be cancelled in a timely manner.  
  
Reported-By: Jeff Janes  
Author: Andres Freund  
Discussion: https://postgr.es/m/CAMkU=1weDXp8eLLPt9SO1LEUsJYYK9cScaGhLKpuN+WbYo9b5g@mail.gmail.com  
Backpatch: 10, as d47cfef711  
  

Fix ordering in pg_dump of GRANTs

  
commit   : 68a7c24fdf2d69fc57cfb26aba7e119aa6ca2621    
  
author   : Stephen Frost <sfrost@snowman.net>    
date     : Wed, 13 Sep 2017 20:04:43 -0400    
  
committer: Stephen Frost <sfrost@snowman.net>    
date     : Wed, 13 Sep 2017 20:04:43 -0400    

Click here for diff

  
The order in which GRANTs are output is important as GRANTs which have  
been GRANT'd by individuals via WITH GRANT OPTION GRANTs have to come  
after the GRANT which included the WITH GRANT OPTION.  This happens  
naturally in the backend during normal operation as we only change  
existing ACLs in-place, only add new ACLs to the end, and when removing  
an ACL we remove any which depend on it also.  
  
Also, adjust the comments in acl.h to make this clear.  
  
Unfortunately, the updates to pg_dump to handle initial privileges  
involved pulling apart ACLs and then combining them back together and  
could end up putting them back together in an invalid order, leading to  
dumps which wouldn't restore.  
  
Fix this by adjusting the queries used by pg_dump to ensure that the  
ACLs are rebuilt in the same order in which they were originally.  
  
Back-patch to 9.6 where the changes for initial privileges were done.  
  

Changed order of statements and added an additiona MSVC safeguard to make ecpg thread test cases work on Windows.

  
commit   : eaf7001eb7e3eecc7e30c31956860f54f1def55f    
  
author   : Michael Meskes <meskes@postgresql.org>    
date     : Sat, 26 Aug 2017 19:07:25 +0200    
  
committer: Michael Meskes <meskes@postgresql.org>    
date     : Sat, 26 Aug 2017 19:07:25 +0200    

Click here for diff

  
  

Make setlocale in ECPG test cases thread aware on Windows.

  
commit   : 38d7cb67f2e8798d6e0ecff8334345a3ae73b902    
  
author   : Michael Meskes <meskes@postgresql.org>    
date     : Sat, 26 Aug 2017 12:57:21 +0200    
  
committer: Michael Meskes <meskes@postgresql.org>    
date     : Sat, 26 Aug 2017 12:57:21 +0200    

Click here for diff

  
Fix threaded test cases on Windows not to crash in setlocale() which can be  
global or local to a thread on Windows.  
  
Author: Christian Ullrich  
  

doc: Remove incorrect SCRAM protocol documentation

  
commit   : d587813edba16ae52330c881c27e4c91799a0d9c    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 13 Sep 2017 10:10:34 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 13 Sep 2017 10:10:34 -0400    

Click here for diff

  
The documentation claimed that one should send  
"pg_same_as_startup_message" as the user name in the SCRAM messages, but  
this did not match the actual implementation, so remove it.  
  

  
commit   : 6dffdcfeef934eb21b8a767d8be11ec33ccb56ed    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 13 Sep 2017 09:22:18 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 13 Sep 2017 09:22:18 -0400    

Click here for diff

  
Backpatch-through: 9.5  
  

docs: improve pg_upgrade standby instructions

  
commit   : aaa4faa7a00cb85322e570f2d148a51b95b847c4    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 13 Sep 2017 09:11:28 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 13 Sep 2017 09:11:28 -0400    

Click here for diff

  
This makes it clear that pg_upgrade standby upgrade instructions should  
only be used in link mode, adds examples, and explains how rsync works  
with links.  
  
Reported-by: Andreas Joseph Krogh  
  
Discussion: https://postgr.es/m/VisenaEmail.6c.c0e592c5af4ef0a2.15e785dcb61@tc7-visena  
  
Backpatch-through: 9.5  
  

Improve error message in WAL sender

  
commit   : 2b0ded5060cc2e0b7d6c765af5b5f7334f64f5dc    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 13 Sep 2017 08:31:03 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 13 Sep 2017 08:31:03 -0400    

Click here for diff

  
The previous error message when attempting to run a general SQL command  
in a physical replication WAL sender was a bit sloppy.  
  
Reported-by: Fujii Masao <masao.fujii@gmail.com>  
  

docs: improve pg_upgrade rsync instructions

  
commit   : b1705f35f805933629520eded68b82d2a2900871    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 12 Sep 2017 13:17:52 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 12 Sep 2017 13:17:52 -0400    

Click here for diff

  
This explains how rsync accomplishes updating standby servers and  
clarifies the instructions.  
  
Reported-by: Andreas Joseph Krogh  
  
Discussion: https://postgr.es/m/VisenaEmail.10.2b4049e43870bd16.15d898d696f@tc7-visena  
  
Backpatch-through: 9.5  
  

Fix RecursiveCopy.pm to cope with disappearing files.

  
commit   : bd18960cb93f3b6e9f43f3cabec34f1929f05ec3    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 11 Sep 2017 22:02:58 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 11 Sep 2017 22:02:58 -0400    

Click here for diff

  
When copying from an active database tree, it's possible for files to be  
deleted after we see them in a readdir() scan but before we can open them.  
(Once we've got a file open, we don't expect any further errors from it  
getting unlinked, though.)  Tweak RecursiveCopy so it can cope with this  
case, so as to avoid irreproducible test failures.  
  
Back-patch to 9.6 where this code was added.  In v10 and HEAD, also  
remove unused "use RecursiveCopy" in one recovery test script.  
  
Michael Paquier and Tom Lane  
  
Discussion: https://postgr.es/m/24621.1504924323@sss.pgh.pa.us  
  

PG 10 release notes: change trigger transition tables

  
commit   : d4c9eb005a16ff5cdc9d5d9514a3195c60ad21ab    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 11 Sep 2017 19:56:44 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 11 Sep 2017 19:56:44 -0400    

Click here for diff

  
Add attribution of trigger transition tables for Thomas Munro.  
  
Reported-by: Thomas Munro  
  
Discussion: https://postgr.es/m/CAEepm=2bDFgr4ut+1-QjKQY4MA=5ek8Ap3nyB19y2tpTL6xxtA@mail.gmail.com  
  
Backpatch-through: 10  
  

PG 10 release notes: update PL/Tcl functions item

  
commit   : 1d27a7004d84516f5d04662c1cd52f41400b7750    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 11 Sep 2017 19:43:49 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 11 Sep 2017 19:43:49 -0400    

Click here for diff

  
Update attribution of PL/Tcl functions item from Jim Nasby to Karl  
Lehenbauer.  
  
Reported-by: Jim Nasby  
  
Discussion: https://postgr.es/m/ed42f3d6-4251-dabc-747f-1ff936763b2b@nasby.net  
  
Backpatch-through: 10  
  

Translation updates

  
commit   : bd72c37b160623bf3f1c9cea82b948ee53a22567    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 11 Sep 2017 12:49:35 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 11 Sep 2017 12:49:35 -0400    

Click here for diff

  
Source-Git-URL: git://git.postgresql.org/git/pgtranslation/messages.git  
Source-Git-Hash: 0c1fdae472e52197eb0e5ccdd2cfdd3654f76834  
  

Message style fixes

  
commit   : f552d18f3edd178598564d20f09577a623b1e302    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 11 Sep 2017 11:20:47 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 11 Sep 2017 11:20:47 -0400    

Click here for diff

  
  

Quick-hack fix for foreign key cascade vs triggers with transition tables.

  
commit   : 5c11717185bc24a2d0a20b38815e182ed99101ce    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 10 Sep 2017 14:59:56 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 10 Sep 2017 14:59:56 -0400    

Click here for diff

  
AFTER triggers using transition tables crashed if they were fired due  
to a foreign key ON CASCADE update.  This is because ExecEndModifyTable  
flushes the transition tables, on the assumption that any trigger that  
could need them was already fired during ExecutorFinish.  Normally  
that's true, because we don't allow transition-table-using triggers  
to be deferred.  However, foreign key CASCADE updates force any  
triggers on the referencing table to be deferred to the outer query  
level, by means of the EXEC_FLAG_SKIP_TRIGGERS flag.  I don't recall  
all the details of why it's like that and am pretty loath to redesign  
it right now.  Instead, just teach ExecEndModifyTable to skip destroying  
the TransitionCaptureState when that flag is set.  This will allow the  
transition table data to survive until end of the current subtransaction.  
  
This isn't a terribly satisfactory solution, because (1) we might be  
leaking the transition tables for much longer than really necessary,  
and (2) as things stand, an AFTER STATEMENT trigger will fire once per  
RI updating query, ie once per row updated or deleted in the referenced  
table.  I suspect that is not per SQL spec.  But redesigning this is a  
research project that we're certainly not going to get done for v10.  
So let's go with this hackish answer for now.  
  
In passing, tweak AfterTriggerSaveEvent to not save the transition_capture  
pointer into the event record for a deferrable trigger.  This is not  
necessary to fix the current bug, but it avoids letting dangling pointers  
to long-gone transition tables persist in the trigger event queue.  That's  
at least a safety feature.  It might also allow merging shared trigger  
states in more cases than before.  
  
I added a regression test that demonstrates the crash on unpatched code,  
and also exposes the behavior of firing the AFTER STATEMENT triggers  
once per row update.  
  
Per bug #14808 from Philippe Beaudoin.  Back-patch to v10.  
  
Discussion: https://postgr.es/m/20170909064853.25630.12825@wrigleys.postgresql.org  
  

pg_upgrade: Message style fixes

  
commit   : 6913d06688a2aa76580d5942b0c98751363c97e0    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Sat, 9 Sep 2017 17:32:10 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Sat, 9 Sep 2017 17:32:10 -0400    

Click here for diff

  
  

Fix uninitialized-variable bug.

  
commit   : 1377b40965b257e228ae8faf45c6ce145ce357e5    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 8 Sep 2017 19:04:32 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 8 Sep 2017 19:04:32 -0400    

Click here for diff

  
map_partition_varattnos() failed to set its found_whole_row output  
parameter if the given expression list was NIL.  This seems to be  
a pre-existing bug that chanced to be exposed by commit 6f6b99d13.  
It might be unreachable in v10, but I have little faith in that  
proposition, so back-patch.  
  
Per buildfarm.  
  

Doc: update v10 release notes through today.

  
commit   : 5f0ac02d7f8ded730c27a5197f8c594302c5d7e0    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 8 Sep 2017 16:59:26 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 8 Sep 2017 16:59:26 -0400    

Click here for diff

  
Also, another round of copy-editing.  I merged a few items that  
didn't seem to be meaningfully different from a user's perspective.  
  

Remove mention of password_encryption = plain in postgresql.conf.sample.

  
commit   : 730169dea70c381a959a357de5c8b56e674af805    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 8 Sep 2017 14:38:54 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 8 Sep 2017 14:38:54 -0400    

Click here for diff

  
Evidently missed in commit eb61136dc.  
  
Spotted by Oleg Bartunov.  
  
Discussion: https://postgr.es/m/CAF4Au4wz_iK5r4fnTnnd8XqioAZQs-P7-VsEAfivW34zMVpAmw@mail.gmail.com  
  

Even if some partitions are foreign, allow tuple routing.

  
commit   : 08cb36417aa22436647a1831a7d1ff6b41232280    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Thu, 7 Sep 2017 10:55:45 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Thu, 7 Sep 2017 10:55:45 -0400    

Click here for diff

  
This doesn't allow routing tuple to the foreign partitions themselves,  
but it permits tuples to be routed to regular partitions despite the  
presence of foreign partitions in the same inheritance hierarchy.  
  
Etsuro Fujita, reviewed by Amit Langote and by me.  
  
Discussion: http://postgr.es/m/bc3db4c1-1693-3b8a-559f-33ad2b50b7ad@lab.ntt.co.jp  
  

Add psql variables showing server version and psql version.

  
commit   : a6c678f018d3a30a88440d3c20cf8e7cd6592a32    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 6 Sep 2017 11:35:31 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 6 Sep 2017 11:35:31 -0400    

Click here for diff

  
We already had a psql variable VERSION that shows the verbose form of  
psql's own version.  Add VERSION_NAME to show the short form (e.g.,  
"11devel") and VERSION_NUM to show the numeric form (e.g., 110000).  
Also add SERVER_VERSION_NAME and SERVER_VERSION_NUM to show the short and  
numeric forms of the server's version.  (We'd probably add SERVER_VERSION  
with the verbose string if it were readily available; but adding another  
network round trip to get it seems too expensive.)  
  
The numeric forms, in particular, are expected to be useful for scripting  
purposes, now that psql can do conditional tests.  
  
Back-patch of commit 9ae9d8c1549c384dbdb8363e1d932b7311d25c56.  
  
Fabien Coelho, reviewed by Pavel Stehule  
  
Discussion: https://postgr.es/m/alpine.DEB.2.20.1704020917220.4632@lancre  
  

Clean up handling of dropped columns in NAMEDTUPLESTORE RTEs.

  
commit   : 483882905a9a5dc72c9487ceee12320b9630ba2b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 6 Sep 2017 10:41:05 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 6 Sep 2017 10:41:05 -0400    

Click here for diff

  
The NAMEDTUPLESTORE patch piggybacked on the infrastructure for  
TABLEFUNC/VALUES/CTE RTEs, none of which can ever have dropped columns,  
so the possibility was ignored most places.  Fix that, including adding a  
specification to parsenodes.h about what it's supposed to look like.  
  
In passing, clean up assorted comments that hadn't been maintained  
properly by said patch.  
  
Per bug #14799 from Philippe Beaudoin.  Back-patch to v10.  
  
Discussion: https://postgr.es/m/20170906120005.25630.84360@wrigleys.postgresql.org  
  

Fix psql’s –help=commands output line count.

  
commit   : 3fbf09563f839137e5279a390044a18e400fa074    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 5 Sep 2017 16:41:22 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 5 Sep 2017 16:41:22 -0400    

Click here for diff

  
Evidently somebody neglected to update this sometime in the v10 cycle.  
  
Patching REL_10_STABLE only; this value is about to be obsolete in  
HEAD anyway.  Noted while examining \gdesc patch.  
  

Correct base backup throttling

  
commit   : 1861b20cd63ba3a2e9d547858fc4e05d882531c7    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 5 Sep 2017 16:59:39 +0200    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 5 Sep 2017 16:59:39 +0200    

Click here for diff

  
Throttling for sending a base backup in walsender is broken for the case  
where there is a lot of WAL traffic, because the latch used to put the  
walsender to sleep is also signalled by regular WAL traffic (and each  
signal causes an additional batch of data to be sent); the net effect is  
that there is no or little actual throttling.  This is undesirable, so  
rewrite the sleep into a loop to achieve the desired effeect.  
  
Author: Jeff Janes, small tweaks by me  
Reviewed-by: Antonin Houska  
Discussion: https://postgr.es/m/CAMkU=1xH6mde-yL-Eo1TKBGNd0PB1-TMxvrNvqcAkN-qr2E9mw@mail.gmail.com  
  

Fix translatable string

  
commit   : a1af1e7cfaefbef38e6b85ac632ed488744b3fd0    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 4 Sep 2017 11:08:52 +0200    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 4 Sep 2017 11:08:52 +0200    

Click here for diff

  
Discussion: https://postgr.es/m/20170828130545.sdajqlpr37hmmd6a@alvherre.pgsql  
  

Fix macro-redefinition warning on MSVC.

  
commit   : d5c65d2f11ac58c517ab7fda01be62e4763504c9    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 3 Sep 2017 11:01:08 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 3 Sep 2017 11:01:08 -0400    

Click here for diff

  
In commit 9d6b160d7, I tweaked pg_config.h.win32 to use  
"#define HAVE_LONG_LONG_INT_64 1" rather than defining it as empty,  
for consistency with what happens in an autoconf'd build.  
But Solution.pm injects another definition of that macro into  
ecpg_config.h, leading to justifiable (though harmless) compiler whining.  
Make that one consistent too.  Back-patch, like the previous patch.  
  
Discussion: https://postgr.es/m/CAEepm=1dWsXROuSbRg8PbKLh0S=8Ou-V8sr05DxmJOF5chBxqQ@mail.gmail.com  
  

doc: Fix typos and other minor issues

  
commit   : c6a7fcb49a60081c04c8e421fbc21475ad6943d8    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 1 Sep 2017 23:34:03 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 1 Sep 2017 23:34:03 -0400    

Click here for diff

  
Author: Alexander Lakhin <exclusion@gmail.com>  
  

Improve division of labor between execParallel.c and nodeGather[Merge].c.

  
commit   : 01edb5c7fc3bcf6aea15f2b3be36189b52ad9d1a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 1 Sep 2017 17:38:54 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 1 Sep 2017 17:38:54 -0400    

Click here for diff

  
Move the responsibility for creating/destroying TupleQueueReaders into  
execParallel.c, to avoid duplicative coding in nodeGather.c and  
nodeGatherMerge.c.  Also, instead of having DestroyTupleQueueReader do  
shm_mq_detach, do it in the caller (which is now only ExecParallelFinish).  
This means execParallel.c does both the attaching and detaching of the  
tuple-queue-reader shm_mqs, which seems less weird than the previous  
arrangement.  
  
These changes also eliminate a vestigial memory leak (of the pei->tqueue  
array).  It's now demonstrable that rescans of Gather or GatherMerge don't  
leak memory.  
  
Discussion: https://postgr.es/m/8670.1504192177@sss.pgh.pa.us  
  

Make [U]INT64CONST safe for use in #if conditions.

  
commit   : f2fe1cbef11c5fc962e338c8523667314faa6d89    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 1 Sep 2017 15:14:18 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 1 Sep 2017 15:14:18 -0400    

Click here for diff

  
Instead of using a cast to force the constant to be the right width,  
assume we can plaster on an L, UL, LL, or ULL suffix as appropriate.  
The old approach to this is very hoary, dating from before we were  
willing to require compilers to have working int64 types.  
  
This fix makes the PG_INT64_MIN, PG_INT64_MAX, and PG_UINT64_MAX  
constants safe to use in preprocessor conditions, where a cast  
doesn't work.  Other symbolic constants that might be defined using  
[U]INT64CONST are likewise safer than before.  
  
Also fix the SIZE_MAX macro to be similarly safe, if we are forced  
to provide a definition for that.  The test added in commit 2e70d6b5e  
happens to do what we want even with the hack "(size_t) -1" definition,  
but we could easily get burnt on other tests in future.  
  
Back-patch to all supported branches, like the previous commits.  
  
Discussion: https://postgr.es/m/15883.1504278595@sss.pgh.pa.us  
  

Ensure SIZE_MAX can be used throughout our code.

  
commit   : cbb51eb69f3faac425caae33195fdfa3396fa1c3    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 1 Sep 2017 13:52:53 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 1 Sep 2017 13:52:53 -0400    

Click here for diff

  
Pre-C99 platforms may lack <stdint.h> and thereby SIZE_MAX.  We have  
a couple of places using the hack "(size_t) -1" as a fallback, but  
it wasn't universally available; which means the code added in commit  
2e70d6b5e fails to compile everywhere.  Move that hack to c.h so that  
we can rely on having SIZE_MAX everywhere.  
  
Per discussion, it'd be a good idea to make the macro's value safe  
for use in #if-tests, but that will take a bit more work.  This is  
just a quick expedient to get the buildfarm green again.  
  
Back-patch to all supported branches, like the previous commit.  
  
Discussion: https://postgr.es/m/15883.1504278595@sss.pgh.pa.us  
  

Fix two-phase commit test for recovery mode

  
commit   : ef585de80e29d7f20988ce06fafa58a215f6b122    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 1 Sep 2017 16:51:55 +0200    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 1 Sep 2017 16:51:55 +0200    

Click here for diff

  
The original code had a race condition because it never ensured the  
standby was caught up before proceeding; add a wait similar to every  
other place that does this.  
  
Author: Michaël Paquier  
Discussion: https://postgr.es/m/CAB7nPqTm9p+LCm1mVJYvgpwagRK+uibT-pKq0O2-paOWxT62jw@mail.gmail.com  
  

Restore behavior for replication origin drop

  
commit   : f15b76a9010dfd6052405d058bf8c0a488cec979    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 1 Sep 2017 16:30:02 +0200    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 1 Sep 2017 16:30:02 +0200    

Click here for diff

  
Do for replication origins what the previous commit did for replication  
slots: restore the original behavior of replication origin drop to raise  
an error rather than blocking, because users might be depending on the  
original behavior.  Maintain the blocking behavior when invoked  
internally from logical replication subscription handling.  
  
Discussion: https://postgr.es/m/20170830133922.tlpo3lgfejm4n2cs@alvherre.pgsql  
  

Avoid race condition in logical replication test

  
commit   : 3950e07eb46ebe99331ca82d659269056470f596    
  
author   : Simon Riggs <simon@2ndQuadrant.com>    
date     : Fri, 1 Sep 2017 14:49:06 +0100    
  
committer: Simon Riggs <simon@2ndQuadrant.com>    
date     : Fri, 1 Sep 2017 14:49:06 +0100    

Click here for diff

  
Wait for slot to become inactive before continuing.  
  
Author: Petr Jelinek  
  

Provisional list of Major Features

  
commit   : 44654f3d2555702279d080e87c70730dc0cb7a9d    
  
author   : Simon Riggs <simon@2ndQuadrant.com>    
date     : Fri, 1 Sep 2017 14:10:52 +0100    
  
committer: Simon Riggs <simon@2ndQuadrant.com>    
date     : Fri, 1 Sep 2017 14:10:52 +0100    

Click here for diff

  
  

Add a WAIT option to DROP_REPLICATION_SLOT

  
commit   : 8ba6d50f923bfc1d7cc91f5ff11e199f18d7fd80    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 1 Sep 2017 13:44:14 +0200    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 1 Sep 2017 13:44:14 +0200    

Click here for diff

  
Commit 9915de6c1cb2 changed the default behavior of  
DROP_REPLICATION_SLOT so that it would wait until any session holding  
the slot active would release it, instead of raising an error.  But  
users are already depending on the original behavior, so revert to it by  
default and add a WAIT option to invoke the new behavior.  
  
Per complaint from Simone Gotti, in  
Discussion: https://postgr.es/m/CAEvsy6Wgdf90O6pUvg2wSVXL2omH5OPC-38OD4Zzgk-FXavj3Q@mail.gmail.com  
  

Add note about diskspace usage of pg_commit_ts

  
commit   : 28915c7db4da4eaffb8eb0dc5c04c87dcf345eb6    
  
author   : Simon Riggs <simon@2ndQuadrant.com>    
date     : Fri, 1 Sep 2017 07:55:00 +0100    
  
committer: Simon Riggs <simon@2ndQuadrant.com>    
date     : Fri, 1 Sep 2017 07:55:00 +0100    

Click here for diff

  
Author: Thomas Munro  
  

Avoid memory leaks when a GatherMerge node is rescanned.

  
commit   : 7610547c95f3a469115538f4b45eda2563a8188e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 31 Aug 2017 16:20:58 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 31 Aug 2017 16:20:58 -0400    

Click here for diff

  
Rescanning a GatherMerge led to leaking some memory in the executor's  
query-lifespan context, because most of the node's working data structures  
were simply abandoned and rebuilt from scratch.  In practice, this might  
never amount to much, given the cost of relaunching worker processes ---  
but it's still pretty messy, so let's fix it.  
  
We can rearrange things so that the tuple arrays are simply cleared and  
reused, and we don't need to rebuild the TupleTableSlots either, just  
clear them.  One small complication is that because we might get a  
different number of workers on each iteration, we can't keep the old  
convention that the leader's gm_slots[] entry is the last one; the leader  
might clobber a TupleTableSlot that we need for a worker in a future  
iteration.  Hence, adjust the logic so that the leader has slot 0 always,  
while the active workers have slots 1..n.  
  
Back-patch to v10 to keep all the existing versions of nodeGatherMerge.c  
in sync --- because of the renumbering of the slots, there would otherwise  
be a very large risk that any future backpatches in this module would  
introduce bugs.  
  
Discussion: https://postgr.es/m/8670.1504192177@sss.pgh.pa.us  
  

Clean up shm_mq cleanup.

  
commit   : b4fa938e9f484a3cf0614aac4686cd26c650d27c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 31 Aug 2017 15:10:24 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 31 Aug 2017 15:10:24 -0400    

Click here for diff

  
The logic around shm_mq_detach was a few bricks shy of a load, because  
(contrary to the comments for shm_mq_attach) all it did was update the  
shared shm_mq state.  That left us leaking a bit of process-local  
memory, but much worse, the on_dsm_detach callback for shm_mq_detach  
was still armed.  That means that whenever we ultimately detach from  
the DSM segment, we'd run shm_mq_detach again for already-detached,  
possibly long-dead queues.  This accidentally fails to fail today,  
because we only ever re-use a shm_mq's memory for another shm_mq, and  
multiple detach attempts on the last such shm_mq are fairly harmless.  
But it's gonna bite us someday, so let's clean it up.  
  
To do that, change shm_mq_detach's API so it takes a shm_mq_handle  
not the underlying shm_mq.  This makes the callers simpler in most  
cases anyway.  Also fix a few places in parallel.c that were just  
pfree'ing the handle structs rather than doing proper cleanup.  
  
Back-patch to v10 because of the risk that the revenant shm_mq_detach  
callbacks would cause a live bug sometime.  Since this is an API  
change, it's too late to do it in 9.6.  (We could make a variant  
patch that preserves API, but I'm not excited enough to do that.)  
  
Discussion: https://postgr.es/m/8670.1504192177@sss.pgh.pa.us  
  

Improve code coverage of select_parallel test.

  
commit   : 4c7af96365d6a50c4f807a97dd37ac3e9c7459cf    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 31 Aug 2017 13:15:54 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 31 Aug 2017 13:15:54 -0400    

Click here for diff

  
Make sure that rescans of parallel indexscans are tested.  
Per code coverage report.  
  

Code review for nodeGatherMerge.c.

  
commit   : cb8e015b948d14d08b486ae1b2de879a0cc827d7    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 30 Aug 2017 17:21:08 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 30 Aug 2017 17:21:08 -0400    

Click here for diff

  
Comment the fields of GatherMergeState, and organize them a bit more  
sensibly.  Comment GMReaderTupleBuffer more usefully too.  Improve  
assorted other comments that were obsolete or just not very good English.  
  
Get rid of the use of a GMReaderTupleBuffer for the leader process;  
that was confusing, since only the "done" field was used, and that  
in a way redundant with need_to_scan_locally.  
  
In gather_merge_init, avoid calling load_tuple_array for  
already-known-exhausted workers.  I'm not sure if there's a live bug there,  
but the case is unlikely to be well tested due to timing considerations.  
  
Remove some useless code, such as duplicating the tts_isempty test done by  
TupIsNull.  
  
Remove useless initialization of ps.qual, replacing that with an assertion  
that we have no qual to check.  (If we did, the code would fail to check  
it.)  
  
Avoid applying heap_copytuple to a null tuple.  While that fails to crash,  
it's confusing and it makes the code less legible not more so IMO.  
  
Propagate a couple of these changes into nodeGather.c, as well.  
  
Back-patch to v10, partly because of the possibility that the  
gather_merge_init change is fixing a live bug, but mostly to keep  
the branches in sync to ease future bug fixes.  
  

Separate reinitialization of shared parallel-scan state from ExecReScan.

  
commit   : d6a149f4e6a1243ccae6e1817050da9e84050b2a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 30 Aug 2017 13:18:16 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 30 Aug 2017 13:18:16 -0400    

Click here for diff

  
Previously, the parallel executor logic did reinitialization of shared  
state within the ExecReScan code for parallel-aware scan nodes.  This is  
problematic, because it means that the ExecReScan call has to occur  
synchronously (ie, during the parent Gather node's ReScan call).  That is  
swimming very much against the tide so far as the ExecReScan machinery is  
concerned; the fact that it works at all today depends on a lot of fragile  
assumptions, such as that no plan node between Gather and a parallel-aware  
scan node is parameterized.  Another objection is that because ExecReScan  
might be called in workers as well as the leader, hacky extra tests are  
needed in some places to prevent unwanted shared-state resets.  
  
Hence, let's separate this code into two functions, a ReInitializeDSM  
call and the ReScan call proper.  ReInitializeDSM is called only in  
the leader and is guaranteed to run before we start new workers.  
ReScan is returned to its traditional function of resetting only local  
state, which means that ExecReScan's usual habits of delaying or  
eliminating child rescan calls are safe again.  
  
As with the preceding commit 7df2c1f8d, it doesn't seem to be necessary  
to make these changes in 9.6, which is a good thing because the FDW and  
CustomScan APIs are impacted.  
  
Discussion: https://postgr.es/m/CAA4eK1JkByysFJNh9M349u_nNjqETuEnY_y1VUc_kJiU0bxtaQ@mail.gmail.com  
  

Restore test case from a2b70c89ca1a5fcf6181d3c777d82e7b83d2de1b.

  
commit   : 5816ddc707e03342502975456d864448ab8dc333    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 30 Aug 2017 09:59:23 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 30 Aug 2017 09:59:23 -0400    

Click here for diff

  
Revert the reversion commits a20aac890 and 9b644745c.  In the wake of  
commit 7df2c1f8d, we should get stable buildfarm results from this test;  
if not, I'd like to know sooner not later.  
  
Discussion: https://postgr.es/m/CAA4eK1JkByysFJNh9M349u_nNjqETuEnY_y1VUc_kJiU0bxtaQ@mail.gmail.com  
  

Force rescanning of parallel-aware scan nodes below a Gather[Merge].

  
commit   : 54eac6e8c5527c22555bc9f61ffa93cd0920b4c7    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 30 Aug 2017 09:29:56 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 30 Aug 2017 09:29:56 -0400    

Click here for diff

  
The ExecReScan machinery contains various optimizations for postponing  
or skipping rescans of plan subtrees; for example a HashAgg node may  
conclude that it can re-use the table it built before, instead of  
re-reading its input subtree.  But that is wrong if the input contains  
a parallel-aware table scan node, since the portion of the table scanned  
by the leader process is likely to vary from one rescan to the next.  
This explains the timing-dependent buildfarm failures we saw after  
commit a2b70c89c.  
  
The established mechanism for showing that a plan node's output is  
potentially variable is to mark it as depending on some runtime Param.  
Hence, to fix this, invent a dummy Param (one that has a PARAM_EXEC  
parameter number, but carries no actual value) associated with each Gather  
or GatherMerge node, mark parallel-aware nodes below that node as dependent  
on that Param, and arrange for ExecReScanGather[Merge] to flag that Param  
as changed whenever the Gather[Merge] node is rescanned.  
  
This solution breaks an undocumented assumption made by the parallel  
executor logic, namely that all rescans of nodes below a Gather[Merge]  
will happen synchronously during the ReScan of the top node itself.  
But that's fundamentally contrary to the design of the ExecReScan code,  
and so was doomed to fail someday anyway (even if you want to argue  
that the bug being fixed here wasn't a failure of that assumption).  
A follow-on patch will address that issue.  In the meantime, the worst  
that's expected to happen is that given very bad timing luck, the leader  
might have to do all the work during a rescan, because workers think  
they have nothing to do, if they are able to start up before the eventual  
ReScan of the leader's parallel-aware table scan node has reset the  
shared scan state.  
  
Although this problem exists in 9.6, there does not seem to be any way  
for it to manifest there.  Without GatherMerge, it seems that a plan tree  
that has a rescan-short-circuiting node below Gather will always also  
have one above it that will short-circuit in the same cases, preventing  
the Gather from being rescanned.  Hence we won't take the risk of  
back-patching this change into 9.6.  But v10 needs it.  
  
Discussion: https://postgr.es/m/CAA4eK1JkByysFJNh9M349u_nNjqETuEnY_y1VUc_kJiU0bxtaQ@mail.gmail.com  
  

doc: Avoid sidebar element

  
commit   : 2fa44f666f144be5436d8725cc259fd1ce29f5ff    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 29 Aug 2017 19:33:24 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 29 Aug 2017 19:33:24 -0400    

Click here for diff

  
The formatting of the sidebar element didn't carry over to the new tool  
chain.  Instead of inventing a whole new way of dealing with it, just  
convert the one use to a "note".  
  

Doc: document libpq’s restriction to INT_MAX rows in a PGresult.

  
commit   : ff59f30dc30ecb4fb777a28774110c6637b10dc1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 29 Aug 2017 15:38:05 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 29 Aug 2017 15:38:05 -0400    

Click here for diff

  
As long as PQntuples, PQgetvalue, etc, use "int" for row numbers, we're  
pretty much stuck with this limitation.  The documentation formerly stated  
that the result of PQntuples "might overflow on 32-bit operating systems",  
which is just nonsense: that's not where the overflow would happen, and  
if you did reach an overflow it would not be on a 32-bit machine, because  
you'd have OOM'd long since.  
  
Discussion: https://postgr.es/m/CA+FnnTxyLWyjY1goewmJNxC==HQCCF4fKkoCTa9qR36oRAHDPw@mail.gmail.com  
  

Teach libpq to detect integer overflow in the row count of a PGresult.

  
commit   : b481b39b876f4bd0e793d93f6202071713bc0edb    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 29 Aug 2017 15:18:01 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 29 Aug 2017 15:18:01 -0400    

Click here for diff

  
Adding more than 1 billion rows to a PGresult would overflow its ntups and  
tupArrSize fields, leading to client crashes.  It'd be desirable to use  
wider fields on 64-bit machines, but because all of libpq's external APIs  
use plain "int" for row counters, that's going to be hard to accomplish  
without an ABI break.  Given the lack of complaints so far, and the general  
pain that would be involved in using such huge PGresults, let's settle for  
just preventing the overflow and reporting a useful error message if it  
does happen.  Also, for a couple more lines of code we can increase the  
threshold of trouble from INT_MAX/2 to INT_MAX rows.  
  
To do that, refactor pqAddTuple() to allow returning an error message that  
replaces the default assumption that it failed because of out-of-memory.  
  
Along the way, fix PQsetvalue() so that it reports all failures via  
pqInternalNotice().  It already did so in the case of bad field number,  
but neglected to report anything for other error causes.  
  
Because of the potential for crashes, this seems like a back-patchable  
bug fix, despite the lack of field reports.  
  
Michael Paquier, per a complaint from Igor Korot.  
  
Discussion: https://postgr.es/m/CA+FnnTxyLWyjY1goewmJNxC==HQCCF4fKkoCTa9qR36oRAHDPw@mail.gmail.com  
  

Improve docs about numeric formatting patterns (to_char/to_number).

  
commit   : 09ec0eb7a6e83aea8adb4522e92138974401cce3    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 29 Aug 2017 09:34:21 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 29 Aug 2017 09:34:21 -0400    

Click here for diff

  
The explanation about "0" versus "9" format characters was confusing  
and arguably wrong; the discussion of sign handling wasn't very good  
either.  Notably, while it's accurate to say that "FM" strips leading  
zeroes in date/time values, what it really does with numeric values  
is to strip *trailing* zeroes, and then only if you wrote "9" rather  
than "0".  Per gripes from Erwin Brandstetter.  
  
Discussion: https://postgr.es/m/CAGHENJ7jgRbTn6nf48xNZ=FHgL2WQ4X8mYsUAU57f-vq8PubEw@mail.gmail.com  
Discussion: https://postgr.es/m/CAGHENJ45ymd=GOCu1vwV9u7GmCR80_5tW0fP9C_gJKbruGMHvQ@mail.gmail.com  
  

Stamp 10beta4.

  
commit   : 2ff326dc4410c283515237cf311358afb9845912    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 28 Aug 2017 17:19:22 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 28 Aug 2017 17:19:22 -0400    

Click here for diff

  
  

Doc: adjust release-note credit for parallel pg_restore fix.

  
commit   : 7dadf7af820d160ace49d6e0b240603d5427bb20    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 28 Aug 2017 11:40:47 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 28 Aug 2017 11:40:47 -0400    

Click here for diff

  
Discussion: https://postgr.es/m/CAFcNs+pJ6_Ud-zg3vY_Y0mzfESdM34Humt8avKrAKq_H+v18Cg@mail.gmail.com  
  

Translation updates

  
commit   : 89f6d587f06b39884f755e871aeeb368e2a75712    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 28 Aug 2017 10:34:14 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 28 Aug 2017 10:34:14 -0400    

Click here for diff

  
Source-Git-URL: git://git.postgresql.org/git/pgtranslation/messages.git  
Source-Git-Hash: 31ad7831c3018858b662ed1d26a6c3bfe92b4e1f  
  

Fix over-aggressive sanity check in misc_sanity.sql.

  
commit   : df44405a0c5c725706317c1faa6e8a0760f17dcc    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 28 Aug 2017 10:14:20 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 28 Aug 2017 10:14:20 -0400    

Click here for diff

  
Fix thinko in commit 8be8510cf: it's okay to have dbid == 0 in normal  
(non-pin) entries in pg_shdepend, because global objects such as  
databases are entered that way.  The test would pass so long as it  
was run in a cluster containing no databases/tablespaces owned by,  
or granted to, roles other than the bootstrap superuser.  That's the  
expected situation for "make check", but for "make installcheck", not  
so much.  
  
Reported by Ryan Murphy.  
  
Discussion: https://postgr.es/m/CAHeEsBc6EQe0mxGBKDXAwJbntgfvoAd5MQC-5362SmC3Tng_6g@mail.gmail.com  
  

Clarify documentation

  
commit   : 5ecd7ccbe672a7ca2f3cd7252b28080100016fc2    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Sun, 27 Aug 2017 21:29:54 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Sun, 27 Aug 2017 21:29:54 -0400    

Click here for diff

  
Discussion: https://www.postgresql.org/message-id/flat/20170618071607.GA16418%40nol.local  
  

Release notes for 9.6.5, 9.5.9, 9.4.14, 9.3.19, 9.2.23.

  
commit   : 947a0cc273f21c0d32f648a2c71809d92ab89d20    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 27 Aug 2017 17:35:04 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 27 Aug 2017 17:35:04 -0400    

Click here for diff

  
  

Doc: update v10 release notes through today.

  
commit   : 5a6273513374756720ae246d7fa15a9e780b4d07    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 26 Aug 2017 16:50:19 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 26 Aug 2017 16:50:19 -0400    

Click here for diff

  
  

pg_test_timing: Some NLS fixes

  
commit   : 145ca364d310932871b06ee4d226c014058aef2c    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Sat, 26 Aug 2017 09:21:46 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Sat, 26 Aug 2017 09:21:46 -0400    

Click here for diff

  
The string "% of total" was marked by xgettext to be a c-format, but it  
is actually not, so mark up the source to prevent that.  
  
Compute the column widths of the final display dynamically based on the  
translated strings, so that translations don't mess up the display  
accidentally.  
  

Improve low-level backup documentation.

  
commit   : 3460728c67852d80569a0382e187480f08771778    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 25 Aug 2017 15:07:44 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 25 Aug 2017 15:07:44 -0400    

Click here for diff

  
Our documentation hasn't really caught up with the fact that  
non-exclusive backups can now be taken using pg_start_backup and  
pg_stop_backup even on standbys.  Update, also correcting some  
errors introduced by 52f8a59dd953c6820baf153e97cf07d31b8ac1d6.  
Updates to the 9.6 documentation are needed as well, but that  
will need a separate patch as some things are different on that  
version.  
  
David Steele, reviewed by Robert Haas and Michael Paquier  
  
Discussion: http://postgr.es/m/d4d951b9-89c0-6bc1-b6ff-d0b2dd5a8966@pgmasters.net  
  

pg_upgrade: Remove more dead code

  
commit   : 33043c69df790d9a08d2ac682c6f1d41c9a652bd    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 25 Aug 2017 12:02:29 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 25 Aug 2017 12:02:29 -0400    

Click here for diff

  
related to 6ce6a61840cc90172ad3da7bf303656132fa5fab  
  
Reported-by: Christoph Berg <myon@debian.org>  
  

Message translatability fixes

  
commit   : 9c57848921ec90fca8dfd297adcb4d5d07d40160    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 25 Aug 2017 11:49:05 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 25 Aug 2017 11:49:05 -0400    

Click here for diff

  
  

Fix harmless thinko in dsa.c.

  
commit   : 1563b8fa673800e79a54fac899f78c836f22ff5c    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Thu, 24 Aug 2017 15:07:40 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Thu, 24 Aug 2017 15:07:40 -0700    

Click here for diff

  
Commit 16be2fd100199bdf284becfcee02c5eb20d8a11d added DSA_ALLOC_HUGE,  
DSA_ALLOC_ZERO and DSA_ALLOC_NO_OOM which have the same numerical  
values and meanings as the similarly named MCXT_... macros.  In one  
place we accidentally used MCXT_ALLOC_NO_OOM when DSA_ALLOC_NO_OOM is  
wanted, so tidy that up.  
  
Author: Thomas Munro  
Discussion: http://postgr.es/m/CAEepm=2AimHxVkkxnMfQvbZMkXy0uKbVa0-D38c5-qwrCm4CMQ@mail.gmail.com  
Backpatch: 10, where dsa was introduced.  
  

psql: Fix \gx when FETCH_COUNT is used

  
commit   : 51d0fa8ed93fe5befe91498f1a3eb5aede32677a    
  
author   : Stephen Frost <sfrost@snowman.net>    
date     : Thu, 24 Aug 2017 16:20:48 -0400    
  
committer: Stephen Frost <sfrost@snowman.net>    
date     : Thu, 24 Aug 2017 16:20:48 -0400    

Click here for diff

  
Set expanded output when requested through \gx in ExecQueryUsingCursor()  
(used when FETCH_COUNT is set).  
  
Discussion: https://www.postgresql.org/message-id/CB7A53AA-5645-4BDD-AB07-4D22CD9D8FF1%40gmx.net  
Author: Tobias Bussmann  
  

pg_upgrade: Remove dead code

  
commit   : 8a7beca69112755094a3f2ca1daa745d378dd452    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 24 Aug 2017 15:29:35 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 24 Aug 2017 15:29:35 -0400    

Click here for diff

  
Remove code meant for upgrading to a particular version of PostgreSQL  
9.0.  Since pg_upgrade only supports upgrading to the current major  
version, this code is no longer useful.  
  

Increase SCRAM salt length

  
commit   : cf98e3837db36d985507a924e392847e2ab857d0    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 24 Aug 2017 14:04:28 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 24 Aug 2017 14:04:28 -0400    

Click here for diff

  
The original value 12 was set based on RFC 5802 for SCRAM-SHA-1, but RFC  
7677 for SCRAM-SHA-256 uses 16, so use that.  (This does not affect the  
validity of already stored verifiers.)  
  
Discussion: https://www.postgresql.org/message-id/flat/12cc9297-7e05-932f-d863-765e5626ead4%402ndquadrant.com  
  

Update code comment for temporary replication slots

  
commit   : d51b0872bf9a71d9585ca13bbf1f9463d9c61182    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 23 Aug 2017 14:59:25 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 23 Aug 2017 14:59:25 -0400    

Click here for diff

  
Reported-by: Alvaro Herrera <alvherre@2ndquadrant.com>  
  

Fix outdated comment

  
commit   : da19c32c6b7dd7d0ff5814538adf5aaa665848a1    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 23 Aug 2017 14:19:35 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 23 Aug 2017 14:19:35 -0400    

Click here for diff

  
Author: Thomas Munro <thomas.munro@enterprisedb.com>  
  

Tweak some SCRAM error messages and code comments

  
commit   : 8bf94694691d1188aee671cdd9ce59c27df9bc7f    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 23 Aug 2017 12:01:43 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 23 Aug 2017 12:01:43 -0400    

Click here for diff

  
Clarify/correct some error messages, fix up some code comments that  
confused SASL and SCRAM, and other minor fixes.  No changes in  
functionality.  
  

Fix translation marker

  
commit   : 5e87f7b1d7079fcbbdb03c1ad02a3e40b2202e3e    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 23 Aug 2017 09:56:38 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 23 Aug 2017 09:56:38 -0400    

Click here for diff

  
This was erroneously removed in  
55a70a023c3daefca9bbd68bfbe6862af10ab479.  
  

pg_upgrade: Message translatability and style fixes

  
commit   : 2ac307bc0125235f124e45bb697d5b445f0118ca    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 22 Aug 2017 20:32:17 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 22 Aug 2017 20:32:17 -0400    

Click here for diff

  
  

doc: Mention identity column feature in section on serial

  
commit   : adce8912e63ade2ca5bba674fcbad860a73888fd    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 22 Aug 2017 19:55:21 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 22 Aug 2017 19:55:21 -0400    

Click here for diff

  
Reported-by: Basil Bourque <basil.bourque@pobox.com>  
  

Backpatch introduction of TupleDescAttr(tupdesc, i).

  
commit   : d34a74dd064af959acd9040446925d9d53dff15b    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Tue, 22 Aug 2017 07:46:05 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Tue, 22 Aug 2017 07:46:05 -0700    

Click here for diff

  
2cd70845240 / c6293249d change the way individual attributes in a  
TupleDesc are stored / accessed.  To reduce the effort of making  
extensions compatible with postgresql 11, and to ease future  
backpatching, backpatch introduction of TupleDescAttr() to all  
releases.  Do not backpatch change in storage, as that'd be a breaking  
change for existing and working extensions.  
  
Author: Andres Freund  
Discussion: https://postgr.es/m/20170820181723.tdswdinzptbcwhrr@alap3.anarazel.de  
Backpatch: 9.2-  
  

Don’t install ICU collation keyword variants

  
commit   : 958ffb8c286d93d1bfced17e6300d13f9634b431    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 21 Aug 2017 11:22:00 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 21 Aug 2017 11:22:00 -0400    

Click here for diff

  
Users can still create them themselves.  Instead, document Unicode TR 35  
collation options for ICU, so users can create all this themselves.  
  
Reviewed-by: Peter Geoghegan <pg@bowt.ie>  
  

Expand set of predefined ICU locales

  
commit   : a79fb8e0c452a9b88206e2abd4add2b432a2596b    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 21 Aug 2017 09:17:06 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 21 Aug 2017 09:17:06 -0400    

Click here for diff

  
Install language+region combinations even if they are not distinct from  
the language's base locale.  This gives better long-term stability of  
the set of predefined locales and makes the predefined locales less  
implementation-dependent and more practical for users.  
  
Reviewed-by: Peter Geoghegan <pg@bowt.ie>  
  

Inject $(ICU_LIBS) regardless of platform.

  
commit   : b8a25494819ac2551a71674effb7f50a7b7b74f6    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sun, 20 Aug 2017 21:22:18 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sun, 20 Aug 2017 21:22:18 -0700    

Click here for diff

  
It appeared in a conditional that excludes AIX, Cygwin and MinGW.  Give  
ICU support a chance to work on those platforms.  Back-patch to v10,  
where ICU support was introduced.  
  

Fix possible core dump in parallel restore when using a TOC list.

  
commit   : 1c3869c0bea4376bcbb358e1abf5ed95e8c41865    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 19 Aug 2017 13:39:37 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 19 Aug 2017 13:39:37 -0400    

Click here for diff

  
Commit 3eb9a5e7c unintentionally introduced an ordering dependency  
into restore_toc_entries_prefork().  The existing coding of  
reduce_dependencies() contains a check to skip moving a TOC entry  
to the ready_list if it wasn't initially in the pending_list.  
This used to suffice to prevent reduce_dependencies() from trying to  
move anything into the ready_list during restore_toc_entries_prefork(),  
because the pending_list stayed empty throughout that phase; but it no  
longer does.  The problem doesn't manifest unless the TOC has been  
reordered by SortTocFromFile, which is how I missed it in testing.  
  
To fix, just add a test for ready_list == NULL, converting the call  
with NULL from a poor man's sanity check into an explicit command  
not to touch TOC items' list membership.  Clarify some of the comments  
around this; in particular, note the primary purpose of the check for  
pending_list membership, which is to ensure that we can't try to restore  
the same item twice, in case a TOC list forces it to be restored before  
its dependency count goes to zero.  
  
Per report from Fabrízio de Royes Mello.  Back-patch to 9.3, like the  
previous commit.  
  
Discussion: https://postgr.es/m/CAFcNs+pjuv0JL_x4+=71TPUPjdLHOXA4YfT32myj_OrrZb4ohA@mail.gmail.com  
  

Fix creation of ICU comments for keyword variants

  
commit   : 7c84acc455368721e046dc0cc2eb84d62c4f5e61    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 18 Aug 2017 23:02:28 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 18 Aug 2017 23:02:28 -0400    

Click here for diff

  
It would create the comment referring to the keyword-less parent  
locale.  This was broken in ddb5fdc068635d003a0d1c303cb109d1cb3ebeb1.  
  

Fix interaction of triggers, partitioning, and EXPLAIN ANALYZE.

  
commit   : d4b42e5215fae85e2ae473ba4957705f4c9861e9    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 18 Aug 2017 13:01:05 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 18 Aug 2017 13:01:05 -0400    

Click here for diff

  
Add a new EState member es_leaf_result_relations, so that the trigger  
code knows about ResultRelInfos created by tuple routing.  Also make  
sure ExplainPrintTriggers knows about partition-related  
ResultRelInfos.  
  
Etsuro Fujita, reviewed by Amit Langote  
  
Discussion: http://postgr.es/m/57163e18-8e56-da83-337a-22f2c0008051@lab.ntt.co.jp  
  

Temporarily revert test case from a2b70c89ca1a5fcf6181d3c777d82e7b83d2de1b.

  
commit   : 9b644745c94944de8f23449524671601d8863830    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 17 Aug 2017 18:35:14 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 17 Aug 2017 18:35:14 -0400    

Click here for diff

  
That code patch was good as far as it went, but the associated test case  
has exposed fundamental brain damage in the parallel scan mechanism,  
which is going to take nontrivial work to correct.  In the interests of  
getting the buildfarm back to green so that unrelated work can proceed,  
let's temporarily remove the test case.  
  

Don’t lock tables in RelationGetPartitionDispatchInfo.

  
commit   : 7c0ca2900f7cae490fd551096cb7dc581cfe45c8    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Thu, 17 Aug 2017 15:39:17 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Thu, 17 Aug 2017 15:39:17 -0400    

Click here for diff

  
Instead, lock them in the caller using find_all_inheritors so that  
they get locked in the standard order, minimizing deadlock risks.  
  
Also in RelationGetPartitionDispatchInfo, avoid opening tables which  
are not partitioned; there's no need.  
  
Amit Langote, reviewed by Ashutosh Bapat and Amit Khandekar  
  
Discussion: http://postgr.es/m/91b36fa1-c197-b72f-ca6e-56c593bae68c@lab.ntt.co.jp  
  

Fix ExecReScanGatherMerge.

  
commit   : de1ca6919ff8f50e09122a1001eee1420b047199    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 17 Aug 2017 13:49:22 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 17 Aug 2017 13:49:22 -0400    

Click here for diff

  
Not surprisingly, since it'd never ever been tested, ExecReScanGatherMerge  
didn't work.  Fix it, and add a regression test case to exercise it.  
  
Amit Kapila  
  
Discussion: https://postgr.es/m/CAA4eK1JkByysFJNh9M349u_nNjqETuEnY_y1VUc_kJiU0bxtaQ@mail.gmail.com  
  

Further tweaks to compiler flags for PL/Perl on Windows.

  
commit   : 1d7a479d22f68c03d22c76b9a6de5cdf6ea9759b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 17 Aug 2017 13:13:47 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 17 Aug 2017 13:13:47 -0400    

Click here for diff

  
It now emerges that we can only rely on Perl to tell us we must use  
-D_USE_32BIT_TIME_T if it's Perl 5.13.4 or later.  For older versions,  
revert to our previous practice of assuming we need that symbol in  
all 32-bit Windows builds.  This is not ideal, but inquiring into  
which compiler version Perl was built with seems far too fragile.  
In any case, we had not previously had complaints about these old  
Perl versions, so let's assume this is Good Enough.  (It's still  
better than the situation ante commit 5a5c2feca, in that at least  
the effects are confined to PL/Perl rather than the whole PG build.)  
  
Back-patch to all supported versions, like 5a5c2feca and predecessors.  
  
Discussion: https://postgr.es/m/CANFyU97OVQ3+Mzfmt3MhuUm5NwPU=-FtbNH5Eb7nZL9ua8=rcA@mail.gmail.com  
  

doc: Update RFC URLs

  
commit   : ca49d69b7c8f04c495ce39ff4460e017656db901    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 17 Aug 2017 11:39:00 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 17 Aug 2017 11:39:00 -0400    

Click here for diff

  
Consistently use the IETF HTML links instead of a random mix of  
different sites and formats.  Correct one RFC number and fix one broken  
link.  
  

Remove bogus line from comment.

  
commit   : b469387fc09a00e1ea9c7e010fafdcf117299cad    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Thu, 17 Aug 2017 11:19:07 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Thu, 17 Aug 2017 11:19:07 -0400    

Click here for diff

  
Spotted by Tom Lane  
  
Discussion: http://postgr.es/m/27897.1502901074@sss.pgh.pa.us  
  

doc: Fix table column count

  
commit   : 28c56553cb39174d0d33e5ed8200dc5e508ba5d8    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 17 Aug 2017 10:37:12 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 17 Aug 2017 10:37:12 -0400    

Click here for diff

  
Author: Erik Rijkers <er@xs4all.nl>  
  

pg_dump: Support using synchronized snapshots on standbys

  
commit   : e4892c68184e199c3117a8f8b52da22a77702a05    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 16 Aug 2017 19:46:50 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 16 Aug 2017 19:46:50 -0400    

Click here for diff

  
This became possible by commit  
6c2003f8a1bbc7c192a2e83ec51581c018aa162f.  This just makes pg_dump aware  
of it and updates the documentation.  
  
Author: Petr Jelinek <petr.jelinek@2ndquadrant.com>  
  

doc: Update URL of DocBook XSL stylesheets

  
commit   : 0c16efcb533c95cec3e11daa13dba18110231831    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 16 Aug 2017 14:44:26 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 16 Aug 2017 14:44:26 -0400    

Click here for diff

  
Author: Masahiko Sawada <sawada.mshk@gmail.com>  
  

doc: Add logical replication to comparison matrix

  
commit   : 2327690df4f839ed34b088727a632867cbc0988e    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 16 Aug 2017 13:59:40 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 16 Aug 2017 13:59:40 -0400    

Click here for diff

  
Author: Steve Singer <steve@ssinger.info>  
  

Allow continuation lines in ecpg cppline parsing.

  
commit   : a6b174f55716c9da2e16804f2d4be4d8f76255ef    
  
author   : Michael Meskes <meskes@postgresql.org>    
date     : Tue, 15 Aug 2017 16:06:56 +0200    
  
committer: Michael Meskes <meskes@postgresql.org>    
date     : Tue, 15 Aug 2017 16:06:56 +0200    

Click here for diff

  
  

Initialize replication_slot_catalog_xmin in procarray

  
commit   : 226be4062865476d190701d6ac13082a0595121e    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 15 Aug 2017 21:05:21 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 15 Aug 2017 21:05:21 -0400    

Click here for diff

  
Although not confirmed and probably rare, if the newly allocated memory  
is not already zero, this could possibly have caused some problems.  
  
Also reorder the initializations slightly so they match the order of the  
struct definition.  
  
Author: Wong, Yi Wen <yiwong@amazon.com>  
Reviewed-by: Masahiko Sawada <sawada.mshk@gmail.com>  
  

Include foreign tables in information_schema.table_privileges

  
commit   : 3ea58216de4b26e27be8c6b23e44e275804542f2    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 15 Aug 2017 19:27:22 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 15 Aug 2017 19:27:22 -0400    

Click here for diff

  
This appears to have been an omission in the original commit  
0d692a0dc9f.  All related information_schema views already include  
foreign tables.  
  
Reported-by: Nicolas Thauvin <nicolas.thauvin@dalibo.com>  
  

psql: Add tab completion for \pset pager

  
commit   : 7502f399de38c68d2bb327e4071dd2fcdb5a20e6    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 15 Aug 2017 19:10:38 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 15 Aug 2017 19:10:38 -0400    

Click here for diff

  
Author: Pavel Stehule <pavel.stehule@gmail.com>  
  

Simplify autovacuum work-item implementation

  
commit   : f2f9fcb3030ba67b4347a44b18b201f84d23997b    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 15 Aug 2017 18:14:07 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 15 Aug 2017 18:14:07 -0300    

Click here for diff

  
The initial implementation of autovacuum work-items used a dynamic  
shared memory area (DSA).  However, it's argued that dynamic shared  
memory is not portable enough, so we cannot rely on it being supported  
everywhere; at the same time, autovacuum work-items are now a critical  
part of the server, so it's not acceptable that they don't work in the  
cases where dynamic shared memory is disabled.  Therefore, let's fall  
back to a simpler implementation of work-items that just uses  
autovacuum's main shared memory segment for storage.  
  
Discussion: https://postgr.es/m/CA+TgmobQVbz4K_+RSmiM9HeRKpy3vS5xnbkL95gSEnWijzprKQ@mail.gmail.com  
  

Fix logical replication protocol comparison logic

  
commit   : edbad25877b10df07164345a8e6ae01236b6a26b    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 15 Aug 2017 16:20:20 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 15 Aug 2017 16:20:20 -0400    

Click here for diff

  
Since we currently only have one protocol, this doesn't make much of a  
difference other than the error message.  
  
Author: Yugo Nagata <nagata@sraoss.co.jp>  
  

doc: Add missing logical replication protocol message

  
commit   : 0cafc267b5b2a0b9d8d93c7c3f1e88adb37fea6e    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 15 Aug 2017 15:36:18 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 15 Aug 2017 15:36:18 -0400    

Click here for diff

  
Author: Masahiko Sawada <sawada.mshk@gmail.com>  
  

Simplify some code in logical replication launcher

  
commit   : 292d9b66e2251df4767a43d78927a614561a21d6    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 15 Aug 2017 15:13:06 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 15 Aug 2017 15:13:06 -0400    

Click here for diff

  
Avoid unnecessary locking calls when a subscription is disabled.  
  
Author: Yugo Nagata <nagata@sraoss.co.jp>  
  

doc: Improve PDF bookmarks

  
commit   : 4e7cd035abaae16e45305417073e7009518acc61    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 15 Aug 2017 14:37:44 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 15 Aug 2017 14:37:44 -0400    

Click here for diff

  
Also create PDF bookmarks/ToC entries for subsections of reference  
pages.  This was a regression from the previous jadetex-based build.  
  
Reported-by: Erik Rijkers <er@xs4all.nl>  
  

Fix error handling path in autovacuum launcher

  
commit   : 870da1e1546c9563c5ae45918392cf7bbc7e5b0e    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 15 Aug 2017 13:35:12 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 15 Aug 2017 13:35:12 -0300    

Click here for diff

  
The original code (since 00e6a16d01) was assuming aborting the  
transaction in autovacuum launcher was sufficient to release all  
resources, but in reality the launcher runs quite a lot of code out of  
any transactions.  Re-introduce individual cleanup calls to make abort  
more robust.  
  
Reported-by: Robert Haas  
Discussion: https://postgr.es/m/CA+TgmobQVbz4K_+RSmiM9HeRKpy3vS5xnbkL95gSEnWijzprKQ@mail.gmail.com  
  

Distinguish wait-for-connection from wait-for-write-ready on Windows.

  
commit   : d7ab908fbab5094e92a167441ec8d6bfb3b0c9fc    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 15 Aug 2017 11:07:52 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 15 Aug 2017 11:07:52 -0400    

Click here for diff

  
The API for WaitLatch and friends followed the Unix convention in which  
waiting for a socket connection to complete is identical to waiting for  
the socket to accept a write.  While Windows provides a select(2)  
emulation that agrees with that, the native WaitForMultipleObjects API  
treats them as quite different --- and for some bizarre reason, it will  
report a not-yet-connected socket as write-ready.  libpq itself has so  
far escaped dealing with this because it waits with select(), but in  
libpqwalreceiver.c we want to wait using WaitLatchOrSocket.  The semantics  
mismatch resulted in replication connection failures on Windows, but only  
for remote connections (apparently, localhost connections complete  
immediately, or at least too fast for anyone to have noticed the problem  
in single-machine testing).  
  
To fix, introduce an additional WL_SOCKET_CONNECTED wait flag for  
WaitLatchOrSocket, which is identical to WL_SOCKET_WRITEABLE on  
non-Windows, but results in waiting for FD_CONNECT events on Windows.  
  
Ideally, we would also distinguish the two conditions in the API for  
PQconnectPoll(), but changing that API at this point seems infeasible.  
Instead, cheat by checking for PQstatus() == CONNECTION_STARTED to  
determine that we're still waiting for the connection to complete.  
(This is a cheat mainly because CONNECTION_STARTED is documented as an  
internal state rather than something callers should rely on.  Perhaps  
we ought to change the documentation ... but this patch doesn't.)  
  
Per reports from Jobin Augustine and Igor Neyman.  Back-patch to v10  
where commit 1e8a85009 exposed this longstanding shortcoming.  
  
Andres Freund, minor fix and some code review/beautification by me  
  
Discussion: https://postgr.es/m/CAHBggj8g2T+ZDcACZ2FmzX9CTxkWjKBsHd6NkYB4i9Ojf6K1Fw@mail.gmail.com  
  

Avoid unnecessary single-child Append nodes.

  
commit   : 17a2a27b49ae19a1002b8230a6ceeef53082211e    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Tue, 15 Aug 2017 09:16:33 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Tue, 15 Aug 2017 09:16:33 -0400    

Click here for diff

  
Before commit d3cc37f1d801a6b5cad9bf179274a8, an inheritance parent  
whose only children were temp tables of other sessions would end up  
as a simple scan of the parent; but with that commit, we end up with  
an Append node, per a report from Ashutosh Bapat.  Tweak the logic  
so that we go back to the old way, and update the function header  
comment for partitioning while we're at it.  
  
Ashutosh Bapat, reviewed by Amit Langote and adjusted by me.  
  
Discussion: http://postgr.es/m/CAFjFpReWJr1yTkHU=OqiMBmcYCMoSW3VPR39RBuQ_ovwDFBT5Q@mail.gmail.com  
  

Add missing call to ExecReScanGatherMerge.

  
commit   : 29990634c76a2278ae68bfb951fd20d5510a732d    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Tue, 15 Aug 2017 08:06:36 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Tue, 15 Aug 2017 08:06:36 -0400    

Click here for diff

  
Amit Kapila  
  
Discussion: http://postgr.es/m/CAA4eK1KeQWZOoDmDmGMwuqzPW9JhRS+ditQVFdAfGjNmMZzqMQ@mail.gmail.com  
  

Expand coverage of parallel gather merge a bit.

  
commit   : ee5572e051955ef4570f95413dc6cddb4df51d50    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 14 Aug 2017 15:21:26 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Mon, 14 Aug 2017 15:21:26 -0700    

Click here for diff

  
Previously paths reaching heap_compare_slots weren't covered.  
  
Author: Rushabh Lathia  
Reviewed-By: Andres Freund  
Discussion:  
	https://postgr.es/m/CAGPqQf3C+3PBujb+7m=ceWeii4-vBY=XS99LjzrpkpefvzJbFg@mail.gmail.com  
	https://postgr.es/m/27200.1502482851@sss.pgh.pa.us  
Backpatch: 10, where gather merge was introduced  
  

Final pgindent + perltidy run for v10.

  
commit   : 21d304dfedb4f26d0d6587d9ac39b1b5c499bb55    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 14 Aug 2017 17:29:33 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 14 Aug 2017 17:29:33 -0400    

Click here for diff

  
  

Handle elog(FATAL) during ROLLBACK more robustly.

  
commit   : 5b6289c1e07dc45f09c3169a189e60d2fcaec2b3    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 14 Aug 2017 15:43:20 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 14 Aug 2017 15:43:20 -0400    

Click here for diff

  
Stress testing by Andreas Seltenreich disclosed longstanding problems that  
occur if a FATAL exit (e.g. due to receipt of SIGTERM) occurs while we are  
trying to execute a ROLLBACK of an already-failed transaction.  In such a  
case, xact.c is in TBLOCK_ABORT state, so that AbortOutOfAnyTransaction  
would skip AbortTransaction and go straight to CleanupTransaction.  This  
led to an assert failure in an assert-enabled build (due to the ROLLBACK's  
portal still having a cleanup hook) or without assertions, to a FATAL exit  
complaining about "cannot drop active portal".  The latter's not  
disastrous, perhaps, but it's messy enough to want to improve it.  
  
We don't really want to run all of AbortTransaction in this code path.  
The minimum required to clean up the open portal safely is to do  
AtAbort_Memory and AtAbort_Portals.  It seems like a good idea to  
do AtAbort_Memory unconditionally, to be entirely sure that we are  
starting with a safe CurrentMemoryContext.  That means that if the  
main loop in AbortOutOfAnyTransaction does nothing, we need an extra  
step at the bottom to restore CurrentMemoryContext = TopMemoryContext,  
which I chose to do by invoking AtCleanup_Memory.  This'll result in  
calling AtCleanup_Memory twice in many of the paths through this function,  
but that seems harmless and reasonably inexpensive.  
  
The original motivation for the assertion in AtCleanup_Portals was that  
we wanted to be sure that any user-defined code executed as a consequence  
of the cleanup hook runs during AbortTransaction not CleanupTransaction.  
That still seems like a valid concern, and now that we've seen one case  
of the assertion firing --- which means that exactly that would have  
happened in a production build --- let's replace the Assert with a runtime  
check.  If we see the cleanup hook still set, we'll emit a WARNING and  
just drop the hook unexecuted.  
  
This has been like this a long time, so back-patch to all supported  
branches.  
  
Discussion: https://postgr.es/m/877ey7bmun.fsf@ansel.ydns.eu  
  

Fix typo

  
commit   : 7f1bb1d7346b67a62e8ec59f79f8284cb7fb4394    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 14 Aug 2017 13:53:05 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 14 Aug 2017 13:53:05 -0400    

Click here for diff

  
Author: Masahiko Sawada <sawada.mshk@gmail.com>  
  

doc: Fix logical replication protocol doc detail

  
commit   : 79e5de690efce6e7aaa9c60e10389a8bc58c1617    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 14 Aug 2017 13:42:03 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 14 Aug 2017 13:42:03 -0400    

Click here for diff

  
Author: Masahiko Sawada <sawada.mshk@gmail.com>  
Reported-by: Kyle Conroy <kyle@kyleconroy.com>  
Bug: #14775  
  

Absorb -D_USE_32BIT_TIME_T switch from Perl, if relevant.

  
commit   : 5a5c2feca3fd858e70ea348822595547e6fa6c15    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 14 Aug 2017 11:48:59 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 14 Aug 2017 11:48:59 -0400    

Click here for diff

  
Commit 3c163a7fc's original choice to ignore all #define symbols whose  
names begin with underscore turns out to be too simplistic.  On Windows,  
some Perl installations are built with -D_USE_32BIT_TIME_T, and we must  
absorb that or we get the wrong result for sizeof(PerlInterpreter).  
  
This effectively re-reverts commit ef58b87df, which injected that symbol  
in a hacky way, making it apply to all of Postgres not just PL/Perl.  
More significantly, it did so on *all* 32-bit Windows builds, even when  
the Perl build to be used did not select this option; so that it fails  
to work properly with some newer Perl builds.  
  
By making this change, we would be introducing an ABI break in 32-bit  
Windows builds; but fortunately we have not used type time_t in any  
exported Postgres APIs in a long time.  So it should be OK, both for  
PL/Perl itself and for third-party extensions, if an extension library  
is built with a different _USE_32BIT_TIME_T setting than the core code.  
  
Patch by me, based on research by Ashutosh Sharma and Robert Haas.  
Back-patch to all supported branches, as commit 3c163a7fc was.  
  
Discussion: https://postgr.es/m/CANFyU97OVQ3+Mzfmt3MhuUm5NwPU=-FtbNH5Eb7nZL9ua8=rcA@mail.gmail.com  
  

Changed ecpg parser to allow RETURNING clauses without attached C variables.

  
commit   : ea0ca75d5d14e0c98782a2188405685af4a475a0    
  
author   : Michael Meskes <meskes@postgresql.org>    
date     : Mon, 14 Aug 2017 11:29:34 +0200    
  
committer: Michael Meskes <meskes@postgresql.org>    
date     : Mon, 14 Aug 2017 11:29:34 +0200    

Click here for diff

  
  

Remove AtEOXact_CatCache().

  
commit   : 004a9702e062b5b6d61813f3fc8d71654d331d05    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 13 Aug 2017 16:15:14 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 13 Aug 2017 16:15:14 -0400    

Click here for diff

  
The sole useful effect of this function, to check that no catcache  
entries have positive refcounts at transaction end, has really been  
obsolete since we introduced ResourceOwners in PG 8.1.  We reduced the  
checks to assertions years ago, so that the function was a complete  
no-op in production builds.  There have been previous discussions about  
removing it entirely, but consensus up to now was that it had some small  
value as a cross-check for bugs in the ResourceOwner logic.  
  
However, it now emerges that it's possible to trigger these assertions  
if you hit an assert-enabled backend with SIGTERM during a call to  
SearchCatCacheList, because that function temporarily increases the  
refcounts of entries it's intending to add to a catcache list construct.  
In a normal ERROR scenario, the extra refcounts are cleaned up by  
SearchCatCacheList's PG_CATCH block; but in a FATAL exit we do a  
transaction abort and exit without ever executing PG_CATCH handlers.  
  
There's a case to be made that this is a generic hazard and we should  
consider restructuring elog(FATAL) handling so that pending PG_CATCH  
handlers do get run.  That's pretty scary though: it could easily create  
more problems than it solves.  Preliminary stress testing by Andreas  
Seltenreich suggests that there are not many live problems of this ilk,  
so we rejected that idea.  
  
There are more-localized ways to fix the problem; the most principled  
one would be to use PG_ENSURE_ERROR_CLEANUP instead of plain PG_TRY.  
But adding cycles to SearchCatCacheList isn't very appealing.  We could  
also weaken the assertions in AtEOXact_CatCache in some more or less  
ad-hoc way, but that just makes its raison d'etre even less compelling.  
In the end, the most reasonable solution seems to be to just remove  
AtEOXact_CatCache altogether, on the grounds that it's not worth trying  
to fix it.  It hasn't found any bugs for us in many years.  
  
Per report from Jeevan Chalke.  Back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/CAM2+6=VEE30YtRQCZX7_sCFsEpoUkFBV1gZazL70fqLn8rcvBA@mail.gmail.com  
  

Reword comment for clarity

  
commit   : 2336f842843e5bd26779692b39eaf0ef9d4d31da    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Sat, 12 Aug 2017 21:36:07 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Sat, 12 Aug 2017 21:36:07 -0400    

Click here for diff

  
Reported by Masahiko Sawada  
Discussion: https://postgr.es/m/CAD21AoB+ycZ2z-4Ye=6MfQ_r0aV5r6cvVPw4kOyPdp6bHqQoBQ@mail.gmail.com  
  

Fix vertical spanning in table “wait_event Description”.

  
commit   : e88928c50dfe2623c899f82b54aad69da248ad07    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sat, 12 Aug 2017 18:19:49 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sat, 12 Aug 2017 18:19:49 -0700    

Click here for diff

  
Michael Paquier  
  
Discussion: https://postgr.es/m/CAB7nPqQr3KEQvXeuUNYcm7tDK2Fb9oLUQ8DU0+y0RZEoN_1_gg@mail.gmail.com  
  

Simplify fetch-slot-xmins logic in recovery TAP tests.

  
commit   : 3043c1ddd13cd902d820d9aea353e60ce2d3d698    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 12 Aug 2017 12:08:54 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 12 Aug 2017 12:08:54 -0400    

Click here for diff

  
Merge wait_slot_xmins() into get_slot_xmins().  At this point the only  
place that wasn't doing a wait was the initial-state test, and a wait  
there seems pretty harmless.  
  
Michael Paquier  
  
Discussion: https://postgr.es/m/CAB7nPqSp_SLQb2uU7am+sn4V3g1UKv8j3yZU385oAG1cG_BN9Q@mail.gmail.com  
  

Be more thorough about cleaning out gcov litter.

  
commit   : d6ecad812f981e6ea611c1022ce7540830393a36    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 11 Aug 2017 17:39:27 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 11 Aug 2017 17:39:27 -0400    

Click here for diff

  
At least on my machine, a run with code coverage enabled produces some  
".gcov" files whose names begin with ".".  "rm -f *.gcov" fails to match  
those, so they don't get cleaned up by "make clean".  Fix it.  
  

Add regression tests exercising more code paths in nodeLimit.c.

  
commit   : 3c8de95979008d67713429d858957c5c78c23d75    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 11 Aug 2017 17:27:54 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 11 Aug 2017 17:27:54 -0400    

Click here for diff

  
Perusal of the code coverage report shows that the existing regression  
test cases for LIMIT/OFFSET don't exercise the nodeLimit code paths  
involving backwards scan, empty results, or null values of LIMIT/OFFSET.  
Improve the coverage.  
  

Add regression tests exercising the non-hashed code paths in nodeSetop.c.

  
commit   : 6efca23cc039b6a0b25d2ebf4a22ab7363d17fcf    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 11 Aug 2017 16:52:12 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 11 Aug 2017 16:52:12 -0400    

Click here for diff

  
Perusal of the code coverage report shows that the existing regression  
test cases for INTERSECT and EXCEPT seemingly all prefer the SETOP_HASHED  
implementation.  Add some test cases in which we force use of the  
SETOP_SORTED mode.  
  

doc: Add example for inet vs cidr difference

  
commit   : ee844bb42632521c89497a2845079770b32a934e    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 11 Aug 2017 16:40:56 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 11 Aug 2017 16:40:56 -0400    

Click here for diff

  
Reported-by: kes-kes@yandex.ru  
  

doc: Update description of rolreplication column

  
commit   : fa65c8c73cb21ab3154db2f0f291227ba901c996    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 11 Aug 2017 16:14:55 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 11 Aug 2017 16:14:55 -0400    

Click here for diff

  
Since PostgreSQL 9.6, rolreplication no longer determines whether a role  
can run pg_start_backup() and pg_stop_backup(), so remove that.  
  
Add that this attribute determines whether a role can create and drop  
replication slots.  
  
Reported-by: Fujii Masao <masao.fujii@gmail.com>  
  

doc: Small wording improvement

  
commit   : 22701a7ec66ffb3b62fae7f04ef36bc6ea21df52    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 11 Aug 2017 15:52:39 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 11 Aug 2017 15:52:39 -0400    

Click here for diff

  
Author: Jeff Janes <jeff.janes@gmail.com>  
  

pg_upgrade: Clarify one message

  
commit   : d4ede668d6f0ca9e5dd6def4ea1ccddc441c6073    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 11 Aug 2017 15:44:10 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 11 Aug 2017 15:44:10 -0400    

Click here for diff

  
Reported-by: Dennis Björklund <db@zigo.dhs.org>  
  

Remove pgbench’s restriction on placement of -M switch.

  
commit   : 79681844297a9d499a10094a17e52b365afdd8bb    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 11 Aug 2017 15:19:40 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 11 Aug 2017 15:19:40 -0400    

Click here for diff

  
Previously the -M switch had to appear before any switch that directly  
or indirectly specified a benchmarking script.  This was both confusing  
and inadequately documented, as per gripe from Tatsuo Ishii.  We can  
remove the restriction at the cost of making an extra pass over the  
lists of SQL commands, which seems like a cheap price (the string scans  
themselves likely cost much more).  The change is just to not extract  
parameters from the SQL commands until we have finished parsing the  
switches and know the final value of -M.  
  
Per discussion, we'll treat this as a low-grade bug fix and sneak it  
into v10, rather than holding it for v11.  
  
Tom Lane, reviewed by Tatsuo Ishii and Fabien Coelho  
  
Discussion: https://postgr.es/m/20170802.110328.1963639094551443169.t-ishii@sraoss.co.jp  
Discussion: https://postgr.es/m/10208.1502465077@sss.pgh.pa.us  
  

Remove uses of “slave” in replication contexts

  
commit   : a1ef920e27ba6ab3602aaf6d6751d8628fac1af8    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 7 Aug 2017 17:42:47 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 7 Aug 2017 17:42:47 -0400    

Click here for diff

  
This affects mostly code comments, some documentation, and tests.  
Official APIs already used "standby".  
  

Reject use of ucol_strcollUTF8() before ICU 53

  
commit   : d6391b03b3025372620925e5746e65c288a1e371    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 9 Aug 2017 20:34:51 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 9 Aug 2017 20:34:51 -0400    

Click here for diff

  
Various bugs can cause crashes, so don't use that function before ICU  
53.  It will fall back to the code path used for other encodings.  
  
Since we now tie the function availability to an ICU version, we don't  
need the configure test anymore.  That also resolves the issue that the  
test result was previously hardcoded for Windows.  
  
researched by Daniel Verite <daniel@manitou-mail.org>, Peter Geoghegan  
<pg@bowt.ie>, Tom Lane <tgl@sss.pgh.pa.us>  
  
Discussion: https://www.postgresql.org/message-id/flat/f1438ec6-22aa-4029-9a3b-26f79d330e72%40manitou-mail.org  
  

Fix order of ICU_CFLAGS

  
commit   : b83e54564ad0733f5382b20c04695ee9fb4cf451    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 9 Aug 2017 20:28:49 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 9 Aug 2017 20:28:49 -0400    

Click here for diff

  
It must be before CPPFLAGS so that an ICU installation in a nonstandard  
path can take precedence over one in the system path.  
  

Improve the error message when creating an empty range partition.

  
commit   : bb5d6e80b1387f0de58e55ac8e882f68ec6d4fcf    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Thu, 10 Aug 2017 13:44:30 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Thu, 10 Aug 2017 13:44:30 -0400    

Click here for diff

  
The previous message didn't mention the name of the table or the  
bounds.  Put the table name in the primary error message and the  
bounds in the detail message.  
  
Amit Langote, changed slightly by me.  Suggestions on the exac  
phrasing from Tom Lane, David G. Johnston, and Dean Rasheed.  
  
Discussion: http://postgr.es/m/CA+Tgmoae6bpwVa-1BMaVcwvCCeOoJ5B9Q9-RHWo-1gJxfPBZ5Q@mail.gmail.com  
  

Make some more improvements to parallel query documentation.

  
commit   : c1ef4e5cdb11cd562891f4ad2f30d1e3583a973d    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Thu, 10 Aug 2017 13:22:31 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Thu, 10 Aug 2017 13:22:31 -0400    

Click here for diff

  
Many places that mentioned only Gather should also mention Gather  
Merge, or should be phrased in a more neutral way.  Be more clear  
about the fact that max_parallel_workers_per_gather affects the number  
of workers the planner may want to use.  Fix a typo.  Explain how  
Gather Merge works.  Adjust wording around parallel scans to be a bit  
more clear.  Adjust wording around parallel-restricted operations for  
the fact that uncorrelated subplans are no longer restricted.  
  
Patch by me, reviewed by Erik Rijkers  
  
Discussion: http://postgr.es/m/CA+TgmoZsTjgVGn=ei5ht-1qGFKy_m1VgB3d8+Rg304hz91N5ww@mail.gmail.com  
  

Fix typo in comment.

  
commit   : e694010758772da1ac0f3355027fad0e47da4465    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Thu, 10 Aug 2017 13:14:47 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Thu, 10 Aug 2017 13:14:47 -0400    

Click here for diff

  
Etsuro Fujita  
  
Discussion: http://postgr.es/m/5f794b91-67df-1ac6-8a4f-069f8e8e169d@lab.ntt.co.jp  
  

pgstatindex: Insert some casts to prevent overflow.

  
commit   : 0b7ba3d6474b8f58e74dba548886df3250805cdf    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Thu, 10 Aug 2017 11:48:42 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Thu, 10 Aug 2017 11:48:42 -0400    

Click here for diff

  
This could cause hash indexes to report greater than 100% free space.  
  
Ashutosh Sharma, reviewed by Amit Kapila  
  
Discussion: http://postgr.es/m/CAE9k0PnCKfg-ZK1CwGZJPF1yKcG2A=GUgC3BMdNMzLAXVOo4Eg@mail.gmail.com  
  

Remove incorrect assertion in clog.c

  
commit   : ec99dd5aee8b831760046d43098c2d1cf23157ed    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Thu, 10 Aug 2017 11:20:57 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Thu, 10 Aug 2017 11:20:57 -0400    

Click here for diff

  
We must advance the oldest XID that can be safely looked up in clog  
*before* truncating CLOG, and the oldest XID that can't be reused  
*after* truncating CLOG.  This assertion, and the accompanying  
comment, are confused; remove them.  
  
Reported by Neha Sharma.  
  
Discussion: http://postgr.es/m/CANiYTQumC3T=UMBMd1Hor=5XWZYuCEQBioL3ug0YtNQCMMT5wQ@mail.gmail.com  
  

Fix handling of container types in find_composite_type_dependencies.

  
commit   : 749c7c41701c62d96a56af1531e4f51e39173be3    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 9 Aug 2017 17:03:09 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 9 Aug 2017 17:03:09 -0400    

Click here for diff

  
find_composite_type_dependencies correctly found columns that are of  
the specified type, and columns that are of arrays of that type, but  
not columns that are domains or ranges over the given type, its array  
type, etc.  The most general way to handle this seems to be to assume  
that any type that is directly dependent on the specified type can be  
treated as a container type, and processed recursively (allowing us  
to handle nested cases such as ranges over domains over arrays ...).  
Since a type's array type already has such a dependency, we can drop  
the existing special case for the array type.  
  
The very similar logic in get_rels_with_domain was likewise a few  
bricks shy of a load, as it supposed that a directly dependent type  
could *only* be a sub-domain.  This is already wrong for ranges over  
domains, and it'll someday be wrong for arrays over domains.  
  
Add test cases illustrating the problems, and back-patch to all  
supported branches.  
  
Discussion: https://postgr.es/m/15268.1502309024@sss.pgh.pa.us  
  

Prevent passing down MAKELEVEL/MAKEFLAGS from non-GNU make to GNU make.

  
commit   : a76200de8462aa0551dde8132c11d648d0ad6e99    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 9 Aug 2017 12:05:53 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 9 Aug 2017 12:05:53 -0400    

Click here for diff

  
FreeBSD's make, for one, sets the MAKELEVEL environment variable when  
invoking commands.  In the special Makefile we provide to hand off control  
from a non-GNU make to GNU make, this causes GNU make to think it is a  
child make invocation rather than top-level.  That interferes with the hack  
added in commit dcae5facc to cause the temp-install tree to be made only by  
the top-level invocation of gmake.  Unset the variable to prevent that.  
  
Likewise unset MAKEFLAGS, which FreeBSD's make also sets, and which could  
easily confuse gmake.  There are no reports of actual trouble from that,  
but it seems better to be proactive.  
  
Back-patch to 9.5 where dcae5facc came in.  
  
Thomas Munro, hacked a bit more by me  
  
Discussion: https://postgr.es/m/CAEepm=1ueww35AXTkt1A3gyzZUqv5XCzh8RUNvJZAQAW=eOhVw@mail.gmail.com  
  

doc: Add missing pieces to logical replication protocol doc

  
commit   : 13f03a001e4d841b6a27c0c9c3fe14e1fb2aad80    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 8 Aug 2017 19:18:16 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 8 Aug 2017 19:18:16 -0400    

Click here for diff

  
Reported-by: Kyle Conroy <kyle@kyleconroy.com>  
  

Fix datumSerialize infrastructure to not crash on non-varlena data.

  
commit   : 9bf4068cc321a4d44ac54089ab651a49d89bb567    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 8 Aug 2017 19:18:11 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 8 Aug 2017 19:18:11 -0400    

Click here for diff

  
Commit 1efc7e538 did a poor job of emulating existing logic for touching  
Datums that might be expanded-object pointers.  It didn't check for typlen  
being -1 first, which meant it could crash on fixed-length pass-by-ref  
values, and probably on cstring values as well.  It also didn't use  
DatumGetPointer before VARATT_IS_EXTERNAL_EXPANDED, which while currently  
harmless is not according to documentation nor prevailing style.  
  
I also think the lack of any explanation as to why datumSerialize makes  
these particular nonobvious choices is pretty awful, so fix that.  
  
Per report from Jarred Ward.  Back-patch to 9.6 where this code came in.  
  
Discussion: https://postgr.es/m/6F61E6D2-2F5E-4794-9479-A429BE1CEA4B@simple.com  
  

Reword some unclear comments

  
commit   : 77d2c00af78ee12ae0d1cea34605f1e7af3f6d93    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 8 Aug 2017 18:46:16 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 8 Aug 2017 18:46:16 -0400    

Click here for diff

  
  

Fix typo in comment

  
commit   : f5d54ef97abdd1df3d6bfe0320a565ecce742abe    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 8 Aug 2017 18:31:39 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 8 Aug 2017 18:31:39 -0400    

Click here for diff

  
  

Fix yet another race condition in recovery/t/001_stream_rep.pl.

  
commit   : 4576a69354fa2efc1bafa50df1c104c1a80c64e5    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 8 Aug 2017 18:03:30 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 8 Aug 2017 18:03:30 -0400    

Click here for diff

  
In commit 5c77690f6, we added polling in front of most of the  
get_slot_xmins calls in 001_stream_rep.pl, but today's results from  
buildfarm member nightjar show that at least one more poll loop  
is needed.  
  
Proactively add a poll loop before the next-to-last get_slot_xmins call  
as well.  It may be that there is no race condition there because the  
standby_2 server is shut down at that point, but I'm quite tired of  
fighting with this test script.  The empirical evidence that it's safe,  
from the buildfarm, is no stronger than the evidence for the other  
call that nightjar just proved unsafe.  
  
The only remaining get_slot_xmins calls without wait_slot_xmins  
protection are the first two, which should be OK since nothing has  
happened at that point.  It's tempting to ignore that special case  
and merge get_slot_xmins and wait_slot_xmins into a single function.  
I didn't go that far though.  
  
Discussion: https://postgr.es/m/18436.1502228036@sss.pgh.pa.us  
  

  
commit   : b2c95a3798ff39fc24d71b6655ddfe0e4cb3f378    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 8 Aug 2017 16:07:46 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 8 Aug 2017 16:07:46 -0400    

Click here for diff

  
Similar to what was fixed in commit 9915de6c1cb2 for replication slots,  
but this time it's related to replication origins: DROP SUBSCRIPTION  
attempts to drop the replication origin, but that fails if the  
replication worker process hasn't yet marked it unused.  This causes  
failures in the buildfarm:  
ERROR:  could not drop replication origin with OID 1, in use by PID 34069  
  
Like the aforementioned commit, fix by having the process running DROP  
SUBSCRIPTION sleep until the worker marks the the replication origin  
struct as free.  This uses a condition variable on each replication  
origin shmem state struct, so that the session trying to drop can sleep  
and expect to be awakened by the process keeping the origin open.  
  
Also fix a SGML markup in the previous commit.  
  
Discussion: https://postgr.es/m/20170808001433.rozlseaf4m2wkw3n@alvherre.pgsql  
  

Fix inadequacies in recently added wait events

  
commit   : 030273b7ea468ed4b3073dfd1f2ad88e3129df6a    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 8 Aug 2017 15:37:44 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 8 Aug 2017 15:37:44 -0400    

Click here for diff

  
In commit 9915de6c1cb2, we introduced a new wait point for replication  
slots and incorrectly labelled it as wait event PG_WAIT_LOCK.  That's  
wrong, so invent an appropriate new wait event instead, and document it  
properly.  
  
While at it, fix numerous other problems in the vicinity:  
- two different walreceiver wait events were being mixed up in a single  
  wait event (which wasn't documented either); split it out so that they  
  can be distinguished, and document the new events properly.  
  
- ParallelBitmapPopulate was documented but didn't exist.  
  
- ParallelBitmapScan was not documented (I think this should be called  
  "ParallelBitmapScanInit" instead.)  
  
- Logical replication wait events weren't documented  
  
- various symbols had been added in dartboard order in various places.  
  Put them in alphabetical order instead, as was originally intended.  
  
Discussion: https://postgr.es/m/20170808181131.mu4fjepuh5m75cyq@alvherre.pgsql  
  

Disclaim xmltable() support for non-UTF8 databases.

  
commit   : b4a2eea030ba74ea84335c7d5bc999f693ffd9a4    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Mon, 7 Aug 2017 17:16:21 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 7 Aug 2017 17:16:21 -0700    

Click here for diff

  
The xmltable() implementation mirrors xpath(), including its lack of  
character encoding awareness.  
  

Stamp 10beta3.

  
commit   : 8d6442377df5451a8db598788847e6a70b3b49ef    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 7 Aug 2017 17:08:19 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 7 Aug 2017 17:08:19 -0400    

Click here for diff

  
  

Skip test for IPC::Run if user is overriding our search for PROVE.

  
commit   : 8014d2afa7b817c98544cace7efc337ee891aa57    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 7 Aug 2017 16:42:18 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 7 Aug 2017 16:42:18 -0400    

Click here for diff

  
The check for IPC::Run we added in commit c254970ad is useful in simple  
cases, but there are real use-cases where "prove" is coming from a  
different Perl installation than the "perl" we want to use to build.  
In such cases asking whether "perl" knows about IPC::Run is irrelevant  
and can cause an unnecessary configure failure.  Hence, if user has  
specified a value for PROVE, skip the IPC::Run check.  Per discussion  
with Andrew Dunstan.  
  
Discussion: https://postgr.es/m/E1dcE5n-0005Sk-UE@gemulon.postgresql.org  
  

Update SQL features list

  
commit   : cdc47d1f3942451952e2d8409069a5d1fa741fa8    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 7 Aug 2017 14:30:24 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 7 Aug 2017 14:30:24 -0400    

Click here for diff

  
  

Translation updates

  
commit   : f7668b2b3532b627ec951e1f0a28944f30cc4a1b    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 7 Aug 2017 13:55:34 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 7 Aug 2017 13:55:34 -0400    

Click here for diff

  
Source-Git-URL: git://git.postgresql.org/git/pgtranslation/messages.git  
Source-Git-Hash: 1a0b5e655d7871506c2b1c7ba562c2de6b6a55de  
  

Last-minute updates for release notes.

  
commit   : a8b37ebe407f1916c5df22452cdbb1d00e2a409d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 7 Aug 2017 11:46:20 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 7 Aug 2017 11:46:20 -0400    

Click here for diff

  
Security: CVE-2017-7546, CVE-2017-7547, CVE-2017-7548  
  

Fix local/remote attribute mix-up in logical replication

  
commit   : fca17a933b4b3cedcd41f14b0fe4d3fb439ea4a4    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 7 Aug 2017 10:49:08 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 7 Aug 2017 10:49:08 -0400    

Click here for diff

  
This would lead to failures if local and remote tables have a different  
column order.  The tests previously didn't catch that because they only  
tested the initial data copy.  So add another test that exercises the  
apply worker.  
  
Author: Petr Jelinek <petr.jelinek@2ndquadrant.com>  
  

Fix handling of dropped columns in logical replication

  
commit   : 0e58455dd48ca9cbc9987c47b8297d10f1c307b0    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 7 Aug 2017 10:28:35 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 7 Aug 2017 10:28:35 -0400    

Click here for diff

  
The relation attribute map was not initialized for dropped columns,  
leading to errors later on.  
  
Author: Petr Jelinek <petr.jelinek@2ndquadrant.com>  
Reported-by: Scott Milliken <scott@deltaex.com>  
Bug: #14769  
  

Require update permission for the large object written by lo_put().

  
commit   : 8d9881911f0d30e0783a6bb1363b94a2c817433d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 7 Aug 2017 10:19:01 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 7 Aug 2017 10:19:01 -0400    

Click here for diff

  
lo_put() surely should require UPDATE permission, the same as lowrite(),  
but it failed to check for that, as reported by Chapman Flack.  Oversight  
in commit c50b7c09d; backpatch to 9.4 where that was introduced.  
  
Tom Lane and Michael Paquier  
  
Security: CVE-2017-7548  
  

Again match pg_user_mappings to information_schema.user_mapping_options.

  
commit   : e568e1eee4650227170cf8c64eedb74bafd7d1f0    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Mon, 7 Aug 2017 07:09:28 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 7 Aug 2017 07:09:28 -0700    

Click here for diff

  
Commit 3eefc51053f250837c3115c12f8119d16881a2d7 claimed to make  
pg_user_mappings enforce the qualifications user_mapping_options had  
been enforcing, but its removal of a longstanding restriction left them  
distinct when the current user is the subject of a mapping yet has no  
server privileges.  user_mapping_options emits no rows for such a  
mapping, but pg_user_mappings includes full umoptions.  Change  
pg_user_mappings to show null for umoptions.  Back-patch to 9.2, like  
the above commit.  
  
Reviewed by Tom Lane.  Reported by Jeff Janes.  
  
Security: CVE-2017-7547  
  

Don’t allow logging in with empty password.

  
commit   : bf6b9e94445610a3d84cf9521032fab993f96fd6    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 7 Aug 2017 17:03:42 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 7 Aug 2017 17:03:42 +0300    

Click here for diff

  
Some authentication methods allowed it, others did not. In the client-side,  
libpq does not even try to authenticate with an empty password, which makes  
using empty passwords hazardous: an administrator might think that an  
account with an empty password cannot be used to log in, because psql  
doesn't allow it, and not realize that a different client would in fact  
allow it. To clear that confusion and to be be consistent, disallow empty  
passwords in all authentication methods.  
  
All the authentication methods that used plaintext authentication over the  
wire, except for BSD authentication, already checked that the password  
received from the user was not empty. To avoid forgetting it in the future  
again, move the check to the recv_password_packet function. That only  
forbids using an empty password with plaintext authentication, however.  
MD5 and SCRAM need a different fix:  
  
* In stable branches, check that the MD5 hash stored for the user does not  
not correspond to an empty string. This adds some overhead to MD5  
authentication, because the server needs to compute an extra MD5 hash, but  
it is not noticeable in practice.  
  
* In HEAD, modify CREATE and ALTER ROLE to clear the password if an empty  
string, or a password hash that corresponds to an empty string, is  
specified. The user-visible behavior is the same as in the stable branches,  
the user cannot log in, but it seems better to stop the empty password from  
entering the system in the first place. Secondly, it is fairly expensive to  
check that a SCRAM hash doesn't correspond to an empty string, because  
computing a SCRAM hash is much more expensive than an MD5 hash by design,  
so better avoid doing that on every authentication.  
  
We could clear the password on CREATE/ALTER ROLE also in stable branches,  
but we would still need to check at authentication time, because even if we  
prevent empty passwords from being stored in pg_authid, there might be  
existing ones there already.  
  
Reported by Jeroen van der Ham, Ben de Graaff and Jelte Fennema.  
  
Security: CVE-2017-7546  
  

Fix function name in code comment

  
commit   : 86524f038799db9e18c86df0ea6fb40c8102c0ab    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 7 Aug 2017 09:49:55 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 7 Aug 2017 09:49:55 -0400    

Click here for diff

  
Reported-by: Peter Geoghegan <pg@bowt.ie>  
  

Improve wording of subscription refresh debug messages

  
commit   : ad2ca3cba6e14dbd7b9f388b1e101cd5e2a2c210    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 7 Aug 2017 09:40:12 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 7 Aug 2017 09:40:12 -0400    

Click here for diff

  
Reported-by: Yugo Nagata <nagata@sraoss.co.jp>  
  

Downgrade subscription refresh messages to DEBUG1

  
commit   : 6f81306e4d1716bdf19aa8629b4004966918c56e    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 7 Aug 2017 09:16:03 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 7 Aug 2017 09:16:03 -0400    

Click here for diff

  
The NOTICE messages about tables being added or removed during  
subscription refresh would be incorrect and possibly confusing if the  
transaction rolls back, so silence them but keep them available for  
debugging.  
  
Discussion: https://www.postgresql.org/message-id/CAD21AoAvaXizc2h7aiNyK_i0FQSa-tmhpdOGwbhh7Jy544Ad4Q%40mail.gmail.com  
  

Update RELEASE_CHANGES’ example of branch name format.

  
commit   : 655727d93bbaf2569281eea07e38b1955bb627b7    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 6 Aug 2017 23:26:09 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 6 Aug 2017 23:26:09 -0400    

Click here for diff

  
We're planning to put an underscore before the major version number in  
branch names for v10 and later.  Make sure the recipe in RELEASE_CHANGES  
reflects that.  
  
In passing, add a reminder to consider doing pgindent right before  
the branch.  
  
Discussion: https://postgr.es/m/E1dAkjZ-0003MG-0U@gemulon.postgresql.org  
  

Release notes for 9.6.4, 9.5.8, 9.4.13, 9.3.18, 9.2.22.

  
commit   : b35006ecccf505d05fd77ce0c820943996ad7ee9    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 6 Aug 2017 17:56:49 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 6 Aug 2017 17:56:49 -0400    

Click here for diff

  
  

Fix thinko introduced in 2bef06d516460 et al.

  
commit   : 5af4456a56472e1928e838c893eb0022f7ab28fb    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Sat, 5 Aug 2017 20:52:53 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Sat, 5 Aug 2017 20:52:53 -0700    

Click here for diff

  
The callers for GetOldestSafeDecodingTransactionId() all inverted the  
argument for the argument introduced in 2bef06d516460. Luckily this  
appears to be inconsequential for the moment, as we wait for  
concurrent in-progress transaction when assembling a  
snapshot. Additionally this could only make a difference when adding a  
second logical slot, because only a pre-existing slot could cause an  
issue by lowering the returned xid dangerously much.  
  
Reported-By: Antonin Houska  
Discussion: https://postgr.es/m/32704.1496993134@localhost  
Backport: 9.4-, where 2bef06d516460 was backpatched to.  
  

Add regression test for wide REPLICA IDENTITY FULL updates.

  
commit   : 0d1f98b80e094827199da8a3dea51f04d134b7bf    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Sat, 5 Aug 2017 14:41:40 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Sat, 5 Aug 2017 14:41:40 -0700    

Click here for diff

  
This just contains the regression tests added by a fix for a 9.4  
specific bug regarding $subject.  
  
Author: Andres Freund  
Backpatch: 9.5-  
  

Doc: update v10 release notes through today.

  
commit   : dd2358a704fc27c3f20b252e1354740086a7b6f3    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 5 Aug 2017 15:55:23 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 5 Aug 2017 15:55:23 -0400    

Click here for diff

  
  

Suppress unused-variable warnings when building with ICU 4.2.

  
commit   : e9f4ac1389d9fe6b996937e5d308f5ec462cf69a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 5 Aug 2017 11:48:32 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 5 Aug 2017 11:48:32 -0400    

Click here for diff

  
Tidy-up for commit eccead9ed.  
  

Improve configure’s check for ICU presence.

  
commit   : f4f41baf29c6835dca58e3aa22c56e9e7c7754de    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 5 Aug 2017 11:47:28 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 5 Aug 2017 11:47:28 -0400    

Click here for diff

  
Without ICU's header files, "configure --with-icu" would succeed anyway,  
at least when using the non-pkgconfig-based setup.  Then you got a bunch of  
ugly failures at build.  Add an explicit header check to tighten that up.  
  

Make pg_stop_backup’s wait_for_archive flag work on standbys.

  
commit   : 52f8a59dd953c6820baf153e97cf07d31b8ac1d6    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Sat, 5 Aug 2017 10:49:26 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Sat, 5 Aug 2017 10:49:26 -0400    

Click here for diff

  
Previously, it had no effect.  Now, if archive_mode=always, it will  
work, and if not, you'll get a warning.  
  
Masahiko Sawada, Michael Paquier, and Robert Haas.  The patch as  
submitted also changed the behavior so that we would write and remove  
history files on standbys, but that seems like material for a separate  
patch to me.  
  
Discussion: http://postgr.es/m/CAD21AoC2Xw6M=ZJyejq_9d_iDkReC_=rpvQRw5QsyzKQdfYpkw@mail.gmail.com  
  

Add support for ICU 4.2

  
commit   : eccead9ed43dc6e653c76dce1d2f455d251bb00c    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 1 Aug 2017 10:49:55 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 1 Aug 2017 10:49:55 -0400    

Click here for diff

  
Supporting ICU 4.2 seems useful because it ships with CentOS 6.  
  
Versions before ICU 4.6 don't support pkg-config, so document an  
installation method without using pkg-config.  
  
In ICU 4.2, ucol_getKeywordsForLocale() sometimes returns values that  
will not be accepted by uloc_toLanguageTag().  Skip loading keyword  
variants in that version.  
  
Reported-by: Victor Wagner <vitus@wagner.pp.ru>  
  

Fix bug in deciding whether to scan newly-attached partition.

  
commit   : f85f88bcc270cf12defc34f143456834d8d8c6f8    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 4 Aug 2017 21:54:28 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 4 Aug 2017 21:54:28 -0400    

Click here for diff

  
If the table being attached had different attribute numbers than the  
parent, the old code could incorrectly decide it needed to be scanned.  
  
Amit Langote, reviewed by Ashutosh Bapat  
  
Discussion: http://postgr.es/m/CA+TgmobexgbBr2+Utw-pOMw9uxaBRKRjMW_-mmzKKx9PejPLMg@mail.gmail.com  
  

Only kill sync workers at commit time in subscription DDL

  
commit   : 7e174fa793a2df89fe03d002a5087ef67abcdde8    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 4 Aug 2017 21:14:35 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 4 Aug 2017 21:14:35 -0400    

Click here for diff

  
This allows a transaction abort to avoid killing those workers.  
  
Author: Petr Jelinek <petr.jelinek@2ndquadrant.com>  
  

hash: Immediately after a bucket split, try to clean the old bucket.

  
commit   : ff98a5e1e49de061600feb6b4de5ce0a22d386af    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 4 Aug 2017 19:33:01 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 4 Aug 2017 19:33:01 -0400    

Click here for diff

  
If it works, then we won't be storing two copies of all the tuples  
that were just moved.  If not, VACUUM will still take care of it  
eventually.  Per a report from AP and analysis from Amit Kapila, it  
seems that a bulk load can cause splits fast enough that VACUUM won't  
deal with the problem in time to prevent bloat.  
  
Amit Kapila; I rewrote the comment.  
  
Discussion: http://postgr.es/m/20170704105728.mwb72jebfmok2nm2@zip.com.au  
  

First-draft release notes for 9.6.4.

  
commit   : 03378c4da598840b0520a53580dd7713c95f21c8    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 4 Aug 2017 18:37:18 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 4 Aug 2017 18:37:18 -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.  
  

Message style improvements

  
commit   : 26d40ada3fa5d2671a16c34b2283448832630c86    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 4 Aug 2017 18:31:01 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 4 Aug 2017 18:31:01 -0400    

Click here for diff

  
  

hash: Increase the number of possible overflow bitmaps by 8x.

  
commit   : 620b49a16d2a16ce6f9edf072a88111f981919d0    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 4 Aug 2017 15:29:26 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 4 Aug 2017 15:29:26 -0400    

Click here for diff

  
Per a report from AP, it's not that hard to exhaust the supply of  
bitmap pages if you create a table with a hash index and then insert a  
few billion rows - and then you start getting errors when you try to  
insert additional rows.  In the particular case reported by AP,  
there's another fix that we can make to improve recycling of overflow  
pages, which is another way to avoid the error, but there may be other  
cases where this problem happens and that fix won't help.  So let's  
buy ourselves as much headroom as we can without rearchitecting  
anything.  
  
The comments claim that the old limit was 64GB, but it was really  
only 32GB, because we didn't use all the bits in the page for bitmap  
bits - only the largest power of 2 that could fit after deducting  
space for the page header and so forth.  Thus, we have 4kB per page  
for bitmap bits, not 8kB.  The new limit is thus actually 8 times the  
old *real* limit but only 4 times the old *purported* limit.  
  
Since this breaks on-disk compatibility, bump HASH_VERSION.  We've  
already done this earlier in this release cycle, so this doesn't cause  
any incremental inconvenience for people using pg_upgrade from  
releases prior to v10.  However, users who use pg_upgrade to reach  
10beta3 or later from 10beta2 or earlier will need to REINDEX any hash  
indexes again.  
  
Amit Kapila and Robert Haas  
  
Discussion: http://postgr.es/m/20170704105728.mwb72jebfmok2nm2@zip.com.au  
  

Apply ALTER … SET NOT NULL recursively in ALTER … ADD PRIMARY KEY.

  
commit   : c30f1770a93db1492755934048656ea809c1f569    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 4 Aug 2017 11:45:18 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 4 Aug 2017 11:45:18 -0400    

Click here for diff

  
If you do ALTER COLUMN SET NOT NULL against an inheritance parent table,  
it will recurse to mark all the child columns as NOT NULL as well.  This  
is necessary for consistency: if the column is labeled NOT NULL then  
reading it should never produce nulls.  
  
However, that didn't happen in the case where ALTER ... ADD PRIMARY KEY  
marks a target column NOT NULL that wasn't before.  That was questionable  
from the beginning, and now Tushar Ahuja points out that it can lead to  
dump/restore failures in some cases.  So let's make that case recurse too.  
  
Although this is meant to fix a bug, it's enough of a behavioral change  
that I'm pretty hesitant to back-patch, especially in view of the lack  
of similar field complaints.  It doesn't seem to be too late to put it  
into v10 though.  
  
Michael Paquier, editorialized on slightly by me  
  
Discussion: https://postgr.es/m/b8794d6a-38f0-9d7c-ad4b-e85adf860fc9@enterprisedb.com  
  

Disallow SSL session tickets.

  
commit   : 97d3a0b0900a30fc51823c2d806ab621299f1b07    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 4 Aug 2017 11:07:10 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 4 Aug 2017 11:07:10 -0400    

Click here for diff

  
We don't actually support session tickets, since we do not create an SSL  
session identifier.  But it seems that OpenSSL will issue a session ticket  
on-demand anyway, which will then fail when used.  This results in  
reconnection failures when using ticket-aware client-side SSL libraries  
(such as the Npgsql .NET driver), as reported by Shay Rojansky.  
  
To fix, just tell OpenSSL not to issue tickets.  At some point in the  
far future, we might consider enabling tickets instead.  But the security  
implications of that aren't entirely clear; and besides it would have  
little benefit except for very short-lived database connections, which is  
Something We're Bad At anyhow.  It would take a lot of other work to get  
to a point where that would really be an exciting thing to do.  
  
While at it, also tell OpenSSL not to use a session cache.  This doesn't  
really do anything, since a backend would never populate the cache anyway,  
but it might gain some micro-efficiencies and/or reduce security  
exposures.  
  
Patch by me, per discussion with Heikki Linnakangas and Shay Rojansky.  
Back-patch to all supported versions.  
  
Discussion: https://postgr.es/m/CADT4RqBU8N-csyZuzaook-c795dt22Zcwg1aHWB6tfVdAkodZA@mail.gmail.com  
  

Further unify ROLE and USER command grammar rules

  
commit   : b3744812215de458c80629c3a9c57f00833de8a9    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 31 Jul 2017 20:36:32 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 31 Jul 2017 20:36:32 -0400    

Click here for diff

  
ALTER USER ... SET did not support all the syntax variants of ALTER ROLE  
...  SET.  Fix that, and to avoid further deviations of this kind, unify  
many the grammar rules for ROLE/USER/GROUP commands.  
  
Reported-by: Pavel Golub <pavel@microolap.com>  
  

Fix pg_dump/pg_restore to emit REFRESH MATERIALIZED VIEW commands last.

  
commit   : 3eb9a5e7c4c9f10178815b569dbc0058eb50c05a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 3 Aug 2017 17:36:23 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 3 Aug 2017 17:36:23 -0400    

Click here for diff

  
Because we push all ACL (i.e. GRANT/REVOKE) restore steps to the end,  
materialized view refreshes were occurring while the permissions on  
referenced objects were still at defaults.  This led to failures if,  
say, an MV owned by user A reads from a table owned by user B, even  
if B had granted the necessary privileges to A.  We've had multiple  
complaints about that type of restore failure, most recently from  
Jordan Gigov.  
  
The ideal fix for this would be to start treating ACLs as dependency-  
sortable objects, rather than hard-wiring anything about their dump order  
(the existing approach is a messy kluge dating to commit dc0e76ca3).  
But that's going to be a rather major change, and it certainly wouldn't  
lead to a back-patchable fix.  As a short-term solution, convert the  
existing two-pass hack (ie, normal objects then ACLs) to a three-pass hack,  
ie, normal objects then ACLs then matview refreshes.  Because this happens  
in RestoreArchive(), it will also fix the problem when restoring from an  
existing archive-format dump.  
  
(Note this means that if a matview refresh would have failed under the  
permissions prevailing at dump time, it'll fail during restore as well.  
We'll define that as user error rather than something we should try  
to work around.)  
  
To avoid performance loss in parallel restore, we need the matview  
refreshes to still be parallelizable.  Hence, clean things up enough  
so that both ACLs and matviews are handled by the parallel restore  
infrastructure, instead of reverting back to serial restore for ACLs.  
There is still a final serial step, but it shouldn't normally have to  
do anything; it's only there to try to recover if we get stuck due to  
some problem like unresolved circular dependencies.  
  
Patch by me, but it owes something to an earlier attempt by Kevin Grittner.  
Back-patch to 9.3 where materialized views were introduced.  
  
Discussion: https://postgr.es/m/28572.1500912583@sss.pgh.pa.us  
  

Fix build on zlib-less environments

  
commit   : 9a3b5d3ad0f1c19c47e2ee65b372344cb0616c9a    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 3 Aug 2017 14:48:54 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 3 Aug 2017 14:48:54 -0400    

Click here for diff

  
Commit 4d57e8381677 added support for getting I/O errors out of zlib,  
but it introduced a portability problem for systems without zlib.  
Repair by wrapping the zlib call inside #ifdef and restore the original  
code in the other branch.  
  
This serves to illustrate the inadequacy of the zlib abstraction in  
pg_backup_archiver: there is no way to call gzerror() in that  
abstraction.  This means that the several places that call GZREAD and  
GZWRITE are currently doing error reporting wrongly, but ENOTIME to get  
it fixed before next week's release set.  
  
Backpatch to 9.4, like the commit that introduced the problem.  
  

Fix lock upgrade hazard in ATExecAttachPartition.

  
commit   : 972b6ec20bf090a18145624f8092d2cb1715ab83    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Thu, 3 Aug 2017 14:21:00 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Thu, 3 Aug 2017 14:21:00 -0400    

Click here for diff

  
Amit Langote  
  
Discussion: http://postgr.es/m/CAFjFpReT_kq_uwU_B8aWDxR7jNGE=P0iELycdq5oupi=xSQTOw@mail.gmail.com  
  

Code beautification for ATExecAttachPartition.

  
commit   : 583df3b5c56258df2a03e08e3ef00aabe0cf306d    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Thu, 3 Aug 2017 14:16:33 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Thu, 3 Aug 2017 14:16:33 -0400    

Click here for diff

  
Amit Langote  
  
Discussion: http://postgr.es/m/CAFjFpReT_kq_uwU_B8aWDxR7jNGE=P0iELycdq5oupi=xSQTOw@mail.gmail.com  
  

Allow a foreign table CHECK constraint to be initially NOT VALID.

  
commit   : 86705aa8c3f3ec78c0b8e66cd8a4b0768e51adeb    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Thu, 3 Aug 2017 13:09:15 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Thu, 3 Aug 2017 13:09:15 -0400    

Click here for diff

  
For a table, the constraint can be considered validated immediately,  
because the table must be empty.  But for a foreign table this is  
not necessarily the case.  
  
Fixes a bug in commit f27a6b15e6566fba7748d0d9a3fc5bcfd52c4a1b.  
  
Amit Langote, with some changes by me.  
  
Discussion: http://postgr.es/m/d2b7419f-4a71-cf86-cc99-bfd0f359a1ea@lab.ntt.co.jp  
  

Improve ExecModifyTable comments.

  
commit   : 12a34f59bf8bc5babf375c95f5192d208dca1739    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Thu, 3 Aug 2017 12:47:00 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Thu, 3 Aug 2017 12:47:00 -0400    

Click here for diff

  
Some of these comments wrongly implied that only an AFTER ROW trigger  
will cause a 'wholerow' attribute to be present for a foreign table,  
but a BEFORE ROW trigger can have the same effect.  Others implied  
that it would always be present for a foreign table, but that's not  
true either.  
  
Etsuro Fujita and Robert Haas  
  
Discussion: http://postgr.es/m/10026bc7-1403-ef85-9e43-c6100c1cc0e3@lab.ntt.co.jp  
  

Teach map_partition_varattnos to handle whole-row expressions.

  
commit   : 610e8ebb0fadd7a738c2ad07fef6c5ea86b11f8d    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Thu, 3 Aug 2017 11:21:29 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Thu, 3 Aug 2017 11:21:29 -0400    

Click here for diff

  
Otherwise, partitioned tables with RETURNING expressions or subject  
to a WITH CHECK OPTION do not work properly.  
  
Amit Langote, reviewed by Amit Khandekar and Etsuro Fujita.  A few  
comment changes by me.  
  
Discussion: http://postgr.es/m/9a39df80-871e-6212-0684-f93c83be4097@lab.ntt.co.jp  
  

Add new files to nls.mk and add translation markers

  
commit   : 5ff3d73813ebcc3ff80be77c30b458d728951036    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 2 Aug 2017 22:44:46 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 2 Aug 2017 22:44:46 -0400    

Click here for diff

  
  

Fix pg_dump’s errno checking for zlib I/O

  
commit   : 4d57e83816778c6f61ea35c697f937a6f9c3c3de    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 2 Aug 2017 18:26:26 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 2 Aug 2017 18:26:26 -0400    

Click here for diff

  
Some error reports were reporting strerror(errno), which for some error  
conditions coming from zlib are wrong, resulting in confusing reports  
such as  
  pg_restore: [compress_io] could not read from input file: Success  
which makes no sense.  To correctly extract the error message we need to  
use gzerror(), so let's do that.  
  
This isn't as comprehensive or as neat as I would like, but at least it  
should improve things in many common cases.  The zlib abstraction in  
compress_io does not seem to be applied consistently enough; we could  
perhaps improve that, but it seems master-only material, not a bug fix  
for back-patching.  
  
This problem goes back all the way, but I decided to apply back to 9.4  
only, because older branches don't contain commit 14ea89366 which this  
change depends on.  
  
Authors: Vladimir Kunschikov, Álvaro Herrera  
Discussion: https://postgr.es/m/1498120508308.9826@infotecs.ru  
  

Add pgtcl back to the list of externally-maintained client interfaces.

  
commit   : 80215156f9a10dfcacfcef15be35ebb0d79300b5    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 2 Aug 2017 16:55:03 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 2 Aug 2017 16:55:03 -0400    

Click here for diff

  
FlightAware is still maintaining this, and indeed is seemingly being  
more active with it than the pgtclng fork is.  List both, for the  
time being anyway.  
  
In the back branches, also back-port commit e20f679f6 and other  
recent updates to the client-interfaces list.  I think these are  
probably of current interest to users of back branches.  I did  
not touch the list of externally maintained PLs in the back  
branches, though.  Those are much more likely to be server version  
sensitive, and I don't know which of these PLs work all the way back.  
  
Discussion: https://postgr.es/m/20170730162612.1449.58796@wrigleys.postgresql.org  
  

Remove broken and useless entry-count printing in HASH_DEBUG code.

  
commit   : 9d4e56699957b261390c50dcda7f947470017484    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 2 Aug 2017 12:16:50 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 2 Aug 2017 12:16:50 -0400    

Click here for diff

  
init_htab(), with #define HASH_DEBUG, prints a bunch of hashtable  
parameters.  It used to also print nentries, but commit 44ca4022f changed  
that to "hash_get_num_entries(hctl)", which is wrong (the parameter should  
be "hashp").  
  
Rather than correct the coding, though, let's just remove that field from  
the printout.  The table must be empty, since we just finished building  
it, so expensively calculating the number of entries is rather pointless.  
Moreover hash_get_num_entries makes assumptions (about not needing locks)  
which we could do without in debugging code.  
  
Noted by Choi Doo-Won in bug #14764.  Back-patch to 9.6 where the  
faulty code was introduced.  
  
Discussion: https://postgr.es/m/20170802032353.8424.12274@wrigleys.postgresql.org  
  

Get a snapshot before COPY in table sync

  
commit   : cf652018332819716b10c9de9ce80c81284d6815    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 2 Aug 2017 10:59:01 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 2 Aug 2017 10:59:01 -0400    

Click here for diff

  
This fixes a crash if the local table has a function index and the  
function makes non-immutable calls.  
  
Reported-by: Scott Milliken <scott@deltaex.com>  
Author: Masahiko Sawada <sawada.mshk@gmail.com>  
  

Remove duplicate setting of SSL_OP_SINGLE_DH_USE option.

  
commit   : f352f91cbf2f662c4f043d3650010b02da0cde1c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 2 Aug 2017 11:28:46 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 2 Aug 2017 11:28:46 -0400    

Click here for diff

  
Commit c0a15e07c moved the setting of OpenSSL's SSL_OP_SINGLE_DH_USE option  
into a new subroutine initialize_dh(), but forgot to remove it from where  
it was.  SSL_CTX_set_options() is a trivial function, amounting indeed to  
just "ctx->options |= op", hence there's no reason to contort the code or  
break separation of concerns to avoid calling it twice.  So separating the  
DH setup from disabling of old protocol versions is a good change, but we  
need to finish the job.  
  
Noted while poking into the question of SSL session tickets.  
  

Fix OBJECT_TYPE/OBJECT_DOMAIN confusion

  
commit   : 41cefbb6db58c574e086efef2773a978f108d717    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 2 Aug 2017 10:40:32 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 2 Aug 2017 10:40:32 -0400    

Click here for diff

  
This doesn't have a significant impact except that now SECURITY LABEL ON  
DOMAIN rejects types that are not domains.  
  
Reported-by: 高增琦 <pgf00a@gmail.com>  
  

Revert test case added by commit 1e165d05fe06a9072867607886f818bc255507db.

  
commit   : 32ca22b02da9d8088b58b3dc64ad78464c7513a3    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 1 Aug 2017 20:15:10 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 1 Aug 2017 20:15:10 -0400    

Click here for diff

  
The buildfarm is still showing at least three distinct behaviors for  
a bad locale name in CREATE COLLATION.  Although this test was helpful  
for getting the error reporting code into some usable shape, it doesn't  
seem worth carrying multiple expected-files in order to support the  
test in perpetuity.  So pull it back out.  
  
Discussion: https://postgr.es/m/CAKKotZS-wcDcofXDCH=sidiuajE+nqHn2CGjLLX78anyDmi3gQ@mail.gmail.com  
  

Second try at getting useful errors out of newlocale/_create_locale.

  
commit   : 514f6132935d5bda84a475d4b70fe2bcfe116766    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 1 Aug 2017 17:17:20 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 1 Aug 2017 17:17:20 -0400    

Click here for diff

  
The early buildfarm returns for commit 1e165d05f are pretty awful:  
not only does Windows not return a useful error, but it looks like  
a lot of Unix-ish platforms don't either.  Given the number of  
different errnos seen so far, guess that what's really going on is  
that some newlocale() implementations fail to set errno at all.  
Hence, let's try zeroing errno just before newlocale() and then  
if it's still zero report as though it's ENOENT.  That should cover  
the Windows case too.  
  
It's clear that we'll have to drop the regression test case, unless  
we want to maintain a separate expected-file for platforms without  
HAVE_LOCALE_T.  But I'll leave it there awhile longer to see if this  
actually improves matters or not.  
  
Discussion: https://postgr.es/m/CAKKotZS-wcDcofXDCH=sidiuajE+nqHn2CGjLLX78anyDmi3gQ@mail.gmail.com  
  

Suppress less info in regression tests using DROP CASCADE.

  
commit   : 8e7537261c4b7d296fc10513b93bd67dc3d415b0    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 1 Aug 2017 16:49:23 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 1 Aug 2017 16:49:23 -0400    

Click here for diff

  
DROP CASCADE doesn't currently promise to visit dependent objects in  
a fixed order, so when the regression tests use it, we typically need  
to suppress the details of which objects get dropped in order to have  
predictable test output.  Traditionally we've done that by setting  
client_min_messages higher than NOTICE, but there's a better way:  
we can "\set VERBOSITY terse" in psql.  That suppresses the DETAIL  
message with the object list, but we still get the basic notice telling  
how many objects were dropped.  So at least the test case can verify  
that the expected number of objects were dropped.  
  
The VERBOSITY method was already in use in a few places, but run  
around and use it wherever it makes sense.  
  
Discussion: https://postgr.es/m/10766.1501608885@sss.pgh.pa.us  
  

Try to deliver a sane message for _create_locale() failure on Windows.

  
commit   : 1e165d05fe06a9072867607886f818bc255507db    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 1 Aug 2017 16:11:51 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 1 Aug 2017 16:11:51 -0400    

Click here for diff

  
We were just printing errno, which is certainly not gonna work on  
Windows.  Now, it's not entirely clear from Microsoft's documentation  
whether _create_locale() adheres to standard Windows error reporting  
conventions, but let's assume it does and try to map the GetLastError  
result to an errno.  If this turns out not to work, probably the best  
thing to do will be to assume the error is always ENOENT on Windows.  
  
This is a longstanding bug, but given the lack of previous field  
complaints, I'm not excited about back-patching it.  
  
Per report from Murtuza Zabuawala.  
  
Discussion: https://postgr.es/m/CAKKotZS-wcDcofXDCH=sidiuajE+nqHn2CGjLLX78anyDmi3gQ@mail.gmail.com  
  

doc: Fix typo

  
commit   : c1bb7870463bd8ab2b28b363616ec60a9041e13a    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 1 Aug 2017 14:33:55 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 1 Aug 2017 14:33:55 -0400    

Click here for diff

  
Author: Fabien COELHO <coelho@cri.ensmp.fr>  
  

Allow creation of C/POSIX collations without depending on libc behavior.

  
commit   : f97256570f45c33abf695a189ab11b25e6cd7985    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 1 Aug 2017 13:51:05 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 1 Aug 2017 13:51:05 -0400    

Click here for diff

  
Most of our collations code has special handling for the locale names  
"C" and "POSIX", allowing those collations to be used whether or not  
the system libraries think those locale names are valid, or indeed  
whether said libraries even have any locale support.  But we missed  
handling things that way in CREATE COLLATION.  This meant you couldn't  
clone the C/POSIX collations, nor explicitly define a new collation  
using those locale names, unless the libraries allow it.  That's pretty  
pointless, as well as being a violation of pg_newlocale_from_collation's  
API specification.  
  
The practical effect of this change is quite limited: it allows creating  
such collations even on platforms that don't HAVE_LOCALE_T, and it allows  
making "POSIX" collation objects on Windows, which before this would only  
let you make "C" collation objects.  Hence, even though this is a bug fix  
IMO, it doesn't seem worth the trouble to back-patch.  
  
In passing, suppress the DROP CASCADE detail messages at the end of the  
collation regression test.  I'm surprised we've never been bit by  
message ordering issues there.  
  
Per report from Murtuza Zabuawala.  
  
Discussion: https://postgr.es/m/CAKKotZS-wcDcofXDCH=sidiuajE+nqHn2CGjLLX78anyDmi3gQ@mail.gmail.com  
  

Further improve consistency of configure’s program searching.

  
commit   : b21c569cea58a1396d9ffd8a7e7a84aa991a1123    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 1 Aug 2017 11:40:00 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 1 Aug 2017 11:40:00 -0400    

Click here for diff

  
Peter Eisentraut noted that commit 40b9f1921 had broken a configure  
behavior that some people might rely on: AC_CHECK_PROGS(FOO,...) will  
allow the search to be overridden by specifying a value for FOO on  
configure's command line or in its environment, but AC_PATH_PROGS(FOO,...)  
accepts such an override only if it's an absolute path.  We had worked  
around that behavior for some, but not all, of the pre-existing uses  
of AC_PATH_PROGS by just skipping the macro altogether when FOO is  
already set.  Let's standardize on that workaround for all uses of  
AC_PATH_PROGS, new and pre-existing, by wrapping AC_PATH_PROGS in a  
new macro PGAC_PATH_PROGS.  While at it, fix a deficiency of the old  
workaround code by making sure we report the setting to configure's log.  
  
Eventually I'd like to improve PGAC_PATH_PROGS so that it converts  
non-absolute override inputs to absolute form, eg "PYTHON=python3"  
becomes, say, PYTHON = /usr/bin/python3.  But that will take some  
nontrivial coding so it doesn't seem like a thing to do in late beta.  
  
Discussion: https://postgr.es/m/90a92a7d-938e-507a-3bd7-ecd2b4004689@2ndquadrant.com  
  

Comment fix for partition_rbound_cmp().

  
commit   : 4de6216877a32e869fe1cf168c1fe1ffb8c3d576    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Tue, 1 Aug 2017 09:40:45 +0100    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Tue, 1 Aug 2017 09:40:45 +0100    

Click here for diff

  
This was an oversight in d363d42.  
  
Beena Emerson  
  

Fix comment.

  
commit   : e662ef0f2e95d9da3df705ddaaff36b0c01c7acc    
  
author   : Tatsuo Ishii <ishii@postgresql.org>    
date     : Tue, 1 Aug 2017 08:00:11 +0900    
  
committer: Tatsuo Ishii <ishii@postgresql.org>    
date     : Tue, 1 Aug 2017 08:00:11 +0900    

Click here for diff

  
XLByteToSeg and XLByteToPrevSeg calculate only a segment number.  The  
definition of these macros were modified by commit  
dfda6ebaec6763090fb78b458a979b558c50b39b but the comment remain  
unchanged.  
  
Patch by Yugo Nagata. Back patched to 9.3 and beyond.  
  

Fix typo

  
commit   : 0b02e3f1289e0454d313e6add45f43a287ebaf8b    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 31 Jul 2017 17:22:47 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 31 Jul 2017 17:22:47 -0400    

Click here for diff

  
Author: Masahiko Sawada <sawada.mshk@gmail.com>  
  

Fix typo

  
commit   : f40254a799f7057a415917dacb5ba7eab5b17a99    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 31 Jul 2017 17:08:14 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 31 Jul 2017 17:08:14 -0400    

Click here for diff

  
Author: Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>  
  

Doc: add v10 release notes entries for the DH parameter changes.

  
commit   : 4427b515e6195bd2304e082ea5a5c5d6d36c4eb5    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 31 Jul 2017 22:47:07 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 31 Jul 2017 22:47:07 +0300    

Click here for diff

  
  

Always use 2048 bit DH parameters for OpenSSL ephemeral DH ciphers.

  
commit   : c0a15e07cd718cb6e455e68328f522ac076a0e4b    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 31 Jul 2017 22:36:09 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 31 Jul 2017 22:36:09 +0300    

Click here for diff

  
1024 bits is considered weak these days, but OpenSSL always passes 1024 as  
the key length to the tmp_dh callback. All the code to handle other key  
lengths is, in fact, dead.  
  
To remedy those issues:  
  
* Only include hard-coded 2048-bit parameters.  
* Set the parameters directly with SSL_CTX_set_tmp_dh(), without the  
  callback  
* The name of the file containing the DH parameters is now a GUC. This  
  replaces the old hardcoded "dh1024.pem" filename. (The files for other  
  key lengths, dh512.pem, dh2048.pem, etc. were never actually used.)  
  
This is not a new problem, but it doesn't seem worth the risk and churn to  
backport. If you care enough about the strength of the DH parameters on  
old versions, you can create custom DH parameters, with as many bits as you  
wish, and put them in the "dh1024.pem" file.  
  
Per report by Nicolas Guini and Damian Quiroga. Reviewed by Michael Paquier.  
  
Discussion: https://www.postgresql.org/message-id/CAMxBoUyjOOautVozN6ofzym828aNrDjuCcOTcCquxjwS-L2hGQ@mail.gmail.com  
  

Doc: specify that the minimum supported version of Perl is 5.8.3.

  
commit   : dea6ba939fd2b70dd444349d52585a0694578571    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 31 Jul 2017 13:42:48 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 31 Jul 2017 13:42:48 -0400    

Click here for diff

  
Previously the docs just said "5.8 or later".  Experimentation shows  
that while you can build on Unix from a git checkout with 5.8.0,  
compiling recent PL/Perl requires at least 5.8.1, and you won't be  
able to run the TAP tests with less than 5.8.3 because that's when  
they added "prove".  (I do not have any information on just what the  
MSVC build scripts require.)  
  
Since all these versions are quite ancient, let's not split hairs  
in the docs, but just say that 5.8.3 is the minimum requirement.  
  
Discussion: https://postgr.es/m/16894.1501392088@sss.pgh.pa.us  
  

Record full paths of programs sought by “configure”.

  
commit   : 40b9f192170a300cd9456eb71ba7c792ba9533e1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 31 Jul 2017 13:02:49 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 31 Jul 2017 13:02:49 -0400    

Click here for diff

  
Previously we had a mix of uses of AC_CHECK_PROG[S] and AC_PATH_PROG[S].  
The only difference between those macros is that the latter emits the  
full path to the program it finds, eg "/usr/bin/prove", whereas the  
former emits just "prove".  Let's standardize on always emitting the  
full path; this is better for documentation of the build, and it might  
prevent some types of failures if later build steps are done with  
a different PATH setting.  
  
I did not touch the AC_CHECK_PROG[S] calls in ax_pthread.m4 and  
ax_prog_perl_modules.m4.  There seems no need to make those diverge from  
upstream, since we do not record the programs sought by the former, while  
the latter's call to AC_CHECK_PROG(PERL,...) will never be reached.  
  
Discussion: https://postgr.es/m/25937.1501433410@sss.pgh.pa.us  
  

Tighten coding for non-composite case in plperl’s return_next.

  
commit   : b4cc35fbb709bd6fcae8998f041fd731c9acbf42    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 31 Jul 2017 11:33:46 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 31 Jul 2017 11:33:46 -0400    

Click here for diff

  
Coverity complained about this code's practice of using scalar variables  
as single-element arrays.  While that's really just nitpicking, it probably  
is more readable to declare them as arrays, so let's do that.  A more  
important point is that the code was just blithely assuming that the  
result tupledesc has exactly one column; if it doesn't, we'd likely get  
a crash of some sort in tuplestore_putvalues.  Since the tupledesc is  
manufactured outside of plperl, that seems like an uncomfortably long  
chain of assumptions.  We can nail it down at little cost with a sanity  
check earlier in the function.  
  

Fix function comment for dumpACL()

  
commit   : d2a51e3efcbab5b288bbadba1a7dfa123a50ba5b    
  
author   : Stephen Frost <sfrost@snowman.net>    
date     : Mon, 31 Jul 2017 10:37:08 -0400    
  
committer: Stephen Frost <sfrost@snowman.net>    
date     : Mon, 31 Jul 2017 10:37:08 -0400    

Click here for diff

  
The comment for dumpACL() got neglected when initacls and initracls were  
added and the discussion of what 'racls' is wasn't very clear either.  
  
Per complaint from Tom.  
  

Add missing comment in postgresql.conf.

  
commit   : 393d47ed0f5b764341c7733ef60e8442d3e9bdc2    
  
author   : Tatsuo Ishii <ishii@postgresql.org>    
date     : Mon, 31 Jul 2017 11:24:51 +0900    
  
committer: Tatsuo Ishii <ishii@postgresql.org>    
date     : Mon, 31 Jul 2017 11:24:51 +0900    

Click here for diff

  
current_source requires to restart server to reflect the new  
value. Per Yugo Nagata and Masahiko Sawada.  
  
Back patched to 9.2 and beyond.  
  

Add missing comment in postgresql.conf.

  
commit   : 8b015dd723ffc1ae7123758dda90d0bf0fa9b464    
  
author   : Tatsuo Ishii <ishii@postgresql.org>    
date     : Mon, 31 Jul 2017 11:06:37 +0900    
  
committer: Tatsuo Ishii <ishii@postgresql.org>    
date     : Mon, 31 Jul 2017 11:06:37 +0900    

Click here for diff

  
dynamic_shared_memory_type requires to restart server to reflect  
the new value. Per Yugo Nagata and Masahiko Sawada.  
  
Back pached to 9.4 and beyond.  
  

Add missing comment in postgresql.conf.

  
commit   : 9fe63092b541e48aebb1190179b47249672a8560    
  
author   : Tatsuo Ishii <ishii@postgresql.org>    
date     : Mon, 31 Jul 2017 10:46:32 +0900    
  
committer: Tatsuo Ishii <ishii@postgresql.org>    
date     : Mon, 31 Jul 2017 10:46:32 +0900    

Click here for diff

  
max_logical_replication_workers requires to restart server to reflect  
the new value. Per Yugo Nagata. Minor editing by me.  
  

Move ExecProcNode from dispatch to function pointer based model.

  
commit   : cc9f08b6b813e30789100b6b34110d8be1090ba0    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 17 Jul 2017 00:33:49 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Mon, 17 Jul 2017 00:33:49 -0700    

Click here for diff

  
This allows us to add stack-depth checks the first time an executor  
node is called, and skip that overhead on following  
calls. Additionally it yields a nice speedup.  
  
While it'd probably have been a good idea to have that check all  
along, it has become more important after the new expression  
evaluation framework in b8d7f053c5c2bf2a7e - there's no stack depth  
check in common paths anymore now. We previously relied on  
ExecEvalExpr() being executed somewhere.  
  
We should move towards that model for further routines, but as this is  
required for v10, it seems better to only do the necessary (which  
already is quite large).  
  
Author: Andres Freund, Tom Lane  
Reported-By: Julien Rouhaud  
Discussion:  
    https://postgr.es/m/22833.1490390175@sss.pgh.pa.us  
    https://postgr.es/m/b0af9eaa-130c-60d0-9e4e-7a135b1e0c76@dalibo.com  
  

Move interrupt checking from ExecProcNode() to executor nodes.

  
commit   : d47cfef7116fb36349949f5c757aa2112c249804    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Tue, 25 Jul 2017 17:37:17 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Tue, 25 Jul 2017 17:37:17 -0700    

Click here for diff

  
In a followup commit ExecProcNode(), and especially the large switch  
it contains, will largely be replaced by a function pointer directly  
to the correct node. The node functions will then get invoked by a  
thin inline function wrapper. To avoid having to include miscadmin.h  
in headers - CHECK_FOR_INTERRUPTS() - move the interrupt checks into  
the individual executor routines.  
  
While looking through all executor nodes, I noticed a number of  
arguably missing interrupt checks, add these too.  
  
Author: Andres Freund, Tom Lane  
Reviewed-By: Tom Lane  
Discussion:  
    https://postgr.es/m/22833.1490390175@sss.pgh.pa.us  
  

Include publication owner’s name in the output of \dRp+.

  
commit   : 9dea962b3ef48f6e96172653b7cf80cb5f53e6b6    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 28 Jul 2017 17:44:48 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 28 Jul 2017 17:44:48 -0400    

Click here for diff

  
Without this, \dRp prints information that \dRp+ does not, which  
seems pretty odd.  
  
Daniel Gustafsson  
  
Discussion: https://postgr.es/m/3641F19B-336A-431A-86CE-A80562505C5E@yesql.se  
  

PL/Perl portability fix: absorb relevant -D switches from Perl.

  
commit   : 3c163a7fc76debbbdad1bdd3c43721cffe72f4db    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 28 Jul 2017 14:25:28 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 28 Jul 2017 14:25:28 -0400    

Click here for diff

  
The Perl documentation is very clear that stuff calling libperl should  
be built with the compiler switches shown by Perl's $Config{ccflags}.  
We'd been ignoring that up to now, and mostly getting away with it,  
but recent Perl versions contain ABI compatibility cross-checks that  
fail on some builds because of this omission.  In particular the  
sizeof(PerlInterpreter) can come out different due to some fields being  
added or removed; which means we have a live ABI hazard that we'd better  
fix rather than continuing to sweep it under the rug.  
  
However, it still seems like a bad idea to just absorb $Config{ccflags}  
verbatim.  In some environments Perl was built with a different compiler  
that doesn't even use the same switch syntax.  -D switch syntax is pretty  
universal though, and absorbing Perl's -D switches really ought to be  
enough to fix the problem.  
  
Furthermore, Perl likes to inject stuff like -D_LARGEFILE_SOURCE and  
-D_FILE_OFFSET_BITS=64 into $Config{ccflags}, which affect libc ABIs on  
platforms where they're relevant.  Adopting those seems dangerous too.  
It's unclear whether a build wherein Perl and Postgres have different ideas  
of sizeof(off_t) etc would work, or whether anyone would care about making  
it work.  But it's dead certain that having different stdio ABIs in  
core Postgres and PL/Perl will not work; we've seen that movie before.  
Therefore, let's also ignore -D switches for symbols beginning with  
underscore.  The symbols that we actually need to import should be the ones  
mentioned in perl.h's PL_bincompat_options stanza, and none of those start  
with underscore, so this seems likely to work.  (If it turns out not to  
work everywhere, we could consider intersecting the symbols mentioned in  
PL_bincompat_options with the -D switches.  But that will be much more  
complicated, so let's try this way first.)  
  
This will need to be back-patched, but first let's see what the  
buildfarm makes of it.  
  
Ashutosh Sharma, some adjustments by me  
  
Discussion: https://postgr.es/m/CANFyU97OVQ3+Mzfmt3MhuUm5NwPU=-FtbNH5Eb7nZL9ua8=rcA@mail.gmail.com  
  

PL/Perl portability fix: avoid including XSUB.h in plperl.c.

  
commit   : bebe174bb4462ef079a1d7eeafb82ff969f160a4    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 28 Jul 2017 12:25:43 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 28 Jul 2017 12:25:43 -0400    

Click here for diff

  
In Perl builds that define PERL_IMPLICIT_SYS, XSUB.h defines macros  
that replace a whole lot of basic libc functions with Perl functions.  
We can't tolerate that in plperl.c; it breaks at least PG_TRY and  
probably other stuff.  The core idea of this patch is to include XSUB.h  
only in the .xs files where it's really needed, and to move any code  
broken by PERL_IMPLICIT_SYS out of the .xs files and into plperl.c.  
  
The reason this hasn't been a problem before is that our build techniques  
did not result in PERL_IMPLICIT_SYS appearing as a #define in PL/Perl,  
even on some platforms where Perl thinks it is defined.  That's about to  
change in order to fix a nasty portability issue, so we need this work to  
make the code safe for that.  
  
Rather unaccountably, the Perl people chose XSUB.h as the place to provide  
the versions of the aTHX/aTHX_ macros that are needed by code that's not  
explicitly aware of the MULTIPLICITY API conventions.  Hence, just removing  
XSUB.h from plperl.c fails miserably.  But we can work around that by  
defining PERL_NO_GET_CONTEXT (which would make the relevant stanza of  
XSUB.h a no-op anyway).  As explained in perlguts.pod, that means we need  
to add a "dTHX" macro call in every C function that calls a Perl API  
function.  In most of them we just add this at the top; but since the  
macro fetches the current Perl interpreter pointer, more care is needed  
in functions that switch the active interpreter.  Lack of the macro is  
easily recognized since it results in bleats about "my_perl" not being  
defined.  
  
(A nice side benefit of this is that it significantly reduces the number  
of fetches of the current interpreter pointer.  On my machine, plperl.so  
gets more than 10% smaller, and there's probably some performance win too.  
We could reduce the number of fetches still more by decorating the code  
with pTHX_/aTHX_ macros to pass the interpreter pointer around, as  
explained by perlguts.pod; but that's a task for another day.)  
  
Formatting note: pgindent seems happy to treat "dTHX;" as a declaration  
so long as it's the first thing after the left brace, as we'd already  
observed with respect to the similar macro "dSP;".  If you try to put  
it later in a set of declarations, pgindent puts ugly extra space  
around it.  
  
Having removed XSUB.h from plperl.c, we need only move the support  
functions for spi_return_next and util_elog (both of which use PG_TRY)  
out of the .xs files and into plperl.c.  This seems sufficient to  
avoid the known problems caused by PERL_IMPLICIT_SYS, although we  
could move more code if additional issues emerge.  
  
This will need to be back-patched, but first let's see what the  
buildfarm makes of it.  
  
Patch by me, with some help from Ashutosh Sharma  
  
Discussion: https://postgr.es/m/CANFyU97OVQ3+Mzfmt3MhuUm5NwPU=-FtbNH5Eb7nZL9ua8=rcA@mail.gmail.com  
  

Fix psql tab completion for CREATE USER MAPPING.

  
commit   : 8d304072a2573f0bfbdf893cc79197aeecdb5242    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 27 Jul 2017 14:13:15 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 27 Jul 2017 14:13:15 -0400    

Click here for diff

  
After typing CREATE USER M..., it would not fill in MAPPING FOR,  
even though that was clearly intended behavior.  
  
Jeff Janes  
  
Discussion: https://postgr.es/m/CAMkU=1wo2iQ6jWnN=egqOb5NxEPn0PpANEtKHr3uPooQ+nYPtw@mail.gmail.com  
  

Standardize describe.c’s behavior for no-matching-objects a bit more.

  
commit   : 77cb4a1d6730a69906baf0b052aae7dc11f07764    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 27 Jul 2017 13:30:59 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 27 Jul 2017 13:30:59 -0400    

Click here for diff

  
Most functions in this file are content to print an empty table if there  
are no matching objects.  In some, the behavior is to loop over all  
matching objects and print a table for each one; therefore, without any  
extra logic, nothing at all would be printed if no objects match.  
We accept that outcome in QUIET mode, but in normal mode it seems better  
to print a helpful message.  The new \dRp+ command had not gotten that  
memo; fix it.  
  
listDbRoleSettings() is out of step on this, but I think it's better for  
it to print a custom message rather than an empty table, because of the  
possibility that the user is confused about what the pattern arguments mean  
or which is which.  The original message wording was entirely useless for  
clarifying that, though, not to mention being unlike the wordings used  
elsewhere.  Improve the text, and also print the messages with psql_error  
as is the general custom here.  
  
listTables() is also out in left field, but since it's such a heavily  
used function, I'm hesitant to change its behavior so much as to print  
an empty table rather than a custom message.  People are probably used  
to getting a message.  But we can make the wording more standardized and  
helpful, and print it with psql_error rather than printing to stdout.  
  
In both listDbRoleSettings and listTables, we play dumb and emit an  
empty table, not a custom message, in QUIET mode.  That was true before  
and I see no need to change it.  
  
Several of the places printing such messages risked dumping core if  
no pattern string had been provided; make them more wary.  (This case  
is presently unreachable in describeTableDetails; but it shouldn't be  
assuming that command.c will never pass it a null.  The text search  
functions would only reach the case if a database contained no text  
search objects, which is also currently impossible since we pin the  
built-in objects, but again it seems unwise to assume that here.)  
  
Daniel Gustafsson, tweaked a bit by me  
  
Discussion: https://postgr.es/m/3641F19B-336A-431A-86CE-A80562505C5E@yesql.se  
  

Avoid use of sprintf/snprintf in describe.c.

  
commit   : 1e2f941db1671909ba3bde447c224bb64d1c002a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 27 Jul 2017 12:12:37 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 27 Jul 2017 12:12:37 -0400    

Click here for diff

  
Most places were already using the PQExpBuffer library for constructing  
variable-length strings; bring the two stragglers into line.  
describeOneTSParser was living particularly dangerously since it wasn't  
even using snprintf().  
  
Daniel Gustafsson  
  
Discussion: https://postgr.es/m/3641F19B-336A-431A-86CE-A80562505C5E@yesql.se  
  

Sync listDbRoleSettings() with the rest of the world.

  
commit   : b884f629dcbac002a703ccaf0990d9467ae69a19    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 27 Jul 2017 11:57:29 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 27 Jul 2017 11:57:29 -0400    

Click here for diff

  
listDbRoleSettings() handled its server version check randomly differently  
from every other comparable function in describe.c, not only as to code  
layout but also message wording.  It also leaked memory, because its  
PQExpBuffer management was also unlike everyplace else (and wrong).  
  
Also fix an error-case leak in add_tablespace_footer().  
  
In passing, standardize the format of function header comments in  
describe.c --- we usually put "/*" alone on a line.  
  
Daniel Gustafsson, memory leak fixes by me  
  
Discussion: https://postgr.es/m/3641F19B-336A-431A-86CE-A80562505C5E@yesql.se  
  

Fix very minor memory leaks in psql’s command.c.

  
commit   : dc4da3dc84c7c0d1a58275f78f0e3401385e3700    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 27 Jul 2017 11:10:38 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 27 Jul 2017 11:10:38 -0400    

Click here for diff

  
\drds leaked its second pattern argument if any, and \connect leaked  
any empty-string or "-" arguments.  These are old bugs, but it's hard  
to imagine any real use-case where the leaks could amount to anything  
meaningful, so not bothering with a back-patch.  
  
Daniel Gustafsson and Tom Lane  
  
Discussion: https://postgr.es/m/3641F19B-336A-431A-86CE-A80562505C5E@yesql.se  
  

Work around Msys weakness in Testlib.pm’s command_like()

  
commit   : efd7f8e36553cd32e445061cbbc80d32028f4248    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Wed, 26 Jul 2017 17:15:59 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Wed, 26 Jul 2017 17:15:59 -0400    

Click here for diff

  
When output of IPC::Run::run () is redirected to scalar references, in  
certain circumstances the Msys perl does not correctly detect that the  
end of file has been seen, making the test hang indefinitely. One such  
circumstance is when the command is 'pg_ctl start', and such a change  
was made in commit f13ea95f9e. The workaround, which only applies on  
MSys, is to redirect the output to temporary files and then read them in  
when the process has finished.  
  
Patch by me, reviewed and tweaked by Tom Lane.  
  

Clean up SQL emitted by psql/describe.c.

  
commit   : 50d2426f5a6d6a47da9ea67be55c3e89069e7bec    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 26 Jul 2017 19:35:35 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 26 Jul 2017 19:35:35 -0400    

Click here for diff

  
Fix assorted places that had not bothered with the convention of  
prefixing catalog and function names with "pg_catalog.".  That  
could possibly result in query failure when running with a nondefault  
search_path.  Also fix two places that weren't quoting OID literals.  
I think the latter hasn't mattered much since about 7.3, but it's still  
a bad idea to be doing it in 99 places and not in 2 others.  
  
Also remove a useless EXISTS sub-select that someone had stuck into  
describeOneTableDetails' queries for child tables.  We just got the OID  
out of pg_class, so I hardly see how checking that it exists in pg_class  
was doing anything helpful.  
  
In passing, try to improve the emitted formatting of a couple of  
these queries, though I didn't work really hard on that.  And merge  
unnecessarily duplicative coding in some other places.  
  
Much of this was new in HEAD, but some was quite old; back-patch  
as appropriate.  
  

  
commit   : 5e3254f0865d2e3372cfd29249063bdaedfa4b00    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 26 Jul 2017 18:17:18 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 26 Jul 2017 18:17:18 -0400    

Click here for diff

  
  

Fix concurrent locking of tuple update chain

  
commit   : 459c64d3227f878c72ef0145a67e80e17728c556    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 26 Jul 2017 17:24:16 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 26 Jul 2017 17:24:16 -0400    

Click here for diff

  
If several sessions are concurrently locking a tuple update chain with  
nonconflicting lock modes using an old snapshot, and they all succeed,  
it may happen that some of them fail because of restarting the loop (due  
to a concurrent Xmax change) and getting an error in the subsequent pass  
while trying to obtain a tuple lock that they already have in some tuple  
version.  
  
This can only happen with very high concurrency (where a row is being  
both updated and FK-checked by multiple transactions concurrently), but  
it's been observed in the field and can have unpleasant consequences  
such as an FK check failing to see a tuple that definitely exists:  
    ERROR:  insert or update on table "child_table" violates foreign key constraint "fk_constraint_name"  
    DETAIL:  Key (keyid)=(123456) is not present in table "parent_table".  
(where the key is observably present in the table).  
  
Discussion: https://postgr.es/m/20170714210011.r25mrff4nxjhmf3g@alvherre.pgsql  
  

Remove obsolete comments about functional dependencies

  
commit   : c28e4f4dc6aeb75cf35f1339cbe3387263e0e69b    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 26 Jul 2017 11:40:39 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 26 Jul 2017 11:40:39 -0400    

Click here for diff

  
Initial submitted versions of the functional dependencies patch ignored  
row groups that were smaller than a configured size.  However, that  
consideration was removed in late stages of the patch just before  
commit, but some comments referring to it remained.  Remove them to  
avoid confusion.  
  
Author: Atsushi Torikoshi  
Discussion: https://postgr.es/m/7cfb23fc-4493-9c02-5da9-e505fd0115d2@lab.ntt.co.jp  
  

Make PostgresNode easily subclassable

  
commit   : 54dacc746628799a3a09ebb78876b0a8d2742d23    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 25 Jul 2017 18:39:44 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 25 Jul 2017 18:39:44 -0400    

Click here for diff

  
This module becomes much more useful if we allow it to be used as base  
class for external projects.  To achieve this, change the exported  
get_new_node function into a class method instead, and use the standard  
Perl idiom of accepting the class as first argument.  This method works  
as expected for subclasses.  The standalone function is kept for  
backwards compatibility, though it could be removed in pg11.  
  
Author: Chap Flackman, based on an earlier patch from Craig Ringer  
Discussion: https://postgr.es/m/CAMsr+YF8kO+4+K-_U4PtN==2FndJ+5Bn6A19XHhMiBykEwv0wA@mail.gmail.com  
  

Fix race conditions in replication slot operations

  
commit   : 9915de6c1cb2c9b87f5f504c97832cdf3a809753    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 25 Jul 2017 13:26:49 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 25 Jul 2017 13:26:49 -0400    

Click here for diff

  
It is relatively easy to get a replication slot to look as still active  
while one process is in the process of getting rid of it; when some  
other process tries to "acquire" the slot, it would fail with an error  
message of "replication slot XYZ is active for PID N".  
  
The error message in itself is fine, except that when the intention is  
to drop the slot, it is unhelpful: the useful behavior would be to wait  
until the slot is no longer acquired, so that the drop can proceed.  To  
implement this, we use a condition variable so that slot acquisition can  
be told to wait on that condition variable if the slot is already  
acquired, and we make any change in active_pid broadcast a signal on the  
condition variable.  Thus, as soon as the slot is released, the drop  
will proceed properly.  
  
Reported by: Tom Lane  
Discussion: https://postgr.es/m/11904.1499039688@sss.pgh.pa.us  
Authors: Petr Jelínek, Álvaro Herrera  
  

Fix partitioning crashes during error reporting.

  
commit   : 4132dbec69dd4d437e132e57a74a98a40cdcf776    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Mon, 24 Jul 2017 18:08:08 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Mon, 24 Jul 2017 18:08:08 -0400    

Click here for diff

  
In various places where we reverse-map a tuple before calling  
ExecBuildSlotValueDescription, we neglected to ensure that the  
slot descriptor matched the tuple stored in it.  
  
Amit Langote and Amit Khandekar, reviewed by Etsuro Fujita  
  
Discussion: http://postgr.es/m/CAJ3gD9cqpP=WvJj=dv1ONkPWjy8ZuUaOM4_x86i3uQPas=0_jg@mail.gmail.com  
  

Fix race condition in predicate-lock init code in EXEC_BACKEND builds.

  
commit   : e2c8100e60729368c84e9a49ada9b44df5a1b851    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 24 Jul 2017 16:45:46 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 24 Jul 2017 16:45:46 -0400    

Click here for diff

  
Trading a little too heavily on letting the code path be the same whether  
we were creating shared data structures or only attaching to them,  
InitPredicateLocks() inserted the "scratch" PredicateLockTargetHash entry  
unconditionally.  This is just wrong if we're in a postmaster child,  
which would only reach this code in EXEC_BACKEND builds.  Most of the  
time, the hash_search(HASH_ENTER) call would simply report that the  
entry already existed, causing no visible effect since the code did not  
bother to check for that possibility.  However, if this happened while  
some other backend had transiently removed the "scratch" entry, then  
that other backend's eventual RestoreScratchTarget would suffer an  
assert failure; this appears to be the explanation for a recent failure  
on buildfarm member culicidae.  In non-assert builds, there would be  
no visible consequences there either.  But nonetheless this is a pretty  
bad bug for EXEC_BACKEND builds, for two reasons:  
  
1. Each new backend would perform the hash_search(HASH_ENTER) call  
without holding any lock that would prevent concurrent access to the  
PredicateLockTargetHash hash table.  This creates a low but certainly  
nonzero risk of corruption of that hash table.  
  
2. In the event that the race condition occurred, by reinserting the  
scratch entry too soon, we were defeating the entire purpose of the  
scratch entry, namely to guarantee that transaction commit could move  
hash table entries around with no risk of out-of-memory failure.  
The odds of an actual OOM failure are quite low, but not zero, and if  
it did happen it would again result in corruption of the hash table.  
  
The user-visible symptoms of such corruption are a little hard to predict,  
but would presumably amount to misbehavior of SERIALIZABLE transactions  
that'd require a crash or postmaster restart to fix.  
  
To fix, just skip the hash insertion if IsUnderPostmaster.  I also  
inserted a bunch of assertions that the expected things happen  
depending on whether IsUnderPostmaster is true.  That might be overkill,  
since most comparable code in other functions isn't quite that paranoid,  
but once burnt twice shy.  
  
In passing, also move a couple of lines to places where they seemed  
to make more sense.  
  
Diagnosis of problem by Thomas Munro, patch by me.  Back-patch to  
all supported branches.  
  
Discussion: https://postgr.es/m/10593.1500670709@sss.pgh.pa.us  
  

When WCOs are present, disable direct foreign table modification.

  
commit   : 7086be6e3627c1ad797e32ebbdd232905b5f577f    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Mon, 24 Jul 2017 15:57:24 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Mon, 24 Jul 2017 15:57:24 -0400    

Click here for diff

  
If the user modifies a view that has CHECK OPTIONs and this gets  
translated into a modification to an underlying relation which happens  
to be a foreign table, the check options should be enforced.  In the  
normal code path, that was happening properly, but it was not working  
properly for "direct" modification because the whole operation gets  
pushed to the remote side in that case and we never have an option to  
enforce the constraint against individual tuples.  Fix by disabling  
direct modification when there is a need to enforce CHECK OPTIONs.  
  
Etsuro Fujita, reviewed by Kyotaro Horiguchi and by me.  
  
Discussion: http://postgr.es/m/f8a48f54-6f02-9c8a-5250-9791603171ee@lab.ntt.co.jp  
  

Ensure that pg_get_ruledef()’s output matches pg_get_viewdef()’s.

  
commit   : b4af9e3f378ef56fa48b98a0bfb641900b0280dc    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 24 Jul 2017 15:16:31 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 24 Jul 2017 15:16:31 -0400    

Click here for diff

  
Various cases involving renaming of view columns are handled by having  
make_viewdef pass down the view's current relation tupledesc to  
get_query_def, which then takes care to use the column names from the  
tupledesc for the output column names of the SELECT.  For some reason  
though, we'd missed teaching make_ruledef to do similarly when it is  
printing an ON SELECT rule, even though this is exactly the same case.  
The results from pg_get_ruledef would then be different and arguably wrong.  
In particular, this breaks pre-v10 versions of pg_dump, which in some  
situations would define views by means of emitting a CREATE RULE ... ON  
SELECT command.  Third-party tools might not be happy either.  
  
In passing, clean up some crufty code in make_viewdef; we'd apparently  
modernized the equivalent code in make_ruledef somewhere along the way,  
and missed this copy.  
  
Per report from Gilles Darold.  Back-patch to all supported versions.  
  
Discussion: https://postgr.es/m/ec05659a-40ff-4510-fc45-ca9d965d0838@dalibo.com  
  

Be more consistent about errors for opfamily member lookup failures.

  
commit   : 278cb4341103e967189997985b09981a73e23a34    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 24 Jul 2017 11:23:27 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 24 Jul 2017 11:23:27 -0400    

Click here for diff

  
Add error checks in some places that were calling get_opfamily_member  
or get_opfamily_proc and just assuming that the call could never fail.  
Also, standardize the wording for such errors in some other places.  
  
None of these errors are expected in normal use, hence they're just  
elog not ereport.  But they may be handy for diagnosing omissions in  
custom opclasses.  
  
Rushabh Lathia found the oversight in RelationBuildPartitionKey();  
I found the others by grepping for all callers of these functions.  
  
Discussion: https://postgr.es/m/CAGPqQf2R9Nk8htpv0FFi+FP776EwMyGuORpc9zYkZKC8sFQE3g@mail.gmail.com  
  

MSVC: Finish clean.bat build artifact coverage.

  
commit   : bbbd9121e63f9f7cf8cc86025d5d848fba477eb4    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Mon, 24 Jul 2017 00:13:23 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 24 Jul 2017 00:13:23 -0700    

Click here for diff

  
With this, "git clean -dnx" is clear after a "clean dist" following a  
build.  Preserve sql_help.h in non-dist cleans, like the Makefile does.  
  

MSVC: Accept tcl86.lib in addition to tcl86t.lib.

  
commit   : 71ad8000da5d836c9ca117a164c38d84284a336f    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sun, 23 Jul 2017 23:53:27 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sun, 23 Jul 2017 23:53:27 -0700    

Click here for diff

  
ActiveTcl8.6.4.1.299124-win32-x86_64-threaded.exe ships just tcl86.lib.  
Back-patch to 9.2, like the commit recognizing tcl86t.lib.  
  

Fix pg_dump’s handling of event triggers.

  
commit   : 93f039b4944fdf806f029ed46cf192bc9021d8e7    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 22 Jul 2017 20:20:09 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 22 Jul 2017 20:20:09 -0400    

Click here for diff

  
pg_dump with the --clean option failed to emit DROP EVENT TRIGGER  
commands for event triggers.  In a closely related oversight,  
it also did not emit ALTER OWNER commands for event triggers.  
Since only superusers can create event triggers, the latter oversight  
is of little practical consequence ... but if we're going to record  
an owner for event triggers, then surely pg_dump should preserve it.  
  
Per complaint from Greg Atkins.  Back-patch to 9.3 where event triggers  
were introduced.  
  
Discussion: https://postgr.es/m/20170722191142.yi4e7tzcg3iacclg@gmail.com  
  

Improve comments about partitioned hash table freelists.

  
commit   : ab2324fd468c4bc6d8b012552550ed951d97339a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 22 Jul 2017 18:02:26 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 22 Jul 2017 18:02:26 -0400    

Click here for diff

  
While I couldn't find any live bugs in commit 44ca4022f, the comments  
seemed pretty far from adequate; in particular it was not made plain that  
"borrowing" entries from other freelists is critical for correctness.  
Try to improve the commentary.  A couple of very minor code style  
tweaks, as well.  
  
Discussion: https://postgr.es/m/10593.1500670709@sss.pgh.pa.us  
  

Update expected results for collate.linux.utf8 regression test.

  
commit   : 991c8b04fc5d61a308bb00ea34a7ff710051c53f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 22 Jul 2017 12:15:19 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 22 Jul 2017 12:15:19 -0400    

Click here for diff

  
I believe this changed as a consequence of commit 54baa4813: trying to  
clone the "C" collation now produces a true clone with collencoding -1,  
hence the error message if it's duplicate no longer specifies an encoding.  
  
Per buildfarm member crake, which apparently hadn't been running this  
test for the last few weeks.  
  

Fix typo in comment

  
commit   : de38489b926e3e5af84f22cf4788fe4498e13c72    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 17 Jul 2017 09:51:42 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 17 Jul 2017 09:51:42 -0400    

Click here for diff

  
Commit fd31cd265138 renamed the variable to skipping_blocks, but forgot  
to update this comment.  
  
Noticed while inspecting code.  
  

Doc: update versioning information in libpq.sgml.

  
commit   : e22efaabf16e3972b91893d89597407d142fb309    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 21 Jul 2017 17:50:57 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 21 Jul 2017 17:50:57 -0400    

Click here for diff

  
The descriptions of PQserverVersion and PQlibVersion hadn't been updated  
for the new two-part version-numbering approach.  Fix that.  
  
In passing, remove some trailing whitespace elsewhere in the file.  
  

pg_rewind: Fix some problems when copying files >2GB.

  
commit   : a46fe6e8be02421ea7e80c5a6d5e388417904fd4    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 21 Jul 2017 14:25:36 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 21 Jul 2017 14:25:36 -0400    

Click here for diff

  
When incrementally updating a file larger than 2GB, the old code could  
either fail outright (if the client asked the server for bytes beyond  
the 2GB boundary) or fail to copy all the blocks that had actually  
been modified (if the server reported a file size to the client in  
excess of 2GB), resulting in data corruption.  Generally, such files  
won't occur anyway, but they might if using a non-default segment size  
or if there the directory contains stray files unrelated to  
PostgreSQL.  Fix by a more prudent choice of data types.  
  
Even with these improvements, this code still uses a mix of different  
types (off_t, size_t, uint64, int64) to represent file sizes and  
offsets, not all of which necessarily have the same width or  
signedness, so further cleanup might be in order here.  However, at  
least now they all have the potential to be 64 bits wide on 64-bit  
platforms.  
  
Kuntal Ghosh and Michael Paquier, with a tweak by me.  
  
Discussion: http://postgr.es/m/CAGz5QC+8gbkz=Brp0TgoKNqHWTzonbPtPex80U0O6Uh_bevbaA@mail.gmail.com  
  

Stabilize postgres_fdw regression tests.

  
commit   : 88f48b57fd33289c26c78ecb28c5f2a1c7a4ac6c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 21 Jul 2017 14:20:43 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 21 Jul 2017 14:20:43 -0400    

Click here for diff

  
The new test cases added in commit 8bf58c0d9 turn out to have output  
that can vary depending on the lc_messages setting prevailing on the  
test server.  Hide the remote end's error messages to ensure stable  
output.  This isn't a terribly desirable solution; we'd rather know  
that the connection failed for the expected reason and not some other  
one.  But there seems little choice for the moment.  
  
Per buildfarm.  
  
Discussion: https://postgr.es/m/18419.1500658570@sss.pgh.pa.us  
  

pg_rewind: Fix busted sanity check.

  
commit   : 063ff9210c54928a2d19f9e826486621809e1b82    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 21 Jul 2017 12:48:22 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 21 Jul 2017 12:48:22 -0400    

Click here for diff

  
As written, the code would only fail the sanity check if none of the  
columns returned by the server were of the expected type, but we want  
it to fail if even one column is not of the expected type.  
  
Discussion: http://postgr.es/m/CA+TgmoYuY5zW7JEs+1hSS1D=V5K8h1SQuESrq=bMNeo0B71Sfw@mail.gmail.com  
  

Re-establish postgres_fdw connections after server or user mapping changes.

  
commit   : 8bf58c0d9bd336868e2d6489f11dc094cad9ad91    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 21 Jul 2017 12:51:38 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 21 Jul 2017 12:51:38 -0400    

Click here for diff

  
Previously, postgres_fdw would keep on using an existing connection even  
if the user did ALTER SERVER or ALTER USER MAPPING commands that should  
affect connection parameters.  Teach it to watch for catcache invals  
on these catalogs and re-establish connections when the relevant catalog  
entries change.  Per bug #14738 from Michal Lis.  
  
In passing, clean up some rather crufty decisions in commit ae9bfc5d6  
about where fields of ConnCacheEntry should be reset.  We now reset  
all the fields whenever we open a new connection.  
  
Kyotaro Horiguchi, reviewed by Ashutosh Bapat and myself.  
Back-patch to 9.3 where postgres_fdw appeared.  
  
Discussion: https://postgr.es/m/20170710113917.7727.10247@wrigleys.postgresql.org  
  

Fix double shared memory allocation.

  
commit   : 7e1fb4c59e4ac86de2640d0f3453fde270ec1ff8    
  
author   : Teodor Sigaev <teodor@sigaev.ru>    
date     : Fri, 21 Jul 2017 13:31:20 +0300    
  
committer: Teodor Sigaev <teodor@sigaev.ru>    
date     : Fri, 21 Jul 2017 13:31:20 +0300    

Click here for diff

  
SLRU buffer lwlocks are allocated twice by oversight in commit  
fe702a7b3f9f2bc5bf6d173166d7d55226af82c8 where that locks were moved to  
separate tranche. The bug doesn't have user-visible effects except small  
overspending of shared memory.  
  
Backpatch to 9.6 where it was introduced.  
  
Alexander Korotkov with small editorization by me.  
  

Make the new partition regression tests locale-independent.

  
commit   : 68f785fd522bca9372cce965ac10cbd8c239c076    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Fri, 21 Jul 2017 10:18:01 +0100    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Fri, 21 Jul 2017 10:18:01 +0100    

Click here for diff

  
The order of partitions listed by \d+ is in general locale-dependent.  
Rename the partitions in the test added by d363d42bb9 to force them to  
be listed in a consistent order.  
  

Use MINVALUE/MAXVALUE instead of UNBOUNDED for range partition bounds.

  
commit   : d363d42bb9a4399a0207bd3b371c966e22e06bd3    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Fri, 21 Jul 2017 09:20:47 +0100    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Fri, 21 Jul 2017 09:20:47 +0100    

Click here for diff

  
Previously, UNBOUNDED meant no lower bound when used in the FROM list,  
and no upper bound when used in the TO list, which was OK for  
single-column range partitioning, but problematic with multiple  
columns. For example, an upper bound of (10.0, UNBOUNDED) would not be  
collocated with a lower bound of (10.0, UNBOUNDED), thus making it  
difficult or impossible to define contiguous multi-column range  
partitions in some cases.  
  
Fix this by using MINVALUE and MAXVALUE instead of UNBOUNDED to  
represent a partition column that is unbounded below or above  
respectively. This syntax removes any ambiguity, and ensures that if  
one partition's lower bound equals another partition's upper bound,  
then the partitions are contiguous.  
  
Also drop the constraint prohibiting finite values after an unbounded  
column, and just document the fact that any values after MINVALUE or  
MAXVALUE are ignored. Previously it was necessary to repeat UNBOUNDED  
multiple times, which was needlessly verbose.  
  
Note: Forces a post-PG 10 beta2 initdb.  
  
Report by Amul Sul, original patch by Amit Langote with some  
additional hacking by me.  
  
Discussion: https://postgr.es/m/CAAJ_b947mowpLdxL3jo3YLKngRjrq9+Ej4ymduQTfYR+8=YAYQ@mail.gmail.com  
  

In v10 release notes, call out sequence changes as a compatibility item.

  
commit   : 866f4a7c210857aa342bf901558d170325094dde    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 20 Jul 2017 15:28:42 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 20 Jul 2017 15:28:42 -0400    

Click here for diff

  
The previous description didn't make it clear that this change  
potentially breaks applications, partly because the entry wasn't even  
in the compatibility-hazard section.  Move and clarify.  
  
Discussion: https://postgr.es/m/603f3f0a-f89d-ae8b-1da9-a92fac16086d@enterprisedb.com  
  

Doc: clarify description of degenerate NATURAL joins.

  
commit   : ed3dc224e5aabd3cb0a5c348107f973fe5b10b0d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 20 Jul 2017 12:41:26 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 20 Jul 2017 12:41:26 -0400    

Click here for diff

  
Claiming that NATURAL JOIN is equivalent to CROSS JOIN when there are  
no common column names is only strictly correct if it's an inner join;  
you can't say e.g. CROSS LEFT JOIN.  Better to explain it as meaning  
JOIN ON TRUE, instead.  Per a suggestion from David Johnston.  
  
Discussion: https://postgr.es/m/CAKFQuwb+mYszQhDS9f_dqRrk1=Pe-S6D=XMkAXcDf4ykKPmgKQ@mail.gmail.com  
  

Fix dumping of outer joins with empty qual lists.

  
commit   : eb145fdfea91ee5dc6d7aad0309527f810f7c90a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 20 Jul 2017 11:29:36 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 20 Jul 2017 11:29:36 -0400    

Click here for diff

  
Normally, a JoinExpr would have empty "quals" only if it came from CROSS  
JOIN syntax.  However, it's possible to get to this state by specifying  
NATURAL JOIN between two tables with no common column names, and there  
might be other ways too.  The code previously printed no ON clause if  
"quals" was empty; that's right for CROSS JOIN but syntactically invalid  
if it's some type of outer join.  Fix by printing ON TRUE in that case.  
  
This got broken by commit 2ffa740be, which stopped using NATURAL JOIN  
syntax in ruleutils output due to its brittleness in the face of  
column renamings.  Back-patch to 9.3 where that commit appeared.  
  
Per report from Tushar Ahuja.  
  
Discussion: https://postgr.es/m/98b283cd-6dda-5d3f-f8ac-87db8c76a3da@enterprisedb.com  
  

Add static assertions about pg_control fitting into one disk sector.

  
commit   : 3cb29c42f990522131535eea75c691fb23191685    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 19 Jul 2017 16:16:57 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 19 Jul 2017 16:16:57 -0400    

Click here for diff

  
When pg_control was first designed, sizeof(ControlFileData) was small  
enough that a comment seemed like plenty to document the assumption that  
it'd fit into one disk sector.  Now it's nearly 300 bytes, raising the  
possibility that somebody would carelessly add enough stuff to create  
a problem.  Let's add a StaticAssertStmt() to ensure that the situation  
doesn't pass unnoticed if it ever occurs.  
  
While at it, rename PG_CONTROL_SIZE to PG_CONTROL_FILE_SIZE to make it  
clearer what that symbol means, and convert the existing runtime  
comparisons of sizeof(ControlFileData) vs. PG_CONTROL_FILE_SIZE to be  
static asserts --- we didn't have that technology when this code was  
first written.  
  
Discussion: https://postgr.es/m/9192.1500490591@sss.pgh.pa.us  
  

Doc: add missing note about permissions needed to change log_lock_waits.

  
commit   : 5752dcd45bd8b9a9115d4be12b9a391464884a39    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 19 Jul 2017 12:58:36 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 19 Jul 2017 12:58:36 -0400    

Click here for diff

  
log_lock_waits is PGC_SUSET, but config.sgml lacked the standard  
boilerplate sentence noting that.  
  
Report: https://postgr.es/m/20170719100838.19352.16320@wrigleys.postgresql.org  
  

Improve make_tsvector() to handle empty input, and simplify its callers.

  
commit   : 04a2c7f412d01da8100de79b13df4fd39e15ce25    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 18 Jul 2017 13:13:47 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 18 Jul 2017 13:13:47 -0400    

Click here for diff

  
It seemed a bit silly that each caller of make_tsvector() was laboriously  
special-casing the situation where no lexemes were found, when it would  
be easy and much more bullet-proof to make make_tsvector() handle that.  
  

Fix serious performance problems in json(b) to_tsvector().

  
commit   : b4c6d31c0be0f5c42a75d50afcf13bdd392db4a1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 18 Jul 2017 12:45:51 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 18 Jul 2017 12:45:51 -0400    

Click here for diff

  
In an off-list followup to bug #14745, Bob Jones complained that  
to_tsvector() on a 2MB jsonb value took an unreasonable amount of  
time and space --- enough to draw the wrath of the OOM killer on  
his machine.  On my machine, his example proved to require upwards  
of 18 seconds and 4GB, which seemed pretty bogus considering that  
to_tsvector() on the same data treated as text took just a couple  
hundred msec and 10 or so MB.  
  
On investigation, the problem is that the implementation scans each  
string element of the json(b) and converts it to tsvector separately,  
then applies tsvector_concat() to join those separate tsvectors.  
The unreasonable memory usage came from leaking every single one of  
the transient tsvectors --- but even without that mistake, this is an  
O(N^2) or worse algorithm, because tsvector_concat() has to repeatedly  
process the words coming from earlier elements.  
  
We can fix it by accumulating all the lexeme data and applying  
make_tsvector() just once.  As a side benefit, that also makes the  
desired adjustment of lexeme positions far cheaper, because we can  
just tweak the running "pos" counter between JSON elements.  
  
In passing, try to make the explanation of that tweak more intelligible.  
(I didn't think that a barely-readable comment far removed from the  
actual code was helpful.)  And do some minor other code beautification.  
  

Doc: fix thinko in v10 release notes.

  
commit   : fb9bd4b0469e06d96c8cfff86d231401b0916736    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 18 Jul 2017 10:17:15 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 18 Jul 2017 10:17:15 -0400    

Click here for diff

  
s/log_destination/log_directory/, per Jov in bug #14749.  
  
Report: https://postgr.es/m/20170718082444.9229.99690@wrigleys.postgresql.org  
  

Reverse-convert row types in ExecWithCheckOptions.

  
commit   : c85ec643ff2586e2d144374f51f93bfa215088a2    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Mon, 17 Jul 2017 21:56:31 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Mon, 17 Jul 2017 21:56:31 -0400    

Click here for diff

  
Just as we already do in ExecConstraints, and for the same reason:  
to improve the quality of error messages.  
  
Etsuro Fujita, reviewed by Amit Langote  
  
Discussion: http://postgr.es/m/56e0baa8-e458-2bbb-7936-367f7d832e43@lab.ntt.co.jp  
  

Use a real RT index when setting up partition tuple routing.

  
commit   : f81a91db4d1c2032632aa5df9fc14be24f5fe5ec    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Mon, 17 Jul 2017 21:29:45 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Mon, 17 Jul 2017 21:29:45 -0400    

Click here for diff

  
Before, we always used a dummy value of 1, but that's not right when  
the partitioned table being modified is inside of a WITH clause  
rather than part of the main query.  
  
Amit Langote, reported and reviewd by Etsuro Fujita, with a comment  
change by me.  
  
Discussion: http://postgr.es/m/ee12f648-8907-77b5-afc0-2980bcb0aa37@lab.ntt.co.jp  
  

Doc: explain dollar quoting in the intro part of the pl/pgsql chapter.

  
commit   : 533463307bf67e1bb7acc345ba7ea535c6aebb78    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 17 Jul 2017 16:43:03 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 17 Jul 2017 16:43:03 -0400    

Click here for diff

  
We're throwing people into the guts of the syntax with not much context;  
let's back up one step and point out that this goes inside a literal in  
a CREATE FUNCTION command.  Per suggestion from Kurt Kartaltepe.  
  
Discussion: https://postgr.es/m/CACawnnyWAmH+au8nfZhLiFfWKjXy4d0kY+eZWfcxPRnjVfaa_Q@mail.gmail.com  
  

Improve legibility of numeric literal

  
commit   : cde11fa3c003407fc6c4ddc427d57e588ea17d1c    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 17 Jul 2017 15:35:19 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 17 Jul 2017 15:35:19 -0400    

Click here for diff

  
  

Merge large_object.sql test into largeobject.source.

  
commit   : a570feaf927b73c5036fa47ea949ca51f2687950    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 17 Jul 2017 15:28:16 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 17 Jul 2017 15:28:16 -0400    

Click here for diff

  
It seems pretty confusing to have tests named both largeobject and  
large_object.  The latter is of very recent vintage (commit ff992c074),  
so get rid of it in favor of merging into the former.  
  
Also, enable the LO comment test that was added by commit 70ad7ed4e,  
since the later commit added the then-missing pg_upgrade functionality.  
The large_object.sql test case is almost completely redundant with that,  
but not quite: it seems like creating a user-defined LO with an OID in  
the system range might be an interesting case for pg_upgrade, so let's  
keep it.  
  
Like the earlier patch, back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/18665.1500306372@sss.pgh.pa.us  
  

Use usleep instead of select for timeouts in PostgresNode.pm

  
commit   : 6c6970a280a50434c28ccd461ba864798f5d2a04    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 17 Jul 2017 15:22:37 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 17 Jul 2017 15:22:37 -0400    

Click here for diff

  
select() for pure timeouts is not portable, and in particular doesn't  
work on Windows.  
  
Discussion: https://postgr.es/m/186943e0-3405-978d-b19d-9d3335427c86@2ndQuadrant.com  
  

  
commit   : 09c2e7cd2ff0b884625c37ce8249832820c58710    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Mon, 17 Jul 2017 12:03:35 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Mon, 17 Jul 2017 12:03:35 -0400    

Click here for diff

  
One, logging for CREATE INDEX was oblivious to the fact that when  
an unlogged table is created, *only* operations on the init fork  
should be logged.  
  
Two, init fork buffers need to be flushed after they are written;  
otherwise, a filesystem-level copy following recovery may do the  
wrong thing.  (There may be a better fix for this issue than the  
one used here, but this is transposed from the similar logic already  
present in XLogReadBufferForRedoExtended, and a broader refactoring  
after beta2 seems inadvisable.)  
  
Amit Kapila, reviewed by Ashutosh Sharma, Kyotaro Horiguchi,  
and Michael Paquier  
  
Discussion: http://postgr.es/m/CAA4eK1JpcMsEtOL_J7WODumeEfyrPi7FPYHeVdS7fyyrCrgp4w@mail.gmail.com  
  

  
commit   : 2f7f45a64badec18ce75e44ca35c078f08e2651e    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sun, 16 Jul 2017 23:13:58 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sun, 16 Jul 2017 23:13:58 -0700    

Click here for diff

  
Doing so was useful in 273c458a2b3a0fb73968020ea5e9e35eb6928967 but  
became obsolete when 818fd4a67d610991757b610755e3065fb99d80a5 caused  
postgres.exe to provide the relevant symbols.  No other loadable module  
links to libpgcommon directly.  
  

fix typo

  
commit   : deb0129a222ec6b189d5d198cf77012591f300d8    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Sun, 16 Jul 2017 12:00:23 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Sun, 16 Jul 2017 12:00:23 -0400    

Click here for diff

  
  

Fix vcregress.pl PROVE_FLAGS bug in commit 93b7d9731f

  
commit   : fd2487e49f406471c11fc337b3e06dcb8579c809    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Sun, 16 Jul 2017 11:24:29 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Sun, 16 Jul 2017 11:24:29 -0400    

Click here for diff

  
This change didn't adjust the publicly visible taptest function, causing  
buildfarm failures on bowerbird.  
  
Backpatch to 9.4 like previous change.  
  

Improve comments for execExpr.c’s handling of FieldStore subexpressions.

  
commit   : de2af6e001a3d6aeb2a10a802e73af8c7d1d3405    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 15 Jul 2017 16:57:43 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 15 Jul 2017 16:57:43 -0400    

Click here for diff

  
Given this code's general eagerness to use subexpressions' output variables  
as temporary workspace, it's not exactly clear that it is safe for  
FieldStore to tell a newval subexpression that it can write into the same  
variable that is being supplied as a potential input.  Document the chain  
of assumptions needed for that to be safe.  
  

Improve comments for execExpr.c’s isAssignmentIndirectionExpr().

  
commit   : e9b64824a067f8180e2553127467d7522516122c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 15 Jul 2017 14:03:32 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 15 Jul 2017 14:03:32 -0400    

Click here for diff

  
I got confused about why this function doesn't need to recursively  
search the expression tree for a CaseTestExpr node.  After figuring  
that out, add a comment to save the next person some time.  
  

pg_upgrade i18n: Fix “%s server/cluster” wording

  
commit   : 837255cc81fb59b12f5a70ac2a8a9850bccf13e0    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 14 Jul 2017 19:20:21 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 14 Jul 2017 19:20:21 -0400    

Click here for diff

  
The original wording was impossible to translate correctly.  
  
Discussion: https://postgr.es/m/20170523002827.lzc2jkzh2gubclqb@alvherre.pgsql  
  

Code review for NextValueExpr expression node type.

  
commit   : decb08ebdf07f2fea4b6bb43380366ef5defbafb    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 14 Jul 2017 15:25:43 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 14 Jul 2017 15:25:43 -0400    

Click here for diff

  
Add missing infrastructure for this node type, notably in ruleutils.c where  
its lack could demonstrably cause EXPLAIN to fail.  Add outfuncs/readfuncs  
support.  (outfuncs support is useful today for debugging purposes.  The  
readfuncs support may never be needed, since at present it would only  
matter for parallel query and NextValueExpr should never appear in a  
parallelizable query; but it seems like a bad idea to have a primnode type  
that isn't fully supported here.)  Teach planner infrastructure that  
NextValueExpr is a volatile, parallel-unsafe, non-leaky expression node  
with cost cpu_operator_cost.  Given its limited scope of usage, there  
*might* be no live bug today from the lack of that knowledge, but it's  
certainly going to bite us on the rear someday.  Teach pg_stat_statements  
about the new node type, too.  
  
While at it, also teach cost_qual_eval() that MinMaxExpr, SQLValueFunction,  
XmlExpr, and CoerceToDomain should be charged as cpu_operator_cost.  
Failing to do this for SQLValueFunction was an oversight in my commit  
0bb51aa96.  The others are longer-standing oversights, but no time like the  
present to fix them.  (In principle, CoerceToDomain could have cost much  
higher than this, but it doesn't presently seem worth trying to examine the  
domain's constraints here.)  
  
Modify execExprInterp.c to execute NextValueExpr as an out-of-line  
function; it seems quite unlikely to me that it's worth insisting that  
it be inlined in all expression eval methods.  Besides, providing the  
out-of-line function doesn't stop anyone from inlining if they want to.  
  
Adjust some places where NextValueExpr support had been inserted with the  
aid of a dartboard rather than keeping it in the same order as elsewhere.  
  
Discussion: https://postgr.es/m/23862.1499981661@sss.pgh.pa.us  
  

  
commit   : c95275fc202c231e867d2f0a00e8d18621b67f0d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 14 Jul 2017 12:26:53 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 14 Jul 2017 12:26:53 -0400    

Click here for diff

  
In the frontend Makefiles that pull in libpgfeutils, we'd generally  
done it like this:  
  
LDFLAGS += -L$(top_builddir)/src/fe_utils -lpgfeutils $(libpq_pgport)  
  
That method is badly broken, as seen in bug #14742 from Chris Ruprecht.  
The -L flag for src/fe_utils ends up being placed after whatever random  
-L flags are in LDFLAGS already.  That puts us at risk of pulling in  
libpgfeutils.a from some previous installation rather than the freshly  
built one in src/fe_utils.  Also, the lack of an "override" is hazardous  
if someone tries to specify some LDFLAGS on the make command line.  
  
The correct way to do it is like this:  
  
override LDFLAGS := -L$(top_builddir)/src/fe_utils -lpgfeutils $(libpq_pgport) $(LDFLAGS)  
  
so that libpgfeutils, along with libpq, libpgport, and libpgcommon, are  
guaranteed to be pulled in from the build tree and not from any referenced  
system directory, because their -L flags will appear first.  
  
In some places we'd been even lazier and done it like this:  
  
LDFLAGS += -L$(top_builddir)/src/fe_utils -lpgfeutils -lpq  
  
which is subtly wrong in an additional way: on platforms where we can't  
restrict the symbols exported by libpq.so, it allows libpgfeutils to  
latch onto libpgport and libpgcommon symbols from libpq.so, rather than  
directly from those static libraries as intended.  This carries hazards  
like those explained in the comments for the libpq_pgport macro.  
  
In addition to fixing the broken libpgfeutils usages, I tried to  
standardize on using $(libpq_pgport) like so:  
  
override LDFLAGS := $(libpq_pgport) $(LDFLAGS)  
  
even where libpgfeutils is not in the picture.  This makes no difference  
right now but will hopefully discourage future mistakes of the same ilk.  
And it's more like the way we handle CPPFLAGS in libpq-using Makefiles.  
  
In passing, just for consistency, make pgbench include PTHREAD_LIBS the  
same way everyplace else does, ie just after LIBS rather than in some  
random place in the command line.  This might have practical effect if  
there are -L switches in that macro on some platform.  
  
It looks to me like the MSVC build scripts are not affected by this  
error, but someone more familiar with them than I might want to double  
check.  
  
Back-patch to 9.6 where libpgfeutils was introduced.  In 9.6, the hazard  
this error creates is that a reinstallation might link to the prior  
installation's copy of libpgfeutils.a and thereby fail to absorb a  
minor-version bug fix.  
  
Discussion: https://postgr.es/m/20170714125106.9231.13772@wrigleys.postgresql.org  
  

Fix pg_basebackup output to stdout on Windows.

  
commit   : 8046465c2ecf6841ad80265f84294edd98aefd8b    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 14 Jul 2017 16:02:53 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 14 Jul 2017 16:02:53 +0300    

Click here for diff

  
When writing a backup to stdout with pg_basebackup on Windows, put stdout  
to binary mode. Any CR bytes in the output will otherwise be output  
incorrectly as CR+LF.  
  
In the passing, standardize on using "_setmode" instead of "setmode", for  
the sake of consistency. They both do the same thing, but according to  
MSDN documentation, setmode is deprecated.  
  
Fixes bug #14634, reported by Henry Boehlert. Patch by Haribabu Kommi.  
Backpatch to all supported versions.  
  
Discussion: https://www.postgresql.org/message-id/20170428082818.24366.13134@wrigleys.postgresql.org  
  

Fix dumping of FUNCTION RTEs that contain non-function-call expressions.

  
commit   : a3ca72ae9ac14acb2b1b9cd207ac0c8a01f1439a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 13 Jul 2017 19:24:44 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 13 Jul 2017 19:24:44 -0400    

Click here for diff

  
The grammar will only accept something syntactically similar to a function  
call in a function-in-FROM expression.  However, there are various ways  
to input something that ruleutils.c won't deparse that way, potentially  
leading to a view or rule that fails dump/reload.  Fix by inserting a  
dummy CAST around anything that isn't going to deparse as a function  
(which is one of the ways to get something like that in there in the  
first place).  
  
In HEAD, also make use of the infrastructure added by this to avoid  
emitting unnecessary parentheses in CREATE INDEX deparsing.  I did  
not change that in back branches, thinking that people might find it  
to be unexpected/unnecessary behavioral change.  
  
In HEAD, also fix incorrect logic for when to add extra parens to  
partition key expressions.  Somebody apparently thought they could  
get away with simpler logic than pg_get_indexdef_worker has, but  
they were wrong --- a counterexample is PARTITION BY LIST ((a[1])).  
Ignoring the prettyprint flag for partition expressions isn't exactly  
a nice solution anyway.  
  
This has been broken all along, so back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/10477.1499970459@sss.pgh.pa.us  
  

Fix typo in v10 release notes

  
commit   : 2036f71b751152e443beecfdd8bffbb4e17447c2    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 13 Jul 2017 18:14:01 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 13 Jul 2017 18:14:01 -0400    

Click here for diff

  
The new functions return a list of files in the corresponding directory,  
not the name of the directory itself.  
  
Pointed out by Gianni Ciolli.  
  

Fix race between GetNewTransactionId and GetOldestActiveTransactionId.

  
commit   : 74fc83869e169470e91363546d945002e71e54ab    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 13 Jul 2017 15:47:02 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 13 Jul 2017 15:47:02 +0300    

Click here for diff

  
The race condition goes like this:  
  
1. GetNewTransactionId advances nextXid e.g. from 100 to 101  
2. GetOldestActiveTransactionId reads the new nextXid, 101  
3. GetOldestActiveTransactionId loops through the proc array. There are no  
   active XIDs there, so it returns 101 as the oldest active XID.  
4. GetNewTransactionid stores XID 100 to MyPgXact->xid  
  
So, GetOldestActiveTransactionId returned XID 101, even though 100 only  
just started and is surely still running.  
  
This would be hard to hit in practice, and even harder to spot any ill  
effect if it happens. GetOldestActiveTransactionId is only used when  
creating a checkpoint in a master server, and the race condition can only  
happen on an online checkpoint, as there are no backends running during a  
shutdown checkpoint. The oldestActiveXid value of an online checkpoint is  
only used when starting up a hot standby server, to determine the starting  
point where pg_subtrans is initialized from. For the race condition to  
happen, there must be no other XIDs in the proc array that would hold back  
the oldest-active XID value, which means that the missed XID must be a top  
transaction's XID. However, pg_subtrans is not used for top XIDs, so I  
believe an off-by-one error is in fact inconsequential. Nevertheless, let's  
fix it, as it's clearly wrong and the fix is simple.  
  
This has been wrong ever since hot standby was introduced, so backport to  
all supported versions.  
  
Discussion: https://www.postgresql.org/message-id/e7258662-82b6-7a45-56d4-99b337a32bf7@iki.fi  
  

Fix ruleutils.c for domain-over-array cases, too.

  
commit   : bc2d716ad09fceeb391c755f78c256ddac9d3b9f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 12 Jul 2017 18:00:04 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 12 Jul 2017 18:00:04 -0400    

Click here for diff

  
Further investigation shows that ruleutils isn't quite up to speed either  
for cases where we have a domain-over-array: it needs to be prepared to  
look past a CoerceToDomain at the top level of field and element  
assignments, else it decompiles them incorrectly.  Potentially this would  
result in failure to dump/reload a rule, if it looked like the one in the  
new test case.  (I also added a test for EXPLAIN; that output isn't broken,  
but clearly we need more test coverage here.)  
  
Like commit b1cb32fb6, this bug is reachable in cases we already support,  
so back-patch all the way.  
  

Reduce memory usage of tsvector type analyze function.

  
commit   : da11977de9c685ef808d3a293727f9ce26753ec4    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 12 Jul 2017 22:03:38 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 12 Jul 2017 22:03:38 +0300    

Click here for diff

  
compute_tsvector_stats() detoasted and kept in memory every tsvector value  
in the sample, but that can be a lot of memory. The original bug report  
described a case using over 10 gigabytes, with statistics target of 10000  
(the maximum).  
  
To fix, allocate a separate copy of just the lexemes that we keep around,  
and free the detoasted tsvector values as we go. This adds some palloc/pfree  
overhead, when you have a lot of distinct lexemes in the sample, but it's  
better than running out of memory.  
  
Fixes bug #14654 reported by James C. Reviewed by Tom Lane. Backport to  
all supported versions.  
  
Discussion: https://www.postgresql.org/message-id/20170514200602.1451.46797@wrigleys.postgresql.org  
  

commit_ts test: Set node name in test

  
commit   : ca793c59a51e94cedf8cbea5c29668bf8fa298f3    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 12 Jul 2017 14:39:44 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 12 Jul 2017 14:39:44 -0400    

Click here for diff

  
Otherwise, the script output has a lot of pointless warnings.  
  
This was forgotten in 9def031bd2821f35b5f506260d922482648a8bb0  
  

Avoid integer overflow while sifting-up a heap in tuplesort.c.

  
commit   : 512f67c8d02cc558f9c269cc848b0f0f788c4fe1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 12 Jul 2017 13:24:16 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 12 Jul 2017 13:24:16 -0400    

Click here for diff

  
If the number of tuples in the heap exceeds approximately INT_MAX/2,  
this loop's calculation "2*i+1" could overflow, resulting in a crash.  
Fix it by using unsigned int rather than int for the relevant local  
variables; that shouldn't cost anything extra on any popular hardware.  
Per bug #14722 from Sergey Koposov.  
  
Original patch by Sergey Koposov, modified by me per a suggestion  
from Heikki Linnakangas to use unsigned int not int64.  
  
Back-patch to 9.4, where tuplesort.c grew the ability to sort as many  
as INT_MAX tuples in-memory (commit 263865a48).  
  
Discussion: https://postgr.es/m/20170629161637.1478.93109@wrigleys.postgresql.org  
  

Fix variable and type name in comment.

  
commit   : ca906f68f22bf2076349394a5f28caf1f6e6f2f7    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 12 Jul 2017 17:07:35 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 12 Jul 2017 17:07:35 +0300    

Click here for diff

  
Kyotaro Horiguchi  
  
Discussion: https://www.postgresql.org/message-id/20170711.163441.241981736.horiguchi.kyotaro@lab.ntt.co.jp  
  

Fix ordering of operations in SyncRepWakeQueue to avoid assertion failure.

  
commit   : 49a3360209ba07d385f1a9e619854bbbe1b7005f    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 12 Jul 2017 15:30:52 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 12 Jul 2017 15:30:52 +0300    

Click here for diff

  
Commit 14e8803f1 removed the locking in SyncRepWaitForLSN, but that  
introduced a race condition, where SyncRepWaitForLSN might see  
syncRepState already set to SYNC_REP_WAIT_COMPLETE, but the process was  
not yet removed from the queue. That tripped the assertion, that the  
process should no longer be in the uqeue. Reorder the operations in  
SyncRepWakeQueue to remove the process from the queue first, and update  
syncRepState only after that, and add a memory barrier in between to make  
sure the operations are made visible to other processes in that order.  
  
Fixes bug #14721 reported by Const Zhang. Analysis and fix by Thomas Munro.  
Backpatch down to 9.5, where the locking was removed.  
  
Discussion: https://www.postgresql.org/message-id/20170629023623.1480.26508%40wrigleys.postgresql.org  
  

Remove unnecessary braces, to match the surrounding style.

  
commit   : 09ed6c7e6765ac4638d1aad2d0babaeaecda5594    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 12 Jul 2017 12:30:50 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 12 Jul 2017 12:30:50 +0300    

Click here for diff

  
Mostly in the new subscription-related commands. Backport the few that  
were also present in older versions.  
  
Thomas Munro  
  
Discussion: https://www.postgresql.org/message-id/CAEepm=3CyW1QmXcXJXmqiJXtXzFDc8SvSfnxkEGD3Bkv2SrkeQ@mail.gmail.com  
  

Fix multiple assignments to a column of a domain type.

  
commit   : b1cb32fb62c9951c9ba35cb774fb8beec9090cb7    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 11 Jul 2017 16:48:59 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 11 Jul 2017 16:48:59 -0400    

Click here for diff

  
We allow INSERT and UPDATE commands to assign to the same column more than  
once, as long as the assignments are to subfields or elements rather than  
the whole column.  However, this failed when the target column was a domain  
over array rather than plain array.  Fix by teaching process_matched_tle()  
to look through CoerceToDomain nodes, and add relevant test cases.  
  
Also add a group of test cases exercising domains over array of composite.  
It's doubtless accidental that CREATE DOMAIN allows this case while not  
allowing straight domain over composite; but it does, so we'd better make  
sure we don't break it.  (I could not find any documentation mentioning  
either side of that, so no doc changes.)  
  
It's been like this for a long time, so back-patch to all supported  
branches.  
  
Discussion: https://postgr.es/m/4206.1499798337@sss.pgh.pa.us  
  

Stamp 10beta2.

  
commit   : 42171e2cd23c8307bbe0ec64e901f58e297db1c3    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Jul 2017 16:26:20 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Jul 2017 16:26:20 -0400    

Click here for diff

  
  

Translation updates

  
commit   : 6c774caf0ea6977f00af4225192915f0a602ea3d    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 10 Jul 2017 11:51:32 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 10 Jul 2017 11:51:32 -0400    

Click here for diff

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

On Windows, retry process creation if we fail to reserve shared memory.

  
commit   : 45e004fb4e3937dbdabf6d5c1706f1a02fdceb94    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Jul 2017 11:00:09 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Jul 2017 11:00:09 -0400    

Click here for diff

  
We've heard occasional reports of backend launch failing because  
pgwin32_ReserveSharedMemoryRegion() fails, indicating that something  
has already used that address space in the child process.  It's not  
very clear what, given that we disable ASLR in Windows builds, but  
suspicion falls on antivirus products.  It'd be better if we didn't  
have to disable ASLR, anyway.  So let's try to ameliorate the problem  
by retrying the process launch after such a failure, up to 100 times.  
  
Patch by me, based on previous work by Amit Kapila and others.  
This is a longstanding issue, so back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/CAA4eK1+R6hSx6t_yvwtx+NRzneVp+MRqXAdGJZChcau8Uij-8g@mail.gmail.com  
  

Fix missing tag in the docs.

  
commit   : d137a6dc239bd32b424826acbb25277ac611ddb1    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 10 Jul 2017 15:36:02 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 10 Jul 2017 15:36:02 +0300    

Click here for diff

  
Masahiko Sawada  
  
Discussion: https://www.postgresql.org/message-id/CAD21AoBCwcTNMdrVWq8T0hoOs2mWSYq9PRJ_fr6SH8HdO+m=0g@mail.gmail.com  
  

Fix check for empty hostname.

  
commit   : 4d06f1f858d0fea01a2cde74d8b831a823776355    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 10 Jul 2017 15:29:36 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 10 Jul 2017 15:29:36 +0300    

Click here for diff

  
As reported by Arthur Zakirov, Gcc 7.1 complained about this with  
-Wpointer-compare.  
  
Discussion: https://www.postgresql.org/message-id/CAKNkYnybV_NFVacGbW=VspzAo3TwRJFNi+9iBob66YqQMZopwg@mail.gmail.com  
  

Fix COPY’s handling of transition tables with indexes.

  
commit   : 1add0b15f117769f619af12720bea2f73d4f7359    
  
author   : Andrew Gierth <rhodiumtoad@postgresql.org>    
date     : Mon, 10 Jul 2017 11:40:08 +0100    
  
committer: Andrew Gierth <rhodiumtoad@postgresql.org>    
date     : Mon, 10 Jul 2017 11:40:08 +0100    

Click here for diff

  
Commit c46c0e5202e8cfe750c6629db7852fdb15d528f3 failed to pass the  
TransitionCaptureState object to ExecARInsertTriggers() in the case  
where it's using heap_multi_insert and there are indexes.  Repair.  
  
Thomas Munro, from a report by David Fetter  
Discussion: https://postgr.es/m/20170708084213.GA14720%40fetter.org  
  

Allow multiple hostaddrs to go with multiple hostnames.

  
commit   : 7b02ba62e9ffad5b14c24756a0c2aeae839c9d05    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 10 Jul 2017 12:28:57 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 10 Jul 2017 12:28:57 +0300    

Click here for diff

  
Also fix two other issues, while we're at it:  
  
* In error message on connection failure, if multiple network addresses  
were given as the host option, as in "host=127.0.0.1,127.0.0.2", the  
error message printed the address twice.  
  
* If there were many more ports than hostnames, the error message would  
always claim that there was one port too many, even if there was more than  
one. For example, if you gave 2 hostnames and 5 ports, the error message  
claimed that you gave 2 hostnames and 3 ports.  
  
Discussion: https://www.postgresql.org/message-id/10badbc6-4d5a-a769-623a-f7ada43e14dd@iki.fi  
  

Doc: remove claim that PROVE_FLAGS defaults to ‘–verbose’.

  
commit   : 260ba8525a6365cfb3251d619767cc6ae19ddff8    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Jul 2017 00:44:05 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Jul 2017 00:44:05 -0400    

Click here for diff

  
Commit e9c81b601 changed this, but missed updating the documentation.  
The adjacent claim that we use TAP tests only in src/bin seems pretty  
obsolete as well.  Minor other copy-editing.  
  

Doc: clarify wording about tool requirements in sourcerepo.sgml.

  
commit   : 3834abe90c7359319d1909fdb69a40963276a690    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Jul 2017 00:08:19 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Jul 2017 00:08:19 -0400    

Click here for diff

  
Original wording had confusingly vague antecedent for "they", so replace  
that with a more repetitive but clearer formulation.  In passing, make the  
link to the installation requirements section more specific.  Per gripe  
from Martin Mai, though this is not the fix he initially proposed.  
  
Discussion: https://postgr.es/m/CAN_NWRu-cWuNaiXUjV3m4H-riWURuPW=j21bSaLADs6rjjzXgQ@mail.gmail.com  
  

Doc: desultory copy-editing for v10 release notes.

  
commit   : 749eceff4a1f9740391b126c81af9fd4bf3b1eaa    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 9 Jul 2017 20:11:21 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 9 Jul 2017 20:11:21 -0400    

Click here for diff

  
Improve many item descriptions, improve markup, relocate some items  
that seemed to be in the wrong section.  
  

Doc: update v10 release notes through today.

  
commit   : fad7873c8c9fae04accbdd3b7c226f451e9ab3b9    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 9 Jul 2017 15:27:21 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 9 Jul 2017 15:27:21 -0400    

Click here for diff

  
  

Doc: fix backwards description of visibility map’s all-frozen data.

  
commit   : 485c515d0176d3210b5405ef23be8ed32cf5c93a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 9 Jul 2017 12:51:15 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 9 Jul 2017 12:51:15 -0400    

Click here for diff

  
Thinko in commit a892234f8.  
  
Vik Fearing  
  
Discussion: https://postgr.es/m/b6aaa23d-e26f-6404-a30d-e89431492d5d@2ndquadrant.com  
  

MSVC: Repair libpq.rc generator.

  
commit   : 3381898f983b9d41c20b50bb1b39c173aa0129e3    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sun, 9 Jul 2017 00:43:17 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sun, 9 Jul 2017 00:43:17 -0700    

Click here for diff

  
It generates an empty file, so libpq.dll advertises no version  
information.  Commit facde2a98f0b5f7689b4e30a9e7376e926e733b8  
mistranslated "print O;" in this one place.  
  

Avoid unreferenced-function warning on low-functionality platforms.

  
commit   : ec4073f64130b40fabaa1b38ad402babda3a48eb    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 8 Jul 2017 12:42:25 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 8 Jul 2017 12:42:25 -0400    

Click here for diff

  
On platforms lacking both locale_t and ICU, collationcmds.c failed  
to make any use of its static function is_all_ascii(), thus probably  
drawing a compiler warning.  Oversight in my commit ddb5fdc06.  
Per buildfarm member gaur.  
  

Fix typo

  
commit   : 46e91519425c5e98380c672d1b5c3acf18c5e565    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 7 Jul 2017 17:10:36 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 7 Jul 2017 17:10:36 -0400    

Click here for diff

  
Noticed while reviewing code.  
  

Fix out of date comment

  
commit   : 4808d69955f5115686633cd3cc78b9957122e1ad    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Fri, 7 Jul 2017 15:08:55 +0300    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Fri, 7 Jul 2017 15:08:55 +0300    

Click here for diff

  
Author: Masahiko Sawada <sawada.mshk@gmail.com>  
  

Fix potential data corruption during freeze

  
commit   : 31b8db8e6c1fa4436116f4be5ca789f3a01b9ebf    
  
author   : Teodor Sigaev <teodor@sigaev.ru>    
date     : Thu, 6 Jul 2017 17:18:55 +0300    
  
committer: Teodor Sigaev <teodor@sigaev.ru>    
date     : Thu, 6 Jul 2017 17:18:55 +0300    

Click here for diff

  
Fix oversight in 3b97e6823b94 bug fix. Bitwise AND is used instead of OR and  
it cleans all bits in t_infomask heap tuple field.  
  
Backpatch to 9.3  
  

Clarify the contract of partition_rbound_cmp().

  
commit   : f1dae097f2945ffcb59a9f236843e0e0bbf0920d    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Thu, 6 Jul 2017 12:46:08 +0100    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Thu, 6 Jul 2017 12:46:08 +0100    

Click here for diff

  
partition_rbound_cmp() is intended to compare range partition bounds  
in a way such that if all the bound values are equal but one is an  
upper bound and one is a lower bound, the upper bound is treated as  
smaller than the lower bound. This particular ordering is required by  
RelationBuildPartitionDesc() when building the PartitionBoundInfoData,  
so that it can consistently keep only the upper bounds when upper and  
lower bounds coincide.  
  
Update the function comment to make that clearer.  
  
Also, fix a (currently unreachable) corner-case bug -- if the bound  
values coincide and they contain unbounded values, fall through to the  
lower-vs-upper comparison code, rather than immediately returning  
0. Currently it is not possible to define coincident upper and lower  
bounds containing unbounded columns, but that may change in the  
future, so code defensively.  
  
Discussion: https://postgr.es/m/CAAJ_b947mowpLdxL3jo3YLKngRjrq9+Ej4ymduQTfYR+8=YAYQ@mail.gmail.com  
  

Simplify the logic checking new range partition bounds.

  
commit   : c03911d9454a0cf5d88910ad46b433ab342c39e0    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Thu, 6 Jul 2017 09:58:06 +0100    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Thu, 6 Jul 2017 09:58:06 +0100    

Click here for diff

  
The previous logic, whilst not actually wrong, was overly complex and  
involved doing two binary searches, where only one was really  
necessary. This simplifies that logic and improves the comments.  
  
One visible change is that if the new partition overlaps multiple  
existing partitions, the error message now always reports the overlap  
with the first existing partition (the one with the lowest  
bounds). The old code would sometimes report the clash with the first  
partition and sometimes with the last one.  
  
Original patch idea from Amit Langote, substantially rewritten by me.  
  
Discussion: https://postgr.es/m/CAAJ_b947mowpLdxL3jo3YLKngRjrq9+Ej4ymduQTfYR+8=YAYQ@mail.gmail.com  
  

Fix another race-condition-ish issue in recovery/t/001_stream_rep.pl.

  
commit   : ec86af917551f52246848dd148885df034273f3d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 5 Jul 2017 23:59:20 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 5 Jul 2017 23:59:20 -0400    

Click here for diff

  
Buildfarm members hornet and sungazer have shown multiple instances of  
"Failed test 'xmin of non-cascaded slot with hs feedback has changed'".  
The reason seems to be that the test is checking the current xmin of the  
master server's replication slot against a past xmin of the first slave  
server's replication slot.  Even though the latter slot is downstream of  
the former, it's possible for its reported xmin to be ahead of the former's  
reported xmin, because those numbers are updated whenever the respective  
downstream walreceiver feels like it (see logic in WalReceiverMain).  
Instrumenting this test shows that indeed the slave slot's xmin does often  
advance before the master's does, especially if an autovacuum transaction  
manages to occur during the relevant window.  If we happen to capture such  
an advanced xmin as $xmin, then the subsequent wait_slot_xmins call can  
fall through before the master's xmin has advanced at all, and then if it  
advances before the get_slot_xmins call, we can get the observed failure.  
Yeah, that's a bit of a long chain of deduction, but it's hard to explain  
any other way how the test can get past an "xmin <> '$xmin'" check only  
to have the next query find that xmin does equal $xmin.  
  
Fix by keeping separate images of the master and slave slots' xmins  
and testing their has-xmin-advanced conditions independently.  
  

Restore linking libpq into pg_ctl on Mingw builds.

  
commit   : ff68e909acd924b532e58c7699e93a1aff71654a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 5 Jul 2017 15:23:22 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 5 Jul 2017 15:23:22 -0400    

Click here for diff

  
Commit 1ae853654 missed this.  Per Andrew Dunstan.  
  

Remove unnecessary pg_is_in_recovery calls in tests

  
commit   : 6deb52b202e0f673b583b03ad141ccad6f8e7fba    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 1 May 2017 12:11:25 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 1 May 2017 12:11:25 -0400    

Click here for diff

  
Since pg_ctl promote already waits for recovery to end, these calls are  
obsolete.  
  

pg_ctl: Make failure to complete operation a nonzero exit

  
commit   : 1bac5f552a25aca3aa2ef1d404f7cdf7788c34d8    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 1 May 2017 12:10:17 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 1 May 2017 12:10:17 -0400    

Click here for diff

  
If an operation being waited for does not complete within the timeout,  
then exit with a nonzero exit status.  This was previously handled  
inconsistently.  
  

Fix output of char node fields

  
commit   : d80e73f2293429cf8a0a13c243852379ec2e37e2    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 21 Jun 2017 22:57:23 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 21 Jun 2017 22:57:23 -0400    

Click here for diff

  
WRITE_CHAR_FIELD() didn't do any escaping, so that for example a zero  
byte would cause the whole output string to be truncated.  To fix, pass  
the char through outToken(), so it is escaped like a string.  Adjust the  
reading side to handle this.  
  

psql documentation fixes

  
commit   : 5191e357cf22e200a9baaf97bbe8a07ee2537537    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 4 Jul 2017 21:10:08 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 4 Jul 2017 21:10:08 -0400    

Click here for diff

  
Update the documentation for \pset to mention  
columns|linestyle|pager_min_lines.  Add various mentions of \pset  
command equivalences that were previously inconsistent.  
  
Author: Дилян Палаузов <dpa-postgres@aegee.org>  
  

Document how logical replication deals with statement triggers

  
commit   : 012d83f57aff973a73214262f3d87105786e3500    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 3 Jul 2017 23:37:53 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 3 Jul 2017 23:37:53 -0400    

Click here for diff

  
Reported-by: Константин Евтеев <konst583@gmail.com>  
Bug: #14699  
  

Improve subscription locking

  
commit   : cb9079cd51a2df677dc182aec72d88383b9c2a79    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 3 Jul 2017 22:47:06 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 3 Jul 2017 22:47:06 -0400    

Click here for diff

  
This avoids "tuple concurrently updated" errors when a ALTER or DROP  
SUBSCRIPTION writes to pg_subscription_rel at the same time as a worker.  
  
Author: Petr Jelinek <petr.jelinek@2ndquadrant.com>  
  

Don’t mention SSL methods that aren’t reachable in docs

  
commit   : 42794d6749f24636efbb198db17c30c63df10900    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Mon, 3 Jul 2017 16:16:35 +0100    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Mon, 3 Jul 2017 16:16:35 +0100    

Click here for diff

  
Author: Michael Paquier <michael.paquier@gmail.com>  
  

Treat clean shutdown of an SSL connection same as the non-SSL case.

  
commit   : b93827c745f346a765e7e59584127e07a37c78da    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 3 Jul 2017 14:51:51 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 3 Jul 2017 14:51:51 +0300    

Click here for diff

  
If the client closes an SSL connection, treat it the same as EOF on a  
non-SSL connection. In particular, don't write a message in the log about  
that.  
  
Michael Paquier.  
  
Discussion: https://www.postgresql.org/message-id/CAB7nPqSfyVV42Q2acFo%3DvrvF2gxoZAMJLAPq3S3KkjhZAYi7aw@mail.gmail.com  
  

Forbid gen_random_uuid() with –disable-strong-random

  
commit   : bf723a274cbb00c7fba66c66312a77940af13d79    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 3 Jul 2017 12:10:11 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 3 Jul 2017 12:10:11 +0300    

Click here for diff

  
Previously, gen_random_uuid() would fall back to a weak random number  
generator, unlike gen_random_bytes() which would just fail. And this was  
not made very clear in the docs. For consistency, also make  
gen_random_uuid() fail outright, if compiled with --disable-strong-random.  
  
Re-word the error message you get with --disable-strong-random. It is also  
used by pgp functions that require random salts, and now also  
gen_random_uuid().  
  
Reported by Radek Slupik.  
  
Discussion: https://www.postgresql.org/message-id/20170101232054.10135.50528@wrigleys.postgresql.org  
  

Fix race condition in recovery/t/009_twophase.pl test.

  
commit   : 647675228f2b18964d8ade8a1061a719e527acfb    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 2 Jul 2017 22:01:19 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 2 Jul 2017 22:01:19 -0400    

Click here for diff

  
Since reducing pg_ctl's reaction time in commit c61559ec3, some  
slower buildfarm members have shown erratic failures in this test.  
The reason turns out to be that the test assumes synchronous  
replication (because it does not provide any lag time for a commit  
to replicate before shutting down the servers), but it had only  
enabled sync rep in one direction.  The observed symptoms correspond  
to failure to replicate the last committed transaction in the other  
direction, which can be expected to happen if the shutdown command  
is issued soon enough and we are providing no synchronous-commit  
guarantees.  
  
Fix that, and add a bit more paranoid state checking at the bottom  
of the script.  
  
Michael Paquier and myself  
  
Discussion: https://postgr.es/m/908.1498965681@sss.pgh.pa.us  
  

Fix bug in PostgresNode::query_hash’s split() call.

  
commit   : efdb4f29ba9ecbddb74d3a68577f068cf034c540    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 2 Jul 2017 17:22:09 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 2 Jul 2017 17:22:09 -0400    

Click here for diff

  
By default, Perl's split() function drops trailing empty fields,  
which is not what we want here.  Oversight in commit fb093e4cb.  
We'd managed to miss it thus far thanks to the very limited usage  
of this function.  
  
Discussion: https://postgr.es/m/14837.1499029831@sss.pgh.pa.us  
  

Try to improve readability of recovery/t/009_twophase.pl test.

  
commit   : 4e15387d2d9d4045efd1a7b3634e5922774139fd    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 2 Jul 2017 15:27:29 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 2 Jul 2017 15:27:29 -0400    

Click here for diff

  
The original coding here was very confusing, because it named the  
two servers it set up "master" and "slave" even though it swapped  
their replication roles multiple times.  At any given point in the  
script it was very unobvious whether "$node_master" actually referred  
to the server named "master" or the other one.  Instead, pick arbitrary  
names for the two servers --- I used "london" and "paris" --- and  
distinguish those permanent names from the nonce references $cur_master  
and $cur_slave.  Add logging to help distinguish which is which at  
any given point.  Also, use distinct data and transaction names to  
make all the prepared transactions easily distinguishable in the  
postmaster logs.  (There was one place where we intentionally tested  
that the server could cope with re-use of a transaction name, but  
it seems like one place is sufficient for that purpose.)  
  
Also, add checks at the end to make sure that all the transactions  
that were supposed to be committed did survive.  
  
Discussion: https://postgr.es/m/28238.1499010855@sss.pgh.pa.us  
  

Improve TAP test function PostgresNode::poll_query_until().

  
commit   : de3de0afd7da7b432e219aa38bde248fc5c5206a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 2 Jul 2017 14:03:41 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 2 Jul 2017 14:03:41 -0400    

Click here for diff

  
Add an optional "expected" argument to override the default assumption  
that we're waiting for the query to return "t".  This allows replacing  
a handwritten polling loop in recovery/t/007_sync_rep.pl with use of  
poll_query_until(); AFAICS that's the only remaining ad-hoc polling  
loop in our TAP tests.  
  
Change poll_query_until() to probe ten times per second not once per  
second.  Like some similar changes I've been making recently, the  
one-second interval seems to be rooted in ancient traditions rather  
than the actual likely wait duration on modern machines.  I'd consider  
reducing it further if there were a convenient way to spawn just one  
psql for the whole loop rather than one per probe attempt.  
  
Discussion: https://postgr.es/m/12486.1498938782@sss.pgh.pa.us  
  

doc: Document that logical replication supports synchronous replication

  
commit   : 2dca03439f1f88e9102aa6bf613b434be0697dae    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Sun, 2 Jul 2017 00:10:57 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Sun, 2 Jul 2017 00:10:57 -0400    

Click here for diff

  
Update the documentation a bit to include that logical replication as  
well as other and third-party replication clients can participate in  
synchronous replication.  
  

Refine memory allocation in ICU conversions

  
commit   : d8b3c81335600ad3487ca9bd642ef354d62919dc    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Sat, 24 Jun 2017 09:39:24 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Sat, 24 Jun 2017 09:39:24 -0400    

Click here for diff

  
The simple calculations done to estimate the size of the output buffers  
for ucnv_fromUChars() and ucnv_toUChars() could overflow int32_t for  
large strings.  To avoid that, go the long way and run the function  
first without an output buffer to get the correct output buffer size  
requirement.  
  

Clean up misuse and nonuse of poll_query_until().

  
commit   : b0f069d931f0a3d4a39aeeb230baf2f2b18cb3c3    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 1 Jul 2017 14:25:09 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 1 Jul 2017 14:25:09 -0400    

Click here for diff

  
Several callers of PostgresNode::poll_query_until() neglected to check  
for failure; I do not think that's optional.  Also, rewrite one place  
that had reinvented poll_query_until() for no very good reason.  
  

Reduce delay for last logicalrep feedback message when master goes idle.

  
commit   : f32678c0163d7d966560bdaf41bfbc2cf179a260    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 1 Jul 2017 12:15:51 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 1 Jul 2017 12:15:51 -0400    

Click here for diff

  
The regression tests contain numerous cases where we do some activity on a  
master server and then wait till the slave has ack'd flushing its copy of  
that transaction.  Because WAL flush on the slave is asynchronous to the  
logicalrep worker process, the worker cannot send such a feedback message  
during the LogicalRepApplyLoop iteration where it processes the last data  
from the master.  In the previous coding, the feedback message would come  
out only when the loop's WaitLatchOrSocket call returned WL_TIMEOUT.  That  
requires one full second of delay (NAPTIME_PER_CYCLE); and to add insult  
to injury, it could take more than that if the WaitLatchOrSocket was  
interrupted a few times by latch-setting events.  
  
In reality we can expect the slave's walwriter process to have flushed the  
WAL data after, more or less, WalWriterDelay (typically 200ms).  Hence,  
if there are unacked transactions pending, make the wait delay only that  
long rather than the full NAPTIME_PER_CYCLE.  Also, move one of the  
send_feedback() calls into the loop main line, so that we'll check for the  
need to send feedback even if we were woken by a latch event and not either  
socket data or timeout.  
  
It's not clear how much this matters for production purposes, but  
it's definitely helpful for testing.  
  
Discussion: https://postgr.es/m/30864.1498861103@sss.pgh.pa.us  
  

Shorten timeouts while waiting for logicalrep worker slot attach/detach.

  
commit   : 799f8bc76a92d48b0f7988f4cc50da438cacec7c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 1 Jul 2017 11:59:44 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 1 Jul 2017 11:59:44 -0400    

Click here for diff

  
When waiting for a logical replication worker process to start or stop,  
we have to busy-wait until we see it add or remove itself from the  
LogicalRepWorker slot in shared memory.  Those loops were using a  
one-second delay between checks, but on any reasonably modern machine, it  
doesn't take more than a couple of msec for a worker to spawn or shut down.  
Reduce the loop delays to 10ms to avoid wasting quite so much time in the  
related regression tests.  
  
In principle, a better solution would be to fix things so that the waiting  
process can be awakened via its latch at the right time.  But that seems  
considerably more invasive, which is undesirable for a post-beta fix.  
Worker start/stop performance likely isn't of huge interest anyway for  
production purposes, so we might not ever get around to it.  
  
In passing, rearrange the second wait loop in logicalrep_worker_stop()  
so that the lock is held at the top of the loop, thus saving one lock  
acquisition/release per call, and making it look more like the other loop.  
  
Discussion: https://postgr.es/m/30864.1498861103@sss.pgh.pa.us  
  

Fix UPDATE of GENERATED ALWAYS identity columns

  
commit   : ef74e03ef65ea870a9c372f500d33cca0a18be6e    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 30 Jun 2017 23:44:17 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 30 Jun 2017 23:44:17 -0400    

Click here for diff

  
The bug would previously prevent the update of any column in a table  
with identity columns, rather than just the actual identity column.  
  
Reported-by: zam6ak@gmail.com  
Bug: #14718  
  

Fix locking in WAL receiver/sender shmem state structs

  
commit   : 572d6ee6d41b43b8871f42c7dbbef795523b2dbf    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 30 Jun 2017 18:06:33 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 30 Jun 2017 18:06:33 -0400    

Click here for diff

  
In WAL receiver and WAL server, some accesses to their corresponding  
shared memory control structs were done without holding any kind of  
lock, which could lead to inconsistent and possibly insecure results.  
  
In walsender, fix by clarifying the locking rules and following them  
correctly, as documented in the new comment in walsender_private.h;  
namely that some members can be read in walsender itself without a lock,  
because the only writes occur in the same process.  The rest of the  
struct requires spinlock for accesses, as usual.  
  
In walreceiver, fix by always holding spinlock while accessing the  
struct.  
  
While there is potentially a problem in all branches, it is minor in  
stable ones.  This only became a real problem in pg10 because of quorum  
commit in synchronous replication (commit 3901fd70cc7c), and a potential  
security problem in walreceiver because a superuser() check was removed  
by default monitoring roles (commit 25fff40798fc).  Thus, no backpatch.  
  
In passing, clean up some leftover braces which were used to create  
unconditional blocks.  Once upon a time these were used for  
volatile-izing accesses to those shmem structs, which is no longer  
required.  Many other occurrences of this pattern remain.  
  
Author: Michaël Paquier  
Reported-by: Michaël Paquier  
Reviewed-by: Masahiko Sawada, Kyotaro Horiguchi, Thomas Munro,  
	Robert Haas  
Discussion: https://postgr.es/m/CAB7nPqTWYqtzD=LN_oDaf9r-hAjUEPAy0B9yRkhcsLdRN8fzrw@mail.gmail.com  
  

PL/Python: Fix hint about returning composite type from Python

  
commit   : 898d24ae2ad7195869c558eb6c126ff6a90474e8    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 30 Jun 2017 16:51:14 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 30 Jun 2017 16:51:14 -0400    

Click here for diff

  
('foo') is not a Python tuple: it is a string wrapped in parentheses.  A  
valid 1-element Python tuple is ('foo',).  
  
Author: Daniele Varrazzo <daniele.varrazzo@gmail.com>  
  

Fix typo in comment

  
commit   : b295cc3b9ab48c3c34724fa577d6c1cfb753058c    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 30 Jun 2017 15:54:14 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 30 Jun 2017 15:54:14 -0400    

Click here for diff

  
Author: Masahiko Sawada <sawada.mshk@gmail.com>  
  

Fix race conditions and missed wakeups in syncrep worker signaling.

  
commit   : 1f201a818a5910a37530cc929bd345688f827942    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 30 Jun 2017 14:57:06 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 30 Jun 2017 14:57:06 -0400    

Click here for diff

  
When a sync worker is waiting for the associated apply worker to notice  
that it's in SYNCWAIT state, wait_for_worker_state_change() would just  
patiently wait for that to happen.  This generally required waiting for  
the 1-second timeout in LogicalRepApplyLoop to elapse.  Kicking the worker  
via its latch makes things significantly snappier.  
  
While at it, fix race conditions that could potentially result in crashes:  
we can *not* call logicalrep_worker_wakeup_ptr() once we've released the  
LogicalRepWorkerLock, because worker->proc might've been reset to NULL  
after we do that (indeed, there's no really solid reason to believe that  
the LogicalRepWorker slot even belongs to the same worker anymore).  
In logicalrep_worker_wakeup(), we can just move the wakeup inside the  
lock scope.  In process_syncing_tables_for_apply(), a bit more code  
rearrangement is needed.  
  
Also improve some nearby comments.  
  

Fix typo in comment

  
commit   : 1db49c3b6d2399f8f83a97f1fa34e749b9fada7c    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 30 Jun 2017 14:51:15 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 30 Jun 2017 14:51:15 -0400    

Click here for diff

  
Author: Albe Laurenz <laurenz.albe@wien.gv.at>  
  

Fix typo in comment

  
commit   : da8f26ec4eb6e3dced9e348efefac17d733008c0    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 30 Jun 2017 14:48:43 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 30 Jun 2017 14:48:43 -0400    

Click here for diff

  
Author: Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>  
  

Remove outdated comment

  
commit   : 1acc04e4045d4e863c14d144f8c2bf18b80da504    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 30 Jun 2017 14:43:05 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 30 Jun 2017 14:43:05 -0400    

Click here for diff

  
Author: Thomas Munro <thomas.munro@enterprisedb.com>  
  

Update code comments for pg_xlog -> pg_wal

  
commit   : 4260c05c6d5ffed8f61d97ec26ebadd991a97c14    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 30 Jun 2017 14:40:50 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 30 Jun 2017 14:40:50 -0400    

Click here for diff

  
Author: Michael Paquier <michael.paquier@gmail.com>  
  

Check for error during PQendcopy.

  
commit   : 609fa63db6d1e1f2c27a6dd31e9ac8d3b7bcae03    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 30 Jun 2017 12:22:33 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 30 Jun 2017 12:22:33 -0400    

Click here for diff

  
Oversight in commit 78c8c8143; noted while nosing around the  
walreceiver startup/shutdown code.  
  

Fix walsender to exit promptly if client requests shutdown.

  
commit   : fca85f8ef157d4d58dea1fdc8e1f1f957b74ee78    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 30 Jun 2017 12:00:02 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 30 Jun 2017 12:00:02 -0400    

Click here for diff

  
It's possible for WalSndWaitForWal to be asked to wait for WAL that doesn't  
exist yet.  That's fine, in fact it's the normal situation if we're caught  
up; but when the client requests shutdown we should not keep waiting.  
The previous coding could wait indefinitely if the source server was idle.  
  
In passing, improve the rather weak comments in this area, and slightly  
rearrange some related code for better readability.  
  
Back-patch to 9.4 where this code was introduced.  
  
Discussion: https://postgr.es/m/14154.1498781234@sss.pgh.pa.us  
  

Prohibit creating ICU collation with different ctype

  
commit   : 13a57710dbafad26669833add0ae6ae60314f8dc    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 30 Jun 2017 11:24:00 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 30 Jun 2017 11:24:00 -0400    

Click here for diff

  
ICU does not support "collate" and "ctype" being different, so the  
collctype catalog column is ignored.  But for catalog neatness, ensure  
that they are the same.  
  

Add missing period to comment.

  
commit   : 7d4a1838efc5a93ba96b8e0e77f39731603a1f48    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 30 Jun 2017 09:52:47 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 30 Jun 2017 09:52:47 -0400    

Click here for diff

  
Masahiko Sawada  
  
Discussion: http://postgr.es/m/CAD21AoA0jjXXhqK6Ym3jZNoUdVhXFyTkWTTTsVSr1vPuKcjsjA@mail.gmail.com  
  

Copy collencoding in CREATE COLLATION / FROM

  
commit   : 54baa48139ae6b67347bea6a9183d494e625939b    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 30 Jun 2017 08:50:39 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 30 Jun 2017 08:50:39 -0400    

Click here for diff

  
This command used to compute the collencoding entry like when a  
completely new collation is created.  But for example when copying the  
"C" collation, this would then result in a collation that has a  
collencoding entry for the current database encoding rather than -1,  
thus not making an exact copy.  This has probably no practical impact,  
but making this change keeps the catalog contents neat.  
  
Reported-by: Tom Lane <tgl@sss.pgh.pa.us>  
  

Eat XIDs more efficiently in recovery TAP test.

  
commit   : 08aed6604de2e6a9f4d499818d7c641cbf5eb9f7    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 28 Jun 2017 22:11:12 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 28 Jun 2017 22:11:12 -0400    

Click here for diff

  
The point of this loop is to insert 1000 rows into the test table  
and consume 1000 XIDs.  I can't see any good reason why it's useful  
to launch 1000 psqls and 1000 backend processes to accomplish that.  
Pushing the looping into a plpgsql DO block shaves about 10 seconds  
off the runtime of the src/test/recovery TAP tests on my machine;  
that's over 10% of the runtime of that test suite.  
  
It is, in fact, sufficiently more efficient that we now demonstrably  
need wait_slot_xmins() afterwards, or the slaves' xmins may not have  
moved yet.  
  

Ooops, WIN32 code in pg_ctl.c still needs PQExpBuffer.

  
commit   : 1ae8536545b7ea486dbe15247e6dd817ee211297    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 28 Jun 2017 18:00:16 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 28 Jun 2017 18:00:16 -0400    

Click here for diff

  
Per buildfarm.  
  

Change pg_ctl to detect server-ready by watching status in postmaster.pid.

  
commit   : f13ea95f9e473a43ee4e1baeb94daaf83535d37c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 28 Jun 2017 17:31:24 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 28 Jun 2017 17:31:24 -0400    

Click here for diff

  
Traditionally, "pg_ctl start -w" has waited for the server to become  
ready to accept connections by attempting a connection once per second.  
That has the major problem that connection issues (for instance, a  
kernel packet filter blocking traffic) can't be reliably told apart  
from server startup issues, and the minor problem that if server startup  
isn't quick, we accumulate "the database system is starting up" spam  
in the server log.  We've hacked around many of the possible connection  
issues, but it resulted in ugly and complicated code in pg_ctl.c.  
  
In commit c61559ec3, I changed the probe rate to every tenth of a second.  
That prompted Jeff Janes to complain that the log-spam problem had become  
much worse.  In the ensuing discussion, Andres Freund pointed out that  
we could dispense with connection attempts altogether if the postmaster  
were changed to report its status in postmaster.pid, which "pg_ctl start"  
already relies on being able to read.  This patch implements that, teaching  
postmaster.c to report a status string into the pidfile at the same  
state-change points already identified as being of interest for systemd  
status reporting (cf commit 7d17e683f).  pg_ctl no longer needs to link  
with libpq at all; all its functions now depend on reading server files.  
  
In support of this, teach AddToDataDirLockFile() to allow addition of  
postmaster.pid lines in not-necessarily-sequential order.  This is needed  
on Windows where the SHMEM_KEY line will never be written at all.  We still  
have the restriction that we don't want to truncate the pidfile; document  
the reasons for that a bit better.  
  
Also, fix the pg_ctl TAP tests so they'll notice if "start -w" mode  
is broken --- before, they'd just wait out the sixty seconds until  
the loop gives up, and then report success anyway.  (Yes, I found that  
out the hard way.)  
  
While at it, arrange for pg_ctl to not need to #include miscadmin.h;  
as a rather low-level backend header, requiring that to be compilable  
client-side is pretty dubious.  This requires moving the #define's  
associated with the pidfile into a new header file, and moving  
PG_BACKEND_VERSIONSTR someplace else.  For lack of a clearly better  
"someplace else", I put it into port.h, beside the declaration of  
find_other_exec(), since most users of that macro are passing the value to  
find_other_exec().  (initdb still depends on miscadmin.h, but at least  
pg_ctl and pg_upgrade no longer do.)  
  
In passing, fix main.c so that PG_BACKEND_VERSIONSTR actually defines the  
output of "postgres -V", which remarkably it had never done before.  
  
Discussion: https://postgr.es/m/CAMkU=1xJW8e+CTotojOMBd-yzUvD0e_JZu2xHo=MnuZ4__m7Pg@mail.gmail.com  
  

Fix transition tables for ON CONFLICT.

  
commit   : 8c55244ae379822d8bf62f6db0b5b1f7637eea3a    
  
author   : Andrew Gierth <rhodiumtoad@postgresql.org>    
date     : Wed, 28 Jun 2017 19:00:55 +0100    
  
committer: Andrew Gierth <rhodiumtoad@postgresql.org>    
date     : Wed, 28 Jun 2017 19:00:55 +0100    

Click here for diff

  
We now disallow having triggers with both transition tables and ON  
INSERT OR UPDATE (which was a PG extension to the spec anyway),  
because in this case it's not at all clear how the transition tables  
should work for an INSERT ... ON CONFLICT query.  Separate ON INSERT  
and ON UPDATE triggers with transition tables are allowed, and the  
transition tables for these reflect only the inserted and only the  
updated tuples respectively.  
  
Patch by Thomas Munro  
  
Discussion: https://postgr.es/m/CAEepm%3D11KHQ0JmETJQihSvhZB5mUZL2xrqHeXbCeLhDiqQ39%3Dw%40mail.gmail.com  
  

Fix transition tables for wCTEs.

  
commit   : c46c0e5202e8cfe750c6629db7852fdb15d528f3    
  
author   : Andrew Gierth <rhodiumtoad@postgresql.org>    
date     : Wed, 28 Jun 2017 18:59:01 +0100    
  
committer: Andrew Gierth <rhodiumtoad@postgresql.org>    
date     : Wed, 28 Jun 2017 18:59:01 +0100    

Click here for diff

  
The original coding didn't handle this case properly; each separate  
DML substatement needs its own set of transitions.  
  
Patch by Thomas Munro  
  
Discussion: https://postgr.es/m/CAL9smLCDQ%3D2o024rBgtD4WihzX8B3C6u_oSQ2K3%2BR5grJrV0bg%40mail.gmail.com  
  

Fix transition tables for partition/inheritance.

  
commit   : 501ed02cf6f4f60c3357775eb07578aebc912d3a    
  
author   : Andrew Gierth <rhodiumtoad@postgresql.org>    
date     : Wed, 28 Jun 2017 18:55:03 +0100    
  
committer: Andrew Gierth <rhodiumtoad@postgresql.org>    
date     : Wed, 28 Jun 2017 18:55:03 +0100    

Click here for diff

  
We disallow row-level triggers with transition tables on child tables.  
Transition tables for triggers on the parent table contain only those  
columns present in the parent.  (We can't mix tuple formats in a  
single transition table.)  
  
Patch by Thomas Munro  
  
Discussion: https://postgr.es/m/CA%2BTgmoZzTBBAsEUh4MazAN7ga%3D8SsMC-Knp-6cetts9yNZUCcg%40mail.gmail.com  
  

Second try at fixing tcp_keepalives_idle option on Solaris.

  
commit   : 99255d73c07c89b69be028a1a7b8027a78befed4    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 28 Jun 2017 12:30:16 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 28 Jun 2017 12:30:16 -0400    

Click here for diff

  
Buildfarm evidence shows that TCP_KEEPALIVE_THRESHOLD doesn't exist  
after all on Solaris < 11.  This means we need to take positive action to  
prevent the TCP_KEEPALIVE code path from being taken on that platform.  
I've chosen to limit it with "&& defined(__darwin__)", since it's unclear  
that anyone else would follow Apple's precedent of spelling the symbol  
that way.  
  
Also, follow a suggestion from Michael Paquier of eliminating code  
duplication by defining a couple of intermediate symbols for the  
socket option.  
  
In passing, make some effort to reduce the number of translatable messages  
by replacing "setsockopt(foo) failed" with "setsockopt(%s) failed", etc,  
throughout the affected files.  And update relevant documentation so  
that it doesn't claim to provide an exhaustive list of the possible  
socket option names.  
  
Like the previous commit (f0256c774), back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/20170627163757.25161.528@wrigleys.postgresql.org  
  

Do not require ‘public’ to exist for pg_dump -c

  
commit   : 4500edc7e9cf771bf8960d1f3f620917871bdb6f    
  
author   : Stephen Frost <sfrost@snowman.net>    
date     : Wed, 28 Jun 2017 10:33:57 -0400    
  
committer: Stephen Frost <sfrost@snowman.net>    
date     : Wed, 28 Jun 2017 10:33:57 -0400    

Click here for diff

  
Commit 330b84d8c4 didn't contemplate the case where the public schema  
has been dropped and introduced a query which fails when there is no  
public schema into pg_dump (when used with -c).  
  
Adjust the query used by pg_dump to handle the case where the public  
schema doesn't exist and add tests to check that such a case no longer  
fails.  
  
Back-patch the specific fix to 9.6, as the prior commit was.  
  
Adding tests for this case involved adding support to the pg_dump  
TAP tests to work with multiple databases, which, while not a large  
change, is a bit much to back-patch, so that's only done in master.  
  
Addresses bug #14650  
Discussion: https://www.postgresql.org/message-id/20170512181801.1795.47483%40wrigleys.postgresql.org  
  

Support tcp_keepalives_idle option on Solaris.

  
commit   : f0256c774daa0dac96154e7ddf54197fb2b83f4d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 27 Jun 2017 18:47:57 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 27 Jun 2017 18:47:57 -0400    

Click here for diff

  
Turns out that the socket option for this is named TCP_KEEPALIVE_THRESHOLD,  
at least according to the tcp(7P) man page for Solaris 11.  (But since that  
text refers to "SunOS", it's likely pretty ancient.)  It appears that the  
symbol TCP_KEEPALIVE does get defined on that platform, but it doesn't  
seem to represent a valid protocol-level socket option.  This leads to  
bleats in the postmaster log, and no tcp_keepalives_idle functionality.  
  
Per bug #14720 from Andrey Lizenko, as well as an earlier report from  
Dhiraj Chawla that nobody had followed up on.  The issue's been there  
since we added the TCP_KEEPALIVE code path in commit 5acd417c8, so  
back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/20170627163757.25161.528@wrigleys.postgresql.org  
  

Re-allow SRFs and window functions within sub-selects within aggregates.

  
commit   : 9c7dc89282b3dac5685c39d4d792b02ca573c2d3    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 27 Jun 2017 17:51:11 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 27 Jun 2017 17:51:11 -0400    

Click here for diff

  
check_agg_arguments_walker threw an error upon seeing a SRF or window  
function, but that is too aggressive: if the function is within a  
sub-select then it's perfectly fine.  I broke the SRF case in commit  
0436f6bde by copying the logic for window functions ... but that was  
broken too, and had been since commit eaccfded9.  
  
Repair both cases in HEAD, and the window function case back to 9.3.  
9.2 gets this right.  
  

Reduce wal_retrieve_retry_interval in applicable TAP tests.

  
commit   : 2710ccd782d0308a3fa1ab193531183148e9b626    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 26 Jun 2017 19:01:26 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 26 Jun 2017 19:01:26 -0400    

Click here for diff

  
By default, wal_retrieve_retry_interval is five seconds, which is far  
more than is needed in any of our TAP tests, leaving the test cases  
just twiddling their thumbs for significant stretches.  Moreover,  
because it's so large, we get basically no testing of the retry-before-  
master-is-ready code path.  Hence, make PostgresNode::init set up  
wal_retrieve_retry_interval = '500ms' as part of its customization of  
test clusters' postgresql.conf.  This shaves quite a few seconds off  
the runtime of the recovery TAP tests.  
  
Back-patch into 9.6.  We have wal_retrieve_retry_interval in 9.5,  
but the test infrastructure isn't there.  
  
Discussion: https://postgr.es/m/31624.1498500416@sss.pgh.pa.us  
  

Don’t lose walreceiver start requests due to race condition in postmaster.

  
commit   : e5d494d78cf6c60f04a5d3f571205f452a78d81f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 26 Jun 2017 17:31:56 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 26 Jun 2017 17:31:56 -0400    

Click here for diff

  
When a walreceiver dies, the startup process will notice that and send  
a PMSIGNAL_START_WALRECEIVER signal to the postmaster, asking for a new  
walreceiver to be launched.  There's a race condition, which at least  
in HEAD is very easy to hit, whereby the postmaster might see that  
signal before it processes the SIGCHLD from the walreceiver process.  
In that situation, sigusr1_handler() just dropped the start request  
on the floor, reasoning that it must be redundant.  Eventually, after  
10 seconds (WALRCV_STARTUP_TIMEOUT), the startup process would make a  
fresh request --- but that's a long time if the connection could have  
been re-established almost immediately.  
  
Fix it by setting a state flag inside the postmaster that we won't  
clear until we do launch a walreceiver.  In cases where that results  
in an extra walreceiver launch, it's up to the walreceiver to realize  
it's unwanted and go away --- but we have, and need, that logic anyway  
for the opposite race case.  
  
I came across this through investigating unexpected delays in the  
src/test/recovery TAP tests: it manifests there in test cases where  
a master server is stopped and restarted while leaving streaming  
slaves active.  
  
This logic has been broken all along, so back-patch to all supported  
branches.  
  
Discussion: https://postgr.es/m/21344.1498494720@sss.pgh.pa.us  
  

Ignore old stats file timestamps when starting the stats collector.

  
commit   : ad1b5c842ba28aab0f487e77f8cac46a30b3b63e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 26 Jun 2017 16:17:05 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 26 Jun 2017 16:17:05 -0400    

Click here for diff

  
The stats collector disregards inquiry messages that bear a cutoff_time  
before when it last wrote the relevant stats file.  That's fine, but at  
startup when it reads the "permanent" stats files, it absorbed their  
timestamps as if they were the times at which the corresponding temporary  
stats files had been written.  In reality, of course, there's no data  
out there at all.  This led to disregarding inquiry messages soon after  
startup if the postmaster had been shut down and restarted within less  
than PGSTAT_STAT_INTERVAL; which is a pretty common scenario, both for  
testing and in the field.  Requesting backends would hang for 10 seconds  
and then report failure to read statistics, unless they got bailed out  
by some other backend coming along and making a newer request within  
that interval.  
  
I came across this through investigating unexpected delays in the  
src/test/recovery TAP tests: it manifests there because the autovacuum  
launcher hangs for 10 seconds when it can't get statistics at startup,  
thus preventing a second shutdown from occurring promptly.  We might  
want to do some things in the autovac code to make it less prone to  
getting stuck that way, but this change is a good bug fix regardless.  
  
In passing, also fix pgstat_read_statsfiles() to ensure that it  
re-zeroes its global stats variables if they are corrupted by a  
short read from the stats file.  (Other reads in that function  
go into temp variables, so that the issue doesn't arise.)  
  
This has been broken since we created the separation between permanent  
and temporary stats files in 8.4, so back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/16860.1498442626@sss.pgh.pa.us  
  

Reduce pg_ctl’s reaction time when waiting for postmaster start/stop.

  
commit   : c61559ec3a41ad72a13c18d95b1eee8251de94c6    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 26 Jun 2017 15:13:23 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 26 Jun 2017 15:13:23 -0400    

Click here for diff

  
pg_ctl has traditionally waited one second between probes for whether  
the start or stop request has completed.  That behavior was embodied  
in the original shell script written in 1999 (commit 5b912b089) and  
I doubt anyone's questioned it since.  Nowadays, machines are a lot  
faster, and the shell script is long since replaced by C code, so it's  
fair to reconsider how long we ought to wait.  
  
This patch adjusts the coding so that the wait time can be any even  
divisor of 1 second, and sets the actual probe rate to 10 per second.  
That's based on experimentation with the src/test/recovery TAP tests,  
which include a lot of postmaster starts and stops.  This patch alone  
reduces the (non-parallelized) runtime of those tests from ~4m30s to  
~3m5s on my machine.  Increasing the probe rate further doesn't help  
much, so this seems like a good number.  
  
In the real world this probably won't have much impact, since people  
don't start/stop production postmasters often, and the shutdown checkpoint  
usually takes nontrivial time too.  But it makes development work and  
testing noticeably snappier, and that's good enough reason for me.  
  
Also, by reducing the dead time in postmaster restart sequences, this  
change has made it easier to reproduce some bugs that have been lurking  
for awhile.  Patches for those will follow.  
  
Discussion: https://postgr.es/m/18444.1498428798@sss.pgh.pa.us  
  

Improve wait logic in TAP tests for streaming replication.

  
commit   : 5c77690f6f419c504b7d8248db30c2280217e72e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 26 Jun 2017 14:39:55 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 26 Jun 2017 14:39:55 -0400    

Click here for diff

  
Remove hard-wired sleep(2) delays in 001_stream_rep.pl in favor of using  
poll_query_until to check for the desired state to appear.  In addition,  
add such a wait before the last test in the script, as it's possible  
to demonstrate failures there after upcoming improvements in pg_ctl.  
  
(We might end up adding polling before each of the get_slot_xmins calls in  
this script, but I feel no great need to do that until shown necessary.)  
  
In passing, clarify the description strings for some of the test cases.  
  
Michael Paquier and Craig Ringer, pursuant to a complaint from me  
  
Discussion: https://postgr.es/m/8962.1498425057@sss.pgh.pa.us  
  

Avoid useless “x = ANY(ARRAY[])” test for empty partition list.

  
commit   : 5efccc1cb43005a832776ed9158d2704fd976f8f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 26 Jun 2017 10:43:20 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 26 Jun 2017 10:43:20 -0400    

Click here for diff

  
This arises in practice if the partition only admits NULL values.  
  
Jeevan Ladhe  
  
Discussion: https://postgr.es/m/CAOgcT0OChrN--uuqH6wG6Z8+nxnCWJ+2Q-uhnK4KOANdRRxuAw@mail.gmail.com  
  

Minor code review for parse_phrase_operator().

  
commit   : 00c5e511b94059396150c406f5d71598034a2061    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 26 Jun 2017 10:31:10 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 26 Jun 2017 10:31:10 -0400    

Click here for diff

  
Fix its header comment, which described the old behavior of the <N>  
phrase distance operator; we missed updating that in commit 028350f61.  
Also, reset errno before strtol() call, to defend against the possibility  
that it was already ERANGE at entry.  (The lack of complaints says that  
it generally isn't, but this is at least a latent bug.)  Very minor  
stylistic improvements as well.  
  
Victor Drobny noted the obsolete comment, I noted the errno issue.  
Back-patch to 9.6 where this code was added, just in case the errno  
issue is a live bug in some cases.  
  
Discussion: https://postgr.es/m/2b5382fdff9b1f79d5eb2c99c4d2cbe2@postgrespro.ru  
  

Consistently use () for function calls in release notes

  
commit   : 59cd3987afd61191483a4cfe8f6a0abfb8c878d6    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Mon, 26 Jun 2017 15:32:21 +0200    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Mon, 26 Jun 2017 15:32:21 +0200    

Click here for diff

  
  

  
commit   : de0c60b7d3f69c75c69c6577ae44caa3aae44800    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 25 Jun 2017 12:27:04 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 25 Jun 2017 12:27:04 -0400    

Click here for diff

  
  

Further hacking on ICU collation creation and usage.

  
commit   : ddb5fdc068635d003a0d1c303cb109d1cb3ebeb1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 24 Jun 2017 13:54:15 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 24 Jun 2017 13:54:15 -0400    

Click here for diff

  
pg_import_system_collations() refused to create any ICU collations if  
the current database's encoding didn't support ICU.  This is wrongheaded:  
initdb must initialize pg_collation in an encoding-independent way  
since it might be used in other databases with different encodings.  
The reason for the restriction seems to be that get_icu_locale_comment()  
used icu_from_uchar() to convert the UChar-format display name, and that  
unsurprisingly doesn't know what to do in unsupported encodings.  
But by the same token that the initial catalog contents must be  
encoding-independent, we can't allow non-ASCII characters in the comment  
strings.  So we don't really need icu_from_uchar() here: just check for  
Unicode codes outside the ASCII range, and if there are none, the format  
conversion is trivial.  If there are some, we can simply not install the  
comment.  (In my testing, this affects only Norwegian Bokmål, which has  
given us trouble before.)  
  
For paranoia's sake, also check for non-ASCII characters in ICU locale  
names, and skip such locales, as we do for libc locales.  I don't  
currently have a reason to believe that this will ever reject anything,  
but then again the libc maintainers should have known better too.  
  
With just the import changes, ICU collations can be found in pg_collation  
in databases with unsupported encodings.  This resulted in more or less  
clean failures at runtime, but that's not how things act for unsupported  
encodings with libc collations.  Make it work the same as our traditional  
behavior for libc collations by having collation lookup take into account  
whether is_encoding_supported_by_icu().  
  
Adjust documentation to match.  Also, expand Table 23.1 to show which  
encodings are supported by ICU.  
  
catversion bump because of likely change in pg_collation/pg_description  
initial contents in ICU-enabled builds.  
  
Discussion: https://postgr.es/m/20c74bc3-d6ca-243d-1bbc-12f17fa4fe9a@gmail.com  
  

Fix typo in comment in SerializeSnapshot

  
commit   : a15b47df357d6c9ac6ebc2ce63bb24c6faddd44c    
  
author   : Simon Riggs <simon@2ndQuadrant.com>    
date     : Sat, 24 Jun 2017 13:51:26 +0100    
  
committer: Simon Riggs <simon@2ndQuadrant.com>    
date     : Sat, 24 Jun 2017 13:51:26 +0100    

Click here for diff

  
Author: Masahiko Sawada  
  

Revert 1f30295eab65eddaa88528876ab66e7095f4bb65

  
commit   : 829f12e2690c0442e156069092b05f1edc78b08a    
  
author   : Simon Riggs <simon@2ndQuadrant.com>    
date     : Sat, 24 Jun 2017 13:03:55 +0100    
  
committer: Simon Riggs <simon@2ndQuadrant.com>    
date     : Sat, 24 Jun 2017 13:03:55 +0100    

Click here for diff

  
Reported-by: Tom Lane  
  

Fix incorrect buffer-length argument to uloc_getDisplayName().

  
commit   : d1fcc622987c1a5b490b956d89f36ac9fed8f9d1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 23 Jun 2017 16:00:45 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 23 Jun 2017 16:00:45 -0400    

Click here for diff

  
The maxResultSize argument of uloc_getDisplayName is the number of  
UChars in the output buffer, not the number of bytes.  In principle  
this could result in a stack smash, although at least in my Fedora 25  
install there are no ICU locales with display names long enough to  
overrun the buffer.  But it's easily proven to be wrong by reducing  
the length of displayname to around 20, whereupon a stack smash  
does happen.  
  
(This is a rather scary bug, because the same mistake could easily  
have been made in other places; but in a quick code search looking  
at uses of UChar I could not find any other instances.)  
  

Fix replication with replica identity full

  
commit   : 08859bb5c2cebc132629ca838113d27bb31b990c    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 23 Jun 2017 15:12:36 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 23 Jun 2017 15:12:36 -0400    

Click here for diff

  
The comparison with the target rows on the subscriber side was done with  
datumIsEqual(), which can have false negatives.  For instance, it didn't  
work reliably for text columns.  So use the equality operator provided  
by the type cache instead.  
  
Also add more user documentation about replica identity requirements.  
  
Reported-by: Tatsuo Ishii <ishii@sraoss.co.jp>  
  

Rethink behavior of pg_import_system_collations().

  
commit   : 0b13b2a7712b6f91590b7589a314240a14520c2f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 23 Jun 2017 14:19:48 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 23 Jun 2017 14:19:48 -0400    

Click here for diff

  
Marco Atzeri reported that initdb would fail if "locale -a" reported  
the same locale name more than once.  All previous versions of Postgres  
implicitly de-duplicated the results of "locale -a", but the rewrite  
to move the collation import logic into C had lost that property.  
It had also lost the property that locale names matching built-in  
collation names were silently ignored.  
  
The simplest way to fix this is to make initdb run the function in  
if-not-exists mode, which means that there's no real use-case for  
non if-not-exists mode; we might as well just drop the boolean argument  
and simplify the function's definition to be "add any collations not  
already known".  This change also gets rid of some odd corner cases  
caused by the fact that aliases were added in if-not-exists mode even  
if the function argument said otherwise.  
  
While at it, adjust the behavior so that pg_import_system_collations()  
doesn't spew "collation foo already exists, skipping" messages during a  
re-run; that's completely unhelpful, especially since there are often  
hundreds of them.  And make it return a count of the number of collations  
it did add, which seems like it might be helpful.  
  
Also, re-integrate the previous coding's property that it would make a  
deterministic selection of which alias to use if there were conflicting  
possibilities.  This would only come into play if "locale -a" reports  
multiple equivalent locale names, say "de_DE.utf8" and "de_DE.UTF-8",  
but that hardly seems out of the question.  
  
In passing, fix incorrect behavior in pg_import_system_collations()'s  
ICU code path: it neglected CommandCounterIncrement, which would result  
in failures if ICU returns duplicate names, and it would try to create  
comments even if a new collation hadn't been created.  
  
Also, reorder operations in initdb so that the 'ucs_basic' collation  
is created before calling pg_import_system_collations() not after.  
This prevents a failure if "locale -a" were to report a locale named  
that.  There's no reason to think that that ever happens in the wild,  
but the old coding would have survived it, so let's be equally robust.  
  
Discussion: https://postgr.es/m/20c74bc3-d6ca-243d-1bbc-12f17fa4fe9a@gmail.com  
  

Improve replication lag interpolation after idle period

  
commit   : 9ea3c64124af039219aa5030d7af675dce5daa60    
  
author   : Simon Riggs <simon@2ndQuadrant.com>    
date     : Fri, 23 Jun 2017 18:58:46 +0100    
  
committer: Simon Riggs <simon@2ndQuadrant.com>    
date     : Fri, 23 Jun 2017 18:58:46 +0100    

Click here for diff

  
After sitting idle and fully replayed for a while and then encountering  
a new burst of WAL activity, we interpolate between an ancient sample and the  
not-yet-reached one for the new traffic. That produced a corner case report  
of lag after receiving first new reply from standby, which might sometimes  
be a large spike.  
  
Correct this by resetting last_read time and handle that new case.  
  
Author: Thomas Munro  
  

Minor corrections to high availability docs

  
commit   : a79122b06194927d2b79465f335b94f2b4472816    
  
author   : Simon Riggs <simon@2ndQuadrant.com>    
date     : Fri, 23 Jun 2017 18:16:00 +0100    
  
committer: Simon Riggs <simon@2ndQuadrant.com>    
date     : Fri, 23 Jun 2017 18:16:00 +0100    

Click here for diff

  
Startup process is displayed in pg_stat_activity, noted by Yugo Nagata.  
Transactions can be resolved at end of recovery.  
  
Author: Yugo Nagata, with addition by me  
  

Fix memory leakage in ICU encoding conversion, and other code review.

  
commit   : b6159202c99d4021fb078cede90b26f94883143d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 23 Jun 2017 12:22:06 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 23 Jun 2017 12:22:06 -0400    

Click here for diff

  
Callers of icu_to_uchar() neglected to pfree the result string when done  
with it.  This results in catastrophic memory leaks in varstr_cmp(),  
because of our prevailing assumption that btree comparison functions don't  
leak memory.  For safety, make all the call sites clean up leaks, though  
I suspect that we could get away without it in formatting.c.  I audited  
callers of icu_from_uchar() as well, but found no places that seemed to  
have a comparable issue.  
  
Add function API specifications for icu_to_uchar() and icu_from_uchar();  
the lack of any thought-through specification is perhaps not unrelated  
to the existence of this bug in the first place.  Fix icu_to_uchar()  
to guarantee a nul-terminated result; although no existing caller appears  
to care, the fact that it would have been nul-terminated except in  
extreme corner cases seems ideally designed to bite someone on the rear  
someday.  Fix ucnv_fromUChars() destCapacity argument --- in the worst  
case, that could perhaps have led to a non-nul-terminated result, too.  
Fix icu_from_uchar() to have a more reasonable definition of the function  
result --- no callers are actually paying attention, so this isn't a live  
bug, but it's certainly sloppily designed.  Const-ify icu_from_uchar()'s  
input string for consistency.  
  
That is not the end of what needs to be done to these functions, but  
it's as much as I have the patience for right now.  
  
Discussion: https://postgr.es/m/1955.1498181798@sss.pgh.pa.us  
  

Add testing to detect errors of omission in “pin” dependency creation.

  
commit   : 8be8510cf89d4e150816941029d7cdddfe9aa474    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 23 Jun 2017 11:03:04 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 23 Jun 2017 11:03:04 -0400    

Click here for diff

  
It's essential that initdb.c's setup_depend() scan each system catalog  
that could contain objects that need to have "p" (pin) entries in pg_depend  
or pg_shdepend.  Forgetting to add that, either when a catalog is first  
invented or when it first acquires DATA() entries, is an obvious bug  
hazard.  We can detect such omissions at reasonable cost by probing every  
OID-containing system catalog to see whether the lowest-numbered OID in it  
is pinned.  If so, the catalog must have been properly accounted for in  
setup_depend().  If the lowest OID is above FirstNormalObjectId then the  
catalog must have been empty at the end of initdb, so it doesn't matter.  
There are a small number of catalogs whose first entry is made later in  
initdb than setup_depend(), resulting in nonempty expected output of the  
test, but these can be manually inspected to see that they are OK.  Any  
future mistake of this ilk will manifest as a new entry in the test's  
output.  
  
Since pg_conversion is already in the test's output, add it to the set of  
catalogs scanned by setup_depend().  That has no effect today (hence, no  
catversion bump here) but it will protect us if we ever do add pin-worthy  
conversions.  
  
This test is very much like the catalog sanity checks embodied in  
opr_sanity.sql and type_sanity.sql, but testing pg_depend doesn't seem to  
fit naturally into either of those scripts' charters.  Hence, invent a new  
test script misc_sanity.sql, which can be a home for this as well as tests  
on any other catalogs we might want in future.  
  
Discussion: https://postgr.es/m/8068.1498155068@sss.pgh.pa.us  
  

Fix typos in README.dependencies

  
commit   : da2322883b9e50b1aac70a3b6eaf2a4f0e486469    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 22 Jun 2017 17:12:27 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 22 Jun 2017 17:12:27 -0400    

Click here for diff

  
There was a logic error in a formula, reported by Atsushi Torokoshi.  
Ashutosh Bapat furthermore recommended to change notation for a variable  
that was re-using a letter from a previous formula, though his proposed  
patch contained a small error in attributing what the new letter is for.  
Also, instead of his proposed d' I ended up using e, to avoid confusing  
the reader with quotes which are used differently in the explaining  
prose.  
  
Bugs appeared in commit 2686ee1b7ccfb9214064d4d2a98ea77382880306.  
  
Reported-by: Atsushi Torikoshi, Ashutosh Bapat  
Discussion: https://postgr.es/m/CAFjFpRd03YojT4wyuDcjhCfYuygfWfnt68XGn2CKv=rcjRCtTA@mail.gmail.com  
  

Fix typo in comment

  
commit   : 82c1507e3067d6d7884e823b09c921f9119dbe6f    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 22 Jun 2017 16:42:38 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 22 Jun 2017 16:42:38 -0400    

Click here for diff

  
Once upon a time, WAL pointers could be NULL, but no longer.  We talk about  
"valid" now.  
  
Reported-by: Amit Langote  
Discussion: https://postgr.es/m/33e9617d-27f1-eee8-3311-e27af98eaf2b@lab.ntt.co.jp  
  

Document partitioned_rels in create_modifytable_path header comment.

  
commit   : 6af9f1bd4bcbb0de15e826205b8e60632147dbe2    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Thu, 22 Jun 2017 13:51:39 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Thu, 22 Jun 2017 13:51:39 -0400    

Click here for diff

  
Etsuro Fujita, slightly adjusted by me.  
  
Discussion: http://postgr.es/m/e87c4a6d-23d7-5e7c-e8db-44ed418eb5d1@lab.ntt.co.jp  
  

Fix autovacuum launcher attachment to its DSA

  
commit   : a4f06606a328664d79f34b6041e816908d93e063    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 22 Jun 2017 13:50:26 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 22 Jun 2017 13:50:26 -0400    

Click here for diff

  
The autovacuum launcher doesn't actually do anything with its DSA other  
than creating it and attaching to it, but it's been observed that after  
longjmp'ing to the standard error handling block (for example after  
getting SIGINT) the autovacuum enters an infinite loop reporting that it  
cannot attach to its DSA anymore (which is correct, because it's already  
attached to it.)  Fix by only attempting to attach if not already  
attached.  
  
I introduced this bug together with BRIN autosummarization in  
7526e10224f0.  
  
Reported-by: Yugo Nagata.  
Author: Thomas Munro.  I added the comment to go with it.  
Discussion: https://postgr.es/m/20170621211538.0c9eae73.nagata@sraoss.co.jp  
  

Update out-of-date comment in vacuumlazy.c

  
commit   : 2a6db5eba69c0d6c842360f836cadd20e6cd9a0c    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Thu, 22 Jun 2017 13:35:39 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Thu, 22 Jun 2017 13:35:39 -0400    

Click here for diff

  
Commit 15c121b3ed7eb2f290e19533e41ccca734d23574 seems to have  
overlooked the need to trim this part of the comment.  
  
Pavan Deolasee  
  
Discussion: http://postgr.es/m/CABOikdPq_9+cWRNZ0RLKTwuZyj=uL85X=Usifa-CbPee1ZCM5A@mail.gmail.com  
  

Fix IF NOT EXISTS in CREATE STATISTICS

  
commit   : 5dfd564b1001f20c9def6ae938a92f39ddbd9984    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 22 Jun 2017 13:17:08 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 22 Jun 2017 13:17:08 -0400    

Click here for diff

  
I misplaced the IF NOT EXISTS clause in commit 7b504eb282, before the  
word STATISTICS.  Put it where it belongs.  
  
Patch written independently by Amit Langote and myself.  I adopted his  
submitted test case with a slight edit also.  
  
Reported-by: Bruno Wolff III  
Discussion: https://postgr.es/m/20170621004237.GB8337@wolff.to  
  

postgres_fdw: Move function prototype to correct section.

  
commit   : 2c77903b2bfba01f159138ba34b95d4b470395a8    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Thu, 22 Jun 2017 12:44:53 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Thu, 22 Jun 2017 12:44:53 -0400    

Click here for diff

  
Etsuro Fujita, reviewed by Ashutosh Bapat.  
  
Discussion: http://postgr.es/m/93a9c487-9920-a38f-da96-503422c50f59@lab.ntt.co.jp  
  

psql: Restore alphabetical order in words_after_create.

  
commit   : da6bf130750dec5bcaab0696b00c513c17b14ff9    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Thu, 22 Jun 2017 11:07:58 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Thu, 22 Jun 2017 11:07:58 -0400    

Click here for diff

  
Rushabh Lathia  
  
Discussion: http://postgr.es/m/CAGPqQf3yKG0Eo04ePfLPG_-KTo=7ZkxbGDVUWfSGN35Y3SG+PA@mail.gmail.com  
  

Update comment to account for table partitioning.

  
commit   : 1300276042f9c4b9db10825f0b4431da423ebb57    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Thu, 22 Jun 2017 10:52:25 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Thu, 22 Jun 2017 10:52:25 -0400    

Click here for diff

  
Ashutosh Bapat and Amit Langote  
  
Discussion: http://postgr.es/m/CAFjFpRcG_NaAv6cDHD-9VfGdvB8maAtSfB=fTQr5+kxP2_sXzg@mail.gmail.com  
  

Fix typo in comment

  
commit   : f0415a30e0bd56c9badecf097e8568ec1b3e3b0e    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Thu, 22 Jun 2017 15:37:30 +0200    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Thu, 22 Jun 2017 15:37:30 +0200    

Click here for diff

  
Author: Masahiko Sawada  
  

Teach pgrowlocks to check relkind before scanning

  
commit   : b56818abd450a87e2e3cb03b2cf3eede73487926    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 21 Jun 2017 23:19:13 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 21 Jun 2017 23:19:13 -0400    

Click here for diff

  
Author: Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>  
  

Fix possibility of creating a “phantom” segment after promotion.

  
commit   : fb886c153bc168eeb1c3fd2f24562b5b808357d6    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Wed, 21 Jun 2017 14:14:45 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Wed, 21 Jun 2017 14:14:45 -0700    

Click here for diff

  
When promoting a standby just after a XLOG_SWITCH record was replayed,  
and next segment(s) are already are locally available (via walsender,  
restore_command + trigger/recovery target), that segment could  
accidentally be recycled onto the past of the new timeline.  Later  
checkpointer would create a .ready file for it, assuming there was an  
error during creation, and it would get archived.  That causes trouble  
if another standby is later brought up from a basebackup from before  
the timeline creation, because it would try to read the  
segment, because XLogFileReadAnyTLI just tries all possible timelines,  
which doesn't have valid contents.  Thus replay would fail.  
  
The problem, if already occurred, can be fixed by removing the segment  
and/or having restore_command filter it out.  
  
The reason for the creation of such "phantom" segments was, that after  
an XLOG_SWITCH record the EndOfLog variable points to the beginning of  
the next segment, and RemoveXlogFile() used XLByteToPrevSeg().  
Normally RemoveXlogFile() doing so is harmless, because the last  
segment will still exist preventing InstallXLogFileSegment() from  
causing harm, but just after promotion there's no previous segment on  
the new timeline.  
  
Fix that by using XLByteToSeg() instead of XLByteToPrevSeg().  
  
Author: Andres Freund  
Reported-By: Greg Burek  
Discussion: https://postgr.es/m/20170619073026.zcwpe6mydsaz5ygd@alap3.anarazel.de  
Backpatch: 9.2-, bug older than all supported versions  
  

Manually un-break a few URLs that pgindent used to insist on splitting.

  
commit   : 780b3a4c43fd47867825d5d628e96a0966e63aa8    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 21 Jun 2017 16:02:08 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 21 Jun 2017 16:02:08 -0400    

Click here for diff

  
These will no longer get re-split by pgindent runs, so it's worth cleaning  
them up now.  
  
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org  
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us  
  

Remove entab and associated detritus.

  
commit   : 81f056c7256f01a39ecc926bf6a4d2d1fa525633    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 21 Jun 2017 15:46:20 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 21 Jun 2017 15:46:20 -0400    

Click here for diff

  
We don't need this anymore, because pg_bsd_indent has been taught to  
follow the same tab-vs-space rules that entab used to enforce.  
  
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org  
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us  
  

Reformat comments about ResultRelInfo

  
commit   : 113b0045e20d40f726a0a30e33214455e4f1385e    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 20 Jun 2017 14:29:48 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 20 Jun 2017 14:29:48 -0400    

Click here for diff

  
Also add a comment on its new member PartitionRoot.  
  
Reported-by: Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>  
  

Phase 3 of pgindent updates.

  
commit   : 382ceffdf7f620d8f2d50e451b4167d291ae2348    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 21 Jun 2017 15:35:54 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 21 Jun 2017 15:35:54 -0400    

Click here for diff

  
Don't move parenthesized lines to the left, even if that means they  
flow past the right margin.  
  
By default, BSD indent lines up statement continuation lines that are  
within parentheses so that they start just to the right of the preceding  
left parenthesis.  However, traditionally, if that resulted in the  
continuation line extending to the right of the desired right margin,  
then indent would push it left just far enough to not overrun the margin,  
if it could do so without making the continuation line start to the left of  
the current statement indent.  That makes for a weird mix of indentations  
unless one has been completely rigid about never violating the 80-column  
limit.  
  
This behavior has been pretty universally panned by Postgres developers.  
Hence, disable it with indent's new -lpl switch, so that parenthesized  
lines are always lined up with the preceding left paren.  
  
This patch is much less interesting than the first round of indent  
changes, but also bulkier, so I thought it best to separate the effects.  
  
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org  
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us  
  

Phase 2 of pgindent updates.

  
commit   : c7b8998ebbf310a156aa38022555a24d98fdbfb4    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 21 Jun 2017 15:18:54 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 21 Jun 2017 15:18:54 -0400    

Click here for diff

  
Change pg_bsd_indent to follow upstream rules for placement of comments  
to the right of code, and remove pgindent hack that caused comments  
following #endif to not obey the general rule.  
  
Commit e3860ffa4dd0dad0dd9eea4be9cc1412373a8c89 wasn't actually using  
the published version of pg_bsd_indent, but a hacked-up version that  
tried to minimize the amount of movement of comments to the right of  
code.  The situation of interest is where such a comment has to be  
moved to the right of its default placement at column 33 because there's  
code there.  BSD indent has always moved right in units of tab stops  
in such cases --- but in the previous incarnation, indent was working  
in 8-space tab stops, while now it knows we use 4-space tabs.  So the  
net result is that in about half the cases, such comments are placed  
one tab stop left of before.  This is better all around: it leaves  
more room on the line for comment text, and it means that in such  
cases the comment uniformly starts at the next 4-space tab stop after  
the code, rather than sometimes one and sometimes two tabs after.  
  
Also, ensure that comments following #endif are indented the same  
as comments following other preprocessor commands such as #else.  
That inconsistency turns out to have been self-inflicted damage  
from a poorly-thought-through post-indent "fixup" in pgindent.  
  
This patch is much less interesting than the first round of indent  
changes, but also bulkier, so I thought it best to separate the effects.  
  
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org  
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us  
  

Restart logical replication launcher when killed

  
commit   : f669c09989bda894d6ba01634ccb229f0687c08a    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 21 Jun 2017 15:15:29 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 21 Jun 2017 15:15:29 -0400    

Click here for diff

  
Author: Yugo Nagata <nagata@sraoss.co.jp>  
  

Initial pgindent run with pg_bsd_indent version 2.0.

  
commit   : e3860ffa4dd0dad0dd9eea4be9cc1412373a8c89    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 21 Jun 2017 14:39:04 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 21 Jun 2017 14:39:04 -0400    

Click here for diff

  
The new indent version includes numerous fixes thanks to Piotr Stefaniak.  
The main changes visible in this commit are:  
  
* Nicer formatting of function-pointer declarations.  
* No longer unexpectedly removes spaces in expressions using casts,  
  sizeof, or offsetof.  
* No longer wants to add a space in "struct structname *varname", as  
  well as some similar cases for const- or volatile-qualified pointers.  
* Declarations using PG_USED_FOR_ASSERTS_ONLY are formatted more nicely.  
* Fixes bug where comments following declarations were sometimes placed  
  with no space separating them from the code.  
* Fixes some odd decisions for comments following case labels.  
* Fixes some cases where comments following code were indented to less  
  than the expected column 33.  
  
On the less good side, it now tends to put more whitespace around typedef  
names that are not listed in typedefs.list.  This might encourage us to  
put more effort into typedef name collection; it's not really a bug in  
indent itself.  
  
There are more changes coming after this round, having to do with comment  
indentation and alignment of lines appearing within parentheses.  I wanted  
to limit the size of the diffs to something that could be reviewed without  
one's eyes completely glazing over, so it seemed better to split up the  
changes as much as practical.  
  
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org  
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us  
  

Adjust pgindent script to use pg_bsd_indent 2.0.

  
commit   : 8ff6d4ec7840b0af56f1207073f44b7f2afae96d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 21 Jun 2017 14:26:21 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 21 Jun 2017 14:26:21 -0400    

Click here for diff

  
Update version-checking code and list of switches.  Delete obsolete  
quasi-support for using GNU indent.  Remove a lot of no-longer-needed  
workarounds for bugs of the old version, and improve comments for  
the hacks that remain.  Update run_build() subroutine to fetch the  
pg_bsd_indent code from the newly established git repo for it.  
  
In passing, fix pgindent to not overwrite files that require no changes;  
this makes it a bit more friendly to run on a built tree.  
  
Adjust relevant documentation.  
  
Remove indent.bsd.patch; it's not relevant anymore (and was obsolete  
long ago anyway).  Likewise remove pgcppindent, since we're no longer  
in the business of shipping C++ code.  
  
Piotr Stefaniak is responsible for most of the algorithmic changes  
to the pgindent script; I did the rest.  
  
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org  
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us  
  

Final pgindent run with old pg_bsd_indent (version 1.3).

  
commit   : 9ef2dbefc7fb3ac22e1528bc22a41a5c6c6a9539    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 21 Jun 2017 14:09:24 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 21 Jun 2017 14:09:24 -0400    

Click here for diff

  
This is just to have a clean basis for comparison with the results of  
the new version (which will indeed end up reverting some of these  
changes...)  
  
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org  
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us  
  

Prevent table partitions from being turned into views.

  
commit   : bcbf392ec84362040faf72daad22c647c74e2b2a    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Wed, 21 Jun 2017 10:43:17 +0100    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Wed, 21 Jun 2017 10:43:17 +0100    

Click here for diff

  
A table partition must be a table, not a view, so don't allow a  
"_RETURN" rule to be added that would convert an existing table  
partition into a view.  
  
Amit Langote  
  
Discussion: https://postgr.es/m/CAEZATCVzFcAjZwC1bTFvJ09skB_sgkF4SwPKMywev-XTnimp9Q%40mail.gmail.com  
  

Fix typo in comment.

  
commit   : ba1f017069dd87d309e2716bf08a40df42b29baa    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 21 Jun 2017 11:55:07 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 21 Jun 2017 11:55:07 +0300    

Click here for diff

  
Etsuro Fujita  
  

Make opr_sanity test complain about built-in functions marked prosecdef.

  
commit   : d412f79381935186dc8f95fd2dc30227a82f012f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 20 Jun 2017 17:06:43 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 20 Jun 2017 17:06:43 -0400    

Click here for diff

  
Currently, there are no built-in functions that are SECURITY DEFINER.  
But we just found an instance where one was mistakenly marked that way,  
so it seems prudent to add a test about it.  If we ever grow some  
functions that are intentionally SECURITY DEFINER, we can alter the  
expected output of this test, or adjust the query to filter out functions  
for which it's okay.  
  
Per suggestion from Robert Haas.  
  
Discussion: https://postgr.es/m/CA+TgmoYXg7McY33+jbWmG=rS-HNUur0S6W8Q8kVNFf7epFimVA@mail.gmail.com  
  

Fix typo in code comment

  
commit   : 15c91568cfa4777892207a85000fdfd72b59b677    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 20 Jun 2017 14:31:29 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 20 Jun 2017 14:31:29 -0400    

Click here for diff

  
Author: Masahiko Sawada <sawada.mshk@gmail.com>  
  

Upgrade documentation connected with shared_preload_libraries et al.

  
commit   : ba63dbd9edc0d58e5f0891ead979674b1b45ad17    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 20 Jun 2017 13:39:57 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 20 Jun 2017 13:39:57 -0400    

Click here for diff

  
Noplace in the documentation actually defined what these variables  
contain.  Define them as lists of arguments for LOAD, and improve  
that command's documentation a bit.  
  
Discussion: https://postgr.es/m/CAB-oJtxHVDc3H+Km3CjB9mY1VDzuyaVH_ZYSz7iXcRqCtb93Ew@mail.gmail.com  
  

pg_upgrade: start/stop new server after pg_resetwal

  
commit   : b710248dd3f90c46bd4208e6bf1290048b9d76cd    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 20 Jun 2017 13:20:02 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 20 Jun 2017 13:20:02 -0400    

Click here for diff

  
When commit 0f33a719fdbb5d8c43839ea0d2c90cd03e2af2d2 removed the  
instructions to start/stop the new cluster before running rsync, it was  
now possible for pg_resetwal/pg_resetxlog to leave the final WAL record  
at wal_level=minimum, preventing upgraded standby servers from  
reconnecting.  
  
This patch fixes that by having pg_upgrade unconditionally start/stop  
the new cluster after pg_resetwal/pg_resetxlog has run.  
  
Backpatch through 9.2 since, though the instructions were added in PG  
9.5, they worked all the way back to 9.2.  
  
Discussion: https://postgr.es/m/20170620171844.GC24975@momjian.us  
  
Backpatch-through: 9.2  
  

Don’t downcase entries within shared_preload_libraries et al.

  
commit   : a69dfe5f40f77d586e8d4d9ecfc39d81612c7dda    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 20 Jun 2017 13:02:42 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 20 Jun 2017 13:02:42 -0400    

Click here for diff

  
load_libraries(), which processes the various xxx_preload_libraries GUCs,  
was parsing them using SplitIdentifierString() which isn't really  
appropriate for values that could be path names: it downcases unquoted  
text, and it doesn't allow embedded whitespace unless quoted.  
Use SplitDirectoriesString() instead.  That also allows us to simplify  
load_libraries() a bit, since canonicalize_path() is now done for it.  
  
While this definitely seems like a bug fix, it has the potential to  
break configuration settings that accidentally worked before because  
of the downcasing behavior.  Also, there's an easy workaround for the  
bug, namely to double-quote troublesome text.  Hence, no back-patch.  
  
QL Zhuo, tweaked a bit by me  
  
Discussion: https://postgr.es/m/CAB-oJtxHVDc3H+Km3CjB9mY1VDzuyaVH_ZYSz7iXcRqCtb93Ew@mail.gmail.com  
  

Tweak publication fetching in psql

  
commit   : a2141c42f9ebc51b4501a4fafea9dd3fb7eda23d    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 20 Jun 2017 12:25:07 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 20 Jun 2017 12:25:07 -0400    

Click here for diff

  
Viewing a table with \d in psql also shows the publications at table is  
in.  If a publication is concurrently dropped, this shows an error,  
because the view pg_publication_tables internally uses  
pg_get_publication_tables(), which uses a catalog snapshot.  This can be  
particularly annoying if a for-all-tables publication is concurrently  
dropped.  
  
To avoid that, write the query in psql differently.  Expose the function  
pg_relation_is_publishable() to SQL and write the query using that.  
That still has a risk of being affected by concurrent catalog changes,  
but in this case it would be a table drop that causes problems, and then  
the psql \d command wouldn't be interesting anymore anyway.  
  
Reported-by: Tom Lane <tgl@sss.pgh.pa.us>  
  

Change pg_get_publication_tables to prosecdef false

  
commit   : 20d7d68b098dde6106e6c382e787c8b10c4403df    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 20 Jun 2017 10:03:35 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 20 Jun 2017 10:03:35 -0400    

Click here for diff

  
This was apparently a mistake in the original commit.  
  
Reported-by: Tom Lane <tgl@sss.pgh.pa.us>  
  

Fix materialized-view documentation oversights.

  
commit   : d14c85ed1abb5d01b10313715ab73aadb9a7a7af    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 19 Jun 2017 18:32:22 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 19 Jun 2017 18:32:22 -0400    

Click here for diff

  
When materialized views were added, psql's \d commands were made to  
treat them as a separate object category ... but not everyplace in the  
documentation or comments got the memo.  
  
Noted by David Johnston.  Back-patch to 9.3 where matviews came in.  
  
Discussion: https://postgr.es/m/CAKFQuwb27M3VXRhHErjCpkWwN9eKThbqWb1=trtoXi9_ejqPXQ@mail.gmail.com  
  

doc: Improve logical replication security setup info

  
commit   : 1c25ef6363f38253e5ac080373eef7f3305fa5dc    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 19 Jun 2017 17:30:52 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 19 Jun 2017 17:30:52 -0400    

Click here for diff

  
Reported-by: Jeff Janes <jeff.janes@gmail.com>  
  

Avoid regressions in foreign-key-based selectivity estimates.

  
commit   : d8e6b84bd2ac045cdbae231012ab5ea4471a02cd    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 19 Jun 2017 15:33:41 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 19 Jun 2017 15:33:41 -0400    

Click here for diff

  
David Rowley found that the "use the smallest per-column selectivity"  
heuristic applied in some cases by get_foreign_key_join_selectivity()  
was badly off if the FK columns are independent, producing estimates  
much worse than we got before that code was added in 9.6.  
  
One case where that heuristic was used was for LEFT and FULL outer joins  
with the referenced rel on the outside of the join.  But we should not  
really need to special-case those here.  eqjoinsel() never has had such a  
special case; the correction is applied by calc_joinrel_size_estimate()  
instead.  Let's just estimate such cases like inner joins and rely on that  
later adjustment.  (I think there was something of a thinko here, in that  
the comments seem to be thinking about the selectivity as defined for  
semi/anti joins; but that shouldn't apply to left/full joins.)  Add a  
regression test exercising such a case to show that this is sane in  
at least some cases.  
  
The other case where we used that heuristic was for SEMI/ANTI outer joins,  
either if the referenced rel was on the outside, or if it was on the inside  
but was part of a join within the RHS.  In either case, the FK doesn't give  
us a lot of traction towards estimating the selectivity.  To ensure that  
we don't have regressions from what happened before 9.6, let's punt by  
ignoring the FK in such cases and applying the traditional selectivity  
calculation.  (We might be able to improve on that later, but for now  
I just want to be sure it's not worse than 9.5.)  
  
Report and patch by David Rowley, simplified a bit by me.  Back-patch  
to 9.6 where this code was added.  
  
Discussion: https://postgr.es/m/CAKJS1f8NO8oCDcxrteohG6O72uU1saEVT9qX=R8pENr5QWerXw@mail.gmail.com  
  

On Windows, make pg_dump use binary mode for compressed plain text output.

  
commit   : bd61d5a194ac24f0c282ed414e1378846f78dee4    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 19 Jun 2017 11:02:45 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 19 Jun 2017 11:02:45 -0400    

Click here for diff

  
The combination of -Z -Fp and output to stdout resulted in corrupted  
output data, because we left stdout in text mode, resulting in newline  
conversion being done on the compressed stream.  Switch stdout to binary  
mode for this case, at the same place where we do it for non-text output  
formats.  
  
Report and patch by Kuntal Ghosh, tested by Ashutosh Sharma and Neha  
Sharma.  Back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/CAGz5QCJPvbBjXAmJuGx1B_41yVCetAJhp7rtaDf7XQGWuB1GSw@mail.gmail.com  
  

Fix leaking of small spilled subtransactions during logical decoding.

  
commit   : 3bdea167eb01491a4898e977d308508374e97bfa    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Sun, 18 Jun 2017 18:48:22 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Sun, 18 Jun 2017 18:48:22 -0700    

Click here for diff

  
When, during logical decoding, a transaction gets too big, it's  
contents get spilled to disk. Not just the top-transaction gets  
spilled, but *also* all of its subtransactions, even if they're not  
that large themselves.  Unfortunately we didn't clean up  
such small spilled subtransactions from disk.  
  
Fix that, by keeping better track of whether a transaction has been  
spilled to disk.  
  
Author: Andres Freund  
Reported-By: Dmitriy Sarafannikov, Fabrízio de Royes Mello  
Discussion:  
    https://postgr.es/m/1457621358.355011041@f382.i.mail.ru  
    https://postgr.es/m/CAFcNs+qNMhNYii4nxpO6gqsndiyxNDYV0S=JNq0v_sEE+9PHXg@mail.gmail.com  
Backpatch: 9.4-, where logical decoding was introduced  
  

Improve PostgreSQL 10.0 release note regarding pg_current_logfile().

  
commit   : b4166a8df914f56b3b7d2dc1b74897e7525c5cea    
  
author   : Tatsuo Ishii <ishii@postgresql.org>    
date     : Mon, 19 Jun 2017 09:10:18 +0900    
  
committer: Tatsuo Ishii <ishii@postgresql.org>    
date     : Mon, 19 Jun 2017 09:10:18 +0900    

Click here for diff

  
Author: Yugo Nagata  
  

Documentation spell checking and markup improvements

  
commit   : bbaf9e8f840acb8e4a52dc1809bd2c9b320e9df8    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Sun, 18 Jun 2017 14:01:45 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Sun, 18 Jun 2017 14:01:45 -0400    

Click here for diff

  
  

Fix copy/paste error in docs

  
commit   : 81a4dcf2f2f92dc01ce0cf318dc9fabfb3021bd7    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Sun, 18 Jun 2017 19:41:46 +0200    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Sun, 18 Jun 2017 19:41:46 +0200    

Click here for diff

  
Author: Julien Rouhaud <julien.rouhaud@dalibo.com>  
  

doc: Fix typo

  
commit   : f6da23f526cf622d2dbcee47695b4aedf8ab2c69    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Sat, 17 Jun 2017 19:03:12 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Sat, 17 Jun 2017 19:03:12 -0400    

Click here for diff

  
Author: Julien Rouhaud <julien.rouhaud@dalibo.com>  
  

doc: Fix typo

  
commit   : 806dccee23dfa3dd3b326354255cf0d5cb032f02    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Sat, 17 Jun 2017 10:21:41 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Sat, 17 Jun 2017 10:21:41 -0400    

Click here for diff

  
Author: Julien Rouhaud <julien.rouhaud@dalibo.com>  
  

Set statement timestamp in apply worker

  
commit   : 033370179a6d15b2e1b519462d14419d6dc84e73    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Sat, 17 Jun 2017 08:54:21 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Sat, 17 Jun 2017 08:54:21 -0400    

Click here for diff

  
This ensures that triggers can see an up-to-date timestamp.  
  
Reported-by: Konstantin Evteev <konst583@gmail.com>  
  

Remove incorrect comment

  
commit   : 7f5cb14e3c507973392e90b25cb4d36932dd42da    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Sat, 17 Jun 2017 10:19:48 +0200    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Sat, 17 Jun 2017 10:19:48 +0200    

Click here for diff

  
Author: Michael Paquier <michael.paquier@gmail.com>  
  

Fix typos in comments

  
commit   : bb1f8f9e5bb13af43ab65faa98ae898a68995070    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Sat, 17 Jun 2017 10:17:01 +0200    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Sat, 17 Jun 2017 10:17:01 +0200    

Click here for diff

  
Author: Daniel Gustafsson <daniel@yesql.se>  
  

Define HAVE_UCOL_STRCOLLUTF8 on Windows

  
commit   : e42645ad92687a2250ad17e1a045da73e54a5064    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 16 Jun 2017 21:23:22 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 16 Jun 2017 21:23:22 -0400    

Click here for diff

  
This should normally be determined by a configure check, but until  
someone figures out how to do that on Windows, it's better that the code  
uses the new function by default.  
  

Teach pgindent to skip files generated by bison or flex automatically.

  
commit   : cea258b63d9c7a6d0a7c5e91e539bb89df4bc078    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 16 Jun 2017 23:14:27 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 16 Jun 2017 23:14:27 -0400    

Click here for diff

  
If a .c or .h file corresponds to a .y or .l file, skip indenting it.  
There's no point in reindenting derived files, and these files tend to  
confuse pgindent.  (Which probably indicates a bug in BSD indent, but  
I can't get excited about trying to fix it.)  
  
For the same reasons, add src/backend/utils/fmgrtab.c to the set of  
files excluded by src/tools/pgindent/exclude_file_patterns.  
  
The point of doing this is that it makes it safe to run pgindent over  
the tree without doing "make maintainer-clean" first.  While these are  
not the only derived .c/.h files in the tree, they are the only ones  
pgindent fails on.  Removing that prerequisite step results in one less  
way to mess up a pgindent run, and it's necessary if we ever hope to get  
to the ease of running pgindent via "make indent".  
  

doc: Add note that COPY commands are published as INSERTs

  
commit   : 57fb1d677d98d9c02565e47afdbf5e887b095c9f    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 16 Jun 2017 21:04:34 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 16 Jun 2017 21:04:34 -0400    

Click here for diff

  
  

Use RangeVarGetRelidExtended() in AlterSequence()

  
commit   : 94da2a6a9a05776953524424a3d8079e54bc5d94    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 13 Jun 2017 14:58:17 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 13 Jun 2017 14:58:17 -0400    

Click here for diff

  
This allows us to combine the opening and the ownership check.  
  
Reported-by: Robert Haas <robertmhaas@gmail.com>  
  

Fix ICU collation use on Windows

  
commit   : 41839b7abc85f21dd7ce76ab9cd1d7533c53cf9c    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 16 Jun 2017 10:08:54 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 16 Jun 2017 10:08:54 -0400    

Click here for diff

  
Windows uses a separate code path for libc locales.  The code previously  
ended up there also if an ICU collation should be used, leading to a  
crash.  
  
Reported-by: Ashutosh Sharma <ashu.coek88@gmail.com>  
  

doc: Add section about logical replication restrictions

  
commit   : 3ef97e725e2cbb050ff2e88adc36299bafa188c4    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 16 Jun 2017 09:55:55 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 16 Jun 2017 09:55:55 -0400    

Click here for diff

  
  

Fix dependency, when changing a function’s argument/return type.

  
commit   : 30681c830d69ca88cf66105c94e63d3e4d905681    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 16 Jun 2017 11:33:12 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 16 Jun 2017 11:33:12 +0300    

Click here for diff

  
When a new base type is created using the old-style procedure of first  
creating the input/output functions with "opaque" in place of the base  
type, the "opaque" argument/return type is changed to the final base type,  
on CREATE TYPE. However, we did not create a pg_depend record when doing  
that, so the functions were left not depending on the type.  
  
Fixes bug #14706, reported by Karen Huddleston.  
  
Discussion: https://www.postgresql.org/message-id/20170614232259.1424.82774@wrigleys.postgresql.org  
  

Reconcile nodes/*funcs.c with PostgreSQL 10 work.

  
commit   : 39ac55918fc31b9bf88185d28ebe7ddc58d01181    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Fri, 16 Jun 2017 00:16:11 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Fri, 16 Jun 2017 00:16:11 -0700    

Click here for diff

  
The _equalTableFunc() omission of coltypmods has semantic significance,  
but I did not track down resulting user-visible bugs, if any.  The other  
changes are cosmetic only, affecting order.  catversion bump due to  
readfuncs.c field order change.  
  

Make configure check for IPC::Run when –enable-tap-tests is specified.

  
commit   : c254970ad6092d201443cced570450d5b29d4234    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 15 Jun 2017 15:56:12 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 15 Jun 2017 15:56:12 -0400    

Click here for diff

  
The TAP tests mostly don't work without IPC::Run, and the reason for  
the failure is not immediately obvious from the error messages you get.  
So teach configure to reject --enable-tap-tests unless IPC::Run exists.  
Mostly this just involves adding ax_prog_perl_modules.m4 from the GNU  
autoconf archives.  
  
This was discussed last year, but we held off on the theory that we might  
be switching to CMake soon.  That's evidently not happening for v10,  
so let's absorb this now.  
  
Eugene Kazakov and Michael Paquier  
  
Discussion: https://postgr.es/m/56BDDC20.9020506@postgrespro.ru  
Discussion: https://postgr.es/m/CAB7nPqRVKG_CR4Dy_AMfE6DXcr6F7ygy2goa2atJU4XkerDRUg@mail.gmail.com  
  

Fix low-probability leaks of PGresult objects in the backend.

  
commit   : a3bed62d44f83283414a82717bc8e96e9f398dcc    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 15 Jun 2017 15:03:39 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 15 Jun 2017 15:03:39 -0400    

Click here for diff

  
We had three occurrences of essentially the same coding pattern  
wherein we tried to retrieve a query result from a libpq connection  
without blocking.  In the case where PQconsumeInput failed (typically  
indicating a lost connection), all three loops simply gave up and  
returned, forgetting to clear any previously-collected PGresult  
object.  Since those are malloc'd not palloc'd, the oversight results  
in a process-lifespan memory leak.  
  
One instance, in libpqwalreceiver, is of little significance because  
the walreceiver process would just quit anyway if its connection fails.  
But we might as well fix it.  
  
The other two instances, in postgres_fdw, are somewhat more worrisome  
because at least in principle the scenario could be repeated, allowing  
the amount of memory leaked to build up to something worth worrying  
about.  Moreover, in these cases the loops contain CHECK_FOR_INTERRUPTS  
calls, as well as other calls that could potentially elog(ERROR),  
providing another way to exit without having cleared the PGresult.  
Here we need to add PG_TRY logic similar to what exists in quite a  
few other places in postgres_fdw.  
  
Coverity noted the libpqwalreceiver bug; I found the other two cases  
by checking all calls of PQconsumeInput.  
  
Back-patch to all supported versions as appropriate (9.2 lacks  
postgres_fdw, so this is really quite unexciting for that branch).  
  
Discussion: https://postgr.es/m/22620.1497486981@sss.pgh.pa.us  
  

doc: remove mention of Windows junction points by pg_upgrade

  
commit   : 07fb943335f3cdd11a9146ae6fdee237cc83c5f6    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Thu, 15 Jun 2017 13:25:45 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Thu, 15 Jun 2017 13:25:45 -0400    

Click here for diff

  
pg_upgrade never used Windows junction points but instead always used  
Windows hard links.  
  
Reported-by: Adrian Klaver  
  
Discussion: https://postgr.es/m/6a638c60-90bb-4921-8ee4-5fdad68f8b09@aklaver.com  
  
Backpatch-through: 9.3, where the mention first appeared  
  

docs: Fix pg_upgrade standby server upgrade docs

  
commit   : 0f33a719fdbb5d8c43839ea0d2c90cd03e2af2d2    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Thu, 15 Jun 2017 12:30:02 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Thu, 15 Jun 2017 12:30:02 -0400    

Click here for diff

  
It was unsafe to instruct users to start/stop the server after  
pg_upgrade was run but before the standby servers were rsync'ed.  The  
new instructions avoid this.  
  
RELEASE NOTES:  This fix should be mentioned in the minor release notes.  
  
Reported-by: Dmitriy Sarafannikov and Sergey Burladyan  
  
Discussion: https://postgr.es/m/87wp8o506b.fsf@seb.koffice.internal  
  
Backpatch-through: 9.5, where standby server upgrade instructions first appeared  
  

Rename function for consistency

  
commit   : 3ab7912c18b6df4d6843d0e0cd6183e7f4912cbb    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 15 Jun 2017 11:44:33 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 15 Jun 2017 11:44:33 -0400    

Click here for diff

  
Avoid using prefix "staext" when everything else uses "statext".  
  
Author: Kyotaro HORIGUCHI  
Discussion: https://postgr.es/m/20170615.140041.165731947.horiguchi.kyotaro@lab.ntt.co.jp  
  

psql: Improve display of “for all tables” publications

  
commit   : 915379c3c2613f2b24d4e9c6fa79a43e7c6a86ec    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 15 Jun 2017 10:46:41 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 15 Jun 2017 10:46:41 -0400    

Click here for diff

  
Show "All tables" property in \dRp and \dRp+.  Don't list tables for  
such publications in \dRp+, since it's redundant and the list could be  
very long.  
  
Author: Masahiko Sawada <sawada.mshk@gmail.com>  
Author: Jeff Janes <jeff.janes@gmail.com>  
  

Fix typo in code comment

  
commit   : 6c6a1149b5662f685ddbb0c6dc83eb110992044a    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 15 Jun 2017 09:45:13 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 15 Jun 2017 09:45:13 -0400    

Click here for diff

  
Author: Daniel Gustafsson <daniel@yesql.se>  
  

Remove unnecessary IPC::Run inclusion

  
commit   : 878b7d9eaa9cbf5f121f9ee8676d82b22decedf0    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 15 Jun 2017 09:19:12 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 15 Jun 2017 09:19:12 -0400    

Click here for diff

  
This is no longer needed because the tests use PostgresNode.  
  
Reported-by: Michael Paquier <michael.paquier@gmail.com>  
  

Fix typo in PostgreSQL 10.0 release note.

  
commit   : e800656d9a9b40b2f55afabe76354ab6d93353b3    
  
author   : Tatsuo Ishii <ishii@postgresql.org>    
date     : Thu, 15 Jun 2017 11:24:47 +0900    
  
committer: Tatsuo Ishii <ishii@postgresql.org>    
date     : Thu, 15 Jun 2017 11:24:47 +0900    

Click here for diff

  
Patch by Yugo Nagata.  
  

Fix document bug regarding read only transactions.

  
commit   : 6108348c09df33773bed6e0ac762fe47bdcbb9e6    
  
author   : Tatsuo Ishii <ishii@postgresql.org>    
date     : Thu, 15 Jun 2017 10:01:39 +0900    
  
committer: Tatsuo Ishii <ishii@postgresql.org>    
date     : Thu, 15 Jun 2017 10:01:39 +0900    

Click here for diff

  
It was explained that read only transactions (not in standby) allow to  
update sequences. This had been wrong since the commit:  
05d8a561ff85db1545f5768fe8d8dc9d99ad2ef7  
  
Discussion: https://www.postgresql.org/message-id/20170614.110826.425627939780392324.t-ishii%40sraoss.co.jp  
  

  
commit   : f32d57fd7088a558dadbe21b9859b09d2f877c19    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Wed, 14 Jun 2017 16:19:46 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Wed, 14 Jun 2017 16:19:46 -0400    

Click here for diff

  
Commit 18ce3a4ab22d2984f8540ab480979c851dae5338 failed to update  
the comments in parsenodes.h for the new members, and made only  
incomplete updates to src/backend/nodes  
  
Thomas Munro, per a report from Noah Misch.  
  
Discussion: http://postgr.es/m/20170611062525.GA1628882@rfd.leadboat.com  
  

Don’t force-assign transaction id when exporting a snapshot.

  
commit   : 6c2003f8a1bbc7c192a2e83ec51581c018aa162f    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Wed, 14 Jun 2017 11:57:21 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Wed, 14 Jun 2017 11:57:21 -0700    

Click here for diff

  
Previously we required every exported transaction to have an xid  
assigned. That was used to check that the exporting transaction is  
still running, which in turn is needed to guarantee that that  
necessary rows haven't been removed in between exporting and importing  
the snapshot.  
  
The exported xid caused unnecessary problems with logical decoding,  
because slot creation has to wait for all concurrent xid to finish,  
which in turn serializes concurrent slot creation.   It also  
prohibited snapshots to be exported on hot-standby replicas.  
  
Instead export the virtual transactionid, which avoids the unnecessary  
serialization and the inability to export snapshots on standbys. This  
changes the file name of the exported snapshot, but since we never  
documented what that one means, that seems ok.  
  
Author: Petr Jelinek, slightly editorialized by me  
Reviewed-By: Andres Freund  
Discussion: https://postgr.es/m/f598b4b8-8cd7-0d54-0939-adda763d8c34@2ndquadrant.com  
  

Use DEFACLOBJ_ macros in error message instead of hardcoding

  
commit   : b6966d4627c0297ad42fe2592c66ac2f76e9962e    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 14 Jun 2017 14:44:24 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 14 Jun 2017 14:44:24 -0400    

Click here for diff

  
  

Add missing serial comma

  
commit   : 4e88fe8f8f148a45feacb50c2eaed9ca9ddea8bb    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 14 Jun 2017 14:43:54 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 14 Jun 2017 14:43:54 -0400    

Click here for diff

  
  

doc: Whitespace fixes in man pages

  
commit   : f0cfff9da2c577a19dd6a15ffc7b404693b700bc    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 14 Jun 2017 13:55:43 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 14 Jun 2017 13:55:43 -0400    

Click here for diff

  
  

Teach predtest.c about CHECK clauses to fix partitioning bugs.

  
commit   : b08df9cab777427fdafe633ca7b8abf29817aa55    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Wed, 14 Jun 2017 13:13:11 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Wed, 14 Jun 2017 13:13:11 -0400    

Click here for diff

  
In a CHECK clause, a null result means true, whereas in a WHERE clause  
it means false.  predtest.c provided different functions depending on  
which set of semantics applied to the predicate being proved, but had  
no option to control what a null meant in the clauses provided as  
axioms.  Add one.  
  
Use that in the partitioning code when figuring out whether the  
validation scan on a new partition can be skipped.  Rip out the  
old logic that attempted (not very successfully) to compensate  
for the absence of the necessary support in predtest.c.  
  
Ashutosh Bapat and Robert Haas, reviewed by Amit Langote and  
incorporating feedback from Tom Lane.  
  
Discussion: http://postgr.es/m/CAFjFpReT_kq_uwU_B8aWDxR7jNGE=P0iELycdq5oupi=xSQTOw@mail.gmail.com  
  

Improve release note text about set-returning-function changes.

  
commit   : a12c09ad86e60a8acb269744b8ee86429dda2cd8    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 14 Jun 2017 11:44:34 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 14 Jun 2017 11:44:34 -0400    

Click here for diff

  
Paul Ramsey griped about this awhile ago, but I'd been holding fire  
on changing it until we settled what to do about the CASE/COALESCE  
issue.  
  
Discussion: https://postgr.es/m/CACowWR0AMyUt5fwtvuDqWyYNdp-hQJj9XqSxJR6YM9sKWov=_w@mail.gmail.com  
  

Avoid bogus TwoPhaseState locking sequences

  
commit   : e90ceeaa495f5f40f224bcf84d2b0700eae8d7a3    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 14 Jun 2017 11:29:05 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 14 Jun 2017 11:29:05 -0400    

Click here for diff

  
The optimized code in 728bd991c3c4 contains a few invalid locking  
sequences.  To wit, the original code would try to acquire an lwlock  
that it already holds.  Avoid this by moving lock acquisitions to  
higher-level code, and install appropriate assertions in low-level that  
the correct mode is held.  
  
Authors: Michael Paquier, Álvaro Herrera  
Reported-By: chuanting wang  
Bug: #14680  
Discussion: https://postgr.es/m/20170531033228.1487.10124@wrigleys.postgresql.org  
  

Put documentation of options and commands in more alphabetical order

  
commit   : 0d9bdbcaae00dac89a82c25e66e4a859130e2fe8    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 14 Jun 2017 11:09:33 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 14 Jun 2017 11:09:33 -0400    

Click here for diff

  
  

Fix no-longer-valid shortcuts in expression_returns_set().

  
commit   : 8e72239e9d961c27f02b242e33fa832c364c7a4b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 14 Jun 2017 11:10:05 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 14 Jun 2017 11:10:05 -0400    

Click here for diff

  
expression_returns_set() used to short-circuit its recursion upon  
seeing certain node types, such as DistinctExpr, that it knew the  
executor did not support set-valued arguments for.  That was never  
inherent, though, just a reflection of laziness in execQual.c.  
With the new implementation of SRFs there is no reason to think  
that any scalar-valued expression node could not have a set-valued  
subexpression, except for AggRefs and WindowFuncs where we know there  
is a parser check rejecting it.  And indeed, the shortcut causes  
unexpected failures for cases such as a SRF underneath DistinctExpr,  
because the planner stops looking for SRFs too soon.  
  
Discussion: https://postgr.es/m/5259.1497044025@sss.pgh.pa.us  
  

Fix violations of CatalogTupleInsert/Update/Delete abstraction.

  
commit   : a571c7f661a7b601aafcb12196d004cdb8b8cb23    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 14 Jun 2017 10:26:46 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 14 Jun 2017 10:26:46 -0400    

Click here for diff

  
In commits 2f5c9d9c9 and ab0289651 we invented an abstraction layer  
to insulate catalog manipulations from direct heap update calls.  
But evidently some patches that hadn't landed in-tree at that point  
didn't get the memo completely.  Fix a couple of direct calls to  
simple_heap_delete to use CatalogTupleDelete instead; these appear  
to have been added in commits 7c4f52409 and 7b504eb28.  This change is  
purely cosmetic ATM, but there's no point in having an abstraction layer  
if we allow random code to break it.  
  
Masahiko Sawada and Tom Lane  
  
Discussion: https://postgr.es/m/CAD21AoDOPRSVcwbnCN3Y1n_68ATyTspsU6=ygtHz_uY0VcdZ8A@mail.gmail.com  
  

Teach PL/pgSQL about partitioned tables.

  
commit   : d3c3f2b1e25cc96d3078bf4d47a2f58fefb70560    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Wed, 14 Jun 2017 09:00:01 +0100    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Wed, 14 Jun 2017 09:00:01 +0100    

Click here for diff

  
Table partitioning, introduced in commit f0e44751d7, added a new  
relkind - RELKIND_PARTITIONED_TABLE. Update a couple of places in  
PL/pgSQL to handle it. Specifically plpgsql_parse_cwordtype() and  
build_row_from_class() needed updating in order to make table%ROWTYPE  
and table.col%TYPE work for partitioned tables.  
  
Dean Rasheed, reviewed by Amit Langote.  
  
Discussion: https://postgr.es/m/CAEZATCUnNOKN8sLML9jUzxecALWpEXK3a3W7y0PgFR4%2Buhgc%3Dg%40mail.gmail.com  
  

Teach RemoveRoleFromObjectPolicy() about partitioned tables.

  
commit   : f356ec57444e42e53474ad5a029cdf6dca195069    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Wed, 14 Jun 2017 08:43:40 +0100    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Wed, 14 Jun 2017 08:43:40 +0100    

Click here for diff

  
Table partitioning, introduced in commit f0e44751d7, added a new  
relkind - RELKIND_PARTITIONED_TABLE. Update  
RemoveRoleFromObjectPolicy() to handle it, otherwise DROP OWNED BY  
will fail if the role has any RLS policies referring to partitioned  
tables.  
  
Dean Rasheed, reviewed by Amit Langote.  
  
Discussion: https://postgr.es/m/CAEZATCUnNOKN8sLML9jUzxecALWpEXK3a3W7y0PgFR4%2Buhgc%3Dg%40mail.gmail.com  
  

Disallow set-returning functions inside CASE or COALESCE.

  
commit   : 0436f6bde8848b7135f19dd7f8548b8c2ae89a34    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 13 Jun 2017 23:46:39 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 13 Jun 2017 23:46:39 -0400    

Click here for diff

  
When we reimplemented SRFs in commit 69f4b9c85, our initial choice was  
to allow the behavior to vary from historical practice in cases where a  
SRF call appeared within a conditional-execution construct (currently,  
only CASE or COALESCE).  But that was controversial to begin with, and  
subsequent discussion has resulted in a consensus that it's better to  
throw an error instead of executing the query differently from before,  
so long as we can provide a reasonably clear error message and a way to  
rewrite the query.  
  
Hence, add a parser mechanism to allow detection of such cases during  
parse analysis.  The mechanism just requires storing, in the ParseState,  
a pointer to the set-returning FuncExpr or OpExpr most recently emitted  
by parse analysis.  Then the parsing functions for CASE and COALESCE can  
detect the presence of a SRF in their arguments by noting whether this  
pointer changes while analyzing their arguments.  Furthermore, if it does,  
it provides a suitable error cursor location for the complaint.  (This  
means that if there's more than one SRF in the arguments, the error will  
point at the last one to be analyzed not the first.  While connoisseurs of  
parsing behavior might find that odd, it's unlikely the average user would  
ever notice.)  
  
While at it, we can also provide more specific error messages than before  
about some pre-existing restrictions, such as no-SRFs-within-aggregates.  
Also, reject at parse time cases where a NULLIF or IS DISTINCT FROM  
construct would need to return a set.  We've never supported that, but the  
restriction is depended on in more subtle ways now, so it seems wise to  
detect it at the start.  
  
Also, provide some documentation about how to rewrite a SRF-within-CASE  
query using a custom wrapper SRF.  
  
It turns out that the information_schema.user_mapping_options view  
contained an instance of exactly the behavior we're now forbidding; but  
rewriting it makes it more clear and safer too.  
  
initdb forced because of user_mapping_options change.  
  
Patch by me, with error message suggestions from Alvaro Herrera and  
Andres Freund, pursuant to a complaint from Regina Obe.  
  
Discussion: https://postgr.es/m/000001d2d5de$d8d66170$8a832450$@pcorp.us  
  

doc: Update example version numbers in pg_upgrade documentation

  
commit   : 39da0f709db4d9f16f46be56ae401df72aab93c0    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 13 Jun 2017 16:10:11 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 13 Jun 2017 16:10:11 -0400    

Click here for diff

  
The exact numbers don't matter, since they are examples, but it was  
looking quite dated.  
  
For the target version, we now automatically substitute the current  
major version.  The updated example source version should be good for a  
couple of years.  
  

psql: Use more consistent capitalization of some output headings

  
commit   : 272171279f8676c57b3a8edf7daf792ad55b2c2c    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 13 Jun 2017 14:38:35 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 13 Jun 2017 14:38:35 -0400    

Click here for diff

  
  

Re-run pgindent.

  
commit   : 651902deb1551db8b401fdeab9bdb8a61cee7f9f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 13 Jun 2017 13:05:59 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 13 Jun 2017 13:05:59 -0400    

Click here for diff

  
This is just to have a clean base state for testing of Piotr Stefaniak's  
latest version of FreeBSD indent.  I fixed up a couple of places where  
pgindent would have changed format not-nicely.  perltidy not included.  
  
Discussion: https://postgr.es/m/VI1PR03MB119959F4B65F000CA7CD9F6BF2CC0@VI1PR03MB1199.eurprd03.prod.outlook.com  
  

Always initialize PartitionBoundInfoData’s null_index.

  
commit   : 096f1ccd5290286b135822bb282fa884454d4b69    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Tue, 13 Jun 2017 12:36:45 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Tue, 13 Jun 2017 12:36:45 -0400    

Click here for diff

  
This doesn't actually matter at present, because the current code  
never consults null_index for range partitions.  However, leaving  
it uninitialized is still a bad idea, so let's not do that.  
  
Amul Sul, reviewed by Ashutosh Bapat  
  
Discussion: http://postgr.es/m/CAAJ_b94AkEzcx+12ySCnbMDX7=UdF4BjnoBGfMQbB0RNSTo3Ng@mail.gmail.com  
  

Teach relation_is_updatable() about partitioned tables.

  
commit   : b6263cd851ef245a5dc38119448e029ca1592da4    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Tue, 13 Jun 2017 17:30:36 +0100    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Tue, 13 Jun 2017 17:30:36 +0100    

Click here for diff

  
Table partitioning, introduced in commit f0e44751d7, added a new  
relkind - RELKIND_PARTITIONED_TABLE. Update relation_is_updatable() to  
handle it. Specifically, partitioned tables and simple views built on  
top of them are updatable.  
  
This affects the SQL-callable functions pg_relation_is_updatable() and  
pg_column_is_updatable(), and the views information_schema.views and  
information_schema.columns.  
  
Dean Rasheed, reviewed by Ashutosh Bapat.  
  
Discussion: https://postgr.es/m/CAEZATCXnbiFkMXgF4Ez1pmM2c-tS1z33bSq7OGbw7QQhHov%2B6Q%40mail.gmail.com  
  

libpq: Message style improvements

  
commit   : 2e3fc7a7d322289c70f89199be0a5e899ec7d9b9    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 13 Jun 2017 11:53:26 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 13 Jun 2017 11:53:26 -0400    

Click here for diff

  
  

Fix failure to remove dependencies when a partition is detached.

  
commit   : ee252f074b88e34ff7ac2b45a73d3cee12b1c671    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Tue, 13 Jun 2017 11:51:42 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Tue, 13 Jun 2017 11:51:42 -0400    

Click here for diff

  
Otherwise, dropping the partitioned table will automatically drop  
any previously-detached children, which would be unfortunate.  
  
Ashutosh Bapat and Rahila Syed, reviewed by Amit Langote and by me.  
  
Discussion: http://postgr.es/m/CAFjFpRdOwHuGj45i25iLQ4QituA0uH6RuLX1h5deD4KBZJ25yg@mail.gmail.com  
  

doc: Fix typo

  
commit   : 506b565831e6c88666c18a467377c2f98066ccac    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 13 Jun 2017 11:28:52 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 13 Jun 2017 11:28:52 -0400    

Click here for diff

  
Author: Julien Rouhaud <julien.rouhaud@dalibo.com>  
  

In initdb, defend against assignment of NULL values to not-null columns.

  
commit   : b74701043e396a93f1f18098044741daaf75f761    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 13 Jun 2017 10:54:39 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 13 Jun 2017 10:54:39 -0400    

Click here for diff

  
Previously, you could write _null_ in a BKI DATA line for a column that's  
supposed to be NOT NULL and initdb would let it pass, probably breaking  
subsequent accesses to the row.  No doubt the original coding overlooked  
this simple sanity check because in the beginning we didn't have any way  
to mark catalog columns NOT NULL at initdb time.  
  

Fix typo

  
commit   : f2a886104a6683227bfcb0932dde97d30b123961    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 13 Jun 2017 10:54:03 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 13 Jun 2017 10:54:03 -0400    

Click here for diff

  
Author: Masahiko Sawada <sawada.mshk@gmail.com>  
  

Improve code comments

  
commit   : 88c6cff8e71eccac00fe68f4c15530161b99e6c5    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 13 Jun 2017 10:43:36 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 13 Jun 2017 10:43:36 -0400    

Click here for diff

  
Author: Erik Rijkers <er@xs4all.nl>  
  

Use correct ICU path for Windows 32 vs. 64 bit

  
commit   : ae1aa28eb6a0adb1ae0b36eb25a7d0ee2ee3db0b    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 13 Jun 2017 09:13:32 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 13 Jun 2017 09:13:32 -0400    

Click here for diff

  
Author: Ashutosh Sharma <ashu.coek88@gmail.com>  
  

Fix collprovider of predefined collations

  
commit   : ec7129b7812ce276520f749d0946875663c34093    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 13 Jun 2017 08:55:09 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 13 Jun 2017 08:55:09 -0400    

Click here for diff

  
An earlier version of the patch had collprovider as an integer and thus  
set these to 0, but the correct setting is now null.  
  

pg_dump: Allow dumping default collation

  
commit   : 4955109d2281eacec6af8aee203382ac3991f1cf    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 13 Jun 2017 08:52:48 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 13 Jun 2017 08:52:48 -0400    

Click here for diff

  
This will not work on restore, but it will allow dumping out pg_catalog  
for research and documentation.  
  
Reported-by: Neil Anderson <neil.t.anderson@gmail.com>  
Bug: #14701  
  

Prevent copying default collation

  
commit   : 17082a88eadfca79b50c04c5a78a2c38ee4f5d9c    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 13 Jun 2017 08:49:41 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 13 Jun 2017 08:49:41 -0400    

Click here for diff

  
This will not have the desired effect and might lead to crashes when the  
copied collation is used.  
  
Reported-by: Tom Lane <tgl@sss.pgh.pa.us>  
  

Fix confusion about number of subplans in partitioned INSERT setup.

  
commit   : 78a030a441966d91bc7e932ef84da39c3ea7d970    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 12 Jun 2017 23:29:44 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 12 Jun 2017 23:29:44 -0400    

Click here for diff

  
ExecInitModifyTable() thought there was a plan per partition, but no,  
there's only one.  The problem had escaped detection so far because there  
would only be visible misbehavior if there were a SubPlan (not an InitPlan)  
in the quals being duplicated for each partition.  However, valgrind  
detected a bogus memory access in test cases added by commit 4f7a95be2,  
and investigation of that led to discovery of the bug.  The additional  
test case added here crashes without the patch.  
  
Patch by Amit Langote, test case by me.  
  
Discussion: https://postgr.es/m/10974.1497227727@sss.pgh.pa.us  
  

pg_dump: Fix harmless type mixup

  
commit   : 791ef001c9fe980e32092227a72ec24a7d66fa3d    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 12 Jun 2017 23:06:38 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 12 Jun 2017 23:06:38 -0400    

Click here for diff

  
  

doc: Update external PL list

  
commit   : 2440c442d167d9d081a3e69c4fa78f3b6f8932e9    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 12 Jun 2017 22:34:04 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 12 Jun 2017 22:34:04 -0400    

Click here for diff

  
Add PL/Lua, PL/v8.  
  
Remove stale/unmaintained PL/PHP, PL/Py, PL/Ruby, PL/Scheme.  
  
Reported-by: Adam Sah <asah@midgard.net>  
  

Assert that we don’t invent relfilenodes or type OIDs in binary upgrade.

  
commit   : 7332c3cbb39026e62f4bd0a8acf3df8f701a9e2f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 12 Jun 2017 20:04:32 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 12 Jun 2017 20:04:32 -0400    

Click here for diff

  
During pg_upgrade's restore run, all relfilenode choices should be  
overridden by commands in the dump script.  If we ever find ourselves  
choosing a relfilenode in the ordinary way, someone blew it.  Likewise for  
pg_type OIDs.  Since pg_upgrade might well succeed anyway, if there happens  
not to be a conflict during the regression test run, we need assertions  
here to keep us on the straight and narrow.  
  
We might someday be able to remove the assertion in GetNewRelFileNode,  
if pg_upgrade is rewritten to remove its assumption that old and new  
relfilenodes always match.  But it's hard to see how to get rid of the  
pg_type OID constraint, since those OIDs are embedded in user tables  
in some cases.  
  
Back-patch as far as 9.5, because of the risk of back-patches breaking  
something here even if it works in HEAD.  I'd prefer to go back further,  
but 9.4 fails both assertions due to get_rel_infos()'s use of a temporary  
table.  We can't use the later-branch solution of a CTE for compatibility  
reasons (cf commit 5d16332e9), and it doesn't seem worth inventing some  
other way to do the query.  (I did check, by dint of changing the Asserts  
to elog(WARNING), that there are no other cases of unwanted OID assignments  
during 9.4's regression test run.)  
  
Discussion: https://postgr.es/m/19785.1497215827@sss.pgh.pa.us  
  

Fix ALTER SEQUENCE OWNED BY to not rewrite the sequence relation.

  
commit   : a475e46634dc7abde1d5a6fc7aaa708219383004    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 12 Jun 2017 16:57:31 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 12 Jun 2017 16:57:31 -0400    

Click here for diff

  
It's not necessary for it to do that, since OWNED BY requires only ordinary  
catalog updates and doesn't affect future sequence values.  And pg_upgrade  
needs to use OWNED BY without having it change the sequence's relfilenode.  
Commit 3d79013b9 broke this by making all forms of ALTER SEQUENCE change  
the relfilenode; that seems to be the explanation for the hard-to-reproduce  
buildfarm failures we've been seeing since then.  
  
Discussion: https://postgr.es/m/19785.1497215827@sss.pgh.pa.us  
  

doc: Update information_schema documentation for identity columns

  
commit   : 5d8beac8bee344bdf4b05a63b93f06e05d999b39    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 12 Jun 2017 16:20:12 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 12 Jun 2017 16:20:12 -0400    

Click here for diff

  
This was apparently forgotten in the original patch.  
  

Add ICU_CFLAGS to global CPPFLAGS

  
commit   : 94c2ed0ebe005aa6389b02a61e3c16d08035299c    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 12 Jun 2017 15:57:22 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 12 Jun 2017 15:57:22 -0400    

Click here for diff

  
The original code only added ICU_CFLAGS to the backend build.  But it is  
also needed for building external modules that include pg_locale.h.  So  
add it to the global CPPFLAGS.  (This is only relevant if ICU is not in  
a compiler default path, so it apparently hasn't bitten many.)  
  

Remove “synchronized table states” notice message

  
commit   : 7f28a7946a37e1716fe12c9e8466dbb868292087    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 12 Jun 2017 11:42:06 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 12 Jun 2017 11:42:06 -0400    

Click here for diff

  
It appears to be more confusing than useful.  
  
Reported-by: Jeff Janes <jeff.janes@gmail.com>  
  

Add MSVC build system support for ICU

  
commit   : 03c396080ddc77b188a11dd54aa2a075ab2718e0    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 12 Jun 2017 11:05:20 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 12 Jun 2017 11:05:20 -0400    

Click here for diff

  
Author: Ashutosh Sharma <ashu.coek88@gmail.com>  
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>  
  

Fix build of ICU support in Windows

  
commit   : 253504fb9f804b6aa7cec9b9b2506fa88accf0dc    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 12 Jun 2017 10:28:37 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 12 Jun 2017 10:28:37 -0400    

Click here for diff

  
and also any platform that does not have locale_t but enabled ICU.  
  
Author: Ashutosh Sharma <ashu.coek88@gmail.com>  
  

Trim trailing whitespace

  
commit   : bf6e4c3c82d349dc311ef795cc8eb7a9badf49eb    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 12 Jun 2017 09:51:18 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 12 Jun 2017 09:51:18 -0400    

Click here for diff

  
  

Stop table sync workers when subscription relation entry is removed

  
commit   : ddd7b22b225ae41d16ceb218b387645cb9becfdc    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 9 Jun 2017 09:47:52 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 9 Jun 2017 09:47:52 -0400    

Click here for diff

  
When a table sync worker is in waiting state and the subscription table  
entry is removed because of a concurrent subscription refresh, the  
worker could be left orphaned.  To avoid that, explicitly stop the  
worker when the pg_subscription_rel entry is removed.  
  
Reported-by: Masahiko Sawada <sawada.mshk@gmail.com>  
  

Fix ALTER TABLE doc examples.

  
commit   : eab86897bd8cbeb21ae8959ca9a095ce7cb663df    
  
author   : Tatsuo Ishii <ishii@postgresql.org>    
date     : Mon, 12 Jun 2017 14:49:25 +0900    
  
committer: Tatsuo Ishii <ishii@postgresql.org>    
date     : Mon, 12 Jun 2017 14:49:25 +0900    

Click here for diff

  
Patch by Yugo Nagata <nagata@sraoss.co.jp>.  Confirmed by Amit  
Langote, who is the original author of the document part.  
  

Handle unqualified SEQUENCE NAME options properly in parse_utilcmd.c.

  
commit   : 51893985d3bcf27304283f7fa67f17e017d2dafd    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 11 Jun 2017 19:00:01 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 11 Jun 2017 19:00:01 -0400    

Click here for diff

  
generateSerialExtraStmts() was sloppy about handling the case where  
SEQUENCE NAME is given with a not-schema-qualified name.  It was generating  
a CreateSeqStmt with an unqualified sequence name, and an AlterSeqStmt  
whose "owned_by" DefElem contained a T_String Value with a null string  
pointer in the schema-name position.  The generated nextval() argument was  
also underqualified.  This accidentally failed to fail at runtime, but only  
so long as the current default creation namespace at runtime is the right  
namespace.  That's bogus; the parse-time transformation is supposed to be  
inserting the right schema name in all cases, so as to avoid any possible  
skew in that selection.  I'm not sure this could fail in pg_dump's usage,  
but it's still wrong; we have had real bugs in this area before adopting  
the policy that parse_utilcmd.c should generate only fully-qualified  
auxiliary commands.  A slightly lesser problem, which is what led me to  
notice this in the first place, is that pprint() dumped core on the  
AlterSeqStmt because of the bogus T_String.  
  
Noted while poking into the open problem with ALTER SEQUENCE breaking  
pg_upgrade.  
  

Apply RLS policies to partitioned tables.

  
commit   : 4f7a95be2c112bdc8da5f7e46cbb743b8ba4cc21    
  
author   : Joe Conway <mail@joeconway.com>    
date     : Sun, 11 Jun 2017 08:51:18 -0700    
  
committer: Joe Conway <mail@joeconway.com>    
date     : Sun, 11 Jun 2017 08:51:18 -0700    

Click here for diff

  
The new partitioned table capability added a new relkind, namely  
RELKIND_PARTITIONED_TABLE. Update fireRIRrules() to apply RLS  
policies on RELKIND_PARTITIONED_TABLE as it does RELKIND_RELATION.  
  
In addition, add RLS regression test coverage for partitioned tables.  
  
Issue raised by Fakhroutdinov Evgenievich and patch by Mike Palmiotto.  
Regression test editorializing by me.  
  
Discussion: https://postgr.es/m/flat/20170601065959.1486.69906@wrigleys.postgresql.org  
  

Take PROVE_FLAGS from the command line but not the environment

  
commit   : 93b7d9731f184e764c642266ecd74be24db73a6e    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Sat, 10 Jun 2017 10:19:06 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Sat, 10 Jun 2017 10:19:06 -0400    

Click here for diff

  
This reverts commit 56b6ef893fee9e9bf47d927a02f4d1ea911f4d9c and instead  
makes vcregress.pl parse out PROVE_FLAGS from a command line argument  
when doing a TAP test, thus making it consistent with the makefile  
treatment.  
  
Discussion: https://postgr.es/m/c26a7416-2fb9-34ab-7991-618c922f896e%402ndquadrant.com  
  
Backpatch to 9.4 like previous patch.  
  

doc: Add Node.js and Go drivers to client interfaces

  
commit   : e20f679f66fb7930215a1b59f13b5b1c06bfc456    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 9 Jun 2017 20:34:27 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 9 Jun 2017 20:34:27 -0400    

Click here for diff

  
Also, fix client interface JDBC language name to Java.  
  
Author: Sehrope Sarkuni <sehrope@jackdb.com>  
  

doc: Improve types in example

  
commit   : 0332993c4e14f13b211f41535f77aadb305fd354    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 9 Jun 2017 19:49:18 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 9 Jun 2017 19:49:18 -0400    

Click here for diff

  
Reported-by: Nikolaus Thiel <klt@fsfe.org>  
  

doc: Document that subscriptions to same server might hang

  
commit   : 0933fcee9851eb2afcd41db1ee4425153f4cbdd3    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 9 Jun 2017 17:11:46 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 9 Jun 2017 17:11:46 -0400    

Click here for diff

  
  

Silence warning about uninitialized ‘ret’ variable on some compilers.

  
commit   : 493490cbcb19c5232038827b114a4ec72aa3e731    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 9 Jun 2017 21:50:35 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 9 Jun 2017 21:50:35 +0300    

Click here for diff

  
If the compiler doesn't notice that the switch-statement handles all  
possible values of the enum, it might complain that 'ret' is being used  
without initialization. Jeff Janes reported that on gcc 4.4.7.  
  
Discussion: https://www.postgresql.org/message-id/CAMkU=1x31RvP+cpooFbmc8K8nt-gNO8woGFhXcgQYYZ5ozYpFA@mail.gmail.com  
  

Formatting improvements in config file samples

  
commit   : e11e24b1ed619ca329a532e5e5ae8b4e5e728f71    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 9 Jun 2017 14:38:33 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 9 Jun 2017 14:38:33 -0400    

Click here for diff

  
  

Update code comments

  
commit   : 8c9387c55e67ca7c23bb8ffd7e8342cca7be127b    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 9 Jun 2017 14:04:22 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 9 Jun 2017 14:04:22 -0400    

Click here for diff

  
Author: Neha Khatri <nehakhatri5@gmail.com>  
  

Fix typo

  
commit   : dabbe8d56470f456e997700efa7d592306ca4274    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 9 Jun 2017 11:40:08 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 9 Jun 2017 11:40:08 -0400    

Click here for diff

  
Author: Masahiko Sawada <sawada.mshk@gmail.com>  
  

psql: Update tab completion for ALTER SUBSCRIPTION

  
commit   : 57f2ff00d7e25ffe33d7e2955428c005d2511277    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 9 Jun 2017 10:17:06 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 9 Jun 2017 10:17:06 -0400    

Click here for diff

  
Author: Masahiko Sawada <sawada.mshk@gmail.com>  
  

Improve tablesync behavior with concurrent changes

  
commit   : 8dc7c338129d22a52d4afcf2f83a73041119efda    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 9 Jun 2017 09:20:54 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 9 Jun 2017 09:20:54 -0400    

Click here for diff

  
When a table is removed from a subscription before the tablesync worker  
could start, this would previously result in an error when reading  
pg_subscription_rel.  Now we just ignore this.  
  
Author: Masahiko Sawada <sawada.mshk@gmail.com>  
  

Give a better error message on invalid hostaddr option.

  
commit   : 76b11e8a43eca4612dfccfe7f3ebd293fb8a46ec    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 9 Jun 2017 13:05:41 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 9 Jun 2017 13:05:41 +0300    

Click here for diff

  
If you accidentally pass a host name in the hostaddr option, e.g.  
hostaddr=localhost, you get an error like:  
  
psql: could not translate host name "localhost" to address: Name or service not known  
  
That's a bit confusing, because it implies that we tried to look up  
"localhost" in DNS, but it failed. To make it more clear that we tried to  
parse "localhost" as a numeric network address, change the message to:  
  
psql: could not parse network address "localhost": Name or service not known  
  
Discussion: https://www.postgresql.org/message-id/10badbc6-4d5a-a769-623a-f7ada43e14dd@iki.fi  
  

Fix script name in README.

  
commit   : 67d370e619897ace44285b1fe10fd788119242ac    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 9 Jun 2017 12:05:03 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 9 Jun 2017 12:05:03 +0300    

Click here for diff

  
The script was rewritten in Perl, and renamed from regress.sh to regress.pl,  
back in 2012.  
  

Use standard interrupt handling in logical replication launcher.

  
commit   : 2c48f5db64b1b999b08052115a5ce873343c372a    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Thu, 8 Jun 2017 15:00:53 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Thu, 8 Jun 2017 15:00:53 -0700    

Click here for diff

  
Previously the exit handling was only able to exit from within the  
main loop, and not from within the backend code it calls.  Fix that by  
using the standard die() SIGTERM handler, and adding the necessary  
CHECK_FOR_INTERRUPTS() call.  
  
This requires adding yet another process-type-specific branch to  
ProcessInterrupts(), which hints that we probably should generalize  
that handling.  But that's work for another day.  
  
Author: Petr Jelinek  
Reviewed-By: Andres Freund  
Discussion: https://postgr.es/m/fe072153-babd-3b5d-8052-73527a6eb657@2ndquadrant.com  
  

Again report a useful error message when walreceiver’s connection closes.

  
commit   : 5fd56b9f5b4a007a4122c313a184f78f1647c4ab    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Thu, 8 Jun 2017 14:42:18 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Thu, 8 Jun 2017 14:42:18 -0700    

Click here for diff

  
Since 7c4f52409a8c (merged in v10), a shutdown master is reported as  
  FATAL:  unexpected result after CommandComplete: server closed the connection unexpectedly  
by walsender. It used to be  
  LOG:  replication terminated by primary server  
  FATAL:  could not send end-of-streaming message to primary: no COPY in progress  
while the old message clearly is not perfect, it's definitely better  
than what's reported now.  
  
The change comes from the attempt to handle finished COPYs without  
erroring out, needed for the new logical replication, which wasn't  
needed before.  
  
There's probably better ways to handle this, but for now just  
explicitly check for a closed connection.  
  
Author: Petr Jelinek  
Reviewed-By: Andres Freund  
Discussion: https://postgr.es/m/f7c7dd08-855c-e4ed-41f4-d064a6c0665a@2ndquadrant.com  
Backpatch: -  
  

Update key words table for version 10

  
commit   : 5c4109f2c8c2027114cfdc7c0617f81928a0b10e    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 8 Jun 2017 17:19:50 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 8 Jun 2017 17:19:50 -0400    

Click here for diff

  
  

Mark to_tsvector(regconfig,json[b]) functions immutable

  
commit   : f7e6853e1a2ee2badd988f5e49e4ceb6a2b15b7f    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Thu, 8 Jun 2017 15:47:10 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Thu, 8 Jun 2017 15:47:10 -0400    

Click here for diff

  
This make them consistent with the text function and means they can be  
used in functional indexes.  
  
Catalog version bumped.  
  
Per gripe from Josh Berkus.  
  

Fix bit-rot in pg_upgrade’s test.sh, and improve documentation.

  
commit   : 5bab1985dfc25eecf4b098145789955c0b246160    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 8 Jun 2017 13:48:27 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 8 Jun 2017 13:48:27 -0400    

Click here for diff

  
Doing a cross-version upgrade test with test.sh evidently hasn't been  
tested since circa 9.2, because the script lacked case branches for  
old-version servers newer than 9.1.  Future-proof that a bit, and  
clean up breakage induced by our recent drop of V0 function call  
protocol (namely that oldstyle_length() isn't in the regression  
suite anymore).  
  
(This isn't enough to make the test work perfectly cleanly across  
versions, but at least it finishes and provides dump files that  
you can diff manually.  One issue I didn't touch is that we might  
want to execute the "reindex_hash.sql" file in the new DB before  
dumping it, so that the hash indexes don't vanish from the dump.)  
  
Improve the TESTING doc file: put the tl;dr version at the top not  
the bottom, and bring its explanation of how to run a cross-version  
test up to speed, since the installcheck target isn't there and won't  
be resurrected.  Improve the comment in the Makefile about why not.  
  
In passing, teach .gitignore and "make clean" about a couple more  
junk output files.  
  
Discussion: https://postgr.es/m/14058.1496892482@sss.pgh.pa.us  
  

Improve authentication error messages.

  
commit   : e3df8f8b93e77c33fa7abb6aca64e07531592130    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 8 Jun 2017 19:54:22 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 8 Jun 2017 19:54:22 +0300    

Click here for diff

  
Most of the improvements were in the new SCRAM code:  
  
* In SCRAM protocol violation messages, use errdetail to provide the  
  details.  
  
* If pg_backend_random() fails, throw an ERROR rather than just LOG. We  
  shouldn't continue authentication if we can't generate a random nonce.  
  
* Use ereport() rather than elog() for the "invalid SCRAM verifier"  
  messages. They shouldn't happen, if everything works, but it's not  
  inconceivable that someone would have invalid scram verifiers in  
  pg_authid, e.g. if a broken client application was used to generate the  
  verifier.  
  
But this change applied to old code:  
  
* Use ERROR rather than COMMERROR for protocol violation errors. There's  
  no reason to not tell the client what they did wrong. The client might be  
  confused already, so that it cannot read and display the error correctly,  
  but let's at least try. In the "invalid password packet size" case, we  
  used to actually continue with authentication anyway, but that is now a  
  hard error.  
  
Patch by Michael Paquier and me. Thanks to Daniel Varrazzo for spotting  
the typo in one of the messages that spurred the discussion and these  
larger changes.  
  
Discussion: https://www.postgresql.org/message-id/CA%2Bmi_8aZYLhuyQi1Jo0hO19opNZ2OEATEOM5fKApH7P6zTOZGg%40mail.gmail.com  
  

Put new command-line options in alphabetical order

  
commit   : 7ff9812f9aef584b6ee076378d77a09a68f12d97    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 8 Jun 2017 12:12:31 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 8 Jun 2017 12:12:31 -0400    

Click here for diff

  
  

Add statistics subdirectory to Makefile.

  
commit   : 0eac8e7ff7ebb807f479dd10aa7c88b799a7e319    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Thu, 8 Jun 2017 11:28:45 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Thu, 8 Jun 2017 11:28:45 -0400    

Click here for diff

  
Commit 7b504eb282ca2f5104b5c00b4f05a3ef6bb1385b overlooked this.  
  
Report and patch by Kyotaro Horiguchi  
  
Discussion: http://postgr.es/m/20170608.145852.54673832.horiguchi.kyotaro@lab.ntt.co.jp  
  

Fix contrib/sepgsql regr tests for tup-routing constraint check change.

  
commit   : 06c0afe56e7aa6e8ab9ea2dd92bac2220201affe    
  
author   : Joe Conway <mail@joeconway.com>    
date     : Wed, 7 Jun 2017 17:54:33 -0700    
  
committer: Joe Conway <mail@joeconway.com>    
date     : Wed, 7 Jun 2017 17:54:33 -0700    

Click here for diff

  
Commit 15ce775 changed tuple-routing constraint checking logic.  
This affects the expected output for contrib/sepgsql, because  
there's no longer LOG entries reporting allowance of int4eq()  
execution. Per buildfarm.  
  

Docs: improve CREATE TABLE ref page’s discussion of partition bounds.

  
commit   : 0198c277a29a035aa8a4e6767967201135f6caa9    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 7 Jun 2017 17:23:38 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 7 Jun 2017 17:23:38 -0400    

Click here for diff

  
Clarify in the syntax synopsis that partition bound values must be  
exactly numeric literals or string literals; previously it  
said "bound_literal" which was defined nowhere.  
  
Replace confusing --- and, I think, incorrect in detail --- definition  
of how range bounds work with a reference to row-wise comparison plus  
a concrete example (which I stole from Robert Haas).  
  
Minor copy-editing in the same area.  
  
Discussion: https://postgr.es/m/30475.1496005465@sss.pgh.pa.us  
Discussion: https://postgr.es/m/28106.1496041449@sss.pgh.pa.us  
  

postgres_fdw: Allow cancellation of transaction control commands.

  
commit   : ae9bfc5d65123aaa0d1cca9988037489760bdeae    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Wed, 7 Jun 2017 15:14:55 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Wed, 7 Jun 2017 15:14:55 -0400    

Click here for diff

  
Commit f039eaac7131ef2a4cf63a10cf98486f8bcd09d2, later back-patched  
with commit 1b812afb0eafe125b820cc3b95e7ca03821aa675, allowed many of  
the queries issued by postgres_fdw to fetch remote data to respond to  
cancel interrupts in a timely fashion.  However, it didn't do anything  
about the transaction control commands, which remained  
noninterruptible.  
  
Improve the situation by changing do_sql_command() to retrieve query  
results using pgfdw_get_result(), which uses the asynchronous  
interface to libpq so that it can check for interrupts every time  
libpq returns control.  Since this might result in a situation  
where we can no longer be sure that the remote transaction state  
matches the local transaction state, add a facility to force all  
levels of the local transaction to abort if we've lost track of  
the remote state; without this, an apparently-successful commit of  
the local transaction might fail to commit changes made on the  
remote side.  Also, add a 60-second timeout for queries issue during  
transaction abort; if that expires, give up and mark the state of  
the connection as unknown.  Drop all such connections when we exit  
the local transaction.  Together, these changes mean that if we're  
aborting the local toplevel transaction anyway, we can just drop the  
remote connection in lieu of waiting (possibly for a very long time)  
for it to complete an abort.  
  
This still leaves quite a bit of room for improvement.  PQcancel()  
has no asynchronous interface, so if we get stuck sending the cancel  
request we'll still hang.  Also, PQsetnonblocking() is not used, which  
means we could block uninterruptibly when sending a query.  There  
might be some other optimizations possible as well.  Nonetheless,  
this allows us to escape a wait for an unresponsive remote server  
quickly in many more cases than previously.  
  
Report by Suraj Kharage.  Patch by me and Rafia Sabih.  Review  
and testing by Amit Kapila and Tushar Ahuja.  
  
Discussion: http://postgr.es/m/CAF1DzPU8Kx+fMXEbFoP289xtm3bz3t+ZfxhmKavr98Bh-C0TqQ@mail.gmail.com  
  

Fix updating of pg_subscription_rel from workers

  
commit   : 644ea35fc1352d845299563c7ddfb8b524ed27d9    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 7 Jun 2017 13:49:14 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 7 Jun 2017 13:49:14 -0400    

Click here for diff

  
A logical replication worker should not insert new rows into  
pg_subscription_rel, only update existing rows, so that there are no  
races if a concurrent refresh removes rows.  Adjust the API to be able  
to choose that behavior.  
  
Author: Masahiko Sawada <sawada.mshk@gmail.com>  
Reported-by: tushar <tushar.ahuja@enterprisedb.com>  
  

Prevent BEFORE triggers from violating partitioning constraints.

  
commit   : 15ce775faa428dc91027e4e2d6b7a167a27118b5    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Wed, 7 Jun 2017 12:45:32 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Wed, 7 Jun 2017 12:45:32 -0400    

Click here for diff

  
Since tuple-routing implicitly checks the partitioning constraints  
at least for the levels of the partitioning hierarchy it traverses,  
there's normally no need to revalidate the partitioning constraint  
after performing tuple routing.  However, if there's a BEFORE trigger  
on the target partition, it could modify the tuple, causing the  
partitioning constraint to be violated.  Catch that case.  
  
Also, instead of checking the root table's partition constraint after  
tuple-routing, check it beforehand.  Otherwise, the rules for when  
the partitioning constraint gets checked get too complicated, because  
you sometimes have to check part of the constraint but not all of it.  
This effectively reverts commit 39162b2030fb0a35a6bb28dc636b5a71b8df8d1c  
in favor of a different approach altogether.  
  
Report by me.  Initial debugging by Jeevan Ladhe.  Patch by Amit  
Langote, reviewed by me.  
  
Discussion: http://postgr.es/m/CA+Tgmoa9DTgeVOqopieV8d1QRpddmP65aCdxyjdYDoEO5pS5KA@mail.gmail.com  
  

Clear auth context correctly when re-connecting after failed auth attempt.

  
commit   : e6c33d594a004a2c831cdff1a16276347d30f703    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 7 Jun 2017 14:01:46 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 7 Jun 2017 14:01:46 +0300    

Click here for diff

  
If authentication over an SSL connection fails, with sslmode=prefer,  
libpq will reconnect without SSL and retry. However, we did not clear  
the variables related to GSS, SSPI, and SASL authentication state, when  
reconnecting. Because of that, the second authentication attempt would  
always fail with a "duplicate GSS/SASL authentication request" error.  
pg_SSPI_startup did not check for duplicate authentication requests like  
the corresponding GSS and SASL functions, so with SSPI, you would leak  
some memory instead.  
  
Another way this could manifest itself, on version 10, is if you list  
multiple hostnames in the "host" parameter. If the first server requests  
Kerberos or SCRAM authentication, but it fails, the attempts to connect to  
the other servers will also fail with "duplicate authentication request"  
errors.  
  
To fix, move the clearing of authentication state from closePGconn to  
pgDropConnection, so that it is cleared also when re-connecting.  
  
Patch by Michael Paquier, with some kibitzing by me.  
  
Backpatch down to 9.3. 9.2 has the same bug, but the code around closing  
the connection is somewhat different, so that this patch doesn't apply.  
To fix this in 9.2, I think we would need to back-port commit 210eb9b743  
first, and then apply this patch. However, given that we only bumped into  
this in our own testing, we haven't heard any reports from users about  
this, and that 9.2 will be end-of-lifed in a couple of months anyway, it  
doesn't seem worth the risk and trouble.  
  
Discussion: https://www.postgresql.org/message-id/CAB7nPqRuOUm0MyJaUy9L3eXYJU3AKCZ-0-03=-aDTZJGV4GyWw@mail.gmail.com  
  

Fix double-free bug in GSS authentication.

  
commit   : 3344582e6f1605d69bef008c4e489cafd9610cfe    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 7 Jun 2017 09:42:29 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 7 Jun 2017 09:42:29 +0300    

Click here for diff

  
The logic to free the buffer after the gss_init_sec_context() call was  
always a bit wonky. Because gss_init_sec_context() sets the GSS context  
variable, conn->gctx, we would in fact always attempt to free the buffer.  
That only works, because previously conn->ginbuf.value was initialized to  
NULL, and free(NULL) is a no-op. Commit 61bf96cab0 refactored things so  
that the GSS input token buffer is allocated locally in pg_GSS_continue,  
and not held in the PGconn object. After that, the now-local ginbuf.value  
variable isn't initialized when it's not used, so we pass a bogus pointer  
to free().  
  
To fix, only try to free the input buffer if we allocated it. That was the  
intention, certainly after the refactoring, and probably even before that.  
But because there's no live bug before the refactoring, I refrained from  
backpatching this.  
  
The bug was also independently reported by Graham Dutton, as bug #14690.  
Patch reviewed by Michael Paquier.  
  
Discussion: https://www.postgresql.org/message-id/6288d80e-a0bf-d4d3-4e12-7b79c77f1771%40iki.fi  
Discussion: https://www.postgresql.org/message-id/20170605130954.1438.90535%40wrigleys.postgresql.org  
  

Consistently use subscription name as application name

  
commit   : d4bfc06e292ee2f537f42d4ed216209c4537ee92    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 6 Jun 2017 21:51:31 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 6 Jun 2017 21:51:31 -0400    

Click here for diff

  
The logical replication apply worker uses the subscription name as  
application name, except for table sync.  This was incorrectly set to  
use the replication slot name, which might be different, in one case.  
Also add a comment why the other case is different.  
  

  
commit   : 9206ced1dc05d3a9cc99faafa22d5d8b16d998d1    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Tue, 6 Jun 2017 16:13:00 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Tue, 6 Jun 2017 16:13:00 -0700    

Click here for diff

  
The larger part of this patch replaces usages of MyProc->procLatch  
with MyLatch.  The latter works even early during backend startup,  
where MyProc->procLatch doesn't yet.  While the affected code  
shouldn't run in cases where it's not initialized, it might get copied  
into places where it might.  Using MyLatch is simpler and a bit faster  
to boot, so there's little point to stick with the previous coding.  
  
While doing so I noticed some weaknesses around newly introduced uses  
of latches that could lead to missed events, and an omitted  
CHECK_FOR_INTERRUPTS() call in worker_spi.  
  
As all the actual bugs are in v10 code, there doesn't seem to be  
sufficient reason to backpatch this.  
  
Author: Andres Freund  
Discussion:  
    https://postgr.es/m/20170606195321.sjmenrfgl2nu6j63@alap3.anarazel.de  
    https://postgr.es/m/20170606210405.sim3yl6vpudhmufo@alap3.anarazel.de  
Backpatch: -  
  

Improve handover logic between sync and apply workers

  
commit   : e3a815d2faa5be28551e71d5db44fb2c78133433    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 6 Jun 2017 14:38:44 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 6 Jun 2017 14:38:44 -0400    

Click here for diff

  
Make apply busy wait check the catalog instead of shmem state to ensure  
that next transaction will see the expected table synchronization state.  
  
Also make the handover always go through same set of steps to make the  
overall process easier to understand and debug.  
  
Author: Petr Jelinek <petr.jelinek@2ndquadrant.com>  
Tested-by: Mark Kirkwood <mark.kirkwood@catalyst.net.nz>  
Tested-by: Erik Rijkers <er@xs4all.nl>  
  

Fix some cases of “the the” split across two lines.

  
commit   : 79c4fa0f62291fd30d126a12f35b9ce71f06b3c0    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Tue, 6 Jun 2017 12:24:44 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Tue, 6 Jun 2017 12:24:44 -0400    

Click here for diff

  
Kevin Grittner observed that 2186b608b3cb859fe0ec04015a5c4e4cbf69caed  
introduced a new occurence of this by copying existing text, and I  
found a few more cases using grep.  
  
Discussion: http://postgr.es/m/CADAecHWfG-K+YvocHCkrXV-ycm+eUOaaUVfYZNOnwf0pSmuQCw@mail.gmail.com  
  

Use NIL rather than NULL to represent an empty list.

  
commit   : 3106829513ab7c8e46e94db103f1ef8d8dfd379b    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Tue, 6 Jun 2017 11:21:22 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Tue, 6 Jun 2017 11:21:22 -0400    

Click here for diff

  
Just to be tidy.  
  
Amit Langote  
  
Discussion: http://postgr.es/m/9297f80f-e4ab-7dda-33d4-8580bab6d634@lab.ntt.co.jp  
  

Clean up partcollation handling for OID 0.

  
commit   : 2186b608b3cb859fe0ec04015a5c4e4cbf69caed    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Tue, 6 Jun 2017 11:07:20 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Tue, 6 Jun 2017 11:07:20 -0400    

Click here for diff

  
Consistent with what we do for indexes, we shouldn't try to record  
dependencies on collation OID 0 or the default collation OID (which  
is pinned).  Also, the fact that indcollation and partcollation can  
contain zero OIDs when the data type is not collatable should be  
documented.  
  
Amit Langote, per a complaint from me.  
  
Discussion: http://postgr.es/m/CA+Tgmoba5mtPgM3NKfG06vv8na5gGbVOj0h4zvivXQwLw8wXXQ@mail.gmail.com  
  

Fix docs to not claim ECPG’s SET CONNECTION is not thread-aware.

  
commit   : 0f33ee0e3b7527fb0c88abf0ae8a49a9c38d9c0e    
  
author   : Michael Meskes <meskes@postgresql.org>    
date     : Tue, 6 Jun 2017 12:19:28 +0200    
  
committer: Michael Meskes <meskes@postgresql.org>    
date     : Tue, 6 Jun 2017 12:19:28 +0200    

Click here for diff

  
Changed by: Tsunakawa, Takayuki <tsunakawa.takay@jp.fujitsu.com>  
  

Wire up query cancel interrupt for walsender backends.

  
commit   : c1abe6c786d8f00643de8519140d77644b474163    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 5 Jun 2017 18:53:41 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Mon, 5 Jun 2017 18:53:41 -0700    

Click here for diff

  
This allows to cancel commands run over replication connections. While  
it might have some use before v10, it has become important now that  
normal SQL commands are allowed in database connected walsender  
connections.  
  
Author: Petr Jelinek  
Reviewed-By: Andres Freund, Michael Paquier  
Discussion: https://postgr.es/m/7966f454-7cd7-2b0c-8b70-cdca9d5a8c97@2ndquadrant.com  
  

Unify SIGHUP handling between normal and walsender backends.

  
commit   : 6e1dd2773eb60a6ab87b27b8d9391b756e904ac3    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 5 Jun 2017 18:53:41 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Mon, 5 Jun 2017 18:53:41 -0700    

Click here for diff

  
Because walsender and normal backends share the same main loop it's  
problematic to have two different flag variables, set in signal  
handlers, indicating a pending configuration reload.  Only certain  
walsender commands reach code paths checking for the  
variable (START_[LOGICAL_]REPLICATION, CREATE_REPLICATION_SLOT  
... LOGICAL, notably not base backups).  
  
This is a bug present since the introduction of walsender, but has  
gotten worse in releases since then which allow walsender to do more.  
  
A later patch, not slated for v10, will similarly unify SIGHUP  
handling in other types of processes as well.  
  
Author: Petr Jelinek, Andres Freund  
Reviewed-By: Michael Paquier  
Discussion: https://postgr.es/m/20170423235941.qosiuoyqprq4nu7v@alap3.anarazel.de  
Backpatch: 9.2-, bug is present since 9.0  
  

Prevent possibility of panics during shutdown checkpoint.

  
commit   : c6c333436491a292d56044ed6e167e2bdee015a2    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 5 Jun 2017 18:53:41 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Mon, 5 Jun 2017 18:53:41 -0700    

Click here for diff

  
When the checkpointer writes the shutdown checkpoint, it checks  
afterwards whether any WAL has been written since it started and  
throws a PANIC if so.  At that point, only walsenders are still  
active, so one might think this could not happen, but walsenders can  
also generate WAL, for instance in BASE_BACKUP and logical decoding  
related commands (e.g. via hint bits).  So they can trigger this panic  
if such a command is run while the shutdown checkpoint is being  
written.  
  
To fix this, divide the walsender shutdown into two phases.  First,  
checkpointer, itself triggered by postmaster, sends a  
PROCSIG_WALSND_INIT_STOPPING signal to all walsenders.  If the backend  
is idle or runs an SQL query this causes the backend to shutdown, if  
logical replication is in progress all existing WAL records are  
processed followed by a shutdown.  Otherwise this causes the walsender  
to switch to the "stopping" state. In this state, the walsender will  
reject any further replication commands. The checkpointer begins the  
shutdown checkpoint once all walsenders are confirmed as  
stopping. When the shutdown checkpoint finishes, the postmaster sends  
us SIGUSR2. This instructs walsender to send any outstanding WAL,  
including the shutdown checkpoint record, wait for it to be replicated  
to the standby, and then exit.  
  
Author: Andres Freund, based on an earlier patch by Michael Paquier  
Reported-By: Fujii Masao, Andres Freund  
Reviewed-By: Michael Paquier  
Discussion: https://postgr.es/m/20170602002912.tqlwn4gymzlxpvs2@alap3.anarazel.de  
Backpatch: 9.4, where logical decoding was introduced  
  

Have walsenders participate in procsignal infrastructure.

  
commit   : 47fd420fb4d3e77dde960312f8672c82b14ecbad    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 5 Jun 2017 18:53:41 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Mon, 5 Jun 2017 18:53:41 -0700    

Click here for diff

  
The non-participation in procsignal was a problem for both changes in  
master, e.g. parallelism not working for normal statements run in  
walsender backends, and older branches, e.g. recovery conflicts and  
catchup interrupts not working for logical decoding walsenders.  
  
This commit thus replaces the previous WalSndXLogSendHandler with  
procsignal_sigusr1_handler.  In branches since db0f6cad48 that can  
lead to additional SetLatch calls, but that only rarely seems to make  
a difference.  
  
Author: Andres Freund  
Reviewed-By: Michael Paquier  
Discussion: https://postgr.es/m/20170421014030.fdzvvvbrz4nckrow@alap3.anarazel.de  
Backpatch: 9.4, earlier commits don't seem to benefit sufficiently  
  

Revert “Prevent panic during shutdown checkpoint”

  
commit   : 703f148e98ecb4b299fdad403fc5a1de51220714    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 5 Jun 2017 18:53:41 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Mon, 5 Jun 2017 18:53:41 -0700    

Click here for diff

  
This reverts commit 086221cf6b1727c2baed4703c582f657b7c5350e, which  
was made to master only.  
  
The approach implemented in the above commit has some issues.  While  
those could easily be fixed incrementally, doing so would make  
backpatching considerably harder, so instead first revert this patch.  
  
Discussion: https://postgr.es/m/20170602002912.tqlwn4gymzlxpvs2@alap3.anarazel.de  
  

Don’t set application_name in logical replication workers

  
commit   : 41a21bf9b4a2449eddc8ea2b29597e835eea9bfd    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 5 Jun 2017 22:16:02 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 5 Jun 2017 22:16:02 -0400    

Click here for diff

  
This was bothering some people because it's not the intended use of  
application_name and it makes the default view of pg_stat_activity  
bulky.  
  

Fix ALTER SUBSCRIPTION grammar ambiguity

  
commit   : 9907b55ceb17f55bb508a1f24027a57530d84442    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 5 Jun 2017 21:37:00 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 5 Jun 2017 21:37:00 -0400    

Click here for diff

  
There was a grammar ambiguity between SET PUBLICATION name REFRESH and  
SET PUBLICATION SKIP REFRESH, because SKIP is not a reserved word.  To  
resolve that, fold the refresh choice into the WITH options.  Refreshing  
is the default now.  
  
Reported-by: tushar <tushar.ahuja@enterprisedb.com>  
  

Ignore WL_POSTMASTER_DEATH latch event in single user mode

  
commit   : 06bfb801c73c89e66f44c1cf693386793e98b637    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 2 Jun 2017 23:02:13 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 2 Jun 2017 23:02:13 -0400    

Click here for diff

  
Otherwise code that uses this will abort with an assertion failure,  
because postmaster_alive_fds are not initialized.  
  
Reported-by: tushar <tushar.ahuja@enterprisedb.com>  
  

Fix thinko in previous openssl change

  
commit   : 2e02136fe688046cd3b3c0bbcdd6ba970932ec8e    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 5 Jun 2017 20:38:46 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 5 Jun 2017 20:38:46 -0400    

Click here for diff

  
  

Fix record length computation in pg_waldump/xlogdump.

  
commit   : c25ed20067d21a97242a023031fcdcc232d6945c    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 5 Jun 2017 15:56:58 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Mon, 5 Jun 2017 15:56:58 -0700    

Click here for diff

  
The current method of computing the record length (excluding the  
lenght of full-page images) has been wrong since the WAL format has  
been revamped in 2c03216d831160bedd72d45f712601b6f7d03f1c.  Only the  
main record's length was counted, but that can be significantly too  
little if there's data associated with further blocks.  
  
Fix by computing the record length as total_lenght - fpi_length.  
  
Reported-By: Chen Huajun  
Bug: #14687  
Reviewed-By: Heikki Linnakangas  
Discussion: https://postgr.es/m/20170603165939.1436.58887@wrigleys.postgresql.org  
Backpatch: 9.5-  
  

Code review for shm_toc.h/.c.

  
commit   : 3e60c6f72328a9ad14d8a087411cd394752c5b23    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 5 Jun 2017 14:50:52 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 5 Jun 2017 14:50:52 -0400    

Click here for diff

  
Declare the toc_nentry field as uint32 not Size.  Since shm_toc_lookup()  
reads the field without any lock, it has to be atomically readable, and  
we do not assume that for fields wider than 32 bits.  Performance would  
be impossibly bad for entry counts approaching 2^32 anyway, so there is  
no need to try to preserve maximum width here.  
  
This is probably an academic issue, because even if reading int64 isn't  
atomic, the high order half would never change in practice.  Still, it's  
a coding rule violation, so let's fix it.  
  
Adjust some other not-terribly-well-chosen data types too, and copy-edit  
some comments.  Make shm_toc_attach's Asserts consistent with  
shm_toc_create's.  
  
None of this looks to be a live bug, so no need for back-patch.  
  
Discussion: https://postgr.es/m/16984.1496679541@sss.pgh.pa.us  
  

Find openssl lib files in right directory for MSVC

  
commit   : 614350a3ab73992f48c86e26552a2cbf030180e2    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 5 Jun 2017 14:24:42 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 5 Jun 2017 14:24:42 -0400    

Click here for diff

  
Some openssl builds put their lib files in a VC subdirectory, others do  
not. Cater for both cases.  
  
Backpatch to all live branches.  
  
From an offline discussion with Leonardo Cecchi.  
  

Don’t be so trusting that shm_toc_lookup() will always succeed.

  
commit   : d4663350646ca0c069a36d906155a0f7e3372eb7    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 5 Jun 2017 12:05:42 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 5 Jun 2017 12:05:42 -0400    

Click here for diff

  
Given the possibility of race conditions and so on, it seems entirely  
unsafe to just assume that shm_toc_lookup() always finds the key it's  
looking for --- but that was exactly what all but one call site were  
doing.  To fix, add a "bool noError" argument, similarly to what we  
have in many other functions, and throw an error on an unexpected  
lookup failure.  Remove now-redundant Asserts that a rather random  
subset of call sites had.  
  
I doubt this will throw any light on buildfarm member lorikeet's  
recent failures, because if an unnoticed lookup failure were involved,  
you'd kind of expect a null-pointer-dereference crash rather than the  
observed symptom.  But you never know ... and this is better coding  
practice even if it never catches anything.  
  
Discussion: https://postgr.es/m/9697.1496675981@sss.pgh.pa.us  
  

Fix typo in error message.

  
commit   : af51fea039bb8e00066d68d919312df1701dc03e    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 5 Jun 2017 11:38:26 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 5 Jun 2017 11:38:26 +0300    

Click here for diff

  
Daniele Varrazzo  
  
Discussion: https://www.postgresql.org/message-id/CA+mi_8bqY5THP8hLKKSdMEr5GCz6M=hD6_uLbvFeyEBfwqUxeA@mail.gmail.com  
  

Fix comments in simplehash.h.

  
commit   : 553e16951c0db4e3d2d0f804ff7f9d2ac0a96fe5    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 5 Jun 2017 10:46:08 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 5 Jun 2017 10:46:08 +0300    

Click here for diff

  
Jeff Janes and me.  
  
Discussion: https://www.postgresql.org/message-id/CAMkU=1zYnniLYg+W9itL93DXebCjx6Uk6m_=Xa8p_zM65X3S0Q@mail.gmail.com  
  

Replace over-optimistic Assert in partitioning code with a runtime test.

  
commit   : e7941a976688f0f5d13a5227ed4f3efe0718db9d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 4 Jun 2017 16:20:03 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 4 Jun 2017 16:20:03 -0400    

Click here for diff

  
get_partition_parent felt that it could simply Assert that systable_getnext  
found a tuple.  This is unlike any other caller of that function, and it's  
unsafe IMO --- in fact, the reason I noticed it was that the Assert failed.  
(OK, I was working with known-inconsistent catalog contents, but I wasn't  
expecting the DB to fall over quite that violently.  The behavior in a  
non-assert-enabled build wouldn't be very nice, either.)  Fix it to do what  
other callers do, namely an actual runtime-test-and-elog.  
  
Also, standardize the wording of elog messages that are complaining about  
unexpected failure of systable_getnext.  90% of them say "could not find  
tuple for <object>", so make the remainder do likewise.  Many of the  
holdouts were using the phrasing "cache lookup failed", which is outright  
misleading since no catcache search is involved.  
  

#ifdef out assorted unused GEQO code.

  
commit   : 9db7d47f909482ac2b76c28f5e9a2ef48fb19b9d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 4 Jun 2017 13:34:05 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 4 Jun 2017 13:34:05 -0400    

Click here for diff

  
I'd always assumed that backend/optimizer/geqo/'s remarkably poor  
showing on code coverage metrics was because we weren't exercising  
it much in the regression tests.  But it turns out that a good chunk  
of the problem is that there's a bunch of code that is physically  
unreachable (because the calls to it are #ifdef'd out in geqo_main.c)  
but is being built anyway.  Making the called code have #if guards  
similar to the calling code saves a couple of kilobytes of executable  
size and should make the coverage numbers more reflective of reality.  
  
It's arguable that we should just delete all the unused recombination  
mechanisms altogether, but I didn't feel a need to go that far today.  
  

Disallow CREATE INDEX if table is already in use in current session.

  
commit   : 0d1885266630eee1de5c43af463fe2b921451932    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 4 Jun 2017 12:02:31 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 4 Jun 2017 12:02:31 -0400    

Click here for diff

  
If we allow this, whatever outer command has the table open will not know  
about the new index and may fail to update it as needed, as shown in a  
report from Laurenz Albe.  We already had such a prohibition in place for  
ALTER TABLE, but the CREATE INDEX syntax missed the check.  
  
Fixing it requires an API change for DefineIndex(), which conceivably  
would break third-party extensions if we were to back-patch it.  Given  
how long this problem has existed without being noticed, fixing it in  
the back branches doesn't seem worth that risk.  
  
Discussion: https://postgr.es/m/A737B7A37273E048B164557ADEF4A58B53A4DC9A@ntex2010i.host.magwien.gv.at  
  

Assorted translatable string fixes

  
commit   : 55a70a023c3daefca9bbd68bfbe6862af10ab479    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Sun, 4 Jun 2017 11:41:16 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Sun, 4 Jun 2017 11:41:16 -0400    

Click here for diff

  
Mark our rusage reportage string translatable; remove quotes from type  
names; unify formatting of very similar messages.  
  

Remove dead variables.

  
commit   : 5936d25f8101f2433e8242794d2275c7a05273bf    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 3 Jun 2017 20:35:52 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 3 Jun 2017 20:35:52 -0400    

Click here for diff

  
Commit 512c7356b left a couple of variables unused except for being set.  
My compiler didn't whine about this, but some buildfarm members did.  
  

Add some missing backslash commands to psql’s tab-completion knowledge.

  
commit   : f1175556a17a193395326f45a3e595b4aa3a9eff    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 3 Jun 2017 17:10:25 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 3 Jun 2017 17:10:25 -0400    

Click here for diff

  
\if and related commands were overlooked here, as were \dRp and \dRs  
from the logical-replication patch, as was \?.  
  
While here, reformat the list to put each new first command letter on  
a separate line; perhaps that will limit the need to reflow the whole  
list when we add more commands in future.  
  
Masahiko Sawada (reformatting by me)  
  
Discussion: https://postgr.es/m/CAD21AoDW1QHtBsM33hV+Fg2mYEs+FWj4qtoCU72AwHAXQ3U6ZQ@mail.gmail.com  
  

Fix <> and pattern-NOT-match estimators to handle nulls correctly.

  
commit   : 512c7356b6574e7622fddb713f96dc8407960680    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 3 Jun 2017 14:36:25 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 3 Jun 2017 14:36:25 -0400    

Click here for diff

  
These estimators returned 1 minus the corresponding equality/match  
estimate, which is incorrect: we need to subtract off the fraction  
of nulls in the column, since those are neither equal nor not equal  
to the comparison value.  The error only becomes obvious if the  
nullfrac is large, but it could be very bad in a mostly-nulls  
column, as reported in bug #14676 from Marko Tiikkaja.  
  
To fix the <> case, refactor eqsel() and neqsel() to call a common  
support routine, which can be made to account for nullfrac correctly.  
The pattern-match cases were already factored that way, and it was  
simply an oversight that patternsel() wasn't subtracting off nullfrac.  
  
neqjoinsel() has a similar problem, but since we're elsewhere discussing  
changing its behavior entirely, I left it alone for now.  
  
This is a very longstanding bug, but I'm hesitant to back-patch a fix for  
it.  Given the lack of prior complaints, such cases must not come up often,  
so it's probably not worth the risk of destabilizing plans in stable  
branches.  
  
Discussion: https://postgr.es/m/20170529153847.4275.95416@wrigleys.postgresql.org  
  

Fix old corner-case logic error in final_cost_nestloop().

  
commit   : 23886581b58c7e5d005d6346c0024a45801cc5a9    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 3 Jun 2017 13:48:15 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 3 Jun 2017 13:48:15 -0400    

Click here for diff

  
When costing a nestloop with stop-at-first-inner-match semantics, and a  
non-indexscan inner path, final_cost_nestloop() wants to charge the full  
scan cost of the inner rel at least once, with additional scans charged  
at inner_rescan_run_cost which might be less.  However the logic for  
doing this effectively assumed that outer_matched_rows is at least 1.  
If it's zero, which is not unlikely for a small outer rel, we ended up  
charging inner_run_cost plus N times inner_rescan_run_cost, as much as  
double the correct charge for an outer rel with only one row that  
we're betting won't be matched.  (Unless the inner rel is materialized,  
in which case it has very small inner_rescan_run_cost and the cost  
is not so far off what it should have been.)  
  
The upshot of this was that the planner had a tendency to select plans  
that failed to make effective use of the stop-at-first-inner-match  
semantics, and that might have Materialize nodes in them even when the  
predicted number of executions of the Materialize subplan was only 1.  
This was not so obvious before commit 9c7f5229a, because the case only  
arose in connection with semi/anti joins where there's not freedom to  
reverse the join order.  But with the addition of unique-inner joins,  
it could result in some fairly bad planning choices, as reported by  
Teodor Sigaev.  Indeed, some of the test cases added by that commit  
have plans that look dubious on closer inspection, and are changed  
by this patch.  
  
Fix the logic to ensure that we don't charge for too many inner scans.  
I chose to adjust it so that the full-freight scan cost is associated  
with an unmatched outer row if possible, not a matched one, since that  
seems like a better model of what would happen at runtime.  
  
This is a longstanding bug, but given the lesser impact in back branches,  
and the lack of field complaints, I won't risk a back-patch.  
  
Discussion: https://postgr.es/m/CAKJS1f-LzkUsFxdJ_-Luy38orQ+AdEXM5o+vANR+-pHAWPSecg@mail.gmail.com  
  

Receive invalidation messages correctly in tablesync worker

  
commit   : 66b84fa82f7318d8da75dbf754df16eb7b1f1037    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Sat, 3 Jun 2017 11:37:47 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Sat, 3 Jun 2017 11:37:47 -0400    

Click here for diff

  
We didn't accept any invalidation messages until the whole sync process  
had finished (because it flattens all the remote transactions in the  
single one).  So the sync worker didn't learn about subscription  
changes/drop until it has finished.  This could lead to "orphaned" sync  
workers.  
  
Author: Petr Jelinek <petr.jelinek@2ndquadrant.com>  
Reported-by: Masahiko Sawada <sawada.mshk@gmail.com>  
  

Make tablesync worker exit when apply dies while it was waiting for it

  
commit   : 3c9bc2157a4f465b3c070d1250597568d2dc285f    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Sat, 3 Jun 2017 09:18:52 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Sat, 3 Jun 2017 09:18:52 -0400    

Click here for diff

  
This avoids "orphaned" sync workers.  
  
This was caused by a thinko in wait_for_sync_status_change.  
  
Author: Petr Jelinek <petr.jelinek@2ndquadrant.com>  
Reported-by: Masahiko Sawada <sawada.mshk@gmail.com>  
  

Allow parallelism in COPY (query) TO …;

  
commit   : 34aebcf42a70089b76ff8e9ccda331f111153eeb    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Fri, 2 Jun 2017 19:05:57 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Fri, 2 Jun 2017 19:05:57 -0700    

Click here for diff

  
Previously this was not allowed, as copy.c didn't set the  
CURSOR_OPT_PARALLEL_OK flag when planning the query. Set it.  
  
While the lack of parallel query for COPY isn't strictly speaking a  
bug, it does prevent parallelism from being used in a facility  
commonly used to run long running queries. Thus backpatch to 9.6.  
  
Author: Andres Freund  
Discussion: https://postgr.es/m/20170531231958.ihanapplorptykzm@alap3.anarazel.de  
Backpatch: 9.6, where parallelism was introduced.  
  

doc: Add note that DROP SUBSCRIPTION drops replication slot

  
commit   : de492c17f064ea3ddcb73d9529f3e30a1483ffa5    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 31 May 2017 22:35:33 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 31 May 2017 22:35:33 -0400    

Click here for diff

  
Add some information about what to do when this fails.  
  

Remove replication slot name check from ReplicationSlotAcquire()

  
commit   : 420a0392ef8fdac3eb6f0a616c136215f7454674    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 30 May 2017 14:57:01 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 30 May 2017 14:57:01 -0400    

Click here for diff

  
When trying to access a replication slot that is supposed to already  
exist, we don't need to check the naming rules again.  If the slot  
does not exist, we will then get a "does not exist" error message, which  
is generally more useful from the perspective of an end user.  
  

Fix signal handling in logical replication workers

  
commit   : 9fcf670c2efdf31233d429f557ab77937f0f1e6a    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 2 Jun 2017 14:46:00 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 2 Jun 2017 14:46:00 -0400    

Click here for diff

  
The logical replication worker processes now use the normal die()  
handler for SIGTERM and CHECK_FOR_INTERRUPTS() instead of custom code.  
One problem before was that the apply worker would not exit promptly  
when a subscription was dropped, which could lead to deadlocks.  
  
Author: Petr Jelinek <petr.jelinek@2ndquadrant.com>  
Reported-by: Masahiko Sawada <sawada.mshk@gmail.com>  
  

Fix copy/paste mistake in comment

  
commit   : acbd8375e954774181b673a31b814e9d46f436a5    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Fri, 2 Jun 2017 11:18:24 +0200    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Fri, 2 Jun 2017 11:18:24 +0200    

Click here for diff

  
Amit Langote  
  

Fix typo in comment

  
commit   : 483373979b17f10b2dfa4b12e68c3b961a9f8454    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Fri, 2 Jun 2017 09:40:54 +0200    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Fri, 2 Jun 2017 09:40:54 +0200    

Click here for diff

  
Masahiko Sawada  
  

Reorganize logical replication worker disconnect code

  
commit   : 6812330f1cc95f258ffe4ce7d56bdd56efbd9fde    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 1 Jun 2017 23:05:47 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 1 Jun 2017 23:05:47 -0400    

Click here for diff

  
Move the walrcv_disconnect() calls into the before_shmem_exit handler.  
This makes sure the call is always made even during exit by signal, it  
saves some duplicate code, and it makes the logic more similar to  
walreceiver.c.  
  
Author: Petr Jelinek <petr.jelinek@2ndquadrant.com>  
  

psql: Fix display of whether table is part of publication

  
commit   : 2d460179baa8744e9e2a183a5121306596c53fba    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 1 Jun 2017 21:13:40 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 1 Jun 2017 21:13:40 -0400    

Click here for diff

  
If a FOR ALL TABLES publication was present, \d of a table would claim  
for each table that it was part of the publication, even for tables that  
are ignored for this purpose, such as system tables and unlogged tables.  
Fix the query by using the function pg_get_publication_tables(), which  
was intended for this purpose.  
  
Reported-by: tushar <tushar.ahuja@enterprisedb.com>  
Reviewed-by: Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>  
Reviewed-by: Kuntal Ghosh <kuntalghosh.2007@gmail.com>  
  

Fix typo

  
commit   : f112f175a464697dd7ff5280de40dcc08d75f995    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 1 Jun 2017 17:45:53 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 1 Jun 2017 17:45:53 -0400    

Click here for diff

  
Reported by: Tim Goodaire  
Discussion: https://postgr.es/m/20170601182230.1487.26008@wrigleys.postgresql.org  
  

Modify sequence catalog tuple before invoking post alter hook.

  
commit   : 665104557fdc25788a6d54ab271ed818bec18598    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Wed, 31 May 2017 17:03:10 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Wed, 31 May 2017 17:03:10 -0700    

Click here for diff

  
This seems to have been broken in the commit (1753b1b027035029) that  
moved the sequence definition into pg_sequence.  
  
Author: Andres Freund  
Discussion: https://postgr.es/m/20170601000716.qxg7c46ukkiljjb3@alap3.anarazel.de  
Backpatch: Bug is in master/v10 only  
  

Make ALTER SEQUENCE, including RESTART, fully transactional.

  
commit   : 3d79013b970d4cc336c06eb77ed526b44308c03e    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Wed, 31 May 2017 16:39:27 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Wed, 31 May 2017 16:39:27 -0700    

Click here for diff

  
Previously the changes to the "data" part of the sequence, i.e. the  
one containing the current value, were not transactional, whereas the  
definition, including minimum and maximum value were.  That leads to  
odd behaviour if a schema change is rolled back, with the potential  
that out-of-bound sequence values can be returned.  
  
To avoid the issue create a new relfilenode fork whenever ALTER  
SEQUENCE is executed, similar to how TRUNCATE ... RESTART IDENTITY  
already is already handled.  
  
This commit also makes ALTER SEQUENCE RESTART transactional, as it  
seems to be too confusing to have some forms of ALTER SEQUENCE behave  
transactionally, some forms not.  This way setval() and nextval() are  
not transactional, but DDL is, which seems to make sense.  
  
This commit also rolls back parts of the changes made in 3d092fe540  
and f8dc1985f as they're now not needed anymore.  
  
Author: Andres Freund  
Discussion: https://postgr.es/m/20170522154227.nvafbsm62sjpbxvd@alap3.anarazel.de  
Backpatch: Bug is in master/v10 only  
  

Always use -fPIC, not -fpic, when building shared libraries with gcc.

  
commit   : e9a3c047a5fc701d2efb776be2b351645ea001c8    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 1 Jun 2017 13:32:55 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 1 Jun 2017 13:32:55 -0400    

Click here for diff

  
On some platforms, -fpic fails for sufficiently large shared libraries.  
We've mostly not hit that boundary yet, but there are some extensions  
such as Citus and pglogical where it's becoming a problem.  A bit of  
research suggests that the penalty for -fPIC is small, in the  
single-digit-percentage range --- and there's none at all on popular  
platforms such as x86_64.  So let's just default to -fPIC everywhere  
and provide one less thing for extension developers to worry about.  
  
Per complaint from Christoph Berg.  Back-patch to all supported branches.  
(I did not bother to touch the recently-removed Makefiles for sco and  
unixware in the back branches, though.  We'd have no way to test that  
it doesn't break anything on those platforms.)  
  
Discussion: https://postgr.es/m/20170529155850.qojdfrwkkqnjb3ap@msg.df7cb.de  
  

Generate pg_basebackup temporary slot name using backend pid

  
commit   : 2712da8b64b4e399a2666cce2c25329f4f834f2d    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Wed, 31 May 2017 20:57:25 +0200    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Wed, 31 May 2017 20:57:25 +0200    

Click here for diff

  
Using the client pid can easily be non-unique when used on different  
hosts. Using the backend pid should be guaranteed unique, since the  
temporary slot gets removed when the client disconnects so it will be  
gone even if the pid is renewed.  
  
Reported by Ludovic Vaugeois-Pepin  
  

Restore accidentally-removed line.

  
commit   : 814573e6c4889f901ba72c0c0d2c948846744c73    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Wed, 31 May 2017 13:34:41 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Wed, 31 May 2017 13:34:41 -0400    

Click here for diff

  
Commit 88e66d193fbaf756b3cc9bf94cad116aacbb355b is to blame.  
  
Masahiko Sawada  
  
Discussion: http://postgr.es/m/CAD21AoAXeb7O4hgg+efs8JT_SxpR4doAH5c5s-Z5WoRLstBZJA@mail.gmail.com  
  

doc: Add another migration item to release notes

  
commit   : 3e6d2fabccef5ed602cd248bfbedf4dc9a57eb09    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 31 May 2017 13:39:28 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 31 May 2017 13:39:28 -0400    

Click here for diff

  
  

Avoid -Wconversion warnings from direct use of GET_n_BYTES macros.

  
commit   : b5b322914100f7526c29c92f88c294a0ae5e7dfd    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 31 May 2017 11:27:21 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 31 May 2017 11:27:21 -0400    

Click here for diff

  
The GET/SET_n_BYTES macros are meant to be infrastructure for the  
DatumGetFoo/FooGetDatum macros, which include a cast to the intended  
target type.  Using them directly without a cast, as DatumGetFloat4  
and friends previously did, can yield warnings when -Wconversion is on.  
This is of little significance when building Postgres proper, because  
there are such a huge number of such warnings in the server that nobody  
would think -Wconversion is of any use.  But some extensions build with  
-Wconversion due to outside constraints.  Commit 14cca1bf8 did a disservice  
to those extensions by moving DatumGetFloat4 et al into postgres.h,  
where they can now cause warnings in extension builds.  
  
To fix, use DatumGetInt32 and friends in place of the low-level macros.  
This is arguably a bit cleaner anyway.  
  
Chapman Flack  
  
Discussion: https://postgr.es/m/592E4D04.1070609@anastigmatix.net  
  

Sort syscache identifiers into alphabetical order.

  
commit   : 54e839fe29c1d071f5129eb4a112546197ea0522    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 30 May 2017 18:47:10 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 30 May 2017 18:47:10 -0400    

Click here for diff

  
Not much point in having a convention about this if we don't enforce it.  
  
Mark Dilger  
  
Discussion: https://postgr.es/m/7F67FBEF-C3B3-404E-8EC6-E02ACB15D894@gmail.com  
  

brin: Don’t crash on auto-summarization

  
commit   : b4da9d0e1ee45a1d157dc7fd24b24745b16ebe9f    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 30 May 2017 17:32:53 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 30 May 2017 17:32:53 -0400    

Click here for diff

  
We were trying to free a pointer into a shared buffer, which never  
works; and we were failing to release the buffer lock appropriately.  
Fix those omissions.  
  
While at it, improve documentation for brinGetTupleForHeapBlock, the  
inadequacy of which evidently caused these bugs in the first place.  
  
Reported independently by Zhou Digoal (bug #14668) and Alexander Sosna.  
  
Discussion: https://postgr.es/m/8c31c11b-6adb-228d-22c2-4ace89fc9209@credativ.de  
Discussion: https://postgr.es/m/20170524063323.29941.46339@wrigleys.postgresql.org  
  

Fix wording in amvalidate error messages

  
commit   : e6785a5ca16bfe67b9c74d168ae6e88c6e55c8ac    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 30 May 2017 15:45:42 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 30 May 2017 15:45:42 -0400    

Click here for diff

  
Remove some gratuituous message differences by making the AM name  
previously embedded in each message be a %s instead.  While at it, get  
rid of terminology that's unclear and unnecessary in one message.  
  
Discussion: https://postgr.es/m/20170523001557.bq2hbq7hxyvyw62q@alvherre.pgsql  
  

doc: Fix ALTER PUBLICATION details

  
commit   : 185364b161512806d23ca390f5b615666079699b    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 30 May 2017 11:47:19 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 30 May 2017 11:47:19 -0400    

Click here for diff

  
Some of the text was made nonsensical by commit  
e9500240661c03750923e6f539bfa2d75cfaa32a.  Fix that and make some other  
minor changes.  
  
Reported-by: Jeff Janes <jeff.janes@gmail.com>  
  

Fix omission of locations in outfuncs/readfuncs partitioning node support.

  
commit   : 80f583ffe930b21d6e5c47be4342356e57851a9a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 30 May 2017 11:32:41 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 30 May 2017 11:32:41 -0400    

Click here for diff

  
We could have limped along without this for v10, which was my intention  
when I annotated the bug in commit 76a3df6e5.  But consensus is that it's  
better to fix it now and take the cost of a post-beta1 initdb (which is  
needed because these node types are stored in pg_class.relpartbound).  
  
Since we're forcing initdb anyway, take the opportunity to make the node  
type identification strings match the node struct names, instead of being  
randomly different from them.  
  
Discussion: https://postgr.es/m/E1dFBEX-0004wt-8t@gemulon.postgresql.org  
  

Fix improper quoting of format_type_be() output.

  
commit   : d5cb3bab564e0927ffac7c8729eacf181a12dd40    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 29 May 2017 21:48:26 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 29 May 2017 21:48:26 -0400    

Click here for diff

  
Per our message style guidelines, error messages incorporating the  
results of format_type_be() and its siblings should not add quotes  
around those results, because those functions already add quotes  
at need.  Fix a few places that hadn't gotten that memo.  
  

Make edge-case behavior of jsonb_populate_record match json_populate_record

  
commit   : 68cff231e3a3d0ca9988cf1fde5a3be53235b3bb    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 29 May 2017 19:29:42 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 29 May 2017 19:29:42 -0400    

Click here for diff

  
json_populate_record throws an error if asked to convert a JSON scalar  
or array into a composite type.  jsonb_populate_record was returning  
a record full of NULL fields instead.  It seems better to make it  
throw an error for this case as well.  
  
Nikita Glukhov  
  
Discussion: https://postgr.es/m/fbd1d566-bba0-a3de-d6d0-d3b1d7c24ff2@postgrespro.ru  
  

Fix thinko in JsObjectSize() macro.

  
commit   : e45c5be99d08d7bb6708d7bb1dd0f5d99798c6aa    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 29 May 2017 18:51:56 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 29 May 2017 18:51:56 -0400    

Click here for diff

  
The macro gave the wrong answers for a JsObject with is_json == 0:  
it would return 1 if jsonb_cont == NULL, or if that wasn't NULL,  
it would return 1 for any non-zero size.  
  
We could fix that, but the only use of this macro at present is in the  
JsObjectIsEmpty() macro, so it seems simpler and clearer to get rid of  
JsObjectSize() and put corrected logic into JsObjectIsEmpty().  
  
Thinko in commit cf35346e8, so no need for back-patch.  
  
Nikita Glukhov  
  
Discussion: https://postgr.es/m/fbd1d566-bba0-a3de-d6d0-d3b1d7c24ff2@postgrespro.ru  
  

Prevent running pg_resetwal/pg_resetxlog against wrong-version data dirs.

  
commit   : f3db7f164a29c5cbdc1d6d5d0d23854df58783c1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 29 May 2017 17:08:16 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 29 May 2017 17:08:16 -0400    

Click here for diff

  
pg_resetwal (formerly pg_resetxlog) doesn't insist on finding a matching  
version number in pg_control, and that seems like an important thing to  
preserve since recovering from corrupt pg_control is a prime reason to  
need to run it.  However, that means you can try to run it against a  
data directory of a different major version, which is at best useless  
and at worst disastrous.  So as to provide some protection against that  
type of pilot error, inspect PG_VERSION at startup and refuse to do  
anything if it doesn't match.  PG_VERSION is read-only after initdb,  
so it's unlikely to get corrupted, and even if it were corrupted it would  
be easy to fix by hand.  
  
This hazard has been there all along, so back-patch to all supported  
branches.  
  
Michael Paquier, with some kibitzing by me  
  
Discussion: https://postgr.es/m/f4b8eb91-b934-8a0d-b3cc-68f06e2279d1@enterprisedb.com  
  

Allow NumericOnly to be “+ FCONST”.

  
commit   : ce509452955487c9e11d042b6a564c76600334db    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 29 May 2017 15:19:07 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 29 May 2017 15:19:07 -0400    

Click here for diff

  
The NumericOnly grammar production accepted ICONST, + ICONST, - ICONST,  
FCONST, and - FCONST, but for some reason not + FCONST.  This led to  
strange inconsistencies like  
  
regression=# set random_page_cost = +4;  
SET  
regression=# set random_page_cost = 4000000000;  
SET  
regression=# set random_page_cost = +4000000000;  
ERROR:  syntax error at or near "4000000000"  
  
(because 4000000000 is too large to be an ICONST).  While there's  
no actual functional reason to need to write a "+", if we allow  
it for integers it seems like we should allow it for numerics too.  
  
It's been like that forever, so back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/30908.1496006184@sss.pgh.pa.us  
  

More code review for get_qual_for_list().

  
commit   : dced55dafead62cfff81a3fedb35acd8e32c9b02    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 29 May 2017 14:24:28 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 29 May 2017 14:24:28 -0400    

Click here for diff

  
Avoid trashing the input PartitionBoundSpec; while that might be safe for  
current callers, it's certainly trouble waiting to happen.  In the same  
vein, make sure that all of the result data structure is freshly palloc'd,  
rather than some of it being pointers into the input data structures  
(which we don't know the lifespans of).  
  
Simplify the logic for tacking on IS NULL or IS NOT NULL conditions some  
more; commit 85c2b9a15 left a lot on the table there.  And rearrange the  
construction of the nodes into (what seems to me) a more logical order.  
  
In passing, make sure that get_qual_for_range() also returns a freshly  
palloc'd structure, since there's no value in having that guarantee for  
only one kind of partitioning.  And improve some comments there.  
  
Jeevan Ladhe, with further tweaking by me  
  
Discussion: https://postgr.es/m/CAOgcT0MAcYoMs93W80iTUf_dP36=1mZQzeUk+nnwY_-qWDrCfw@mail.gmail.com  
  

Fix typo in comment

  
commit   : 917d91285f187e599039a962d9b869a782390304    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Mon, 29 May 2017 16:29:19 +0200    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Mon, 29 May 2017 16:29:19 +0200    

Click here for diff

  
Masahiko Sawada  
  

Fix reference to RFC specifying SCRAM.

  
commit   : 6fd65f6b877512eb1c35897d4c4c6779d100e459    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 29 May 2017 09:31:33 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 29 May 2017 09:31:33 +0300    

Click here for diff

  
Noted by Peter Eisentraut  
  

Code review focused on new node types added by partitioning support.

  
commit   : 76a3df6e5e621928fbf0cddf347e16a62e9433ec    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 28 May 2017 23:20:28 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 28 May 2017 23:20:28 -0400    

Click here for diff

  
Fix failure to check that we got a plain Const from const-simplification of  
a coercion request.  This is the cause of bug #14666 from Tian Bing: there  
is an int4 to money cast, but it's only stable not immutable (because of  
dependence on lc_monetary), resulting in a FuncExpr that the code was  
miserably unequipped to deal with, or indeed even to notice that it was  
failing to deal with.  Add test cases around this coercion behavior.  
  
In view of the above, sprinkle the code liberally with castNode() macros,  
in hope of catching the next such bug a bit sooner.  Also, change some  
functions that were randomly declared to take Node* to take more specific  
pointer types.  And change some struct fields that were declared Node*  
but could be given more specific types, allowing removal of assorted  
explicit casts.  
  
Place PARTITION_MAX_KEYS check a bit closer to the code it's protecting.  
Likewise check only-one-key-for-list-partitioning restriction in a less  
random place.  
  
Avoid not-per-project-style usages like !strcmp(...).  
  
Fix assorted failures to avoid scribbling on the input of parse  
transformation.  I'm not sure how necessary this is, but it's entirely  
silly for these functions to be expending cycles to avoid that and not  
getting it right.  
  
Add guards against partitioning on system columns.  
  
Put backend/nodes/ support code into an order that matches handling  
of these node types elsewhere.  
  
Annotate the fact that somebody added location fields to PartitionBoundSpec  
and PartitionRangeDatum but forgot to handle them in  
outfuncs.c/readfuncs.c.  This is fairly harmless for production purposes  
(since readfuncs.c would just substitute -1 anyway) but it's still bogus.  
It's not worth forcing a post-beta1 initdb just to fix this, but if we  
have another reason to force initdb before 10.0, we should go back and  
clean this up.  
  
Contrariwise, somebody added location fields to PartitionElem and  
PartitionSpec but forgot to teach exprLocation() about them.  
  
Consolidate duplicative code in transformPartitionBound().  
  
Improve a couple of error messages.  
  
Improve assorted commentary.  
  
Re-pgindent the files touched by this patch; this affects a few comment  
blocks that must have been added quite recently.  
  
Report: https://postgr.es/m/20170524024550.29935.14396@wrigleys.postgresql.org  
  

Format v10 release notes’ commit references more like previous releases.

  
commit   : 54bb322ec7e1f7c3a674b4ea02f7010a51d51f99    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 28 May 2017 16:42:22 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 28 May 2017 16:42:22 -0400    

Click here for diff

  
Left-justify these comments, remove committer names, remove SGML markup  
that was randomly added to some of them.  Aside from being more consistent  
with previous practice, this keeps the lines shorter than 80 characters,  
improving readability in standard terminal windows.  
  

Improve v10 release notes’ discussion of money operator changes.

  
commit   : 1c8b88ab9b72fe4c7c4193170d0810aa42b889cf    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 28 May 2017 15:49:44 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 28 May 2017 15:49:44 -0400    

Click here for diff

  
Mention the rounding behavioral change for money/int8.  
  
Discussion: https://postgr.es/m/20170519164653.29941.19098@wrigleys.postgresql.org  
  

Avoid locale-dependent output in select_views regression test.

  
commit   : eac0a6c7d35dee6d4329b3c7d8bf82fac4c1eff1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 28 May 2017 14:52:18 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 28 May 2017 14:52:18 -0400    

Click here for diff

  
Use 'COLLATE "C"' to force locale-independent sorting of the iexit  
view results in select_views.sql.  We aren't particularly interested  
in the exact sorting behavior here, and this doesn't change the shape  
of the generated plan, so it seems like a wash as far as the goals  
of this test go.  
  
This is in response to bug #14637 from Tomasz Kontusz.  It doesn't  
fully resolve his problem, because he also saw some diffs in the  
create_index test.  But other people have had issues with select_views  
too, and this fix lets us drop the select_views_1.out variant expected  
file altogether, which is a nice win from a maintenance standpoint.  
  
Emre Hasegeli  
  
Discussion: https://postgr.es/m/20170501000609.24360.24248@wrigleys.postgresql.org  
  

Fix typo in pg_dump’s support for dumping collations from pre-v10 servers.

  
commit   : 764cb2b596ced6aea4d83fd52ff628bdedb63316    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 26 May 2017 15:37:06 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 26 May 2017 15:37:06 -0400    

Click here for diff

  
Dunno what 'p' was supposed to mean, but since neither the code below  
here nor pg_collation.h think it's valid, it must be a mistake.  
  
Per report from Thomas Kellerer.  
  
Discussion: https://postgr.es/m/og9q8f%24oes%241%40blaine.gmane.org  
  

Move autogenerated array types out of the way during ALTER … RENAME.

  
commit   : 94aced8cd0e229670877fe5c406a98d9a4f1b92a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 26 May 2017 15:16:59 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 26 May 2017 15:16:59 -0400    

Click here for diff

  
Commit 9aa3c782c added code to allow CREATE TABLE/CREATE TYPE to not fail  
when the desired type name conflicts with an autogenerated array type, by  
dint of renaming the array type out of the way.  But I (tgl) overlooked  
that the same case arises in ALTER TABLE/TYPE RENAME.  Fix that too.  
Back-patch to all supported branches.  
  
Report and patch by Vik Fearing, modified a bit by me  
  
Discussion: https://postgr.es/m/0f4ade49-4f0b-a9a3-c120-7589f01d1eb8@2ndquadrant.com  
  

Fix pg_dump to not emit invalid SQL for an empty operator class.

  
commit   : 0461b66e361f56560aaa50e1bd006e36e8bedc6e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 26 May 2017 12:51:05 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 26 May 2017 12:51:05 -0400    

Click here for diff

  
If an operator class has no operators or functions, and doesn't need  
a STORAGE clause, we emitted "CREATE OPERATOR CLASS ... AS ;" which  
is syntactically invalid.  Fix by forcing a STORAGE clause to be  
emitted anyway in this case.  
  
(At some point we might consider changing the grammar to allow CREATE  
OPERATOR CLASS without an opclass_item_list.  But probably we'd want to  
omit the AS in that case, so that wouldn't fix this pg_dump issue anyway.)  
  
It's been like this all along, so back-patch to all supported branches.  
  
Daniel Gustafsson, tweaked by me to avoid a dangling-pointer bug  
  
Discussion: https://postgr.es/m/D9E5FC64-7A37-4F3D-B946-7E4FB468F88A@yesql.se  
  

Remove docs mention of PGREALM variable

  
commit   : 9c34a05b7d2304eac3fdc5e9db9fcd0d7c72883f    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Fri, 26 May 2017 10:58:15 -0400    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Fri, 26 May 2017 10:58:15 -0400    

Click here for diff

  
This variable was only used with Kerberos v4. That support was removed  
in 2005, but we forgot to remove the documentation.  
  
Noted by Shinichi Matsuda  
  

Update expected file

  
commit   : 08aa5506948e010dacaa344074063ccd0ecc3b21    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 25 May 2017 14:41:43 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 25 May 2017 14:41:43 -0400    

Click here for diff

  
Missed in ea3e310e712a.  
  

extended stats: Clarify behavior of omitting stat type clause

  
commit   : eb67e2e35a046f700172fbce52ad2331fe6c57ac    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 25 May 2017 13:17:57 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 25 May 2017 13:17:57 -0400    

Click here for diff

  
Pointed out by Jeff Janes  
Discussion: https://postgr.es/m/CAMkU=1zGhK-nW10RAXhokcT3MM=YBg=j5LkG9RMDwmu3i0H0Og@mail.gmail.com  
  

Fix message case

  
commit   : ea3e310e712ac53653d4100ea2a7c516c30d4971    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 25 May 2017 13:16:00 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 25 May 2017 13:16:00 -0400    

Click here for diff

  
  

Fix whitespace

  
commit   : 04f1798eaa0aeff81f90e2d28679b0a2cd267b8e    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 25 May 2017 11:17:09 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 25 May 2017 11:17:09 -0400    

Click here for diff

  
  

Abort authentication if the client selected an invalid SASL mechanism.

  
commit   : 505b5d2f8672f13c98dd744a6d421da14f59cd39    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 25 May 2017 08:50:47 -0400    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 25 May 2017 08:50:47 -0400    

Click here for diff

  
Previously, the server would log an error, but then try to continue with  
SCRAM-SHA-256 anyway.  
  
Michael Paquier  
  
Discussion: https://www.postgresql.org/message-id/CAB7nPqR0G5aF2_kc_LH29knVqwvmBc66TF5DicvpGVdke68nKw@mail.gmail.com  
  

Fix table syncing with different column order

  
commit   : 073ce405d68355eed36a11b41e558232ecf18201    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 18 May 2017 14:16:16 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 18 May 2017 14:16:16 -0400    

Click here for diff

  
Logical replication supports replicating between tables with different  
column order.  But this failed for the initial table sync because of a  
logic error in how the column list for the internal COPY command was  
composed.  Fix that and also add a test.  
  
Also fix a minor omission in the column name mapping cache.  When  
creating the mapping list, it would not skip locally dropped columns.  
So if a remote column had the same name as a locally dropped  
column (...pg.dropped...), then the expected error would not occur.  
  

Improve logical replication worker log messages

  
commit   : 92ecb148e517704ec945dce513db71fee7790cfd    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 24 May 2017 18:56:21 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 24 May 2017 18:56:21 -0400    

Click here for diff

  
Reduce some redundant messages to DEBUG1.  Be clearer about the  
distinction between apply workers and table synchronization workers.  
Add subscription and table name where possible.  
  
Reviewed-by: Masahiko Sawada <sawada.mshk@gmail.com>  
  

Code review of get_qual_for_list.

  
commit   : 85c2b9a15a1d667b1e2cd580da8c1d9fef0af1e8    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Wed, 24 May 2017 16:30:47 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Wed, 24 May 2017 16:30:47 -0400    

Click here for diff

  
We need not consider the case where both nulltest1 and nulltest2 are  
NULL; the partition either accepts nulls or it does not.  
  
Jeevan Ladhe.  I added an assertion.  
  

Tighten checks for whitespace in functions that parse identifiers etc.

  
commit   : 9ae2661fe1fef6b3242ecb39a2f7ffcffb2a4f70    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 24 May 2017 15:28:34 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 24 May 2017 15:28:34 -0400    

Click here for diff

  
This patch replaces isspace() calls with scanner_isspace() in functions  
that are likely to be presented with non-ASCII input.  isspace() has  
the small advantage that it will correctly recognize no-break space  
in single-byte encodings (such as LATIN1); but it cannot work successfully  
for any multibyte character, and depending on platform it might return  
false positive results for some fragments of multibyte characters.  That's  
disastrous for functions that are trying to discard whitespace between  
valid strings, as noted in bug #14662 from Justin Muise.  Even treating  
no-break space as whitespace is pretty questionable for the usages touched  
here, because the core scanner would think it is an identifier character.  
  
Affected functions are parse_ident(), parseNameAndArgTypes (underlying  
regprocedurein() and siblings), SplitIdentifierString (used for parsing  
GUCs and options that are qualified names or lists of names), and  
SplitDirectoriesString (used for parsing GUCs that are lists of  
directories).  
  
All the functions adjusted here are parsing SQL identifiers and similar  
constructs, so it's reasonable to insist that their definition of  
whitespace match the core scanner.  So we can hope that this won't cause  
many backwards-compatibility problems.  I've left alone isspace() calls  
in places that aren't really expecting any non-ASCII input characters,  
such as float8in().  
  
Back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/10129.1495302480@sss.pgh.pa.us  
  

Update URLs in pgindent source and README

  
commit   : f61bd73993bd616ebdc0f34c204291461e3cb52e    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Tue, 23 May 2017 13:58:11 -0400    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Tue, 23 May 2017 13:58:11 -0400    

Click here for diff

  
Website and buildfarm is https, not http, and the ftp protocol will be  
shut down shortly.  
  

Verify that the server constructed the SCRAM nonce correctly.

  
commit   : 1c9b6e818f047e07f1de62b4d11e0c5db2d55ab7    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 23 May 2017 05:55:19 -0400    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 23 May 2017 05:55:19 -0400    

Click here for diff

  
The nonce consists of client and server nonces concatenated together. The  
client checks the nonce contained the client nonce, but it would get fooled  
if the server sent a truncated or even empty nonce.  
  
Reported by Steven Fackler to security@postgresql.org. Neither me or Steven  
are sure what harm a malicious server could do with this, but let's fix it.  
  

Synced ecpg’s pg_type.h with the one used in the backend.

  
commit   : d951db2eff9e31637669a1452a0260616fdb5f50    
  
author   : Michael Meskes <meskes@postgresql.org>    
date     : Tue, 23 May 2017 09:48:51 +0200    
  
committer: Michael Meskes <meskes@postgresql.org>    
date     : Tue, 23 May 2017 09:48:51 +0200    

Click here for diff

  
Patch by Vinayak Pokale.  
  

Fix typo in comment

  
commit   : 312bac54cc9cc26e9cee23033c5c4f029976753a    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Mon, 22 May 2017 09:10:02 +0200    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Mon, 22 May 2017 09:10:02 +0200    

Click here for diff

  
Author: Masahiko Sawada  
  

Fix precision and rounding issues in money multiplication and division.

  
commit   : d761fe2182d9e26f9483e4b7ac303e38bfbd7a24    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 21 May 2017 13:05:16 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 21 May 2017 13:05:16 -0400    

Click here for diff

  
The cash_div_intX functions applied rint() to the result of the division.  
That's not merely useless (because the result is already an integer) but  
it causes precision loss for values larger than 2^52 or so, because of  
the forced conversion to float8.  
  
On the other hand, the cash_mul_fltX functions neglected to apply rint() to  
their multiplication results, thus possibly causing off-by-one outputs.  
  
Per C standard, arithmetic between any integral value and a float value is  
performed in float format.  Thus, cash_mul_flt4 and cash_div_flt4 produced  
answers good to only about six digits, even when the float value is exact.  
We can improve matters noticeably by widening the float inputs to double.  
(It's tempting to consider using "long double" arithmetic if available,  
but that's probably too much of a stretch for a back-patched fix.)  
  
Also, document that cash_div_intX operators truncate rather than round.  
  
Per bug #14663 from Richard Pistole.  Back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/22403.1495223615@sss.pgh.pa.us  
  

Fix contrib/sepgsql regression tests for partition NOT NULL change.

  
commit   : 2dd510e630cdd692bb7b2c9c092b1b352e0f6451    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 21 May 2017 11:46:04 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 21 May 2017 11:46:04 -0400    

Click here for diff

  
Commit 3ec76ff1f changed the partitioning logic to not install a forced  
NOT NULL constraint on range partitioning columns.  This affects the  
expected output for contrib/sepgsql, because there's no longer LOG  
entries reporting allowance of such a constraint.  Per buildfarm.  
  

Change documentation references to PG website to use https: not http:

  
commit   : 7f77cbd996855a06fb742ea11adbe55c42b48fe2    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 20 May 2017 21:50:47 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 20 May 2017 21:50:47 -0400    

Click here for diff

  
This is more secure, and saves a redirect since we no longer accept  
plain HTTP connections on the website.  
  
References in code comments should probably be updated too, but  
that doesn't seem to need back-patching, whereas this does.  
  
Also, in the 9.2 branch, remove suggestion that you can get the  
source code via FTP, since that service will be shut down soon.  
  
Daniel Gustafsson, with a few additional changes by me  
  
Discussion: https://postgr.es/m/9A2C89A7-0BB8-41A8-B288-8B7BD09D7D44@yesql.se  
  

Rethink flex flags for syncrep_scanner.l.

  
commit   : 5c837ddd7092ce9243225d12ca03fdbae136227f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 19 May 2017 18:05:20 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 19 May 2017 18:05:20 -0400    

Click here for diff

  
Using flex's -i switch to achieve case-insensitivity is not a very safe  
practice, because the scanner's behavior may then depend on the locale  
that flex was invoked in.  In the particular example at hand, that's  
not academic: the possible matches for "FIRST" will be different in a  
Turkish locale than elsewhere.  Do it the hard way instead, as our  
other scanners do.  
  
Also, drop use of -b -CF -p, because this scanner is only used when  
parsing the contents of a GUC variable.  That's not done often, and  
the amount of text to be parsed can be expected to be trivial, so  
prioritizing scanner speed over code size seems like quite the wrong  
tradeoff.  Using flex's default optimization options reduces the  
size of syncrep_gram.o by more than 50%.  
  
The case-insensitivity problem is new in HEAD (cf commit 3901fd70c).  
The poor choice of optimization flags exists also in 9.6, but it doesn't  
seem important enough to back-patch.  
  
Discussion: https://postgr.es/m/24403.1495225931@sss.pgh.pa.us  
  

pg_upgrade: Handle hash index upgrades more smoothly.

  
commit   : a95410e2ec39b6776381fd01198dc57a063e8185    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 19 May 2017 16:49:38 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 19 May 2017 16:49:38 -0400    

Click here for diff

  
Mark any old hash indexes as invalid so that they don't get used, and  
create a script to run REINDEX on all of them.  Without this, we'd  
still try to use any upgraded hash indexes, but it would fail.  
  
Amit Kapila, reviewed by me.  Per a suggestion from Tom Lane.  
  
Discussion: http://postgr.es/m/CAA4eK1Jidtagm7Q81q-WoegOVgkotv0OxvHOjFxcvFRP4X=mSw@mail.gmail.com  
  

Fix mistake in error message

  
commit   : e807d8b16338c97e60e41344d0fc13bd9cf540be    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 19 May 2017 16:30:02 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 19 May 2017 16:30:02 -0400    

Click here for diff

  
Reported-by: tushar <tushar.ahuja@enterprisedb.com>  
Author: Dilip Kumar <dilipbalaut@gmail.com>  
  

libpq: Try next host if one of them times out.

  
commit   : 5f374fe7a83304fd339789da22599bd102dac9e5    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 19 May 2017 16:19:51 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 19 May 2017 16:19:51 -0400    

Click here for diff

  
If one host in a multi-host connection string times out, move on to  
the next specified host instead of giving up entirely.  
  
Takayuki Tsunakawa, reviewed by Michael Paquier.  I added  
a minor adjustment to the documentation.  
  
Discussion: http://postgr.es/m/0A3221C70F24FB45833433255569204D1F6F42F5@G01JPEXMBYT05  
  

Capitalize SHOW when testing whether target_session_attrs=read-write.

  
commit   : aa41bc794c51a4d5c364cca014c199b1a00d26aa    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 19 May 2017 15:48:10 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 19 May 2017 15:48:10 -0400    

Click here for diff

  
This makes it also work for replication connections.  
  
Report and patch by Daisuke Higuchi.  
  
Discussion: http://postgr.es/m/1803D792815FC24D871C00D17AE95905B1A34A@g01jpexmbkw24  
  

Copy partitioned_rels lists to avoid shared substructure.

  
commit   : b522759508dae17535f8cd20598a50a409a97f4d    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 19 May 2017 15:23:42 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 19 May 2017 15:23:42 -0400    

Click here for diff

  
Otherwise, set_plan_refs() can get applied to the same list  
multiple times through different references, leading to chaos.  
  
Amit Langote, Dilip Kumar, and Robert Haas, reviewed by Ashutosh  
Bapat.  Original report by Sveinn Sveinsson.  
  
Discussion: http://postgr.es/m/20170517141151.1435.79890@wrigleys.postgresql.org  
  

Fix misspelled struct tag.

  
commit   : cf5389f5b57af714d002d532add291f87ddb0062    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 19 May 2017 15:05:54 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 19 May 2017 15:05:54 -0400    

Click here for diff

  
This was evidently intended to match the struct's typedef name,  
but it didn't quite.  Noted while testing find_typedefs.  
  

Fix corruption of tableElts list by MergeAttributes().

  
commit   : ac8d7e1b834e252c9aa8d5750f70a86ca74228b8    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 19 May 2017 15:02:16 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 19 May 2017 15:02:16 -0400    

Click here for diff

  
Since commit e7b3349a8ad7afaad565c573fbd65fb46af6abbe, MergeAttributes  
destructively modifies the input List, to which the caller's  
CreateStmt still points.  One may wonder whether this was already a  
bug, but commit f0e44751d7175fa3394da2c8f85e3ceb3cdbfe63 made things  
noticeably worse by adding additional destructive modifications so  
that the caller's List might, in the case of creation a partitioned  
table, no longer even be structurally valid.  Restore the status quo  
ante by assigning the return value of MergeAttributes back to  
stmt->tableElts in the caller.  
  
In most of the places where DefineRelation is called, it doesn't  
matter what stmt->tableElts points to here or whether it's valid or  
not, because the caller doesn't use the statement for anything after  
DefineRelation returns anyway.  However, ProcessUtilitySlow passes it  
to EventTriggerCollectSimpleCommand, and that function tries to invoke  
copyObject on it.  If any of the CreateStmt's substructure is invalid  
at that point, undefined behavior will result.  
  
One might wonder whether this whole area needs further revision -  
perhaps DefineRelation() ought not to be destructively modifying the  
caller-provided CreateStmt at all.  However, that would be a behavior  
change for any event triggers using C code to inspect the CreateStmt,  
so for now, just fix the crash.  
  
Report by Amit Langote, who provided a somewhat different patch for it.  
  
Discussion: http://postgr.es/m/bf6a39a7-100a-74bd-1156-3c16a1429d88@lab.ntt.co.jp  
  

Fix argument name differences

  
commit   : 7f17ae0ad07a76eeb1b26e7aa8c4539ce14b253b    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 19 May 2017 14:47:56 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 19 May 2017 14:47:56 -0400    

Click here for diff

  
Different names were used between function declaration and definition.  
  

doc: remove duplicate PG 10 release notes entry

  
commit   : f6d5d22ea9497aecdfdfa92717a11f0bcdf17223    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Fri, 19 May 2017 12:16:53 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Fri, 19 May 2017 12:16:53 -0400    

Click here for diff

  
Reported-by: Daniel Gustafsson  
  

doc: fix PG 10 release notes with proper attribution and commit

  
commit   : f45d86d762b8bcdac42d5448734016242a1d738b    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Fri, 19 May 2017 12:10:10 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Fri, 19 May 2017 12:10:10 -0400    

Click here for diff

  
Fix for hot_standby=on change.  
  
Reported-by: Huong Dangminh  
  
Author: Huong Dangminh  
  

Fix compilation with –with-bsd-auth.

  
commit   : 866490a6b72c625c29ced23065d367a1b0484760    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 19 May 2017 12:21:55 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 19 May 2017 12:21:55 +0300    

Click here for diff

  
Commit 8d3b9cce81 added extra arguments to the sendAuthRequest function,  
but neglected this caller inside #ifdef USE_BSD_AUTH.  
  
Per report from Pierre-Emmanuel André.  
  
Discussion: https://www.postgresql.org/message-id/20170519090336.whzmjzrsap6ktbgg@digipea.digitick.local  
  

doc: Fix ALTER SUBSCRIPTION option syntax synopsis

  
commit   : f4205c4c1fcfc88d0c3885c160f24873bcbcc04d    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 18 May 2017 21:37:57 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 18 May 2017 21:37:57 -0400    

Click here for diff

  
Author: Masahiko Sawada <sawada.mshk@gmail.com>  
  

Make slab allocator work on platforms with MAXIMUM_ALIGNOF < sizeof(int).

  
commit   : 94884e1c27ccd38bf494fc7f5aa46b269bbb6c9c    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 18 May 2017 22:22:13 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 18 May 2017 22:22:13 +0300    

Click here for diff

  
Notably, m68k only needs 2-byte alignment. Per report from Christoph Berg.  
  
Discussion: https://www.postgresql.org/message-id/20170517193957.fwntkgi6epuso5l2@msg.df7cb.de  
  

Don’t explicitly mark range partitioning columns NOT NULL.

  
commit   : 3ec76ff1f2cf52e9b900349957b42d28128b7bc7    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Thu, 18 May 2017 13:48:10 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Thu, 18 May 2017 13:48:10 -0400    

Click here for diff

  
This seemed like a good idea originally because there's no way to mark  
a range partition as accepting NULL, but that now seems more like a  
current limitation than something we want to lock down for all time.  
For example, there's a proposal to add the notion of a default  
partition which accepts all rows not otherwise routed, which directly  
conflicts with the idea that a range-partitioned table should never  
allow nulls anywhere.  So let's change this while we still can, by  
putting the NOT NULL test into the partition constraint instead of  
changing the column properties.  
  
Amit Langote and Robert Haas, reviewed by Amit Kapila  
  
Discussion: http://postgr.es/m/8e2dd63d-c6fb-bb74-3c2b-ed6d63629c9d@lab.ntt.co.jp  
  

Fix typo in comment.

  
commit   : 2df537e43fdc432cccbe64de166ac97363cbca3c    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 18 May 2017 10:33:16 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 18 May 2017 10:33:16 +0300    

Click here for diff

  
Daniel Gustafsson  
  

pg_dump: Fix dumping of slot_name = NONE

  
commit   : 157239d2cdad8fdc19afc13269c852dbddbe290b    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 17 May 2017 21:19:14 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 17 May 2017 21:19:14 -0400    

Click here for diff

  
It previously wrote out slot_name = '', which was incorrect.  
  
Reported-by: Masahiko Sawada <sawada.mshk@gmail.com>  
  

Improve CREATE SUBSCRIPTION option parsing

  
commit   : 62345698513cbcb3c48a6dae414abf0f24fd163a    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 17 May 2017 20:47:37 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 17 May 2017 20:47:37 -0400    

Click here for diff

  
When creating a subscription with slot_name = NONE, we failed to check  
that also create_slot = false and enabled = false were set.  This  
created an invalid subscription and could later lead to a crash if a  
NULL slot name was accessed.  Add more checks around that for  
robustness.  
  
Reported-by: tushar <tushar.ahuja@enterprisedb.com>  
  

Post-PG 10 beta1 pgperltidy run

  
commit   : ce554810329b9b8e862eade08b598148931eb456    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 17 May 2017 19:01:23 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 17 May 2017 19:01:23 -0400    

Click here for diff

  
  

Post-PG 10 beta1 pgindent run

  
commit   : a6fd7b7a5f7bf3a8aa3f3d076cf09d922c1c6dd2    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 17 May 2017 16:31:56 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 17 May 2017 16:31:56 -0400    

Click here for diff

  
perltidy run not included.  
  

Update typedefs list in prep. for post-PG10 beta1 pgindent run

  
commit   : 8a943324780259757c77c56cfc597347d1150cdb    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 17 May 2017 15:52:16 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 17 May 2017 15:52:16 -0400    

Click here for diff

  
  

Add download URL for perltidy version v20090616

  
commit   : df238b43d76fb8e08469f418f570690651baaa7a    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 17 May 2017 15:29:37 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 17 May 2017 15:29:37 -0400    

Click here for diff

  
  

Code review for make_partition_op_expr.

  
commit   : b2e4399baaa805a046b7ffa155c666c80bbf8429    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Wed, 17 May 2017 14:31:48 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Wed, 17 May 2017 14:31:48 -0400    

Click here for diff

  
It's better to use the actual keynum here rather than 0, because  
someday someone might try to make list partitioning work with  
multiple partitioning columns.  
  
Jeevan Ladhe  
  
Discussion: http://postgr.es/m/CAOgcT0M6-mx+dSX47JGJuJP1CKr4XssBFVmKNETt0OZYWpFr+w@mail.gmail.com  
  

Revert changes to pg_basebackup and pg_waldump usage() code.

  
commit   : 05b5feb60e7cf36db08eb0d34dbd21854cb9e8ce    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 17 May 2017 13:04:03 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 17 May 2017 13:04:03 -0400    

Click here for diff

  
Partially revert commit c079673dcb7f210617c9fc1470e6bf166d8a2971.  
There were complaints that splitting switch descriptions would  
complicate translation efforts.  There are probably ways to resolve  
the formatting problem without doing that, but undo it while we're  
discussing.  
  

Remove redundant has_null member from PartitionBoundInfoData.

  
commit   : 236d6d462d2c8e4ae4ce04572cea6fe3ccc724cb    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Wed, 17 May 2017 12:48:16 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Wed, 17 May 2017 12:48:16 -0400    

Click here for diff

  
Jeevan Ladhe, with some changes by me.  
  
Discussion: http://postgr.es/m/CAOgcT0NZ_30-pjBpW2OgneV1ammArHkZDZ8B_KFC3q+_Xb2H9A@mail.gmail.com  
  

Add more tests for CREATE SUBSCRIPTION

  
commit   : 3db22794b76eb0548f002f02a607ebcd101fc68e    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 17 May 2017 12:22:56 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 17 May 2017 12:22:56 -0400    

Click here for diff

  
Add some tests for parsing different option combinations.  Fix some of  
the resulting error messages for recent changes in option naming.  
  
Author: Masahiko Sawada <sawada.mshk@gmail.com>  
  

Make psql handle EOF during COPY FROM STDIN properly on all platforms.

  
commit   : 9485516ea2bf3b3ff36020bec03cbb752d8a204c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 17 May 2017 12:24:19 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 17 May 2017 12:24:19 -0400    

Click here for diff

  
When stdin is a terminal, it's possible to end a COPY FROM STDIN with  
a keyboard EOF signal (typically control-D), and then keep on issuing  
SQL commands.  One would expect another COPY FROM STDIN to work as well,  
but on some platforms it did not.  This turns out to be because we were  
not resetting the stream's feof() flag, and BSD-ish versions of fread()  
and fgets() won't attempt to read more data if that's set.  
  
The misbehavior is observed on BSDen (including macOS), but not Linux,  
Windows, or SysV-ish Unixen, which makes this a portability bug not  
just a missing feature.  
  
Add a clearerr() call to fix the behavior, and improve the prompt that's  
issued when copying from a TTY to mention that EOF signals work.  
  
It's been like this forever, so back-patch to all supported branches.  
  
Thomas Munro  
  
Discussion: https://postgr.es/m/CAEepm=0MCGfYf=JAMiYhO6JPtv9-3ZfBo8fcGeCZ8oMzaw+Z+Q@mail.gmail.com  
  

Check relkind of tables in CREATE/ALTER SUBSCRIPTION

  
commit   : 944dc0f9cec7c3d33648f41aaecfbd976106e975    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 16 May 2017 22:57:16 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 16 May 2017 22:57:16 -0400    

Click here for diff

  
We used to only check for a supported relkind on the subscriber during  
replication, which is needed to ensure that the setup is valid and we  
don't crash.  But it's also useful to tell the user immediately when  
CREATE or ALTER SUBSCRIPTION is executed that the relation being added  
to the subscription is not of a supported relkind.  
  
Author: Petr Jelinek <petr.jelinek@2ndquadrant.com>  
Reported-by: tushar <tushar.ahuja@enterprisedb.com>  
  

psql: publication/subscription tab completion fixes

  
commit   : 0fbfb65d4bfd429651dc28faf3ad1846c965e18d    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 16 May 2017 22:19:21 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 16 May 2017 22:19:21 -0400    

Click here for diff

  
  

Preventive maintenance in advance of pgindent run.

  
commit   : c079673dcb7f210617c9fc1470e6bf166d8a2971    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 16 May 2017 20:36:35 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 16 May 2017 20:36:35 -0400    

Click here for diff

  
Reformat various places in which pgindent will make a mess, and  
fix a few small violations of coding style that I happened to notice  
while perusing the diffs from a pgindent dry run.  
  
There is one actual bug fix here: the need-to-enlarge-the-buffer code  
path in icu_convert_case was obviously broken.  Perhaps it's unreachable  
in our usage?  Or maybe this is just sadly undertested.  
  

Fix leakage of memory context header in find_all_inheritors().

  
commit   : ddd243584a0f353bbaba260d976cc41b251bbf21    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 16 May 2017 19:33:31 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 16 May 2017 19:33:31 -0400    

Click here for diff

  
Commit 827d6f977 contained the same misunderstanding of hash_create's API  
as commit 090010f2e.  As in 5d00b764c, remove the unnecessary layer of  
memory context.  (This bug is less significant than the other one, since  
the extra context would be under a relatively short-lived context, but  
it's still a bug.)  
  

Revert “Add a test for transition table usage in FOR EACH ROW trigger.”

  
commit   : a19ea9c6601bfb06dfd9f4c1060550dbc3f7bde1    
  
author   : Kevin Grittner <kgrittn@postgresql.org>    
date     : Tue, 16 May 2017 17:15:33 -0500    
  
committer: Kevin Grittner <kgrittn@postgresql.org>    
date     : Tue, 16 May 2017 17:15:33 -0500    

Click here for diff

  
This reverts commit 4a03f935b3438de27ee00d9e562ffe4e225978a9.  
  

Add a test for transition table usage in FOR EACH ROW trigger.

  
commit   : 4a03f935b3438de27ee00d9e562ffe4e225978a9    
  
author   : Kevin Grittner <kgrittn@postgresql.org>    
date     : Tue, 16 May 2017 16:09:55 -0500    
  
committer: Kevin Grittner <kgrittn@postgresql.org>    
date     : Tue, 16 May 2017 16:09:55 -0500    

Click here for diff

  
  

Try to ensure that stats collector’s receive buffer size is at least 100KB.

  
commit   : 8b0b6303e991079726e83d17401405e94da11564    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 16 May 2017 15:24:52 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 16 May 2017 15:24:52 -0400    

Click here for diff

  
Since commit 4e37b3e15, buildfarm member frogmouth has been failing  
occasionally with symptoms indicating that some expected stats data is  
getting dropped.  The reason that that commit changed the behavior seems  
probably to be that more data is getting shoved at the collector in a short  
span of time.  In current sources, the stats test's first session sends  
about 9KB of data while exiting, which is probably the same as what was  
sent just before wait_for_stats() in the previous test design.  But now,  
the test's second session is starting up concurrently, and it sends another  
2KB (presumably reflecting its initial catalog accesses).  Since frogmouth  
is running on Windows XP, which reputedly has a default socket receive  
buffer size of only 8KB, it is not very surprising if this has put us over  
the threshold where the receive buffer can overflow and drop messages.  
  
The same mechanism could very easily explain the intermittent stats test  
failures we've been seeing for years, since background processes such  
as the bgwriter will sometimes send data concurrently with all this, and  
could thus cause occasional buffer overflows.  
  
Hence, insert some code into pgstat_init() to increase the stats socket's  
receive buffer size to 100KB if it's less than that.  (On failure, emit a  
LOG message, but keep going.)  Modern systems seem to have default sizes  
in the range of 100KB-250KB, but older platforms don't.  I couldn't find  
any platforms that wouldn't accept 100KB, so in theory this won't cause  
any portability problems.  
  
If this is successful at reducing the buildfarm failure rate in HEAD,  
we should back-patch it, because it's certain that similar buffer overflows  
happen in the field on platforms with small buffer sizes.  Going forward,  
there might be an argument for trying to increase the buffer size even  
more, but let's take a baby step first.  
  
Discussion: https://postgr.es/m/22173.1494788088@sss.pgh.pa.us  
  

Fix relcache leak when row triggers on partitions are fired by COPY.

  
commit   : 59f40566cab95181ec132b3f0208f34e4c67f2b0    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Tue, 16 May 2017 12:46:32 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Tue, 16 May 2017 12:46:32 -0400    

Click here for diff

  
Thomas Munro, reviewed by Amit Langote  
  
Discussion: http://postgr.es/m/CAEepm=15Jss-yhFApuKzxcoCuFnb8TR8iQiWMjG=CLYPx48QLw@mail.gmail.com  
  

doc: Remove unnecessary RETURN statements from example.

  
commit   : 8e709a612f4c10cdc4b19a734cd67ac019d0a2ec    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Tue, 16 May 2017 11:35:23 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Tue, 16 May 2017 11:35:23 -0400    

Click here for diff

  
Paul Jungwirth, reviewed by Ashutosh Bapat.  
  
Discussion: http://postgr.es/m/e24a6a6d-5670-739b-00f3-41a226a80f25@illuminatedcomputing.com  
  

In SSL tests, don’t scribble on permissions of a repo file.

  
commit   : 91102dab44c3406f21bbbc28c1032d49e0721710    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 15 May 2017 23:27:51 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 15 May 2017 23:27:51 -0400    

Click here for diff

  
Modifying the permissions of a persistent file isn't really much nicer  
than modifying its contents, even if git doesn't currently notice it.  
Adjust the test script to make a copy and set the permissions of that  
instead.  
  
Michael Paquier, per a gripe from me.  Back-patch to 9.5 where these  
tests were introduced.  
  
Discussion: https://postgr.es/m/14836.1494885946@sss.pgh.pa.us  
  

Update CREATE SUBSCRIPTION docs for recent syntax change.

  
commit   : 6accefd46639db9f20bcc4c2e15c9844bae0d184    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 15 May 2017 22:06:27 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 15 May 2017 22:06:27 -0400    

Click here for diff

  
Masahiko Sawada  
  

Stamp 10beta1.

  
commit   : 5ad367a35b58a02686558a0189ef74f123ac85ba    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 15 May 2017 17:20:59 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 15 May 2017 17:20:59 -0400    

Click here for diff

  
  

git-ignore intermediate files from new docs toolchain.

  
commit   : 1aedcf98181602890ea8899202a7143543f9785a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 15 May 2017 15:48:23 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 15 May 2017 15:48:23 -0400    

Click here for diff

  
Building PDFs with the new toolchain creates *.fo temporary files.  
  

Add missing apostrophe.

  
commit   : 0ad226f2ae55620107eb61591d2f96236aec477c    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Mon, 15 May 2017 15:41:15 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Mon, 15 May 2017 15:41:15 -0400    

Click here for diff

  
Masahiko Sawada  
  
Discussion: http://postgr.es/m/CAD21AoAzaR_XV7j7Wk9-QYXaFoT8H4egKwXvFY63wc8Lw2C9cg@mail.gmail.com  
  

Update oidjoins regression test for v10.

  
commit   : e3f67a5a1732321dfa094e14c083dc482ad066b4    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 15 May 2017 14:04:03 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 15 May 2017 14:04:03 -0400    

Click here for diff

  
  

Add assertion to quiet Coverity

  
commit   : b1ff33fd9bb82937f4719f264972e6a3c83cdb89    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 15 May 2017 13:59:58 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 15 May 2017 13:59:58 -0400    

Click here for diff

  
  

Translation updates

  
commit   : 82d24bab75d4f85ae7a6d89f149d29fbb2ccbc70    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 15 May 2017 12:19:54 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 15 May 2017 12:19:54 -0400    

Click here for diff

  
Source-Git-URL: git://git.postgresql.org/git/pgtranslation/messages.git  
Source-Git-Hash: 398beeef4921df0956f917becd7b5669d2a8a5c4  
  

doc: Remove unused file

  
commit   : 4b99d32b2b0de97063b85a0ea69d482d8a4bf075    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 15 May 2017 12:09:19 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 15 May 2017 12:09:19 -0400    

Click here for diff

  
sql.sgml has not been part of the documentation since forever, so it's  
pointless to keep it around.  
  

Fix bogus syntax for CREATE PUBLICATION commands emitted by pg_dump.

  
commit   : 4041808b5b70433206b37e1305c807c325b06713    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 15 May 2017 11:48:39 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 15 May 2017 11:48:39 -0400    

Click here for diff

  
Original coding was careless about where to insert commas.  
  
Masahiko Sawada  
  
Discussion: https://postgr.es/m/3427593a-61aa-b17e-64ef-383b7742d6d9@enterprisedb.com  
  

Fix unsafe reference into relcache in constructed CommentStmt.

  
commit   : 12590c5d33d013e55995c0c0ea6c70262a6d13b3    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 15 May 2017 11:33:44 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 15 May 2017 11:33:44 -0400    

Click here for diff

  
The CommentStmt made by RebuildConstraintComment() has to pstrdup the  
relation name, else it will contain a dangling pointer after that  
relcache entry is flushed.  (I'm less sure that pstrdup'ing conname  
is necessary, but let's be safe.)  Failure to do this leads to weird  
errors or crashes, as reported by Marko Elezovic.  
  
Bug introduced by commit e42375fc8, so back-patch to 9.5 as that was.  
  
Fix by David Rowley, regression test by Michael Paquier  
  
Discussion: https://postgr.es/m/DB6PR03MB30775D58E732D4EB0C13725B9AE00@DB6PR03MB3077.eurprd03.prod.outlook.com  
  

Fix ALTER SEQUENCE locking

  
commit   : f8dc1985fd390774aab4ab0ba71036d6d5e631a9    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 9 May 2017 23:35:31 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 9 May 2017 23:35:31 -0400    

Click here for diff

  
In 1753b1b027035029c2a2a1649065762fafbf63f3, the pg_sequence system  
catalog was introduced.  This made sequence metadata changes  
transactional, while the actual sequence values are still behaving  
nontransactionally.  This requires some refinement in how ALTER  
SEQUENCE, which operates on both, locks the sequence and the catalog.  
  
The main problems were:  
  
- Concurrent ALTER SEQUENCE causes "tuple concurrently updated" error,  
  caused by updates to pg_sequence catalog.  
  
- Sequence WAL writes and catalog updates are not protected by same  
  lock, which could lead to inconsistent recovery order.  
  
- nextval() disregarding uncommitted ALTER SEQUENCE changes.  
  
To fix, nextval() and friends now lock the sequence using  
RowExclusiveLock instead of AccessShareLock.  ALTER SEQUENCE locks the  
sequence using ShareRowExclusiveLock.  This means that nextval() and  
ALTER SEQUENCE block each other, and ALTER SEQUENCE on the same sequence  
blocks itself.  (This was already the case previously for the OWNER TO,  
RENAME, and SET SCHEMA variants.)  Also, rearrange some code so that the  
entire AlterSequence is protected by the lock on the sequence.  
  
As an exception, use reduced locking for ALTER SEQUENCE ... RESTART.  
Since that is basically a setval(), it does not require the full locking  
of other ALTER SEQUENCE actions.  So check whether we are only running a  
RESTART and run with less locking if so.  
  
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>  
Reported-by: Jason Petersen <jason@citusdata.com>  
Reported-by: Andres Freund <andres@anarazel.de>  
  

Fix typo in comment

  
commit   : b1c45afb01248f5d6d6d2f0761a35843576f940f    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Mon, 15 May 2017 11:08:02 +0200    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Mon, 15 May 2017 11:08:02 +0200    

Click here for diff

  
Michael Paquier  
  

stats regression test’s wait_for_stats() must check timestamp too.

  
commit   : eda4ef81511ea62e49f5ea9edb8fbfdd529dd959    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 14 May 2017 23:33:03 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 14 May 2017 23:33:03 -0400    

Click here for diff

  
pg_stat_get_snapshot_timestamp() returns the timestamp seen in the "global"  
stats file.  Because pgstat_write_statsfiles() writes per-DB stats files  
before the global file (or at least before renaming it into place), there  
is a window where the test backend can see all the stats updates that  
wait_for_stats() was checking for (all of which come from the per-DB file)  
but also see the same global stats file it had seen at the start of the  
test script.  This results in a failure in only the "snapshot_newer" query,  
as reported by a couple of buildfarm members recently.  
  
I suspect that this ought to be back-patched.  Commit 4e37b3e15 has  
evidently increased the probability of this window getting hit, but  
it's not apparent why it could not have been hit before.  I'll refrain  
for the moment though.  
  

doc: update the “current as of” date in the PG 10 release notes

  
commit   : de7cca982ca253236051c2a7f6477bee5ce4b045    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Sun, 14 May 2017 23:15:43 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Sun, 14 May 2017 23:15:43 -0400    

Click here for diff

  
  

Make pgstat tabstat lookup hash table less fragile.

  
commit   : 5d00b764cd682f6071b35033f508a431d9d3f920    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 14 May 2017 22:52:41 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 14 May 2017 22:52:41 -0400    

Click here for diff

  
Code review for commit 090010f2e.  
  
Fix cases where an elog(ERROR) partway through a function would leave the  
persistent data structures in a corrupt state.  pgstat_report_stat got this  
wrong by invalidating PgStat_TableEntry structs before removing hashtable  
entries pointing to them, and get_tabstat_entry got it wrong by ignoring  
the possibility of palloc failure after it had already created a hashtable  
entry.  
  
Also, avoid leaking a memory context per transaction, which the previous  
code did through misunderstanding hash_create's API.  We do not need to  
create a context to hold the hash table; hash_create will do that.  
(The leak wasn't that large, amounting to only a memory context header  
per iteration, but it's still surprising that nobody noticed it yet.)  
  

doc: update PG 10 release notes for recent changes

  
commit   : b91e5b4684d840c903a78e86700b9d906033c2ad    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Sun, 14 May 2017 22:45:11 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Sun, 14 May 2017 22:45:11 -0400    

Click here for diff

  
  

Make stats regression test more robust in the face of parallel query.

  
commit   : 7606bbb3de48b35f6fc0c918b39cd4be82de8848    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 14 May 2017 21:39:10 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 14 May 2017 21:39:10 -0400    

Click here for diff

  
Commit 60690a6fe attempted to fix the wait_for_stats() function in this  
test so that it would wait properly if the tenk2 scans were done in  
parallel workers instead of the main session (typically as a consequence of  
force_parallel_mode being turned on).  However, we made it test for whether  
the main session's actions had been reported by looking for inserts on  
'trunc_stats_test'.  This is the Wrong Thing, because those aren't the last  
updates we expect the main session to do.  As shown by recent failures on  
buildfarm member frogmouth, it's entirely likely that the trunc_stats_test  
updates will be reported in a separate message from later updates, which  
means there can be a window in which wait_for_stats() will exit but not all  
the updates we are expecting to see will have arrived.  We should test for  
the last updates we're expecting, namely those on 'trunc_stats_test4'.  
  
Unfortunately, I doubt that this explains frogmouth's failures, because  
there's no reason to believe that it's running the tenk2 queries in  
parallel.  Still, the test is wrong on its own terms, so fix and back-patch  
to 9.6 where parallel query came in.  
  

Attempt to fix compiler warning.

  
commit   : edbe2a29365e0358387db92db0ccd5260d2bc7b1    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Sun, 14 May 2017 20:59:28 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Sun, 14 May 2017 20:59:28 -0400    

Click here for diff

  
Per a report from Tom Lane, newer versions of gcc apparently think  
that partexprs_item_saved can be used uninitialized.  Try to convince  
them otherwise.  
  

  
commit   : 93ece9cc887239deef6539d607063d98aa03aff3    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 14 May 2017 19:15:52 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 14 May 2017 19:15:52 -0400    

Click here for diff

  
Use the "statistics object" terminology uniformly here too.  Assorted  
copy-editing.  Put new catalogs.sgml sections into alphabetical order.  
  

Fix maintenance hazards caused by ill-considered use of default: cases.

  
commit   : e84c0195980f24b1c7f857b88834c1dcaf20a102    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 14 May 2017 13:32:59 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 14 May 2017 13:32:59 -0400    

Click here for diff

  
Remove default cases from assorted switches over ObjectClass and some  
related enum types, so that we'll get compiler warnings when someone  
adds a new enum value without accounting for it in all these places.  
  
In passing, re-order some switch cases as needed to match the declaration  
of enum ObjectClass.  OK, that's just neatnik-ism, but I dislike code  
that looks like it was assembled with the help of a dartboard.  
  
Discussion: https://postgr.es/m/20170512221010.nglatgt5azzdxjlj@alvherre.pgsql  
  

Fix handling of extended statistics during ALTER COLUMN TYPE.

  
commit   : b5b0db19b895f033ada35bc7c337183be7356977    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 14 May 2017 12:22:16 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 14 May 2017 12:22:16 -0400    

Click here for diff

  
ALTER COLUMN TYPE on a column used by a statistics object fails since  
commit 928c4de30, because the relevant switch in ATExecAlterColumnType  
is unprepared for columns to have dependencies from OCLASS_STATISTIC_EXT  
objects.  
  
Although the existing types of extended statistics don't actually need us  
to do any work for a column type change, it seems completely indefensible  
that that assumption is hidden behind the failure of an unrelated module  
to contain any code for the case.  Hence, create and call an API function  
in statscmds.c where the assumption can be explained, and where we could  
add code to deal with the problem when it inevitably becomes real.  
  
Also, the reason this wasn't handled before, neither for extended stats  
nor for the last half-dozen new OCLASS kinds :-(, is that the default:  
in that switch suppresses compiler warnings, allowing people to miss the  
need to consider it when adding an OCLASS.  We don't really need a default  
because surely getObjectClass should only return valid values of the enum;  
so remove it, and add the missed OCLASS entries where they should be.  
  
Discussion: https://postgr.es/m/20170512221010.nglatgt5azzdxjlj@alvherre.pgsql  
  

Update config.guess and config.sub

  
commit   : 65b655b53ec1cb91fda0d34e5176f8cdcfcf2e3d    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Sun, 14 May 2017 11:09:34 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Sun, 14 May 2017 11:09:34 -0400    

Click here for diff

  
  

Remove no-longer-needed fields of Hash plan nodes.

  
commit   : f6747434873693e001737ca06c30dcbcc2320b20    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 14 May 2017 11:07:40 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 14 May 2017 11:07:40 -0400    

Click here for diff

  
skewColType/skewColTypmod are no longer used in the wake of commit  
9aab83fc5, and seem unlikely to be wanted in future, so let's drop 'em.  
  
Discussion: https://postgr.es/m/16364.1494520862@sss.pgh.pa.us  
  

Standardize terminology for pg_statistic_ext entries.

  
commit   : f04c9a61468904b6815b2bc73a48878817766e0e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 14 May 2017 10:54:47 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 14 May 2017 10:54:47 -0400    

Click here for diff

  
Consistently refer to such an entry as a "statistics object", not just  
"statistics" or "extended statistics".  Previously we had a mismash of  
terms, accompanied by utter confusion as to whether the term was  
singular or plural.  That's not only grating (at least to the ear of  
a native English speaker) but could be outright misleading, eg in error  
messages that seemed to be referring to multiple objects where only one  
could be meant.  
  
This commit fixes the code and a lot of comments (though I may have  
missed a few).  I also renamed two new SQL functions,  
pg_get_statisticsextdef -> pg_get_statisticsobjdef  
pg_statistic_ext_is_visible -> pg_statistics_obj_is_visible  
to conform better with this terminology.  
  
I have not touched the SGML docs other than fixing those function  
names; the docs certainly need work but it seems like a separable task.  
  
Discussion: https://postgr.es/m/22676.1494557205@sss.pgh.pa.us  
  

Suppress indentation from Data::Dumper in regression tests

  
commit   : 12ad38b3b4b5004001a525e0a0eda2ec45329e8e    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Sun, 14 May 2017 01:10:18 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Sun, 14 May 2017 01:10:18 -0400    

Click here for diff

  
Ultra-modern versions of the perl Data::Dumper module have apparently  
changed how they indent output. Instead of trying to keep up we choose  
to tell it to supporess all indentation in the hstore_plperl regression  
tests.  
  
Backpatch to 9.5 where this feature was introduced.  
  

Specify –outputdir for isolation install check, not just plain check.

  
commit   : 29c7d5e4844443acaa74a0d06dd6c70b320bb315    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Sat, 13 May 2017 15:13:17 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Sat, 13 May 2017 15:13:17 -0700    

Click here for diff

  
This should probably have been part of 60f826c5e62.  
  
Reported-By: Andrew Gierth  
  

Avoid superfluous work for commits during logical slot creation.

  
commit   : 524dbc14335cde0b18745f05a9112436d212f061    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Sat, 13 May 2017 14:47:41 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Sat, 13 May 2017 14:47:41 -0700    

Click here for diff

  
Before 955a684e0401 logical decoding snapshot maintenance needed to  
cope with transactions it might not have seen in their entirety. For  
such transactions we'd to assume they modified the catalog (could have  
happened before we were watching), and thus a new snapshot had to be  
built, and distributed to concurrently running transactions.  
  
That's problematic because building a new snapshot isn't that cheap ,  
especially as the the array of committed transactions needs to be  
sorted.  When creating a slot on a server with a lot of transactions,  
this could make logical slot creation infeasibly expensive.  
  
After 955a684e0401 there's no need to deal with transaction that  
aren't guaranteed to be fully observable.  That allows to avoid  
building snapshots for transactions that haven't modified catalog,  
even before reaching consistency.  
  
While this isn't necessarily a bugfix, slot creation being impossible  
in some production workloads, is severe enough to warrant  
backpatching.  
  
Author: Andres Freund, based on a quite different patch from Petr Jelinek  
Analyzed-By: Petr Jelinek  
Reviewed-By: Petr Jelinek  
Discussion: https://postgr.es/m/f37e975c-908f-858e-707f-058d3b1eb214@2ndquadrant.com  
Backpatch: 9.4-, where logical decoding has been introduced  
  

Fix race condition leading to hanging logical slot creation.

  
commit   : 955a684e0401954a58e956535107bc4b7136d952    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Sat, 13 May 2017 14:21:00 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Sat, 13 May 2017 14:21:00 -0700    

Click here for diff

  
The snapshot assembly during the creation of logical slots relied  
waiting for transactions in xl_running_xacts to end, by checking for  
their commit/abort records.  Unfortunately, despite locking, it is  
possible to see an xl_running_xact record listing transactions as  
ready, that have already WAL-logged an commit/abort record, as the  
locking just prevents the ProcArray to be adjusted, and the commit  
record has to be logged first.  
  
That lead to either delayed or hanging snapshot creation, because  
snapbuild.c would wait "forever" to see commit/abort records for some  
transactions.  That hang resolved only if a xl_running_xacts record  
without any running transactions happened to be logged, far from  
certain on a busy server.  
  
It's impractical to prevent that via more heavyweight locking, the  
likelihood of deadlocks and significantly increased contention would  
be too big.  
  
Instead change the initial snapshot creation to be solely based on  
tracking the oldest running transaction via  
xl_running_xacts->oldestRunningXid - that actually ends up  
significantly simplifying the code.  That has two disadvantages:  
1) Because we cannot fully "trust" the contents of xl_running_xacts,  
   we cannot use it to build the initial snapshot.  Instead we have to  
   wait twice for all running transactions to finish.  
2) Previously a slot, unless the race occurred, could be created when  
   the all transaction perceived as running based on commit/abort  
   records, now we have to wait for the next xl_running_xacts record.  
To address that, trigger logging new xl_running_xacts record from  
within snapbuild.c exactly when necessary.  
  
Unfortunately snabuild.c's SnapBuild is stored on disk, one of the  
stupider ideas of a certain Mr Freund, so we can't change it in a  
minor release.  As this is going to be backpatched, we have to hack  
around a bit to keep on-disk compatibility.  A later commit will  
rejigger that on master.  
  
Author: Andres Freund, based on a quite different patch from Petr Jelinek  
Analyzed-By: Petr Jelinek  
Reviewed-By: Petr Jelinek  
Discussion: https://postgr.es/m/f37e975c-908f-858e-707f-058d3b1eb214@2ndquadrant.com  
Backpatch: 9.4-, where logical decoding has been introduced  
  

Redesign get_attstatsslot()/free_attstatsslot() for more safety and speed.

  
commit   : 9aab83fc5039d83e84144b7bed3fb1d62a74ae78    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 13 May 2017 15:14:39 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 13 May 2017 15:14:39 -0400    

Click here for diff

  
The mess cleaned up in commit da0759600 is clear evidence that it's a  
bug hazard to expect the caller of get_attstatsslot()/free_attstatsslot()  
to provide the correct type OID for the array elements in the slot.  
Moreover, we weren't even getting any performance benefit from that,  
since get_attstatsslot() was extracting the real type OID from the array  
anyway.  So we ought to get rid of that requirement; indeed, it would  
make more sense for get_attstatsslot() to pass back the type OID it found,  
in case the caller isn't sure what to expect, which is likely in binary-  
compatible-operator cases.  
  
Another problem with the current implementation is that if the stats array  
element type is pass-by-reference, we incur a palloc/memcpy/pfree cycle  
for each element.  That seemed acceptable when the code was written because  
we were targeting O(10) array sizes --- but these days, stats arrays are  
almost always bigger than that, sometimes much bigger.  We can save a  
significant number of cycles by doing one palloc/memcpy/pfree of the whole  
array.  Indeed, in the now-probably-common case where the array is toasted,  
that happens anyway so this method is basically free.  (Note: although the  
catcache code will inline any out-of-line toasted values, it doesn't  
decompress them.  At the other end of the size range, it doesn't expand  
short-header datums either.  In either case, DatumGetArrayTypeP would have  
to make a copy.  We do end up using an extra array copy step if the element  
type is pass-by-value and the array length is neither small enough for a  
short header nor large enough to have suffered compression.  But that  
seems like a very acceptable price for winning in pass-by-ref cases.)  
  
Hence, redesign to take these insights into account.  While at it,  
convert to an API in which we fill a struct rather than passing a bunch  
of pointers to individual output arguments.  That will make it less  
painful if we ever want further expansion of what get_attstatsslot can  
pass back.  
  
It's certainly arguable that this is new development and not something to  
push post-feature-freeze.  However, I view it as primarily bug-proofing  
and therefore something that's better to have sooner not later.  Since  
we aren't quite at beta phase yet, let's put it in.  
  
Discussion: https://postgr.es/m/16364.1494520862@sss.pgh.pa.us  
  

Teach \d+ to show partitioning constraints.

  
commit   : 1848b73d4576e30c89ba450ad9f169774a6819bf    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Sat, 13 May 2017 12:04:53 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Sat, 13 May 2017 12:04:53 -0400    

Click here for diff

  
The fact that we didn't have this in the first place is likely why  
the problem fixed by f8bffe9e6d700fd34759a92e47930ce9ba7dcbd5  
escaped detection.  
  
Patch by Amit Langote, reviewed and slightly adjusted by me.  
  
Discussion: http://postgr.es/m/CA+TgmoYWnV2GMnYLG-Czsix-E1WGAbo4D+0tx7t9NdfYBDMFsA@mail.gmail.com  
  

Fix multi-column range partitioning constraints.

  
commit   : f8bffe9e6d700fd34759a92e47930ce9ba7dcbd5    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Sat, 13 May 2017 11:35:30 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Sat, 13 May 2017 11:35:30 -0400    

Click here for diff

  
The old logic was just plain wrong.  
  
Report by Olaf Gawenda.  Patch by Amit Langote, reviewed by  
Beena Emerson and by me.  Minor adjustments by me also.  
  

Avoid hard-wired sleep delays in stats regression test.

  
commit   : 4e37b3e15c4e129dbbcf46e00ad36672f4f7b359    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 13 May 2017 09:42:12 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 13 May 2017 09:42:12 -0400    

Click here for diff

  
On faster machines, the overall runtime for running the core regression  
tests is under twenty seconds these days, of which the hard-wired delays  
in the stats test are a significant fraction.  But on closer inspection,  
it seems like we shouldn't need those.  
  
The initial 2-second delay is there only to reduce the risk of the test's  
stats messages not getting sent due to contention.  But analysis of the  
last ten years' worth of buildfarm runs shows no evidence that such  
failures actually occur.  (We do see failures that look like stats  
messages not getting sent, particularly on Windows; but there is little  
reason to believe that the initial delay reduces their frequency.)  
  
The later 1-second delay is there to ensure that our session's stats  
will have gotten sent.  But we could also do that by starting a fresh  
session, which takes well under 1 second even on very slow machines.  
  
Hence, let's remove both delays and see what happens.  The first delay  
was the only test of pg_sleep_for() in the regression tests, but we can  
move that responsibility into wait_for_stats().  
  
Discussion: https://postgr.es/m/17795.1493869423@sss.pgh.pa.us  
  

Use a better way of skipping all subscription tests on Windows

  
commit   : 8d9f06097714ce1f4243329172f73c2d20b896a6    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Sat, 13 May 2017 02:47:11 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Sat, 13 May 2017 02:47:11 -0400    

Click here for diff

  
This way we only need to specify the number of tests in one place, and  
the output is also less verbose.  
  

Complete tab completion for DROP STATISTICS

  
commit   : d99d58cdc8c0b5b50ee92995e8575c100b1a458a    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Sat, 13 May 2017 01:05:48 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Sat, 13 May 2017 01:05:48 -0300    

Click here for diff

  
Tab-completing DROP STATISTICS would only work if you started writing  
the schema name containing the statistics object, because the visibility  
clause was missing.  To add it, we need to add SQL-callable support for  
testing visibility of a statistics object, like all other object types  
already have.  
  
Discussion: https://postgr.es/m/22676.1494557205@sss.pgh.pa.us  
  

Avoid searching for callback functions in CallSyscacheCallbacks().

  
commit   : 2df5d465558b6f17c161cbbe246b050b453ec99c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 12 May 2017 19:05:13 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 12 May 2017 19:05:13 -0400    

Click here for diff

  
We have now grown enough registerable syscache-invalidation callback  
functions that the original assumption that there would be few of them  
is causing performance problems.  In particular, let's fix things so that  
CallSyscacheCallbacks doesn't have to search the whole array to find  
which callback(s) to invoke for a given cache ID.  Preserve the original  
behavior that callbacks are called in order of registration, just in  
case there's someplace that depends on that (which I doubt).  
  
In support of this, export the number of syscaches from syscache.h.  
People could have found that out anyway from the enum, but adding a  
#define makes that much safer.  
  
This provides a useful additional speedup in Mathieu Fenniak's  
logical-decoding test case, although we're reaching the point of  
diminishing returns there.  I think any further improvement will have  
to come from reducing the number of cache invalidations that are  
triggered in the first place.  Still, we can hope that this change  
gives some incremental benefit for all invalidation scenarios.  
  
Back-patch to 9.4 where logical decoding was introduced.  
  
Discussion: https://postgr.es/m/CAHoiPjzea6N0zuCi=+f9v_j94nfsy6y8SU7-=bp4=7qw6_i=Rg@mail.gmail.com  
  

doc: update markup for release note “release date” block

  
commit   : 9ed74fd463ede1db4ce829f9ff461d0b7f28f1f3    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Fri, 12 May 2017 18:31:55 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Fri, 12 May 2017 18:31:55 -0400    

Click here for diff

  
This has to be backpatched to all supported releases so release markup  
added to HEAD and copied to back branches matches the existing markup.  
  
Reported-by: Peter Eisentraut  
  
Discussion: 2b8a2552-fffa-f7c8-97c5-14db47a87731@2ndquadrant.com  
  
Author: initial patch and sample markup by Peter Eisentraut  
  
Backpatch-through: 9.2  
  

Reduce initial size of RelfilenodeMapHash.

  
commit   : 8085a4f7510191b8fe7f8f7b5846fdbc79abcf8d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 12 May 2017 18:30:02 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 12 May 2017 18:30:02 -0400    

Click here for diff

  
A test case provided by Mathieu Fenniak shows that hash_seq_search'ing  
this hashtable can consume a very significant amount of overhead during  
logical decoding, which triggers frequent cache invalidation.  Testing  
suggests that the actual population of the hashtable is often no more  
than a few dozen entries, so we can cut the overhead just by dropping  
the initial number of buckets down from 1024 --- I chose to cut it to 64.  
(In situations where we do have a significant number of entries, we  
shouldn't get any real penalty from doing this, as the dynahash.c code  
will resize the hashtable automatically.)  
  
This gives a further factor-of-two savings in Mathieu's test case.  
That may be overly optimistic for real-world benefit, as real cases  
may have larger average table populations, but it's hard to see it  
turning into a net negative for any workload.  
  
Back-patch to 9.4 where relfilenodemap.c was introduced.  
  
Discussion: https://postgr.es/m/CAHoiPjzea6N0zuCi=+f9v_j94nfsy6y8SU7-=bp4=7qw6_i=Rg@mail.gmail.com  
  

getObjectDescription: support extended statistics

  
commit   : 5e2af609e14ede1b5e0d73d59ed8548c76e1943a    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 12 May 2017 19:22:03 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 12 May 2017 19:22:03 -0300    

Click here for diff

  
This was missed in 7b504eb282ca.  
  
Remove the "default:" clause in the switch, to avoid this problem in the  
future.  Other switches involving the same enum should probably be  
changed in the same way, but are not touched by this patch.  
  
Discussion: https://postgr.es/m/20170512204800.iqt2uwyx3c32j45r@alvherre.pgsql  
  

Avoid searching for the target catcache in CatalogCacheIdInvalidate.

  
commit   : 50ee1c7462d796639eef6c24b1797df8c4d6c098    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 12 May 2017 18:17:29 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 12 May 2017 18:17:29 -0400    

Click here for diff

  
A test case provided by Mathieu Fenniak shows that the initial search for  
the target catcache in CatalogCacheIdInvalidate consumes a very significant  
amount of overhead in cases where cache invalidation is triggered but has  
little useful work to do.  There is no good reason for that search to exist  
at all, as the index array maintained by syscache.c allows direct lookup of  
the catcache from its ID.  We just need a frontend function in syscache.c,  
matching the division of labor for most other cache-accessing operations.  
  
While there's more that can be done in this area, this patch alone reduces  
the runtime of Mathieu's example by 2X.  We can hope that it offers some  
useful benefit in other cases too, although usually cache invalidation  
overhead is not such a striking fraction of the total runtime.  
  
Back-patch to 9.4 where logical decoding was introduced.  It might be  
worth going further back, but presently the only case we know of where  
cache invalidation is really a significant burden is in logical decoding.  
Also, older branches have fewer catcaches, reducing the possible benefit.  
  
(Note: although this nominally changes catcache's API, we have always  
documented CatalogCacheIdInvalidate as a private function, so I would  
have little sympathy for an external module calling it directly.  So  
backpatching should be fine.)  
  
Discussion: https://postgr.es/m/CAHoiPjzea6N0zuCi=+f9v_j94nfsy6y8SU7-=bp4=7qw6_i=Rg@mail.gmail.com  
  

Fix dependencies for extended statistics objects.

  
commit   : 928c4de30991ca24a46a92f006892c039af30833    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 12 May 2017 16:26:31 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 12 May 2017 16:26:31 -0400    

Click here for diff

  
A stats object ought to have a dependency on each individual column  
it reads, not the entire table.  Doing this honestly lets us get rid  
of the hard-wired logic in RemoveStatisticsExt, which seems to have  
been misguidedly modeled on RemoveStatistics; and it will be far easier  
to extend to multiple tables later.  
  
Also, add overlooked dependency on owner, and make the dependency on  
schema be NORMAL like every other such dependency.  
  
There remains some unfinished work here, which is to allow statistics  
objects to be extension members.  That takes more effort than just  
adding the dependency call, though, so I left it out for now.  
  
initdb forced because this changes the set of pg_depend records that  
should exist for a statistics object.  
  
Discussion: https://postgr.es/m/22676.1494557205@sss.pgh.pa.us  
  

Change CREATE STATISTICS syntax

  
commit   : bc085205c8a425fcaa54e27c6dcd83101130439b    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 12 May 2017 14:59:23 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 12 May 2017 14:59:23 -0300    

Click here for diff

  
Previously, we had the WITH clause in the middle of the command, where  
you'd specify both generic options as well as statistic types.  Few  
people liked this, so this commit changes it to remove the WITH keyword  
from that clause and makes it accept statistic types only.  (We  
currently don't have any generic options, but if we invent in the  
future, we will gain a new WITH clause, probably at the end of the  
command).  
  
Also, the column list is now specified without parens, which makes the  
whole command look more similar to a SELECT command.  This change will  
let us expand the command to supporting expressions (not just columns  
names) as well as multiple tables and their join conditions.  
  
Tom added lots of code comments and fixed some parts of the CREATE  
STATISTICS reference page, too; more changes in this area are  
forthcoming.  He also fixed a potential problem in the alter_generic  
regression test, reducing verbosity on a cascaded drop to avoid  
dependency on message ordering, as we do in other tests.  
  
Tom also closed a security bug: we documented that table ownership was  
required in order to create a statistics object on it, but didn't  
actually implement it.  
  
Implement tab-completion for statistics objects.  This can stand some  
more improvement.  
  
Authors: Alvaro Herrera, with lots of cleanup by Tom Lane  
Discussion: https://postgr.es/m/20170420212426.ltvgyhnefvhixm6i@alvherre.pgsql  
  

Replace another “transaction log” with “write-ahead log”

  
commit   : 46052d9ef314deafa8c94ac7fda4a2811db0679e    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 12 May 2017 13:53:24 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 12 May 2017 13:53:24 -0400    

Click here for diff

  
Reported-by: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org>  
  

Standardize “WAL location” terminology

  
commit   : d496a65790734f808789f39e4f63b2790821c2be    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 12 May 2017 13:51:27 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 12 May 2017 13:51:27 -0400    

Click here for diff

  
Other previously used terms were "WAL position" or "log position".  
  

Replace “transaction log” with “write-ahead log”

  
commit   : c1a7f64b4a720a662ecec809bc9e289f35e887ad    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 12 May 2017 11:49:56 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 12 May 2017 11:49:56 -0400    

Click here for diff

  
This makes documentation and error messages match the renaming of "xlog"  
to "wal" in APIs and file naming.  
  

Honor PROVE_FLAGS environment setting

  
commit   : 56b6ef893fee9e9bf47d927a02f4d1ea911f4d9c    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 12 May 2017 11:11:49 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 12 May 2017 11:11:49 -0400    

Click here for diff

  
On MSVC builds and on back branches that means removing the hardcoded  
--verbose setting. On master for Unix that means removing the empty  
setting in the global Makefile so that the value can be acquired from  
the environment as well as from the make arguments.  
  
Backpatch to 9.4 where we introduced TAP tests  
  

Add libxml2 include path for MSVC builds

  
commit   : b757e01f62e44b4f425f78e3dc4e247ca9f1e983    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 12 May 2017 10:17:54 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 12 May 2017 10:17:54 -0400    

Click here for diff

  
On Unix this path is detected via the use of xml2-config, but that's not  
available on Windows. This means that users building with libxml2 will  
no longer need to move things around from the standard libxml2  
installation for MSVC builds.  
  
Backpatch to all live branches.  
  

pg_dump: Add –no-publications option

  
commit   : 96e1cb4c0fb45dfca2d8b0a58693b94cbdaabe11    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 12 May 2017 09:15:40 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 12 May 2017 09:15:40 -0400    

Click here for diff

  
Author: Michael Paquier <michael.paquier@gmail.com>  
  

Rework the options syntax for logical replication commands

  
commit   : b807f59828fbc02fea612e1cbc0066c6dfa3be9b    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 12 May 2017 08:57:01 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 12 May 2017 08:57:01 -0400    

Click here for diff

  
For CREATE/ALTER PUBLICATION/SUBSCRIPTION, use similar option style as  
other statements that use a WITH clause for options.  
  
Author: Petr Jelinek <petr.jelinek@2ndquadrant.com>  
  

Avoid tests which crash the calling process on Windows

  
commit   : 734cb4c2e7de92972c01b6339a3e15ac4bc605dd    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 12 May 2017 06:41:23 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 12 May 2017 06:41:23 -0400    

Click here for diff

  
Certain recovery tests use the Perl IPC::Run module's start/kill_kill  
method of processing. On at least some versions of perl this causes the  
whole process and its caller to crash. If we ever find a better way of  
doing these tests they can be re-enabled on this platform. This does not  
affect Mingw or Cygwin builds, which use a different perl and a  
different shell and so are not affected.  
  

Lag tracking for logical replication

  
commit   : 024711bb544645c8b1061e9f02b261e2e336981d    
  
author   : Simon Riggs <simon@2ndQuadrant.com>    
date     : Fri, 12 May 2017 10:50:56 +0100    
  
committer: Simon Riggs <simon@2ndQuadrant.com>    
date     : Fri, 12 May 2017 10:50:56 +0100    

Click here for diff

  
Lag tracking is called for each commit, but we introduce  
a pacing delay to ensure we don't swamp the lag tracker.  
  
Author: Petr Jelinek, with minor pacing delay code from me  
  

Doc fix: scale(numeric) returns integer, not numeric.

  
commit   : efa2c18f4e8a8ccc74d9005d960f4c1a2bf05ea9    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 11 May 2017 18:09:22 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 11 May 2017 18:09:22 -0400    

Click here for diff

  
Thinko in commit abb173392, which introduced this function.  
  
Report: https://postgr.es/m/20170511215234.1795.54347@wrigleys.postgresql.org  
  

Increase MAX_SYSCACHE_CALLBACKS to provide more room for extensions.

  
commit   : 596a7c8df74ed2ffb850dd4408094ef489a3d14d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 11 May 2017 14:51:21 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 11 May 2017 14:51:21 -0400    

Click here for diff

  
Increase from the historical value of 32 to 64.  We are up to 31 callers  
of CacheRegisterSyscacheCallback() in HEAD, so if they were all to be  
exercised in one process that would leave only one slot for add-on modules.  
It's probably not possible for that to happen, but still we clearly need  
more daylight here.  (At some point it might be worth making the array  
dynamically resizable; but since we've never heard a complaint of "out of  
syscache_callback_list slots" happening in the field, I doubt it's worth  
it yet.)  
  
Back-patch as far as 9.4, which is where we increased the companion limit  
MAX_RELCACHE_CALLBACKS (cf commit f01d1ae3a).  It's not as urgent in  
released branches, which have only a couple dozen call sites in core, but  
it still seems that somebody might hit the limit before these branches die.  
  
Discussion: https://postgr.es/m/12184.1494450131@sss.pgh.pa.us  
  

  
commit   : d10c626de47d8b048b663471c7785603a2ec8641    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 11 May 2017 11:49:59 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 11 May 2017 11:49:59 -0400    

Click here for diff

  
Per discussion, "location" is a rather vague term that could refer to  
multiple concepts.  "LSN" is an unambiguous term for WAL locations and  
should be preferred.  Some function names, view column names, and function  
output argument names used "lsn" already, but others used "location",  
as well as yet other terms such as "wal_position".  Since we've already  
renamed a lot of things in this area from "xlog" to "wal" for v10,  
we may as well incur a bit more compatibility pain and make these names  
all consistent.  
  
David Rowley, minor additional docs hacking by me  
  
Discussion: https://postgr.es/m/CAKJS1f8O0njDKe8ePFQ-LK5-EjwThsDws6ohJ-+c6nWK+oUxtg@mail.gmail.com  
  

Revert “Permit dump/reload of not-too-large >1GB tuples”

  
commit   : b66adb7b0c83e632e0f881f828fa6f4233d01d06    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 10 May 2017 18:41:27 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 10 May 2017 18:41:27 -0300    

Click here for diff

  
This reverts commits fa2fa9955280 and 42f50cb8fa98.  
  
While the functionality that was intended to be provided by these  
commits is desired, the patch didn't actually solve as many of the  
problematic situations as we hoped, and it created a bunch of its own  
problems.  Since we're going to require more extensive changes soon for  
other reasons and users have been working around these problems for a  
long time already, there is no point in spending effort in fixing this  
halfway measure.  
  
Per complaint from Tom Lane.  
Discussion: https://postgr.es/m/21407.1484606922@sss.pgh.pa.us  
  
(Commit fa2fa9955280 had already been reverted in branches 9.5 as  
f858524ee4f and 9.6 as e9e44a0953, so this touches master only.  
Commit 42f50cb8fa98 was not present in the older branches.)  
  

psql: Add missing translation markers

  
commit   : b83f4e4a25394b964a7fadc6429c7de82d62b58a    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 10 May 2017 10:14:49 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 10 May 2017 10:14:49 -0400    

Click here for diff

  
  

Fix typo.

  
commit   : 03bf59676ea0473e85b5540fe23be399ee3b3ac4    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Tue, 9 May 2017 23:57:52 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Tue, 9 May 2017 23:57:52 -0400    

Click here for diff

  
Thomas Munro  
  
Discussion: http://postgr.es/m/CAEepm=3vV1YKxDfLMqq-nYM2fN+STMYLwPKFCoah4M0gxqqNNg@mail.gmail.com  
  

Avoid theoretical infinite loop loading relcache partition key.

  
commit   : 622c82279dcba1208049b8b9ae93023757a2dbbe    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Tue, 9 May 2017 23:51:54 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Tue, 9 May 2017 23:51:54 -0400    

Click here for diff

  
Amit Langote, per report from 甄明洋  
  
Discussion: http://postgr.es/m/57bd1e1.1886.15bd7b79cee.Coremail.18612389267@yeah.net  
  

Document trigger-firing behavior for inheritance/partitioning.

  
commit   : e17628145ac33bf271b3f575b52cdbe9dde0bb80    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Tue, 9 May 2017 23:49:20 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Tue, 9 May 2017 23:49:20 -0400    

Click here for diff

  
Amit Langote, reviewed Thomas Munro and by me.  
  
Discussion: http://postgr.es/m/CA+Tgmoadpcs3=mMgdyqVX7L7L_PwO_Dn5j-98a6Tj7ByBuimUQ@mail.gmail.com  
  

Remove no-longer-needed compatibility code for hash indexes.

  
commit   : a5775991bb86d95939b3eb1173b88d8c5312962d    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Tue, 9 May 2017 23:44:21 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Tue, 9 May 2017 23:44:21 -0400    

Click here for diff

  
Because commit ea69a0dead5128c421140dc53fac165ba4af8520 bumped the  
HASH_VERSION, we don't need to worry about PostgreSQL 10 seeing  
bucket pages from earlier versions.  
  
Amit Kapila  
  
Discussion: http://postgr.es/m/CAA4eK1LAo4DGwh+mi-G3U8Pj1WkBBeFL38xdCnUHJv1z4bZFkQ@mail.gmail.com  
  

Fix typos in comments.

  
commit   : df1a4eba948f386845f75c2864de0a35e5ede849    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Tue, 9 May 2017 23:40:08 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Tue, 9 May 2017 23:40:08 -0400    

Click here for diff

  
Etsuro Fujita  
  
Discussion: http://postgr.es/m/968d99bf-0fa8-085b-f0a1-a379f8d661ff@lab.ntt.co.jp  
  

Prohibit transition tables on views and foreign tables.

  
commit   : 9e6104c6672dc948a430d1ee269b0c31bf5bc974    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Tue, 9 May 2017 23:34:02 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Tue, 9 May 2017 23:34:02 -0400    

Click here for diff

  
Thomas Munro, per off-list report from Prabhat Sabu.  Changes  
to the message wording for consistency with the existing  
relkind check for partitioned tables by me.  
  
Discussion: http://postgr.es/m/CAEepm=2xJFFpGM+N=gpWx-9Nft2q1oaFZX07_y23AHCrJQLt0g@mail.gmail.com  
  

Don’t permit transition tables with TRUNCATE triggers.

  
commit   : 29fd3d9da0ff9e230ff051c1423871bd6eac377d    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Tue, 9 May 2017 23:22:39 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Tue, 9 May 2017 23:22:39 -0400    

Click here for diff

  
Prior to this prohibition, such a trigger caused a crash.  
  
Thomas Munro, per a report from Neha Sharma.  I added a  
regression test.  
  
Discussion: http://postgr.es/m/CAEepm=0VR5W-N38eTkO_FqJbGqQ_ykbBRmzmvHyxDhy1p=0Csw@mail.gmail.com  
  

Pass EXEC_FLAG_REWIND when initializing a tuplestore scan.

  
commit   : 304007d9f1f66fd37e50e5a5aa6f17400f1239f8    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Tue, 9 May 2017 23:13:21 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Tue, 9 May 2017 23:13:21 -0400    

Click here for diff

  
Since a rescan is possible, we must be able to rewind.  
  
Thomas Munro, per a report from Prabhat Sabu  
  
Discussion: http://postgr.es/m/CAEepm=2=Uv5fm=exqL+ygBxaO+-tgmC=o+63H4zYAXi9HtXf1w@mail.gmail.com  
  

Disallow finite partition bound following earlier UNBOUNDED column.

  
commit   : 3439f84475642fab029df0c06c81df94e6941dc0    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Tue, 9 May 2017 22:41:12 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Tue, 9 May 2017 22:41:12 -0400    

Click here for diff

  
Amit Langote, per an observation by me.  
  
Discussion: http://postgr.es/m/CA+TgmoYWnV2GMnYLG-Czsix-E1WGAbo4D+0tx7t9NdfYBDMFsA@mail.gmail.com  
  

Improve memory use in logical replication apply

  
commit   : 489b96e80b96c0eda02575347654e87968f2f5f4    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 9 May 2017 14:40:42 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 9 May 2017 14:40:42 -0400    

Click here for diff

  
Previously, the memory used by the logical replication apply worker for  
processing messages would never be freed, so that could end up using a  
lot of memory.  To improve that, change the existing ApplyContext memory  
context to ApplyMessageContext and reset that after every  
message (similar to MessageContext used elsewhere).  For consistency of  
naming, rename the ApplyCacheContext to ApplyContext.  
  
Author: Stas Kelvich <s.kelvich@postgrespro.ru>  
  

Ignore PQcancel errors properly

  
commit   : e0bf16060be695ced920727fa29f0d9ede61bd3f    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 9 May 2017 14:58:51 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 9 May 2017 14:58:51 -0300    

Click here for diff

  
Add a (void) cast to all PQcancel() calls that purposefully don't check  
the return value, to keep compilers and static checkers happy.  
  
Per Coverity.  
  

pg_dump: Add –no-subscriptions option

  
commit   : 26aa1cf376f68b800b73c326edeea6d1996ec246    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 9 May 2017 10:58:06 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 9 May 2017 10:58:06 -0400    

Click here for diff

  
Author: Michael Paquier <michael.paquier@gmail.com>  
Reviewed-by: Petr Jelinek <petr.jelinek@2ndquadrant.com>  
  

doc: Add info about replication slot management

  
commit   : ab178bb2f4b35fbcc0f78822c72063a8a5e9dbb0    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 9 May 2017 10:25:26 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 9 May 2017 10:25:26 -0400    

Click here for diff

  
Add some more information about managing replication slots associated  
with logical replication subscriptions.  
  

Remove the NODROP SLOT option from DROP SUBSCRIPTION

  
commit   : 013c1178fd0adefa0f68d5ce2d84e7ae6f9613a1    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 9 May 2017 10:20:42 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 9 May 2017 10:20:42 -0400    

Click here for diff

  
It turned out this approach had problems, because a DROP command should  
not have any options other than CASCADE and RESTRICT.  Instead, always  
attempt to drop the slot if there is one configured, but also add an  
ALTER SUBSCRIPTION action to set the slot to NONE.  
  
Author: Petr Jelinek <petr.jelinek@2ndquadrant.com>  
Reported-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://www.postgresql.org/message-id/29431.1493730652@sss.pgh.pa.us  
  

pgindent: use HTTP instead of FTP to retrieve pg_bsd_indent src

  
commit   : c4c493fd3581dfbce45e903b87e12eea508f47e4    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 9 May 2017 09:28:44 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 9 May 2017 09:28:44 -0400    

Click here for diff

  
FTP support will be removed from ftp.postgresql.org in months, but http  
still works.  Typedefs already used http.  
  

Further patch rangetypes_selfuncs.c’s statistics slot management.

  
commit   : da0759600664439238fe25fa84b1f0059bfdcdd6    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 8 May 2017 15:02:57 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 8 May 2017 15:02:57 -0400    

Click here for diff

  
Values in a STATISTIC_KIND_RANGE_LENGTH_HISTOGRAM slot are float8,  
not of the type of the column the statistics are for.  
  
This bug is at least partly the fault of sloppy specification comments  
for get_attstatsslot()/free_attstatsslot(): the type OID they want is that  
of the stavalues entries, not of the underlying column.  (I double-checked  
other callers and they seem to get this right.)  Adjust the comments to be  
more correct.  
  
Per buildfarm.  
  
Security: CVE-2017-7484  
  

Check connection info string in ALTER SUBSCRIPTION

  
commit   : fe974cc5a69903e9f53b36d6e2709fd3de0a1ac7    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 8 May 2017 14:01:00 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 8 May 2017 14:01:00 -0400    

Click here for diff

  
Previously it would allow an invalid connection string to be set.  
  
Author: Petr Jelinek <petr.jelinek@2ndquadrant.com>  
Reported-by: tushar <tushar.ahuja@enterprisedb.com>  
  

Last-minute updates for release notes.

  
commit   : c89d2d0204f25e556e94dabd0fd5174cf6963b1d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 8 May 2017 12:57:27 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 8 May 2017 12:57:27 -0400    

Click here for diff

  
Security: CVE-2017-7484, CVE-2017-7485, CVE-2017-7486  
  

Fix statistics reporting in logical replication workers

  
commit   : 9a591c1bccc5edeb06b979c59f39753982131181    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 8 May 2017 12:07:59 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 8 May 2017 12:07:59 -0400    

Click here for diff

  
This new arrangement ensures that statistics are reported right after  
commit of transactions.  The previous arrangement didn't get this quite  
right and could lead to assertion failures.  
  
Author: Petr Jelinek <petr.jelinek@2ndquadrant.com>  
Reported-by: Erik Rijkers <er@xs4all.nl>  
  

Fix possibly-uninitialized variable.

  
commit   : b6576e5914d042bfad1c8629fe199f59b036c342    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 8 May 2017 11:18:40 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 8 May 2017 11:18:40 -0400    

Click here for diff

  
Oversight in e2d4ef8de et al (my fault not Peter's).  Per buildfarm.  
  
Security: CVE-2017-7484  
  

Match pg_user_mappings limits to information_schema.user_mapping_options.

  
commit   : 3eefc51053f250837c3115c12f8119d16881a2d7    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Mon, 8 May 2017 07:24:24 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 8 May 2017 07:24:24 -0700    

Click here for diff

  
Both views replace the umoptions field with NULL when the user does not  
meet qualifications to see it.  They used different qualifications, and  
pg_user_mappings documented qualifications did not match its implemented  
qualifications.  Make its documentation and implementation match those  
of user_mapping_options.  One might argue for stronger qualifications,  
but these have long, documented tenure.  pg_user_mappings has always  
exhibited this problem, so back-patch to 9.2 (all supported versions).  
  
Michael Paquier and Feike Steenbergen.  Reviewed by Jeff Janes.  
Reported by Andrew Wheelwright.  
  
Security: CVE-2017-7486  
  

Restore PGREQUIRESSL recognition in libpq.

  
commit   : 0170b10dff04e0f50f5522c377a4d10d4424155c    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Mon, 8 May 2017 07:24:24 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 8 May 2017 07:24:24 -0700    

Click here for diff

  
Commit 65c3bf19fd3e1f6a591618e92eb4c54d0b217564 moved handling of the,  
already then, deprecated requiressl parameter into conninfo_storeval().  
The default PGREQUIRESSL environment variable was however lost in the  
change resulting in a potentially silent accept of a non-SSL connection  
even when set.  Its documentation remained.  Restore its implementation.  
Also amend the documentation to mark PGREQUIRESSL as deprecated for  
those not following the link to requiressl.  Back-patch to 9.3, where  
commit 65c3bf1 first appeared.  
  
Behavior has been more complex when the user provides both deprecated  
and non-deprecated settings.  Before commit 65c3bf1, libpq operated  
according to the first of these found:  
  
  requiressl=1  
  PGREQUIRESSL=1  
  sslmode=*  
  PGSSLMODE=*  
  
(Note requiressl=0 didn't override sslmode=*; it would only suppress  
PGREQUIRESSL=1 or a previous requiressl=1.  PGREQUIRESSL=0 had no effect  
whatsoever.)  Starting with commit 65c3bf1, libpq ignored PGREQUIRESSL,  
and order of precedence changed to this:  
  
  last of requiressl=* or sslmode=*  
  PGSSLMODE=*  
  
Starting now, adopt the following order of precedence:  
  
  last of requiressl=* or sslmode=*  
  PGSSLMODE=*  
  PGREQUIRESSL=1  
  
This retains the 65c3bf1 behavior for connection strings that contain  
both requiressl=* and sslmode=*.  It retains the 65c3bf1 change that  
either connection string option overrides both environment variables.  
For the first time, PGSSLMODE has precedence over PGREQUIRESSL; this  
avoids reducing security of "PGREQUIRESSL=1 PGSSLMODE=verify-full"  
configurations originating under v9.3 and later.  
  
Daniel Gustafsson  
  
Security: CVE-2017-7485  
  

doc: add Simon Riggs to VACUUM VERBOSE PG 10 release note item

  
commit   : 74cadeaa2f12320c5064af61915fefcd5c24149a    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 8 May 2017 09:50:07 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 8 May 2017 09:50:07 -0400    

Click here for diff

  
Reported-by: Masahiko Sawada  
  

Add security checks to selectivity estimation functions

  
commit   : e2d4ef8de869c57e3bf270a30c12d48c2ce4e00c    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 5 May 2017 12:18:48 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 5 May 2017 12:18:48 -0400    

Click here for diff

  
Some selectivity estimation functions run user-supplied operators over  
data obtained from pg_statistic without security checks, which allows  
those operators to leak pg_statistic data without having privileges on  
the underlying tables.  Fix by checking that one of the following is  
satisfied: (1) the user has table or column privileges on the table  
underlying the pg_statistic data, or (2) the function implementing the  
user-supplied operator is leak-proof.  If neither is satisfied, planning  
will proceed as if there are no statistics available.  
  
At least one of these is satisfied in most cases in practice.  The only  
situations that are negatively impacted are user-defined or  
not-leak-proof operators on a security-barrier view.  
  
Reported-by: Robert Haas <robertmhaas@gmail.com>  
Author: Peter Eisentraut <peter_e@gmx.net>  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
  
Security: CVE-2017-7484  
  

Remove support for password_encryption=‘off’ / ‘plain’.

  
commit   : eb61136dc75a76caef8460fa939244d8593100f2    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 8 May 2017 11:26:07 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 8 May 2017 11:26:07 +0300    

Click here for diff

  
Storing passwords in plaintext hasn't been a good idea for a very long  
time, if ever. Now seems like a good time to finally forbid it, since we're  
messing with this in PostgreSQL 10 anyway.  
  
Remove the CREATE/ALTER USER UNENCRYPTED PASSSWORD 'foo' syntax, since  
storing passwords unencrypted is no longer supported. ENCRYPTED PASSWORD  
'foo' is still accepted, but ENCRYPTED is now just a noise-word, it does  
the same as just PASSWORD 'foo'.  
  
Likewise, remove the --unencrypted option from createuser, but accept  
--encrypted as a no-op for backward compatibility. AFAICS, --encrypted was  
a no-op even before this patch, because createuser encrypted the password  
before sending it to the server even if --encrypted was not specified. It  
added the ENCRYPTED keyword to the SQL command, but since the password was  
already in encrypted form, it didn't make any difference. The documentation  
was not clear on whether that was intended or not, but it's moot now.  
  
Also, while password_encryption='on' is still accepted as an alias for  
'md5', it is now marked as hidden, so that it is not listed as an accepted  
value in error hints, for example. That's not directly related to removing  
'plain', but it seems better this way.  
  
Reviewed by Michael Paquier  
  
Discussion: https://www.postgresql.org/message-id/16e9b768-fd78-0b12-cfc1-7b6b7f238fde@iki.fi  
  

Remove poorly worded and duplicated comment

  
commit   : 1f30295eab65eddaa88528876ab66e7095f4bb65    
  
author   : Simon Riggs <simon@2ndQuadrant.com>    
date     : Mon, 8 May 2017 08:49:28 +0100    
  
committer: Simon Riggs <simon@2ndQuadrant.com>    
date     : Mon, 8 May 2017 08:49:28 +0100    

Click here for diff

  
Move line of code to avoid need for duplicated comment  
  
Brought to attention by Masahiko Sawada  
  

Release notes for 9.6.3, 9.5.7, 9.4.12, 9.3.17, 9.2.21.

  
commit   : 27dae036a5809a61104b7380f0cd98c37b43170f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 7 May 2017 16:56:02 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 7 May 2017 16:56:02 -0400    

Click here for diff

  
  

Third pass on 9.6.3 release notes.

  
commit   : 86713deecda4ddbf8e339ec48fafa4d8080f6079    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 7 May 2017 14:43:04 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 7 May 2017 14:43:04 -0400    

Click here for diff

  
Add updates for recent commits.  
  
In passing, credit Etsuro Fujita for his work on the postgres_fdw  
query cancel feature in 9.6; I seem to have missed that in the  
original drafting of the 9.6 notes.  
  

Fix memory leaks if random salt generation fails.

  
commit   : 0186ded5460c4868db8c5f98ab17287c15fedd7e    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Sun, 7 May 2017 19:58:21 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Sun, 7 May 2017 19:58:21 +0300    

Click here for diff

  
In the backend, this is just to silence coverity warnings, but in the  
frontend, it's a genuine leak, even if extremely rare.  
  
Spotted by Coverity, patch by Michael Paquier.  
  

Guard against null t->tm_zone in strftime.c.

  
commit   : a54d5875fe0bc19d05236b85e1e1bf0af9fa2902    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 7 May 2017 12:33:12 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 7 May 2017 12:33:12 -0400    

Click here for diff

  
The upstream IANA code does not guard against null TM_ZONE pointers in this  
function, but in our code there is such a check in the other pre-existing  
use of t->tm_zone.  We do have some places that set pg_tm.tm_zone to NULL.  
I'm not entirely sure it's possible to reach strftime with such a value,  
but I'm not sure it isn't either, so be safe.  
  
Per Coverity complaint.  
  

  
commit   : d4e59c5521c244e809c3d68df51fb79543578e41    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 7 May 2017 11:57:41 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 7 May 2017 11:57:41 -0400    

Click here for diff

  
Somehow, we'd missed ever doing this.  The consequences aren't too  
severe: basically, the timezone library would fall back on its hardwired  
notion of the DST transition dates to use for a POSIX-style zone name,  
rather than obeying US/Eastern which is the intended behavior.  The net  
effect would only be to obey current US DST law further back than it  
ought to apply; so it's not real surprising that nobody noticed.  
  
David Rowley, per report from Amit Kapila  
  
Discussion: https://postgr.es/m/CAA4eK1LC7CaNhRAQ__C3ht1JVrPzaAXXhEJRnR5L6bfYHiLmWw@mail.gmail.com  
  

Restore fullname[] contents before falling through in pg_open_tzfile().

  
commit   : 5788a5670e4a58049b8adc82c4fef97a2c3be327    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 7 May 2017 11:34:31 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 7 May 2017 11:34:31 -0400    

Click here for diff

  
Fix oversight in commit af2c5aa88: if the shortcut open() doesn't work,  
we need to reset fullname[] to be just the name of the toplevel tzdata  
directory before we fall through into the pre-existing code.  This failed  
to be exposed in my (tgl's) testing because the fall-through path is  
actually never taken under normal circumstances.  
  
David Rowley, per report from Amit Kapila  
  
Discussion: https://postgr.es/m/CAA4eK1LC7CaNhRAQ__C3ht1JVrPzaAXXhEJRnR5L6bfYHiLmWw@mail.gmail.com  
  

doc PG 10: adjustments to BRIN, WAL, JSON, XML items, syntax

  
commit   : 628462bda908873688ce738a191b470ab769d604    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Sat, 6 May 2017 23:31:54 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Sat, 6 May 2017 23:31:54 -0400    

Click here for diff

  
Reported-by: Alvaro Herrera  
  

pg_dump: Don’t leak memory in buildDefaultACLCommands()

  
commit   : 09f842181943b6e83b0779f2e872ff0180b66883    
  
author   : Stephen Frost <sfrost@snowman.net>    
date     : Sat, 6 May 2017 22:58:12 -0400    
  
committer: Stephen Frost <sfrost@snowman.net>    
date     : Sat, 6 May 2017 22:58:12 -0400    

Click here for diff

  
buildDefaultACLCommands() didn't destroy the string buffer created in  
certain cases, leading to a memory leak.  Fix by destroying the buffer  
before returning from the function.  
  
Spotted by Coverity.  
  
Author: Michael Paquier  
  
Back-patch to 9.6 where buildDefaultACLCommands() was added.  
  

RLS: Fix ALL vs. SELECT+UPDATE policy usage

  
commit   : aa5d3c0b3fb906dfa910b0ca6f75ab701b2f1c09    
  
author   : Stephen Frost <sfrost@snowman.net>    
date     : Sat, 6 May 2017 21:46:35 -0400    
  
committer: Stephen Frost <sfrost@snowman.net>    
date     : Sat, 6 May 2017 21:46:35 -0400    

Click here for diff

  
When we add the SELECT-privilege based policies to the RLS with check  
options (such as for an UPDATE statement, or when we have INSERT ...  
RETURNING), we need to be sure and use the 'USING' case if the policy is  
actually an 'ALL' policy (which could have both a USING clause and an  
independent WITH CHECK clause).  
  
This could result in policies acting differently when built using ALL  
(when the ALL had both USING and WITH CHECK clauses) and when building  
the policies independently as SELECT and UPDATE policies.  
  
Fix this by adding an explicit boolean to add_with_check_options() to  
indicate when the USING policy should be used, even if the policy has  
both USING and WITH CHECK policies on it.  
  
Reported by: Rod Taylor  
  
Back-patch to 9.5 where RLS was introduced.  
  

Fix duplicated words in comment.

  
commit   : b58c433ef90be2f9752cd54561c07dae87e3819c    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Sat, 6 May 2017 17:03:04 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Sat, 6 May 2017 17:03:04 -0700    

Click here for diff

  
Reported-By: Peter Geoghegan  
Discussion: https://postgr.es/m/CAH2-Wzn3rY2N0gTWndaApD113T+O8L6oz8cm7_F3P8y4awdoOg@mail.gmail.com  
Backpatch: no, only present in master  
  

Fix off-by-one possibly leading to skipped XLOG_RUNNING_XACTS records.

  
commit   : e6c44eef55cda493c759e926cecceb92186159b8    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Sat, 6 May 2017 16:47:40 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Sat, 6 May 2017 16:47:40 -0700    

Click here for diff

  
Since 6ef2eba3f57f1 ("Skip checkpoints, archiving on idle systems."),  
GetLastImportantRecPtr() is used to avoid performing superfluous  
checkpoints, xlog switches, running-xact records when the system is  
idle.  Unfortunately the check concerning running-xact records had a  
off-by-one error, leading to such records being potentially skipped  
when only a single record has been inserted since the last  
running-xact record.  
  
An alternative approach would have been to change  
GetLastImportantRecPtr()'s definition to point to the end of records,  
but that would make the checkpoint code more complicated.  
  
Author: Andres Freund  
Discussion: https://postgr.es/m/20170505012447.wsrympaxnfis6ojt@alap3.anarazel.de  
Backpatch: no, code only present in master  
  

Second pass on 9.6.3 release notes.

  
commit   : 334b82cd56a65e09154d9f930d35a761a9c5cfab    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 6 May 2017 16:28:20 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 6 May 2017 16:28:20 -0400    

Click here for diff

  
Improve description of logical decoding snapshot issues, per suggestion  
from Petr Jelinek.  Mention possible need to re-sync logical replicas  
as a post-upgrade task.  Minor copy-editing for some other items.  
  

Document current_role.

  
commit   : a9c6d704354bfe91bc389742cb5d331ae4e93831    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 6 May 2017 14:19:47 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 6 May 2017 14:19:47 -0400    

Click here for diff

  
This system function has been there a very long time, but somehow escaped  
being listed in func.sgml.  
  
Fabien Coelho and Tom Lane  
  
Discussion: https://postgr.es/m/alpine.DEB.2.20.1705061027580.3896@lancre  
  

First-draft release notes for 9.6.3.

  
commit   : 54dbd4dc78b045ffcc046b9a43681770c3992dd4    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 5 May 2017 19:33:34 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 5 May 2017 19:33:34 -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.  Note there  
are some entries that really only apply to pre-9.6 branches.  
  

Suppress compiler warning about unportable pointer value.

  
commit   : b3a47cdfd692079e36d2055d7d93759e083263ca    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 5 May 2017 12:46:04 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 5 May 2017 12:46:04 -0400    

Click here for diff

  
Setting a pointer value to "0xdeadbeef" draws a warning from some  
compilers, and for good reason.  Be less cute and just set it to NULL.  
  
In passing make some other cosmetic adjustments nearby.  
  
Discussion: https://postgr.es/m/CAJrrPGdW3EkU-CRobvVKYf3fJuBdgWyuGeAbNzAQ4yBh+bfb_Q@mail.gmail.com  
  

Allow MSVC to build with Tcl 8.6.

  
commit   : 14722c69f924810ecf11769e8b9788b3f82d2a0e    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 5 May 2017 12:05:34 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 5 May 2017 12:05:34 -0300    

Click here for diff

  
Commit eaba54c20c5 added support for Tcl 8.6 for configure-supported  
platforms after verifying that pltcl works without further changes, but  
the MSVC tooling wasn't updated accordingly.  Update MSVC to match,  
restructuring the code to avoid duplicating the logic for every Tcl  
version supported.  
  
Backpatch to all live branches, like eaba54c20c5.  In 9.4 and previous,  
change the patch to use backslashes rather than forward, as in the rest  
of the file.  
  
Reported by Paresh More, who also tested the patch I provided.  
Discussion: https://postgr.es/m/CAAgiCNGVw3ssBtSi3ZNstrz5k00ax=UV+_ZEHUeW_LMSGL2sew@mail.gmail.com  
  

Prevent panic during shutdown checkpoint

  
commit   : 086221cf6b1727c2baed4703c582f657b7c5350e    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 1 May 2017 15:09:06 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 1 May 2017 15:09:06 -0400    

Click here for diff

  
When the checkpointer writes the shutdown checkpoint, it checks  
afterwards whether any WAL has been written since it started and throws  
a PANIC if so.  At that point, only walsenders are still active, so one  
might think this could not happen, but walsenders can also generate WAL,  
for instance in BASE_BACKUP and certain variants of  
CREATE_REPLICATION_SLOT.  So they can trigger this panic if such a  
command is run while the shutdown checkpoint is being written.  
  
To fix this, divide the walsender shutdown into two phases.  First, the  
postmaster sends a SIGUSR2 signal to all walsenders.  The walsenders  
then put themselves into the "stopping" state.  In this state, they  
reject any new commands.  (For simplicity, we reject all new commands,  
so that in the future we do not have to track meticulously which  
commands might generate WAL.)  The checkpointer waits for all walsenders  
to reach this state before proceeding with the shutdown checkpoint.  
After the shutdown checkpoint is done, the postmaster sends  
SIGINT (previously unused) to the walsenders.  This triggers the  
existing shutdown behavior of sending out the shutdown checkpoint record  
and then terminating.  
  
Author: Michael Paquier <michael.paquier@gmail.com>  
Reported-by: Fujii Masao <masao.fujii@gmail.com>  
  

Fix wording in pg_upgrade docs

  
commit   : 499ae5f5db99c84035e9951fd30e428adf0f40d2    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Fri, 5 May 2017 12:42:21 +0200    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Fri, 5 May 2017 12:42:21 +0200    

Click here for diff

  
Author: Daniel Gustafsson  
  

Build pgoutput.dll in MSVC build

  
commit   : 28d1c8ccc87128f9b0b937eae277473027c36b7e    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Fri, 5 May 2017 12:08:48 +0200    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Fri, 5 May 2017 12:08:48 +0200    

Click here for diff

  
Without this, logical replication obviously does not work on Windows  
  
MauMau, with clean.bet additions from me per note from Michael Paquier  
  

Make SCRAM salts and nonces longer.

  
commit   : 0557a5dc2cf845639d384801b6861ebbd35dc7ee    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 5 May 2017 10:02:13 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 5 May 2017 10:02:13 +0300    

Click here for diff

  
The salt is stored base64-encoded. With the old 10 bytes raw length, it was  
always padded to 16 bytes after encoding. We might as well use 12 raw bytes  
for the salt, and it's still encoded into 16 bytes.  
  
Similarly for the random nonces, use a raw length that's divisible by 3, so  
that there's no padding after base64 encoding. Make the nonces longer while  
we're at it. 10 bytes was probably enough to prevent replay attacks, but  
there's no reason to be skimpy here.  
  
Per suggestion from Álvaro Hernández Tortosa.  
  
Discussion: https://www.postgresql.org/message-id/df8c6e27-4d8e-5281-96e5-131a4e638fc8@8kdata.com  
  

Misc cleanup of SCRAM code.

  
commit   : e6e9c4da3a55450b120ad7e3d0be426255850914    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 5 May 2017 10:01:44 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 5 May 2017 10:01:44 +0300    

Click here for diff

  
* Remove is_scram_verifier() function. It was unused.  
* Fix sanitize_char() function, used in error messages on protocol  
  violations, to print bytes >= 0x7F correctly.  
* Change spelling of scram_MockSalt() function to be more consistent with  
  the surroundings.  
* Change a few more references to "server proof" to "server signature" that  
  I missed in commit d981074c24.  
  

Don’t use SCRAM-specific “e=invalid-proof” on invalid password.

  
commit   : 344a113079888c9b9a81ffa3c3a7d95666347119    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 5 May 2017 10:01:41 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 5 May 2017 10:01:41 +0300    

Click here for diff

  
Instead, send the same FATAL message as with other password-based  
authentication mechanisms. This gives a more user-friendly message:  
  
psql: FATAL:  password au