PostgreSQL 10.0 commit log

commit   : 5df0e99bea1c3e5fbffa7fbd0982da88ea149bb6    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 2 Oct 2017 17:09:15 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 2 Oct 2017 17:09:15 -0400    

commit   : 1f19550a874d02c6e9f6192ed1a97995f9598f53    
  
author   : Peter Eisentraut <[email protected]>    
date     : Mon, 2 Oct 2017 12:03:01 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Mon, 2 Oct 2017 12:03:01 -0400    

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

commit   : b6cbd30582a5a58ef0ce7a16c2b003b318d63619    
  
author   : Peter Eisentraut <[email protected]>    
date     : Fri, 22 Sep 2017 13:51:01 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Fri, 22 Sep 2017 13:51:01 -0400    

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.  

commit   : 086fda9073d37b519519926136c9fe5418451c0e    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 1 Oct 2017 13:32:26 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 1 Oct 2017 13:32:26 -0400    

Last(?) round of changes for 10.0.  

commit   : 1a6b2b16565aa70f663f83aa6c47b4cbc545eeb2    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 1 Oct 2017 12:43:47 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 1 Oct 2017 12:43:47 -0400    

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.  

commit   : e775dd6a4b1b87cd367a725f8840f068f2daae27    
  
author   : Peter Eisentraut <[email protected]>    
date     : Sun, 1 Oct 2017 08:51:20 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Sun, 1 Oct 2017 08:51:20 -0400    

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  

commit   : babf18579455e85269ad75e1ddb03f34138f77b6    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Sun, 1 Oct 2017 09:29:27 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Sun, 1 Oct 2017 09:29:27 +0300    

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  

commit   : 2aab70205be012d06f7d077dd1fa5e6afea9d19c    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 29 Sep 2017 16:26:21 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 29 Sep 2017 16:26:21 -0400    

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/[email protected]  

commit   : 434146d21666dd2023705fb26582918212e124d1    
  
author   : Robert Haas <[email protected]>    
date     : Fri, 29 Sep 2017 13:51:14 -0400    
  
committer: Robert Haas <[email protected]>    
date     : Fri, 29 Sep 2017 13:51:14 -0400    

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  

commit   : 5cc5987cedd8c60c738135abcb25df5247db7d1e    
  
author   : Peter Eisentraut <[email protected]>    
date     : Mon, 25 Sep 2017 11:59:46 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Mon, 25 Sep 2017 11:59:46 -0400    

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 <[email protected]>  

commit   : 46c35116ae1acc8826705ef2a7b5d9110f9d6e84    
  
author   : Alvaro Herrera <[email protected]>    
date     : Thu, 28 Sep 2017 16:44:01 +0200    
  
committer: Alvaro Herrera <[email protected]>    
date     : Thu, 28 Sep 2017 16:44:01 +0200    

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/[email protected]  
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/[email protected]  

commit   : 07ea925e20ee80898638800c8479b48e7e97d431    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 27 Sep 2017 17:05:53 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 27 Sep 2017 17:05:53 -0400    

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/[email protected]  

commit   : 93a1af0b3f63838774a9e524589344c3d44c867d    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 27 Sep 2017 16:14:37 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 27 Sep 2017 16:14:37 -0400    

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/[email protected]  

commit   : 4d5d08c1cd52add02bdfadc00854135a3b6c88f6    
  
author   : Dean Rasheed <[email protected]>    
date     : Wed, 27 Sep 2017 17:13:37 +0100    
  
committer: Dean Rasheed <[email protected]>    
date     : Wed, 27 Sep 2017 17:13:37 +0100    

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.  

commit   : bfd551570265049ea17f18f65a156c1d8ba66a23    
  
author   : Noah Misch <[email protected]>    
date     : Tue, 26 Sep 2017 22:39:44 -0700    
  
committer: Noah Misch <[email protected]>    
date     : Tue, 26 Sep 2017 22:39:44 -0700    

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/[email protected]  

commit   : 9ebc7781444fd15d56ed16e5312a954483e85cd9    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 26 Sep 2017 15:25:56 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 26 Sep 2017 15:25:56 -0400    

Per suggestions from Peter Eisentraut and David Johnston.  
Back-patch, like the previous commit.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : d29f30d8c3b2a9d8c57324355df8a8d9da1d9c12    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 26 Sep 2017 13:42:53 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 26 Sep 2017 13:42:53 -0400    

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/[email protected]  

commit   : 01c5de88ff242b379a033e46e4da6476f2213029    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 26 Sep 2017 13:12:13 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 26 Sep 2017 13:12:13 -0400    

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/[email protected]  

commit   : 175774d2932d969875b0709ec5f400ba19000c99    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 26 Sep 2017 13:12:03 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 26 Sep 2017 13:12:03 -0400    

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/[email protected]  

commit   : 1a499c252049dad9016a04bcbab27b8c616d4d03    
  
author   : Peter Eisentraut <[email protected]>    
date     : Tue, 26 Sep 2017 10:03:56 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Tue, 26 Sep 2017 10:03:56 -0400    

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 <[email protected]>  
Bug: #14785  
Reviewed-by: Andres Freund <[email protected]>  
Reviewed-by: Petr Jelinek <[email protected]>  

commit   : 4621c7f7a432fbb24b69c5cf0c877c17832c26ac    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 25 Sep 2017 16:09:19 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 25 Sep 2017 16:09:19 -0400    

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/[email protected]  

commit   : 99e90bac4f9f3bd8d7b285a6f4095c2089e09efe    
  
author   : Andrew Dunstan <[email protected]>    
date     : Mon, 25 Sep 2017 08:03:05 -0400    
  
committer: Andrew Dunstan <[email protected]>    
date     : Mon, 25 Sep 2017 08:03:05 -0400    

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

commit   : 29923859f91f94c97417b8417ff8475cf4261be1    
  
author   : Peter Eisentraut <[email protected]>    
date     : Sun, 24 Sep 2017 00:56:31 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Sun, 24 Sep 2017 00:56:31 -0400    

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 <[email protected]>  

commit   : 33e2f346b0689cf7631fcfe7db91dc56767f2659    
  
author   : Peter Eisentraut <[email protected]>    
date     : Sun, 24 Sep 2017 00:29:59 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Sun, 24 Sep 2017 00:29:59 -0400    

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 <[email protected]>  

commit   : 7c8ce791d4b3e774ffe4c7c987a7055619663818    
  
author   : Peter Eisentraut <[email protected]>    
date     : Sat, 23 Sep 2017 22:59:26 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Sat, 23 Sep 2017 22:59:26 -0400    

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 <[email protected]>  

commit   : 3d7f11a0fabb038ce5c630b87dfadd8b625347fe    
  
author   : Peter Eisentraut <[email protected]>    
date     : Fri, 22 Sep 2017 16:50:59 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Fri, 22 Sep 2017 16:50:59 -0400    

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.  

commit   : 3571a53345bb4d3d055d8a720e9817038927877e    
  
author   : Alvaro Herrera <[email protected]>    
date     : Sat, 23 Sep 2017 14:05:57 +0200    
  
committer: Alvaro Herrera <[email protected]>    
date     : Sat, 23 Sep 2017 14:05:57 +0200    

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/[email protected]  

commit   : e114289e1e4774dfc3371372e36b3f0fed66b741    
  
author   : Peter Eisentraut <[email protected]>    
date     : Fri, 22 Sep 2017 15:01:13 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Fri, 22 Sep 2017 15:01:13 -0400    

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

commit   : 1a44df007c9b9adc5e6082fc90fe68e615d38ecd    
  
author   : Robert Haas <[email protected]>    
date     : Fri, 22 Sep 2017 14:28:22 -0400    
  
committer: Robert Haas <[email protected]>    
date     : Fri, 22 Sep 2017 14:28:22 -0400    

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  

commit   : c08c98df3d30c0d773d5624860145fb4215b84fb    
  
author   : Peter Eisentraut <[email protected]>    
date     : Thu, 21 Sep 2017 14:42:10 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Thu, 21 Sep 2017 14:42:10 -0400    

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 <[email protected]>  
Reported-by: Noah Misch <[email protected]>  

commit   : e9c9ba7845c1d5a59d5f9d2429fd81638ae48a19    
  
author   : Alvaro Herrera <[email protected]>    
date     : Fri, 22 Sep 2017 13:35:54 +0200    
  
committer: Alvaro Herrera <[email protected]>    
date     : Fri, 22 Sep 2017 13:35:54 +0200    

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

commit   : 3876b16ce3f30fcd8e10738d4449f8c51a695b17    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 22 Sep 2017 00:04:21 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 22 Sep 2017 00:04:21 -0400    

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/[email protected]  

commit   : a2b1eb23496e9abd695036e3cbb1d39c05618692    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 21 Sep 2017 18:13:11 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 21 Sep 2017 18:13:11 -0400    

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/[email protected]  

commit   : 97514bf88bd96a4f213fbe6ae6911ba1dd033b8b    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 20 Sep 2017 13:52:36 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 20 Sep 2017 13:52:36 -0400    

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.  

commit   : ee266774454d5cce3375145e2f86a99910eb263f    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 20 Sep 2017 11:28:34 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 20 Sep 2017 11:28:34 -0400    

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/[email protected]  

commit   : e77730721f5faddb28fd11912f7968ddfd8b58c2    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 20 Sep 2017 11:10:42 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 20 Sep 2017 11:10:42 -0400    

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/[email protected]  

commit   : 4131cc6b90ce274a44462627a1c878bf1950838b    
  
author   : Bruce Momjian <[email protected]>    
date     : Wed, 20 Sep 2017 09:36:19 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Wed, 20 Sep 2017 09:36:19 -0400    

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

commit   : 0017aa981fef11f48a4c347b512d21f41d6e1ee1    
  
author   : Magnus Hagander <[email protected]>    
date     : Wed, 20 Sep 2017 14:09:05 +0200    
  
committer: Magnus Hagander <[email protected]>    
date     : Wed, 20 Sep 2017 14:09:05 +0200    

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.  

commit   : ba01ef267ee48e86566886376c41d0a20551713c    
  
author   : Bruce Momjian <[email protected]>    
date     : Tue, 19 Sep 2017 12:23:18 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Tue, 19 Sep 2017 12:23:18 -0400    

Reported-by: Zhou Digoal  
  
Discussion: https://postgr.es/m/[email protected]  
  
Backpatch-through: 10  

commit   : dc28213c3e0b8f2b71d75bb8c779b9dd0fce5670    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 18 Sep 2017 17:28:38 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 18 Sep 2017 17:28:38 -0400    

commit   : 75fbf8ad1209e3711704dd6194926a2d60a8d849    
  
author   : Michael Meskes <[email protected]>    
date     : Mon, 11 Sep 2017 21:10:36 +0200    
  
committer: Michael Meskes <[email protected]>    
date     : Mon, 11 Sep 2017 21:10:36 +0200    

commit   : c1bde0747983993a695d12c4403a730b2be579d2    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 18 Sep 2017 11:39:44 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 18 Sep 2017 11:39:44 -0400    

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 <[email protected]>    
date     : Mon, 18 Sep 2017 11:09:15 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Mon, 18 Sep 2017 11:09:15 -0400    

commit   : 4f75e3bbd96fcb73e4995428c595b2698471871a    
  
author   : Peter Eisentraut <[email protected]>    
date     : Mon, 18 Sep 2017 10:41:48 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Mon, 18 Sep 2017 10:41:48 -0400    

commit   : b2800df278b3914044285980826b5c9db308971f    
  
author   : Peter Eisentraut <[email protected]>    
date     : Mon, 18 Sep 2017 09:09:36 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Mon, 18 Sep 2017 09:09:36 -0400    

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

commit   : 522b028a0000d08c6d113c2334e669dd31a6b1cd    
  
author   : Peter Eisentraut <[email protected]>    
date     : Sun, 17 Sep 2017 21:37:02 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Sun, 17 Sep 2017 21:37:02 -0400    

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 <[email protected]>  
Discussion: https://www.postgresql.org/message-id/flat/87mv6av84w.fsf%40ars-thinkpad  

commit   : 90cebfa9ee3a4110c83c6b012ec523adcc1c2468    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 17 Sep 2017 17:04:21 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 17 Sep 2017 17:04:21 -0400    

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.  

commit   : 244b4a37eb8e253e5221477534c2a2f0a9c23630    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 17 Sep 2017 15:28:51 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 17 Sep 2017 15:28:51 -0400    

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  

commit   : 66fe509be0166058f53bf857b21eae125de30fc5    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 17 Sep 2017 14:50:01 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 17 Sep 2017 14:50:01 -0400    

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/[email protected]  

commit   : 5cc23493195cbd2205d5e476e725657c0a29ea34    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 17 Sep 2017 12:16:38 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 17 Sep 2017 12:16:38 -0400    

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/[email protected]  

commit   : 0749ef8e9eceb04dd8c365443d0d994f7ad34c17    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 16 Sep 2017 15:31:26 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 16 Sep 2017 15:31:26 -0400    

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.  

commit   : 54d4d0ff6cd40638d026c01e46deb102e7951ba6    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 16 Sep 2017 13:20:32 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 16 Sep 2017 13:20:32 -0400    

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/[email protected]  

commit   : d2bbd6104096b1559c1683d39e2c4e4cfbcada1c    
  
author   : Bruce Momjian <[email protected]>    
date     : Sat, 16 Sep 2017 11:58:00 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Sat, 16 Sep 2017 11:58:00 -0400    

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/[email protected]  
  
Backpatch-through: 9.5  

commit   : e8b65986ba0de2daeb5bcedc02fb936b04fe464c    
  
author   : Robert Haas <[email protected]>    
date     : Fri, 15 Sep 2017 21:15:55 -0400    
  
committer: Robert Haas <[email protected]>    
date     : Fri, 15 Sep 2017 21:15:55 -0400    

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  

commit   : f830183492d3a3b74cbd33645db19b8b5b5a2622    
  
author   : Peter Eisentraut <[email protected]>    
date     : Fri, 15 Sep 2017 14:04:51 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Fri, 15 Sep 2017 14:04:51 -0400    

Bug: #14813  

commit   : a2a61f633e36445d7a15baad22d4d1db102e4a7e    
  
author   : Robert Haas <[email protected]>    
date     : Thu, 14 Sep 2017 16:25:19 -0400    
  
committer: Robert Haas <[email protected]>    
date     : Thu, 14 Sep 2017 16:25:19 -0400    

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  

commit   : 29f021160ea7bfbc02600e651cf3588bb4ce8e78    
  
author   : Robert Haas <[email protected]>    
date     : Thu, 14 Sep 2017 11:11:12 -0400    
  
committer: Robert Haas <[email protected]>    
date     : Thu, 14 Sep 2017 11:11:12 -0400    

Amit Langote  
  
Discussion: http://postgr.es/m/[email protected]  

commit   : 448aa36e8b969da257bb58a6fe3db6498d48d4e8    
  
author   : Robert Haas <[email protected]>    
date     : Thu, 14 Sep 2017 10:43:44 -0400    
  
committer: Robert Haas <[email protected]>    
date     : Thu, 14 Sep 2017 10:43:44 -0400    

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  

commit   : 253c8afc9eb178b7241b4cc571acf7fb6ac6f976    
  
author   : Andres Freund <[email protected]>    
date     : Thu, 14 Sep 2017 01:53:10 -0700    
  
committer: Andres Freund <[email protected]>    
date     : Thu, 14 Sep 2017 01:53:10 -0700    

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  

commit   : 68a7c24fdf2d69fc57cfb26aba7e119aa6ca2621    
  
author   : Stephen Frost <[email protected]>    
date     : Wed, 13 Sep 2017 20:04:43 -0400    
  
committer: Stephen Frost <[email protected]>    
date     : Wed, 13 Sep 2017 20:04:43 -0400    

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.  

commit   : eaf7001eb7e3eecc7e30c31956860f54f1def55f    
  
author   : Michael Meskes <[email protected]>    
date     : Sat, 26 Aug 2017 19:07:25 +0200    
  
committer: Michael Meskes <[email protected]>    
date     : Sat, 26 Aug 2017 19:07:25 +0200    

commit   : 38d7cb67f2e8798d6e0ecff8334345a3ae73b902    
  
author   : Michael Meskes <[email protected]>    
date     : Sat, 26 Aug 2017 12:57:21 +0200    
  
committer: Michael Meskes <[email protected]>    
date     : Sat, 26 Aug 2017 12:57:21 +0200    

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  

commit   : d587813edba16ae52330c881c27e4c91799a0d9c    
  
author   : Peter Eisentraut <[email protected]>    
date     : Wed, 13 Sep 2017 10:10:34 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Wed, 13 Sep 2017 10:10:34 -0400    

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 <[email protected]>    
date     : Wed, 13 Sep 2017 09:22:18 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Wed, 13 Sep 2017 09:22:18 -0400    

Backpatch-through: 9.5  

commit   : aaa4faa7a00cb85322e570f2d148a51b95b847c4    
  
author   : Bruce Momjian <[email protected]>    
date     : Wed, 13 Sep 2017 09:11:28 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Wed, 13 Sep 2017 09:11:28 -0400    

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  

commit   : 2b0ded5060cc2e0b7d6c765af5b5f7334f64f5dc    
  
author   : Peter Eisentraut <[email protected]>    
date     : Wed, 13 Sep 2017 08:31:03 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Wed, 13 Sep 2017 08:31:03 -0400    

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 <[email protected]>  

commit   : b1705f35f805933629520eded68b82d2a2900871    
  
author   : Bruce Momjian <[email protected]>    
date     : Tue, 12 Sep 2017 13:17:52 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Tue, 12 Sep 2017 13:17:52 -0400    

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  

commit   : bd18960cb93f3b6e9f43f3cabec34f1929f05ec3    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 11 Sep 2017 22:02:58 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 11 Sep 2017 22:02:58 -0400    

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/[email protected]  

commit   : d4c9eb005a16ff5cdc9d5d9514a3195c60ad21ab    
  
author   : Bruce Momjian <[email protected]>    
date     : Mon, 11 Sep 2017 19:56:44 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Mon, 11 Sep 2017 19:56:44 -0400    

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  

commit   : 1d27a7004d84516f5d04662c1cd52f41400b7750    
  
author   : Bruce Momjian <[email protected]>    
date     : Mon, 11 Sep 2017 19:43:49 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Mon, 11 Sep 2017 19:43:49 -0400    

Update attribution of PL/Tcl functions item from Jim Nasby to Karl  
Lehenbauer.  
  
Reported-by: Jim Nasby  
  
Discussion: https://postgr.es/m/[email protected]  
  
Backpatch-through: 10  

commit   : bd72c37b160623bf3f1c9cea82b948ee53a22567    
  
author   : Peter Eisentraut <[email protected]>    
date     : Mon, 11 Sep 2017 12:49:35 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Mon, 11 Sep 2017 12:49:35 -0400    

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

commit   : f552d18f3edd178598564d20f09577a623b1e302    
  
author   : Peter Eisentraut <[email protected]>    
date     : Mon, 11 Sep 2017 11:20:47 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Mon, 11 Sep 2017 11:20:47 -0400    

commit   : 5c11717185bc24a2d0a20b38815e182ed99101ce    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 10 Sep 2017 14:59:56 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 10 Sep 2017 14:59:56 -0400    

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/[email protected]  

commit   : 6913d06688a2aa76580d5942b0c98751363c97e0    
  
author   : Peter Eisentraut <[email protected]>    
date     : Sat, 9 Sep 2017 17:32:10 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Sat, 9 Sep 2017 17:32:10 -0400    

commit   : 1377b40965b257e228ae8faf45c6ce145ce357e5    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 8 Sep 2017 19:04:32 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 8 Sep 2017 19:04:32 -0400    

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.  

commit   : 5f0ac02d7f8ded730c27a5197f8c594302c5d7e0    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 8 Sep 2017 16:59:26 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 8 Sep 2017 16:59:26 -0400    

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

commit   : 730169dea70c381a959a357de5c8b56e674af805    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 8 Sep 2017 14:38:54 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 8 Sep 2017 14:38:54 -0400    

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

commit   : 08cb36417aa22436647a1831a7d1ff6b41232280    
  
author   : Robert Haas <[email protected]>    
date     : Thu, 7 Sep 2017 10:55:45 -0400    
  
committer: Robert Haas <[email protected]>    
date     : Thu, 7 Sep 2017 10:55:45 -0400    

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/[email protected]  

commit   : a6c678f018d3a30a88440d3c20cf8e7cd6592a32    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 6 Sep 2017 11:35:31 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 6 Sep 2017 11:35:31 -0400    

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  

commit   : 483882905a9a5dc72c9487ceee12320b9630ba2b    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 6 Sep 2017 10:41:05 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 6 Sep 2017 10:41:05 -0400    

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/[email protected]  

commit   : 3fbf09563f839137e5279a390044a18e400fa074    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 5 Sep 2017 16:41:22 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 5 Sep 2017 16:41:22 -0400    

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.  

commit   : 1861b20cd63ba3a2e9d547858fc4e05d882531c7    
  
author   : Alvaro Herrera <[email protected]>    
date     : Tue, 5 Sep 2017 16:59:39 +0200    
  
committer: Alvaro Herrera <[email protected]>    
date     : Tue, 5 Sep 2017 16:59:39 +0200    

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  

commit   : a1af1e7cfaefbef38e6b85ac632ed488744b3fd0    
  
author   : Alvaro Herrera <[email protected]>    
date     : Mon, 4 Sep 2017 11:08:52 +0200    
  
committer: Alvaro Herrera <[email protected]>    
date     : Mon, 4 Sep 2017 11:08:52 +0200    

Discussion: https://postgr.es/m/[email protected]  

commit   : d5c65d2f11ac58c517ab7fda01be62e4763504c9    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 3 Sep 2017 11:01:08 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 3 Sep 2017 11:01:08 -0400    

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  

commit   : c6a7fcb49a60081c04c8e421fbc21475ad6943d8    
  
author   : Peter Eisentraut <[email protected]>    
date     : Fri, 1 Sep 2017 23:34:03 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Fri, 1 Sep 2017 23:34:03 -0400    

Author: Alexander Lakhin <[email protected]>  

commit   : 01edb5c7fc3bcf6aea15f2b3be36189b52ad9d1a    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 1 Sep 2017 17:38:54 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 1 Sep 2017 17:38:54 -0400    

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/[email protected]  

commit   : f2fe1cbef11c5fc962e338c8523667314faa6d89    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 1 Sep 2017 15:14:18 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 1 Sep 2017 15:14:18 -0400    

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/[email protected]  

commit   : cbb51eb69f3faac425caae33195fdfa3396fa1c3    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 1 Sep 2017 13:52:53 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 1 Sep 2017 13:52:53 -0400    

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/[email protected]  

commit   : ef585de80e29d7f20988ce06fafa58a215f6b122    
  
author   : Alvaro Herrera <[email protected]>    
date     : Fri, 1 Sep 2017 16:51:55 +0200    
  
committer: Alvaro Herrera <[email protected]>    
date     : Fri, 1 Sep 2017 16:51:55 +0200    

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  

commit   : f15b76a9010dfd6052405d058bf8c0a488cec979    
  
author   : Alvaro Herrera <[email protected]>    
date     : Fri, 1 Sep 2017 16:30:02 +0200    
  
committer: Alvaro Herrera <[email protected]>    
date     : Fri, 1 Sep 2017 16:30:02 +0200    

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/[email protected]  

commit   : 3950e07eb46ebe99331ca82d659269056470f596    
  
author   : Simon Riggs <[email protected]>    
date     : Fri, 1 Sep 2017 14:49:06 +0100    
  
committer: Simon Riggs <[email protected]>    
date     : Fri, 1 Sep 2017 14:49:06 +0100    

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

commit   : 44654f3d2555702279d080e87c70730dc0cb7a9d    
  
author   : Simon Riggs <[email protected]>    
date     : Fri, 1 Sep 2017 14:10:52 +0100    
  
committer: Simon Riggs <[email protected]>    
date     : Fri, 1 Sep 2017 14:10:52 +0100    

commit   : 8ba6d50f923bfc1d7cc91f5ff11e199f18d7fd80    
  
author   : Alvaro Herrera <[email protected]>    
date     : Fri, 1 Sep 2017 13:44:14 +0200    
  
committer: Alvaro Herrera <[email protected]>    
date     : Fri, 1 Sep 2017 13:44:14 +0200    

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  

commit   : 28915c7db4da4eaffb8eb0dc5c04c87dcf345eb6    
  
author   : Simon Riggs <[email protected]>    
date     : Fri, 1 Sep 2017 07:55:00 +0100    
  
committer: Simon Riggs <[email protected]>    
date     : Fri, 1 Sep 2017 07:55:00 +0100    

Author: Thomas Munro  

commit   : 7610547c95f3a469115538f4b45eda2563a8188e    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 31 Aug 2017 16:20:58 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 31 Aug 2017 16:20:58 -0400    

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/[email protected]  

commit   : b4fa938e9f484a3cf0614aac4686cd26c650d27c    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 31 Aug 2017 15:10:24 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 31 Aug 2017 15:10:24 -0400    

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/[email protected]  

commit   : 4c7af96365d6a50c4f807a97dd37ac3e9c7459cf    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 31 Aug 2017 13:15:54 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 31 Aug 2017 13:15:54 -0400    

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

commit   : cb8e015b948d14d08b486ae1b2de879a0cc827d7    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 30 Aug 2017 17:21:08 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 30 Aug 2017 17:21:08 -0400    

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.  

commit   : d6a149f4e6a1243ccae6e1817050da9e84050b2a    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 30 Aug 2017 13:18:16 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 30 Aug 2017 13:18:16 -0400    

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  

commit   : 5816ddc707e03342502975456d864448ab8dc333    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 30 Aug 2017 09:59:23 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 30 Aug 2017 09:59:23 -0400    

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  

commit   : 54eac6e8c5527c22555bc9f61ffa93cd0920b4c7    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 30 Aug 2017 09:29:56 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 30 Aug 2017 09:29:56 -0400    

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  

commit   : 2fa44f666f144be5436d8725cc259fd1ce29f5ff    
  
author   : Peter Eisentraut <[email protected]>    
date     : Tue, 29 Aug 2017 19:33:24 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Tue, 29 Aug 2017 19:33:24 -0400    

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".  

commit   : ff59f30dc30ecb4fb777a28774110c6637b10dc1    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 29 Aug 2017 15:38:05 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 29 Aug 2017 15:38:05 -0400    

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  

commit   : b481b39b876f4bd0e793d93f6202071713bc0edb    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 29 Aug 2017 15:18:01 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 29 Aug 2017 15:18:01 -0400    

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  

commit   : 09ec0eb7a6e83aea8adb4522e92138974401cce3    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 29 Aug 2017 09:34:21 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 29 Aug 2017 09:34:21 -0400    

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  

commit   : 2ff326dc4410c283515237cf311358afb9845912    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 28 Aug 2017 17:19:22 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 28 Aug 2017 17:19:22 -0400    

commit   : 7dadf7af820d160ace49d6e0b240603d5427bb20    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 28 Aug 2017 11:40:47 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 28 Aug 2017 11:40:47 -0400    

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

commit   : 89f6d587f06b39884f755e871aeeb368e2a75712    
  
author   : Peter Eisentraut <[email protected]>    
date     : Mon, 28 Aug 2017 10:34:14 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Mon, 28 Aug 2017 10:34:14 -0400    

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

commit   : df44405a0c5c725706317c1faa6e8a0760f17dcc    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 28 Aug 2017 10:14:20 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 28 Aug 2017 10:14:20 -0400    

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  

commit   : 5ecd7ccbe672a7ca2f3cd7252b28080100016fc2    
  
author   : Peter Eisentraut <[email protected]>    
date     : Sun, 27 Aug 2017 21:29:54 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Sun, 27 Aug 2017 21:29:54 -0400    

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

commit   : 947a0cc273f21c0d32f648a2c71809d92ab89d20    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 27 Aug 2017 17:35:04 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 27 Aug 2017 17:35:04 -0400    

commit   : 5a6273513374756720ae246d7fa15a9e780b4d07    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 26 Aug 2017 16:50:19 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 26 Aug 2017 16:50:19 -0400    

commit   : 145ca364d310932871b06ee4d226c014058aef2c    
  
author   : Peter Eisentraut <[email protected]>    
date     : Sat, 26 Aug 2017 09:21:46 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Sat, 26 Aug 2017 09:21:46 -0400    

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.  

commit   : 3460728c67852d80569a0382e187480f08771778    
  
author   : Robert Haas <[email protected]>    
date     : Fri, 25 Aug 2017 15:07:44 -0400    
  
committer: Robert Haas <[email protected]>    
date     : Fri, 25 Aug 2017 15:07:44 -0400    

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/[email protected]  

commit   : 33043c69df790d9a08d2ac682c6f1d41c9a652bd    
  
author   : Peter Eisentraut <[email protected]>    
date     : Fri, 25 Aug 2017 12:02:29 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Fri, 25 Aug 2017 12:02:29 -0400    

related to 6ce6a61840cc90172ad3da7bf303656132fa5fab  
  
Reported-by: Christoph Berg <[email protected]>  

commit   : 9c57848921ec90fca8dfd297adcb4d5d07d40160    
  
author   : Peter Eisentraut <[email protected]>    
date     : Fri, 25 Aug 2017 11:49:05 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Fri, 25 Aug 2017 11:49:05 -0400    

commit   : 1563b8fa673800e79a54fac899f78c836f22ff5c    
  
author   : Andres Freund <[email protected]>    
date     : Thu, 24 Aug 2017 15:07:40 -0700    
  
committer: Andres Freund <[email protected]>    
date     : Thu, 24 Aug 2017 15:07:40 -0700    

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.  

commit   : 51d0fa8ed93fe5befe91498f1a3eb5aede32677a    
  
author   : Stephen Frost <[email protected]>    
date     : Thu, 24 Aug 2017 16:20:48 -0400    
  
committer: Stephen Frost <[email protected]>    
date     : Thu, 24 Aug 2017 16:20:48 -0400    

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  

commit   : 8a7beca69112755094a3f2ca1daa745d378dd452    
  
author   : Peter Eisentraut <[email protected]>    
date     : Thu, 24 Aug 2017 15:29:35 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Thu, 24 Aug 2017 15:29:35 -0400    

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.  

commit   : cf98e3837db36d985507a924e392847e2ab857d0    
  
author   : Peter Eisentraut <[email protected]>    
date     : Thu, 24 Aug 2017 14:04:28 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Thu, 24 Aug 2017 14:04:28 -0400    

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  

commit   : d51b0872bf9a71d9585ca13bbf1f9463d9c61182    
  
author   : Peter Eisentraut <[email protected]>    
date     : Wed, 23 Aug 2017 14:59:25 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Wed, 23 Aug 2017 14:59:25 -0400    

Reported-by: Alvaro Herrera <[email protected]>  

commit   : da19c32c6b7dd7d0ff5814538adf5aaa665848a1    
  
author   : Peter Eisentraut <[email protected]>    
date     : Wed, 23 Aug 2017 14:19:35 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Wed, 23 Aug 2017 14:19:35 -0400    

Author: Thomas Munro <[email protected]>  

commit   : 8bf94694691d1188aee671cdd9ce59c27df9bc7f    
  
author   : Peter Eisentraut <[email protected]>    
date     : Wed, 23 Aug 2017 12:01:43 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Wed, 23 Aug 2017 12:01:43 -0400    

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

commit   : 5e87f7b1d7079fcbbdb03c1ad02a3e40b2202e3e    
  
author   : Peter Eisentraut <[email protected]>    
date     : Wed, 23 Aug 2017 09:56:38 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Wed, 23 Aug 2017 09:56:38 -0400    

This was erroneously removed in  
55a70a023c3daefca9bbd68bfbe6862af10ab479.  

commit   : 2ac307bc0125235f124e45bb697d5b445f0118ca    
  
author   : Peter Eisentraut <[email protected]>    
date     : Tue, 22 Aug 2017 20:32:17 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Tue, 22 Aug 2017 20:32:17 -0400    

commit   : adce8912e63ade2ca5bba674fcbad860a73888fd    
  
author   : Peter Eisentraut <[email protected]>    
date     : Tue, 22 Aug 2017 19:55:21 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Tue, 22 Aug 2017 19:55:21 -0400    

Reported-by: Basil Bourque <[email protected]>  

commit   : d34a74dd064af959acd9040446925d9d53dff15b    
  
author   : Andres Freund <[email protected]>    
date     : Tue, 22 Aug 2017 07:46:05 -0700    
  
committer: Andres Freund <[email protected]>    
date     : Tue, 22 Aug 2017 07:46:05 -0700    

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/[email protected]  
Backpatch: 9.2-  

commit   : 958ffb8c286d93d1bfced17e6300d13f9634b431    
  
author   : Peter Eisentraut <[email protected]>    
date     : Mon, 21 Aug 2017 11:22:00 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Mon, 21 Aug 2017 11:22:00 -0400    

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 <[email protected]>  

commit   : a79fb8e0c452a9b88206e2abd4add2b432a2596b    
  
author   : Peter Eisentraut <[email protected]>    
date     : Mon, 21 Aug 2017 09:17:06 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Mon, 21 Aug 2017 09:17:06 -0400    

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 <[email protected]>  

commit   : b8a25494819ac2551a71674effb7f50a7b7b74f6    
  
author   : Noah Misch <[email protected]>    
date     : Sun, 20 Aug 2017 21:22:18 -0700    
  
committer: Noah Misch <[email protected]>    
date     : Sun, 20 Aug 2017 21:22:18 -0700    

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.  

commit   : 1c3869c0bea4376bcbb358e1abf5ed95e8c41865    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 19 Aug 2017 13:39:37 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 19 Aug 2017 13:39:37 -0400    

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  

commit   : 7c84acc455368721e046dc0cc2eb84d62c4f5e61    
  
author   : Peter Eisentraut <[email protected]>    
date     : Fri, 18 Aug 2017 23:02:28 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Fri, 18 Aug 2017 23:02:28 -0400    

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

commit   : d4b42e5215fae85e2ae473ba4957705f4c9861e9    
  
author   : Robert Haas <[email protected]>    
date     : Fri, 18 Aug 2017 13:01:05 -0400    
  
committer: Robert Haas <[email protected]>    
date     : Fri, 18 Aug 2017 13:01:05 -0400    

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/[email protected]  

commit   : 9b644745c94944de8f23449524671601d8863830    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 17 Aug 2017 18:35:14 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 17 Aug 2017 18:35:14 -0400    

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.  

commit   : 7c0ca2900f7cae490fd551096cb7dc581cfe45c8    
  
author   : Robert Haas <[email protected]>    
date     : Thu, 17 Aug 2017 15:39:17 -0400    
  
committer: Robert Haas <[email protected]>    
date     : Thu, 17 Aug 2017 15:39:17 -0400    

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/[email protected]  

commit   : de1ca6919ff8f50e09122a1001eee1420b047199    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 17 Aug 2017 13:49:22 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 17 Aug 2017 13:49:22 -0400    

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  

commit   : 1d7a479d22f68c03d22c76b9a6de5cdf6ea9759b    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 17 Aug 2017 13:13:47 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 17 Aug 2017 13:13:47 -0400    

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  

commit   : ca49d69b7c8f04c495ce39ff4460e017656db901    
  
author   : Peter Eisentraut <[email protected]>    
date     : Thu, 17 Aug 2017 11:39:00 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Thu, 17 Aug 2017 11:39:00 -0400    

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.  

commit   : b469387fc09a00e1ea9c7e010fafdcf117299cad    
  
author   : Robert Haas <[email protected]>    
date     : Thu, 17 Aug 2017 11:19:07 -0400    
  
committer: Robert Haas <[email protected]>    
date     : Thu, 17 Aug 2017 11:19:07 -0400    

Spotted by Tom Lane  
  
Discussion: http://postgr.es/m/[email protected]  

commit   : 28c56553cb39174d0d33e5ed8200dc5e508ba5d8    
  
author   : Peter Eisentraut <[email protected]>    
date     : Thu, 17 Aug 2017 10:37:12 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Thu, 17 Aug 2017 10:37:12 -0400    

Author: Erik Rijkers <[email protected]>  

commit   : e4892c68184e199c3117a8f8b52da22a77702a05    
  
author   : Peter Eisentraut <[email protected]>    
date     : Wed, 16 Aug 2017 19:46:50 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Wed, 16 Aug 2017 19:46:50 -0400    

This became possible by commit  
6c2003f8a1bbc7c192a2e83ec51581c018aa162f.  This just makes pg_dump aware  
of it and updates the documentation.  
  
Author: Petr Jelinek <[email protected]>  

commit   : 0c16efcb533c95cec3e11daa13dba18110231831    
  
author   : Peter Eisentraut <[email protected]>    
date     : Wed, 16 Aug 2017 14:44:26 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Wed, 16 Aug 2017 14:44:26 -0400    

Author: Masahiko Sawada <[email protected]>  

commit   : 2327690df4f839ed34b088727a632867cbc0988e    
  
author   : Peter Eisentraut <[email protected]>    
date     : Wed, 16 Aug 2017 13:59:40 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Wed, 16 Aug 2017 13:59:40 -0400    

Author: Steve Singer <[email protected]>  

commit   : a6b174f55716c9da2e16804f2d4be4d8f76255ef    
  
author   : Michael Meskes <[email protected]>    
date     : Tue, 15 Aug 2017 16:06:56 +0200    
  
committer: Michael Meskes <[email protected]>    
date     : Tue, 15 Aug 2017 16:06:56 +0200    

commit   : 226be4062865476d190701d6ac13082a0595121e    
  
author   : Peter Eisentraut <[email protected]>    
date     : Tue, 15 Aug 2017 21:05:21 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Tue, 15 Aug 2017 21:05:21 -0400    

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 <[email protected]>  
Reviewed-by: Masahiko Sawada <[email protected]>  

commit   : 3ea58216de4b26e27be8c6b23e44e275804542f2    
  
author   : Peter Eisentraut <[email protected]>    
date     : Tue, 15 Aug 2017 19:27:22 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Tue, 15 Aug 2017 19:27:22 -0400    

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 <[email protected]>  

commit   : 7502f399de38c68d2bb327e4071dd2fcdb5a20e6    
  
author   : Peter Eisentraut <[email protected]>    
date     : Tue, 15 Aug 2017 19:10:38 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Tue, 15 Aug 2017 19:10:38 -0400    

Author: Pavel Stehule <[email protected]>  

commit   : f2f9fcb3030ba67b4347a44b18b201f84d23997b    
  
author   : Alvaro Herrera <[email protected]>    
date     : Tue, 15 Aug 2017 18:14:07 -0300    
  
committer: Alvaro Herrera <[email protected]>    
date     : Tue, 15 Aug 2017 18:14:07 -0300    

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  

commit   : edbad25877b10df07164345a8e6ae01236b6a26b    
  
author   : Peter Eisentraut <[email protected]>    
date     : Tue, 15 Aug 2017 16:20:20 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Tue, 15 Aug 2017 16:20:20 -0400    

Since we currently only have one protocol, this doesn't make much of a  
difference other than the error message.  
  
Author: Yugo Nagata <[email protected]>  

commit   : 0cafc267b5b2a0b9d8d93c7c3f1e88adb37fea6e    
  
author   : Peter Eisentraut <[email protected]>    
date     : Tue, 15 Aug 2017 15:36:18 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Tue, 15 Aug 2017 15:36:18 -0400    

Author: Masahiko Sawada <[email protected]>  

commit   : 292d9b66e2251df4767a43d78927a614561a21d6    
  
author   : Peter Eisentraut <[email protected]>    
date     : Tue, 15 Aug 2017 15:13:06 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Tue, 15 Aug 2017 15:13:06 -0400    

Avoid unnecessary locking calls when a subscription is disabled.  
  
Author: Yugo Nagata <[email protected]>  

commit   : 4e7cd035abaae16e45305417073e7009518acc61    
  
author   : Peter Eisentraut <[email protected]>    
date     : Tue, 15 Aug 2017 14:37:44 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Tue, 15 Aug 2017 14:37:44 -0400    

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 <[email protected]>  

commit   : 870da1e1546c9563c5ae45918392cf7bbc7e5b0e    
  
author   : Alvaro Herrera <[email protected]>    
date     : Tue, 15 Aug 2017 13:35:12 -0300    
  
committer: Alvaro Herrera <[email protected]>    
date     : Tue, 15 Aug 2017 13:35:12 -0300    

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  

commit   : d7ab908fbab5094e92a167441ec8d6bfb3b0c9fc    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 15 Aug 2017 11:07:52 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 15 Aug 2017 11:07:52 -0400    

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  

commit   : 17a2a27b49ae19a1002b8230a6ceeef53082211e    
  
author   : Robert Haas <[email protected]>    
date     : Tue, 15 Aug 2017 09:16:33 -0400    
  
committer: Robert Haas <[email protected]>    
date     : Tue, 15 Aug 2017 09:16:33 -0400    

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  

commit   : 29990634c76a2278ae68bfb951fd20d5510a732d    
  
author   : Robert Haas <[email protected]>    
date     : Tue, 15 Aug 2017 08:06:36 -0400    
  
committer: Robert Haas <[email protected]>    
date     : Tue, 15 Aug 2017 08:06:36 -0400    

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

commit   : ee5572e051955ef4570f95413dc6cddb4df51d50    
  
author   : Andres Freund <[email protected]>    
date     : Mon, 14 Aug 2017 15:21:26 -0700    
  
committer: Andres Freund <[email protected]>    
date     : Mon, 14 Aug 2017 15:21:26 -0700    

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/[email protected]  
Backpatch: 10, where gather merge was introduced  

commit   : 21d304dfedb4f26d0d6587d9ac39b1b5c499bb55    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 14 Aug 2017 17:29:33 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 14 Aug 2017 17:29:33 -0400    

commit   : 5b6289c1e07dc45f09c3169a189e60d2fcaec2b3    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 14 Aug 2017 15:43:20 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 14 Aug 2017 15:43:20 -0400    

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/[email protected]  

commit   : 7f1bb1d7346b67a62e8ec59f79f8284cb7fb4394    
  
author   : Peter Eisentraut <[email protected]>    
date     : Mon, 14 Aug 2017 13:53:05 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Mon, 14 Aug 2017 13:53:05 -0400    

Author: Masahiko Sawada <[email protected]>  

commit   : 79e5de690efce6e7aaa9c60e10389a8bc58c1617    
  
author   : Peter Eisentraut <[email protected]>    
date     : Mon, 14 Aug 2017 13:42:03 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Mon, 14 Aug 2017 13:42:03 -0400    

Author: Masahiko Sawada <[email protected]>  
Reported-by: Kyle Conroy <[email protected]>  
Bug: #14775  

commit   : 5a5c2feca3fd858e70ea348822595547e6fa6c15    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 14 Aug 2017 11:48:59 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 14 Aug 2017 11:48:59 -0400    

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  

commit   : ea0ca75d5d14e0c98782a2188405685af4a475a0    
  
author   : Michael Meskes <[email protected]>    
date     : Mon, 14 Aug 2017 11:29:34 +0200    
  
committer: Michael Meskes <[email protected]>    
date     : Mon, 14 Aug 2017 11:29:34 +0200    

commit   : 004a9702e062b5b6d61813f3fc8d71654d331d05    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 13 Aug 2017 16:15:14 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 13 Aug 2017 16:15:14 -0400    

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  

commit   : 2336f842843e5bd26779692b39eaf0ef9d4d31da    
  
author   : Alvaro Herrera <[email protected]>    
date     : Sat, 12 Aug 2017 21:36:07 -0400    
  
committer: Alvaro Herrera <[email protected]>    
date     : Sat, 12 Aug 2017 21:36:07 -0400    

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

commit   : e88928c50dfe2623c899f82b54aad69da248ad07    
  
author   : Noah Misch <[email protected]>    
date     : Sat, 12 Aug 2017 18:19:49 -0700    
  
committer: Noah Misch <[email protected]>    
date     : Sat, 12 Aug 2017 18:19:49 -0700    

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

commit   : 3043c1ddd13cd902d820d9aea353e60ce2d3d698    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 12 Aug 2017 12:08:54 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 12 Aug 2017 12:08:54 -0400