PostgreSQL 9.6.7 commit log

commit   : 799107108b36ca3ef498bf5997626f5fc43cabb0    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 5 Feb 2018 16:03:36 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 5 Feb 2018 16:03:36 -0500    

commit   : 0ba3e3ec8166907df835895279bb9b832f6ae348    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 5 Feb 2018 14:43:40 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 5 Feb 2018 14:43:40 -0500    

Security: CVE-2018-1052, CVE-2018-1053  

commit   : 5bdbc5b7550091be3ccf56eed8e6b4e0197fa7f1    
  
author   : Peter Eisentraut <[email protected]>    
date     : Mon, 5 Feb 2018 12:38:16 -0500    
  
committer: Peter Eisentraut <[email protected]>    
date     : Mon, 5 Feb 2018 12:38:16 -0500    

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

commit   : 1341e017dffee00fb245081ec5a11d3b93d9aafb    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 5 Feb 2018 10:58:27 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 5 Feb 2018 10:58:27 -0500    

pg_upgrade has always attempted to ensure that the transient dump files  
it creates are inaccessible except to the owner.  However, refactoring  
in commit 76a7650c4 broke that for the file containing "pg_dumpall -g"  
output; since then, that file was protected according to the process's  
default umask.  Since that file may contain role passwords (hopefully  
encrypted, but passwords nonetheless), this is a particularly unfortunate  
oversight.  Prudent users of pg_upgrade on multiuser systems would  
probably run it under a umask tight enough that the issue is moot, but  
perhaps some users are depending only on pg_upgrade's umask changes to  
protect their data.  
  
To fix this in a future-proof way, let's just tighten the umask at  
process start.  There are no files pg_upgrade needs to write at a  
weaker security level; and if there were, transiently relaxing the  
umask around where they're created would be a safer approach.  
  
Report and patch by Tom Lane; the idea for the fix is due to Noah Misch.  
Back-patch to all supported branches.  
  
Security: CVE-2018-1053  

commit   : b2e15d39d74f226f25a9362f1a1834bf25f47288    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 4 Feb 2018 15:13:44 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 4 Feb 2018 15:13:44 -0500    

commit   : 12db49a83058d8e9269b405d9fe17ea662623e80    
  
author   : Bruce Momjian <[email protected]>    
date     : Wed, 31 Jan 2018 16:54:33 -0500    
  
committer: Bruce Momjian <[email protected]>    
date     : Wed, 31 Jan 2018 16:54:33 -0500    

Also remove outdated comment about SPI subtransactions.  
  
Reported-by: [email protected]  
  
Discussion: https://postgr.es/m/[email protected]  
  
Backpatch-through: 9.3  

commit   : 06b2f15f354cadec5fb5c50bdfe9cadf24c856fb    
  
author   : Bruce Momjian <[email protected]>    
date     : Wed, 31 Jan 2018 16:43:32 -0500    
  
committer: Bruce Momjian <[email protected]>    
date     : Wed, 31 Jan 2018 16:43:32 -0500    

Commit 9521ce4a7a1125385fb4de9689f345db594c516a from Sep 13, 2017 and  
backpatched through 9.5 used rsync examples with datadir.  The reporter  
has pointed out, and testing has verified, that clusterdir must be used,  
so update the docs accordingly.  
  
Reported-by: Don Seiler  
  
Discussion: https://postgr.es/m/CAHJZqBD0u9dCERpYzK6BkRv=663AmH==DFJpVC=M4Xg_rq2=CQ@mail.gmail.com  
  
Backpatch-through: 9.5  

commit   : 7201c68793e98ffaa77616bda91613815aa0a66b    
  
author   : Robert Haas <[email protected]>    
date     : Wed, 31 Jan 2018 16:28:11 -0500    
  
committer: Robert Haas <[email protected]>    
date     : Wed, 31 Jan 2018 16:28:11 -0500    

Previously, only 128 was mentioned, but the others are also supported.  
  
Thomas Munro, reviewed by Michael Paquier and extended a bit by me.  
  
Discussion: http://postgr.es/m/CAEepm=1XbBHXYJKofGjnM2Qfz-ZBVqhGU4AqvtgR+Hegy4fdKg@mail.gmail.com  

commit   : d397f558d5552b01643f000d4db7e0960d76241f    
  
author   : Robert Haas <[email protected]>    
date     : Tue, 30 Jan 2018 14:27:38 -0500    
  
committer: Robert Haas <[email protected]>    
date     : Tue, 30 Jan 2018 14:27:38 -0500    

Commit 4bbf6edfbd5d03743ff82dda2f00c738fb3208f5 added a test case,  
but it turns out that the test case doesn't reliably test for the  
bug, and in the context of the regression test suite did not because  
ANALYZE had not been run.  
  
Report and patch by Etsuro Fujita.  I added a comment along lines  
previously suggested by Tom Lane.  
  
Discussion: http://postgr.es/m/[email protected]  

commit   : 8067cf816cd49d47f258a1115a1443a4e70b3864    
  
author   : Peter Eisentraut <[email protected]>    
date     : Mon, 29 Jan 2018 14:04:32 -0500    
  
committer: Peter Eisentraut <[email protected]>    
date     : Mon, 29 Jan 2018 14:04:32 -0500    

Update the documentation for \pset to mention  
columns|linestyle|pager_min_lines.  
  
Author: Дилян Палаузов <[email protected]>  

commit   : 4e9fb4bfe2e33aff941e29ec55972d68f4cdb69c    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 28 Jan 2018 13:39:07 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 28 Jan 2018 13:39:07 -0500    

create_plan_recurse lacked any stack depth check.  This is not per  
our normal coding rules, but I'd supposed it was safe because earlier  
planner processing is more complex and presumably should eat more  
stack.  But bug #15033 from Andrew Grossman shows this isn't true,  
at least not for queries having the form of a many-thousand-way  
INTERSECT stack.  
  
Further testing showed that recurse_set_operations is also capable  
of being crashed in this way, since it likewise will recurse to the  
bottom of a parsetree before calling any support functions that  
might themselves contain any stack checks.  However, its stack  
consumption is only perhaps a third of create_plan_recurse's.  
  
It's possible that this particular problem with create_plan_recurse can  
only manifest in 9.6 and later, since before that we didn't build a Path  
tree for set operations.  But having seen this example, I now have no  
faith in the proposition that create_plan_recurse doesn't need a stack  
check, so back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 462402be873dfa252c8ab34ff42a7af252cfa481    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 27 Jan 2018 16:42:28 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 27 Jan 2018 16:42:28 -0500    

DST law changes in Brazil, Sao Tome and Principe.  Historical corrections  
for Bolivia, Japan, and South Sudan.  The "US/Pacific-New" zone has been  
removed (it was only a link to America/Los_Angeles anyway).  

commit   : ae3699a6ae55f370bfd7f169a46f89f4aca84f27    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 23 Jan 2018 16:50:35 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 23 Jan 2018 16:50:35 -0500    

If we're inside a lateral subquery, there may be no unparameterized paths  
for a particular child relation of an appendrel, in which case we *must*  
be able to create similarly-parameterized paths for each other child  
relation, else the planner will fail with "could not devise a query plan  
for the given query".  This means that there are situations where we'd  
better be able to reparameterize at least one path for each child.  
  
This calls into question the assumption in reparameterize_path() that  
it can just punt if it feels like it.  However, the only case that is  
known broken right now is where the child is itself an appendrel so that  
all its paths are AppendPaths.  (I think possibly I disregarded that in  
the original coding on the theory that nested appendrels would get folded  
together --- but that only happens *after* reparameterize_path(), so it's  
not excused from handling a child AppendPath.)  Given that this code's been  
like this since 9.3 when LATERAL was introduced, it seems likely we'd have  
heard of other cases by now if there were a larger problem.  
  
Per report from Elvis Pranskevichus.  Back-patch to 9.3.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 2843c01a56eb2116a7cf871d7ed324ed3d5e522e    
  
author   : Robert Haas <[email protected]>    
date     : Tue, 23 Jan 2018 11:13:50 -0500    
  
committer: Robert Haas <[email protected]>    
date     : Tue, 23 Jan 2018 11:13:50 -0500    

Commit 28724fd90d2f85a0573a8107b48abad062a86d83 fixed things so that  
if a background worker fails to start due to fork() failure or because  
it is terminated before startup succeeds, BGWH_STOPPED will be  
reported.  However, that only helps if the code that uses the  
background worker machinery notices the change in status, and the code  
in parallel.c did not.  
  
To fix that, do two things.  First, make sure that when a worker  
exits, it triggers the leader to read from error queues.  That way, if  
a worker which has attached to an error queue exits uncleanly, the  
leader is sure to throw some error, either the contents of the  
ErrorResponse sent by the worker, or "lost connection to parallel  
worker" if it exited without sending one.  To cover the case where  
the worker never starts up in the first place or exits before  
attaching to the error queue, the ParallelContext now keeps track  
of which workers have sent at least one message via the error  
queue.  A worker which sends no messages by the time the parallel  
operation finishes will be checked to see whether it exited before  
attaching to the error queue; if so, a new error message, "parallel  
worker failed to initialize", will be reported.  If not, we'll  
continue to wait until it either starts up and exits cleanly, starts  
up and exits uncleanly, or fails to start, and then take the  
appropriate action.  
  
Patch by me, reviewed by Amit Kapila.  
  
Discussion: http://postgr.es/m/CA+TgmoYnBgXgdTu6wk5YPdWhmgabYc9nY_pFLq=tB=FSLYkD8Q@mail.gmail.com  

commit   : cda1ba3f3bebd5a61bef981773c4cbb97ad33590    
  
author   : Bruce Momjian <[email protected]>    
date     : Tue, 23 Jan 2018 10:18:21 -0500    
  
committer: Bruce Momjian <[email protected]>    
date     : Tue, 23 Jan 2018 10:18:21 -0500    

Backpatch-through: 9.3  

commit   : 52cc1b484e52faad20a4a6094b015080b3ff8e07    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 22 Jan 2018 12:06:19 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 22 Jan 2018 12:06:19 -0500    

_tocEntryRequired() expects that it can identify ACL, SECURITY LABEL,  
and COMMENT TOC entries that are for large objects by seeing whether  
the tag for them starts with "LARGE OBJECT ".  While that works fine  
for actual large objects, which are indeed tagged that way, it's  
subject to false positives unless every such entry's tag starts with an  
appropriate type ID.  And in fact it does not work for ACLs, because  
up to now we customarily tagged those entries with just the bare name  
of the object.  This means that an ACL for an object named  
"LARGE OBJECT something" would be misclassified as data not schema,  
with undesirable results in a schema-only or data-only dump ---  
although pg_upgrade seems unaffected, due to the special case for  
binary-upgrade mode further down in _tocEntryRequired().  
  
We can fix this by changing all the dumpACL calls to use the label  
strings already in use for comments and security labels, which do  
follow the convention of starting with an object type indicator.  
  
Well, mostly they follow it.  dumpDatabase() got it wrong, using  
just the bare database name for those purposes, so that a database  
named "LARGE OBJECT something" would similarly be subject to having  
its comment or security label dropped or included when not wanted.  
Bring that into line too.  (Note that up to now, database ACLs have  
not been processed by pg_dump, so that this issue doesn't affect them.)  
  
_tocEntryRequired() itself is not free of fault: it was overly liberal  
about matching object tags to "LARGE OBJECT " in binary-upgrade mode.  
This looks like it is probably harmless because there would be no data  
component to strip anyway in that mode, but at best it's trouble  
waiting to happen, so tighten that up too.  
  
The possible misclassification of SECURITY LABEL entries for databases is  
in principle a security problem, but the opportunities for actual exploits  
seem too narrow to be interesting.  The other cases seem like just bugs,  
since an object owner can change its ACL or comment for himself, he needn't  
try to trick someone else into doing it by choosing a strange name.  
  
This has been broken since per-large-object TOC entries were introduced  
in 9.0, so back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : d516aea6591e03edd92e781dad07367117a7cd91    
  
author   : Bruce Momjian <[email protected]>    
date     : Sat, 20 Jan 2018 21:47:02 -0500    
  
committer: Bruce Momjian <[email protected]>    
date     : Sat, 20 Jan 2018 21:47:02 -0500    

Document how to properly create root and intermediate certificates using  
v3_ca extensions and where to place intermediate certificates so they  
are properly transferred to the remote side with the leaf certificate to  
link to the remote root certificate.  This corrects docs that used to  
say that intermediate certificates must be stored with the root  
certificate.  
  
Also add instructions on how to create root, intermediate, and leaf  
certificates.  
  
Discussion: https://postgr.es/m/[email protected]  
  
Reviewed-by: Michael Paquier  
  
Backpatch-through: 9.3  

commit   : 8a71ee6288547e20218b08240d8ae867bb16d6c6    
  
author   : Alvaro Herrera <[email protected]>    
date     : Fri, 19 Jan 2018 10:15:08 -0300    
  
committer: Alvaro Herrera <[email protected]>    
date     : Fri, 19 Jan 2018 10:15:08 -0300    

For no apparent reason, this function was using a 16bit-wide inhseqno  
value, rather than the correct 32 bit width which is what is stored in  
the pg_inherits catalog.  This becomes evident if you try to create a  
table with more than 65535 parents, because this error appears:  
  
ERROR:  duplicate key value violates unique constraint «pg_inherits_relid_seqno_index»  
DETAIL:  Key (inhrelid, inhseqno)=(329371, 0) already exists.  
  
Needless to say, having so many parents is an uncommon situations, which  
explains why this error has never been reported despite being having  
been introduced with the Postgres95 1.01 sources in commit d31084e9d111:  
https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/backend/commands/creatinh.c;hb=d31084e9d111#l349  
  
Backpatch all the way back.  
  
David Rowley noticed this while reviewing a patch of mine.  
Discussion: https://postgr.es/m/CAKJS1f8Dn7swSEhOWwzZzssW7747YB=2Hi+T7uGud40dur69-g@mail.gmail.com  

commit   : 456cab29df65b7ad3d9ce6345bb85448d7c8f98e    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 18 Jan 2018 11:09:44 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 18 Jan 2018 11:09:44 -0500    

On Sparc64, use of __attribute__(aligned(8)) with __int128 causes faulty  
code generation in gcc versions at least through 5.5.0.  We can work around  
that by disabling use of __int128, so teach configure to test for the bug.  
  
This solution doesn't fix things for the case of cross-compiling with a  
buggy compiler; to support that nicely, we'd need to add a manual disable  
switch.  Unless more such cases turn up, it doesn't seem worth the work.  
Affected users could always edit pg_config.h manually.  
  
In passing, fix some typos in the existing configure test for __int128.  
They're harmless because we only compile that code not run it, but  
they're still confusing for anyone looking at it closely.  
  
This is needed in support of commit 751804998, so back-patch to 9.5  
as that was.  
  
Marina Polyakova, Victor Wagner, Tom Lane  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 4a81c022975ec786b26ec8af6b7d8527319bf445    
  
author   : Robert Haas <[email protected]>    
date     : Wed, 17 Jan 2018 16:18:39 -0500    
  
committer: Robert Haas <[email protected]>    
date     : Wed, 17 Jan 2018 16:18:39 -0500    

When pushing down a join to a foreign server, postgres_fdw constructs  
an alternative plan to be used for any EvalPlanQual rechecks that  
prove to be necessary.  This plan is stored as the outer subplan of  
the Foreign Scan implementing the pushed-down join.  Previously, this  
alternative plan could have a different nominal sort ordering than its  
parent, which seemed OK since there will only be one tuple per base  
table anyway in the case of an EvalPlanQual recheck.  Actually,  
though, it caused a problem if that path was used as a building block  
for the EvalPlanQual recheck plan of a higher-level foreign join,  
because we could end up with a merge join one of whose inputs was not  
labelled with the correct sort order.  Repair by injecting an extra  
Sort node into the EvalPlanQual recheck plan whenever it would  
otherwise fail to be sorted at least as well as its parent Foreign  
Scan.  
  
Report by Jeff Janes.  Patch by me, reviewed by Tom Lane, who also  
provided the test case and comment text.  
  
Discussion: http://postgr.es/m/CAMkU=1y2G8VOVBHv3iXU2TMAj7-RyBFFW1uhkr5sm9LQ2=X35g@mail.gmail.com  

commit   : f082ef83688b036437e580f42894f674534fdb24    
  
author   : Michael Meskes <[email protected]>    
date     : Sat, 13 Jan 2018 14:56:49 +0100    
  
committer: Michael Meskes <[email protected]>    
date     : Sat, 13 Jan 2018 14:56:49 +0100    

Patch by: "Rader, David" <[email protected]>  

commit   : c2a7044a5128a17256c771b545a534c7dccb7736    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 12 Jan 2018 15:46:37 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 12 Jan 2018 15:46:37 -0500    

If a query against an inheritance tree runs concurrently with an ALTER  
TABLE that's disinheriting one of the tree members, it's possible to get  
a "could not find inherited attribute" error because after obtaining lock  
on the removed member, make_inh_translation_list sees that its columns  
have attinhcount=0 and decides they aren't the columns it's looking for.  
  
An ideal fix, perhaps, would avoid including such a just-removed member  
table in the query at all; but there seems no way to accomplish that  
without adding expensive catalog rechecks or creating a likelihood of  
deadlocks.  Instead, let's just drop the check on attinhcount.  In this  
way, a query that's included a just-disinherited child will still  
succeed, which is not a completely unreasonable behavior.  
  
This problem has existed for a long time, so back-patch to all supported  
branches.  Also add an isolation test verifying related behaviors.  
  
Patch by me; the new isolation test is based on Kyotaro Horiguchi's work.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 6520d4a9692882a7d5233dac40c4b7ff07f55049    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 12 Jan 2018 12:24:50 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 12 Jan 2018 12:24:50 -0500    

If we flatten a subquery whose target list contains constants or  
expressions, when those output columns are used in GROUPING SET columns,  
the planner was capable of doing the wrong thing by merging a pulled-up  
expression into the surrounding expression during const-simplification.  
Then the late processing that attempts to match subexpressions to grouping  
sets would fail to match those subexpressions to grouping sets, with the  
effect that they'd not go to null when expected.  
  
To fix, wrap such subquery outputs in PlaceHolderVars, ensuring that  
they preserve their separate identity throughout the planner's expression  
processing.  This is a bit of a band-aid, because the wrapper defeats  
const-simplification even in places where it would be safe to allow.  
But a nicer fix would likely be too invasive to back-patch, and the  
consequences of the missed optimizations probably aren't large in most  
cases.  
  
Back-patch to 9.5 where grouping sets were introduced.  
  
Heikki Linnakangas, with small mods and better test cases by me;  
additional review by Andrew Gierth  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : bda5281fdc5e41b6f54ff8f47df2ca37df00a19e    
  
author   : Teodor Sigaev <[email protected]>    
date     : Thu, 11 Jan 2018 14:43:13 +0300    
  
committer: Teodor Sigaev <[email protected]>    
date     : Thu, 11 Jan 2018 14:43:13 +0300    

~> (cube, int) operator was especially designed for knn-gist search.  
However, it appears that knn-gist search can't work correctly with current  
behavior of this operator when dataset contains cubes of variable  
dimensionality. In this case, the same value of second operator argument  
can point to different dimension depending on dimensionality of particular cube.  
Such behavior is incompatible with gist indexing of cubes, and knn-gist doesn't  
work correctly for it.  
  
This patch changes behavior of ~> (cube, int) operator by introducing dimension  
numbering where value of second argument unambiguously identifies number of  
dimension. With new behavior, this operator can be correctly supported by  
knn-gist. Relevant changes to cube operator class are also included.  
  
Backpatch to v9.6 where operator was introduced.  
  
Since behavior of ~> (cube, int) operator is changed, depending entities  
must be refreshed after upgrade. Such as, expression indexes using this  
operator must be reindexed, materialized views must be rebuilt, stored  
procedures and client code must be revised to correctly use new behavior.  
That should be mentioned in release notes.  
  
Noticed by: Tomas Vondra  
Author: Alexander Korotkov  
Reviewed by: Tomas Vondra, Andrey Borodin  
Discussion: https://www.postgresql.org/message-id/flat/[email protected]  

commit   : 1226051948e00c3fcadf82da47e9513572a1d5dc    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 10 Jan 2018 17:13:29 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 10 Jan 2018 17:13:29 -0500    

These functions are stated to be Oracle-compatible, but they weren't.  
Yugo Nagata noticed that while our code returns zero for a zero or  
negative fourth parameter (occur_index), Oracle throws an error.  
Further testing by me showed that there was also a discrepancy in the  
interpretation of a negative third parameter (beg_index): Oracle thinks  
that a negative beg_index indicates the last place where the target  
substring can *begin*, whereas our code thinks it is the last place  
where the target can *end*.  
  
Adjust the sample code to behave like Oracle in both these respects.  
Also change it to be a CDATA[] section, simplifying copying-and-pasting  
out of the documentation source file.  And fix minor problems in the  
introductory comment, which wasn't very complete or accurate.  
  
Back-patch to all supported branches.  Although this patch only touches  
documentation, we should probably call it out as a bug fix in the next  
minor release notes, since users who have adopted the functions will  
likely want to update their versions.  
  
Yugo Nagata and Tom Lane  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : c24a908d04806c34c3e5dda42d39bb5ca1fc5ffb    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 10 Jan 2018 15:50:54 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 10 Jan 2018 15:50:54 -0500    

It seems incorrect to assume that the list of CkptSortItems can never  
contain duplicate page numbers: concurrent activity could result in some  
page getting dropped from a low-numbered buffer and later loaded into a  
high-numbered buffer while BufferSync is scanning the buffer pool.  
If that happened, the comparator would give self-inconsistent results,  
potentially confusing qsort().  Saving one comparison step is not worth  
possibly getting the sort wrong.  
  
So far as I can tell, nothing would actually go wrong given our current  
implementation of qsort().  It might get a bit slower than expected  
if there were a large number of duplicates of one value, but that's  
surely a probability-epsilon case.  Still, the comment is wrong,  
and if we ever switched to another sort implementation it might be  
less forgiving.  
  
In passing, avoid casting away const-ness of the argument pointers;  
I've not seen any compiler complaints from that, but it seems likely  
that some compilers would not like it.  
  
Back-patch to 9.6 where this code came in, just in case I've underestimated  
the possible consequences.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 01268386665f4a59c2fa9236f448bf3caf8c3b0b    
  
author   : Alvaro Herrera <[email protected]>    
date     : Tue, 9 Jan 2018 15:54:39 -0300    
  
committer: Alvaro Herrera <[email protected]>    
date     : Tue, 9 Jan 2018 15:54:39 -0300    

As src/backend/access/transam/README says, PageGetLSN may only be called  
by processes holding either exclusive lock on buffer, or a shared lock  
on buffer plus buffer header lock.  Therefore any place that only holds  
a shared buffer lock must use BufferGetLSNAtomic instead of PageGetLSN,  
which internally obtains buffer header lock prior to reading the LSN.  
  
A few callsites failed to comply with this rule.  This was detected by  
running all tests under a new (not committed) assertion that verifies  
PageGetLSN locking contract.  All but one of the callsites that failed  
the assertion are fixed by this patch.  Remaining callsites were  
inspected manually and determined not to need any change.  
  
The exception (unfixed callsite) is in TestForOldSnapshot, which only  
has a Page argument, making it impossible to access the corresponding  
Buffer from it.  Fixing that seems a much larger patch that will have to  
be done separately; and that's just as well, since it was only  
introduced in 9.6 and other bugs are much older.  
  
Some of these bugs are ancient; backpatch all the way back to 9.3.  
  
Authors: Jacob Champion, Asim Praveen, Ashwin Agrawal  
Reviewed-by: Michaël Paquier  
Discussion: https://postgr.es/m/CABAq_6GXgQDVu3u12mK9O5Xt5abBZWQ0V40LZCE+oUf95XyNFg@mail.gmail.com  

commit   : 1d135657a308e920d92df35e3453ed1725dbbc0d    
  
author   : Bruce Momjian <[email protected]>    
date     : Fri, 5 Jan 2018 14:11:15 -0500    
  
committer: Bruce Momjian <[email protected]>    
date     : Fri, 5 Jan 2018 14:11:15 -0500    

Backpatch-through: 9.4 (9.3 didn't need improving)  

commit   : 9a5e4a6e08faf68f9fbc1e15eeade46fd7b1d7e0    
  
author   : Alvaro Herrera <[email protected]>    
date     : Fri, 5 Jan 2018 12:17:10 -0300    
  
committer: Alvaro Herrera <[email protected]>    
date     : Fri, 5 Jan 2018 12:17:10 -0300    

Logical decoding's reorderbuffer.c may spill transaction files to disk  
when transactions are large.  These are supposed to be removed when they  
become "too old" by xid; but file removal requires the boundary LSNs of  
the transaction to be known.  The final_lsn is only set when we see the  
commit or abort record for the transaction, but nothing sets the value  
for transactions that crash, so the removal code misbehaves -- in  
assertion-enabled builds, it crashes by a failed assertion.  
  
To fix, modify the final_lsn of transactions that don't have a value  
set, to the LSN of the very latest change in the transaction.  This  
causes the spilled files to be removed appropriately.  
  
Author: Atsushi Torikoshi  
Reviewed-by: Kyotaro HORIGUCHI, Craig Ringer, Masahiko Sawada  
Discussion: https://postgr.es/m/[email protected]  

commit   : ad592f4a6eed64358bf1ec8733c4f0be2a3c85dd    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 4 Jan 2018 14:59:00 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 4 Jan 2018 14:59:00 -0500    

Instead of using our standard macro for this calculation, this code  
did it itself ... and got it wrong, leading to incorrect display of  
the null bitmap in some cases.  Noted and fixed by Maksim Milyutin.  
  
In passing, remove a uselessly duplicative error check.  
  
Errors were introduced in commit d6061f83a; back-patch to 9.6  
where that came in.  
  
Maksim Milyutin, reviewed by Andrey Borodin  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 2157a61b5aa3805a9e0fb11fa2fd4da9ca54234c    
  
author   : Robert Haas <[email protected]>    
date     : Tue, 19 Dec 2017 12:21:56 -0500    
  
committer: Robert Haas <[email protected]>    
date     : Tue, 19 Dec 2017 12:21:56 -0500    

When a Gather or Gather Merge node is started and stopped multiple  
times, accumulate instrumentation data only once, at the end, instead  
of after each execution, to avoid recording inflated totals.  
  
This is a back-port of commit 8526bcb2df76d5171b4f4d6dc7a97560a73a5eff  
by Amit Kapila.  
  
Discussion: http://postgr.es/m/[email protected]  
Discussion: http://postgr.es/m/CAA4eK1KT3BYj50qWhK5qBF=LDzQCoUVSFZjcK3mHoJJeWA+fNA@mail.gmail.com  

commit   : b64d6c9341522e89f30beecc72ce8859afd8b6c9    
  
author   : Alvaro Herrera <[email protected]>    
date     : Wed, 3 Jan 2018 11:16:34 -0300    
  
committer: Alvaro Herrera <[email protected]>    
date     : Wed, 3 Jan 2018 11:16:34 -0300    

This reverts commit 2268e6afd596.  It turned out that inconsistency in  
the report is still possible, so go back to the simpler formulation of  
the test and instead add an alternate expected output.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : ceee51e3813e810e1e33afb372c547e550e78db6    
  
author   : Andres Freund <[email protected]>    
date     : Wed, 3 Jan 2018 12:00:11 -0800    
  
committer: Andres Freund <[email protected]>    
date     : Wed, 3 Jan 2018 12:00:11 -0800    

Upcoming versions of glibc will contain copy_file_range(2), a wrapper  
around a new linux syscall for in-kernel copying of data ranges. This  
conflicts with pg_rewinds function of the same name.  
  
Therefore rename pg_rewinds version. As our version isn't a generic  
copying facility we decided to choose a rewind specific function name.  
  
Per buildfarm animal caiman and subsequent discussion with Tom Lane.  
  
Author: Andres Freund  
Discussion:  
    https://postgr.es/m/[email protected]  
    https://postgr.es/m/[email protected]  
Backpatch: 9.5-, where pg_rewind was introduced  

commit   : 85cdcde1f42e136efce3c51bfd47bdf8ecb7d3dd    
  
author   : Andrew Dunstan <[email protected]>    
date     : Wed, 3 Jan 2018 15:26:39 -0500    
  
committer: Andrew Dunstan <[email protected]>    
date     : Wed, 3 Jan 2018 15:26:39 -0500    

Commit 614350a3 allowed for an different builds of OpenSSL libraries on  
Windows, but ignored the fact that the alternative builds don't have  
config-specific libraries. This patch fixes the Solution file to ask for  
the correct libraries.  
  
per offline discussions with Leonardo Cecchi and Marco Nenciarini,  
  
Backpatch to all live branches.  

commit   : fe0cc5ba5372eca5e9eec1b317dffa0adf7b1049    
  
author   : Alvaro Herrera <[email protected]>    
date     : Wed, 3 Jan 2018 17:26:20 -0300    
  
committer: Alvaro Herrera <[email protected]>    
date     : Wed, 3 Jan 2018 17:26:20 -0300    

XactLockTableWait assumed that its xid argument has already added itself  
to the lock table.  That assumption led to another assumption that if  
locking the xid has succeeded but the xid is reported as still in  
progress, then the input xid must have been a subtransaction.  
  
These assumptions hold true for the original uses of this code in  
locking related to on-disk tuples, but they break down in logical  
replication slot snapshot building -- in particular, when a standby  
snapshot logged contains an xid that's already in ProcArray but not yet  
in the lock table.  This leads to assertion failures that can be  
reproduced all the way back to 9.4, when logical decoding was  
introduced.  
  
To fix, change SubTransGetParent to SubTransGetTopmostTransaction which  
has a slightly different API: it returns the argument Xid if there is no  
parent, and it goes all the way to the top instead of moving up the  
levels one by one.  Also, to avoid busy-waiting, add a 1ms sleep to give  
the other process time to register itself in the lock table.  
  
For consistency, change ConditionalXactLockTableWait the same way.  
  
Author: Petr Jelínek  
Discussion: https://postgr.es/m/[email protected]  
Reported-by: Konstantin Knizhnik  
Diagnosed-by: Stas Kelvich, Petr Jelínek  
Reviewed-by: Andres Freund, Robert Haas  

commit   : 0f38a1d85abebd79ad8ac348e3912463ae56192e    
  
author   : Alvaro Herrera <[email protected]>    
date     : Wed, 3 Jan 2018 11:16:34 -0300    
  
committer: Alvaro Herrera <[email protected]>    
date     : Wed, 3 Jan 2018 11:16:34 -0300    

I did this by adding another locking process, which makes the other two  
wait.  This way the output should be stable enough.  
  
Per buildfarm and Andres Freund  
Discussion: https://postgr.es/m/[email protected]  

commit   : 1a6429d455962191da78a61475b89b434643385e    
  
author   : Bruce Momjian <[email protected]>    
date     : Tue, 2 Jan 2018 23:30:12 -0500    
  
committer: Bruce Momjian <[email protected]>    
date     : Tue, 2 Jan 2018 23:30:12 -0500    

Backpatch-through: certain files through 9.3  

commit   : fb7b43903e911fef30c97ee1747ee948f2ba5e28    
  
author   : Alvaro Herrera <[email protected]>    
date     : Tue, 2 Jan 2018 19:16:16 -0300    
  
committer: Alvaro Herrera <[email protected]>    
date     : Tue, 2 Jan 2018 19:16:16 -0300    

Multiple sessions doing CREATE INDEX CONCURRENTLY simultaneously are  
supposed to be able to work in parallel, as evidenced by fixes in commit  
c3d09b3bd23f specifically to support this case.  In reality, one of the  
sessions would be aborted by a misterious "deadlock detected" error.  
  
Jeff Janes diagnosed that this is because of leftover snapshots used for  
system catalog scans -- this was broken by 8aa3e47510b9 keeping track of  
(registering) the catalog snapshot.  To fix the deadlocks, it's enough  
to de-register that snapshot prior to waiting.  
  
Backpatch to 9.4, which introduced MVCC catalog scans.  
  
Include an isolationtester spec that 8 out of 10 times reproduces the  
deadlock with the unpatched code for me (Álvaro).  
  
Author: Jeff Janes  
Diagnosed-by: Jeff Janes  
Reported-by: Jeremy Finzel  
Discussion: https://postgr.es/m/CAMa1XUhHjCv8Qkx0WOr1Mpm_R4qxN26EibwCrj0Oor2YBUFUTg%40mail.gmail.com  

commit   : f9c1c6099519609aceb54fc5366f096a0b1e1b41    
  
author   : Noah Misch <[email protected]>    
date     : Sun, 31 Dec 2017 21:58:29 -0800    
  
committer: Noah Misch <[email protected]>    
date     : Sun, 31 Dec 2017 21:58:29 -0800    

Otherwise, the test fails with "Timed out while waiting for standby to  
catch up".  This happened rarely, perhaps only when autovacuum wrote WAL  
between our choosing the recovery target and choosing the LSN to await.  
Commit b26f7fa6ae2b4e5d64525b3d5bc66a0ddccd9e24 fixed one case of this.  
Fix two more.  Back-patch to 9.6, which introduced the affected test.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : bd29bc417e7130312b47ba0da244c020a0193694    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 22 Dec 2017 12:08:28 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 22 Dec 2017 12:08:28 -0500    

Since 9.4, we've allowed the syntax "select union select" and variants  
of that.  However, the planner wasn't expecting a no-column set operation  
and ended up treating the set operation as if it were UNION ALL.  
  
Pre-v10, there seem to be some executor issues that would need to be  
fixed to support such cases, and it doesn't really seem worth expending  
much effort on.  Just disallow it, instead.  
  
Per report from Victor Yegorov.  
  
Discussion: https://postgr.es/m/CAGnEbojGJrRSOgJwNGM7JSJZpVAf8xXcVPbVrGdhbVEHZ-BUMw@mail.gmail.com  

commit   : 23b63417e20d548d281cd8f904f6f2ffcebddc8c    
  
author   : Peter Eisentraut <[email protected]>    
date     : Mon, 18 Dec 2017 16:00:35 -0500    
  
committer: Peter Eisentraut <[email protected]>    
date     : Mon, 18 Dec 2017 16:00:35 -0500    

oversight in 244c8b466a743d1ec18a7d841bf42669699b3b56  
  
Reported-by: Blaz Merela <[email protected]>  

commit   : 0668c84e28578921f46ad276f9cd24bb773841f2    
  
author   : Fujii Masao <[email protected]>    
date     : Tue, 19 Dec 2017 03:46:14 +0900    
  
committer: Fujii Masao <[email protected]>    
date     : Tue, 19 Dec 2017 03:46:14 +0900    

Previously an assertion failure occurred when pg_stop_backup() for  
non-exclusive backup was aborted while it's waiting for WAL files to  
be archived. This assertion failure happened in do_pg_abort_backup()  
which was called when a non-exclusive backup was canceled.  
do_pg_abort_backup() assumes that there is at least one non-exclusive  
backup running when it's called. But pg_stop_backup() can be canceled  
even after it marks the end of non-exclusive backup (e.g.,  
during waiting for WAL archiving). This broke the assumption that  
do_pg_abort_backup() relies on, and which caused an assertion failure.  
  
This commit changes do_pg_abort_backup() so that it does nothing  
when non-exclusive backup has been already marked as completed.  
That is, the asssumption is also changed, and do_pg_abort_backup()  
now can handle even the case where it's called when there is  
no running backup.  
  
Backpatch to 9.6 where SQL-callable non-exclusive backup was added.  
  
Author: Masahiko Sawada and Michael Paquier  
Reviewed-By: Robert Haas and Fujii Masao  
Discussion: https://www.postgresql.org/message-id/CAD21AoD2L1Fu2c==gnVASMyFAAaq3y-AQ2uEVj-zTCGFFjvmDg@mail.gmail.com  

commit   : 986a9153b9708071adf6ce2c9131266f3431f4ec    
  
author   : Andres Freund <[email protected]>    
date     : Mon, 13 Nov 2017 18:45:47 -0800    
  
committer: Andres Freund <[email protected]>    
date     : Mon, 13 Nov 2017 18:45:47 -0800    

The previous commit has shown that the sanity checks around freezing  
aren't strong enough. Strengthening them seems especially important  
because the existance of the bug has caused corruption that we don't  
want to make even worse during future vacuum cycles.  
  
The errors are emitted with ereport rather than elog, despite being  
"should never happen" messages, so a proper error code is emitted. To  
avoid superflous translations, mark messages as internal.  
  
Author: Andres Freund and Alvaro Herrera  
Reviewed-By: Alvaro Herrera, Michael Paquier  
Discussion: https://postgr.es/m/[email protected]  
Backpatch: 9.3-  

commit   : 937494c0e1f9b0589d32e00acb4c253ada9958b1    
  
author   : Andres Freund <[email protected]>    
date     : Fri, 3 Nov 2017 07:52:29 -0700    
  
committer: Andres Freund <[email protected]>    
date     : Fri, 3 Nov 2017 07:52:29 -0700    

Previously it was possible that a tuple was not pruned during vacuum,  
even though its update xmax (i.e. the updating xid in a multixact with  
both key share lockers and an updater) was below the cutoff horizon.  
  
As the freezing code assumed, rightly so, that that's not supposed to  
happen, xmax would be preserved (as a member of a new multixact or  
xmax directly). That causes two problems: For one the tuple is below  
the xmin horizon, which can cause problems if the clog is truncated or  
once there's an xid wraparound. The bigger problem is that that will  
break HOT chains, which in turn can lead two to breakages: First,  
failing index lookups, which in turn can e.g lead to constraints being  
violated. Second, future hot prunes / vacuums can end up making  
invisible tuples visible again. There's other harmful scenarios.  
  
Fix the problem by recognizing that tuples can be DEAD instead of  
RECENTLY_DEAD, even if the multixactid has alive members, if the  
update_xid is below the xmin horizon. That's safe because newer  
versions of the tuple will contain the locking xids.  
  
A followup commit will harden the code somewhat against future similar  
bugs and already corrupted data.  
  
Author: Andres Freund, with changes by Alvaro Herrera  
Reported-By: Daniel Wood  
Analyzed-By: Andres Freund, Alvaro Herrera, Robert Haas, Peter  
   Geoghegan, Daniel Wood, Yi Wen Wong, Michael Paquier  
Reviewed-By: Alvaro Herrera, Robert Haas, Michael Paquier  
Discussion:  
    https://postgr.es/m/[email protected]  
    https://postgr.es/m/[email protected]  
Backpatch: 9.3-  

commit   : c28e0b1e0ab951a434cc4774a82876628092f166    
  
author   : Andrew Dunstan <[email protected]>    
date     : Thu, 14 Dec 2017 11:31:13 -0500    
  
committer: Andrew Dunstan <[email protected]>    
date     : Thu, 14 Dec 2017 11:31:13 -0500    

The logical slots have a fast code path for sending data so as not to  
impose too high a per message overhead. The fast path skips checks for  
interrupts and timeouts. However, the existing coding failed to consider  
the fact that a transaction with a large number of changes may take a  
very long time to be processed and sent to the client. This causes the  
walsender to ignore interrupts for potentially a long time and more  
importantly it will result in the walsender being killed due to  
timeout at the end of such a transaction.  
  
This commit changes the fast path to also check for interrupts and only  
allows calling the fast path when the last keepalive check happened less  
than half the walsender timeout ago. Otherwise the slower code path will  
be taken.  
  
Backpatched to 9.4  
  
Petr Jelinek, reviewed by  Kyotaro HORIGUCHI, Yura Sokolov,  Craig  
Ringer and Robert Haas.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : c26d46ff6d6e10e8ac1ecf80f8cf9014e3efe418    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 11 Dec 2017 16:33:20 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 11 Dec 2017 16:33:20 -0500    

I noticed that _SPI_execute_plan initially sets spierrcontext.arg = NULL,  
and only fills it in some time later.  If an error were to happen in  
between, _SPI_error_callback would try to dereference the null pointer.  
This is unlikely --- there's not much between those points except  
push-snapshot calls --- but it's clearly not impossible.  Tweak the  
callback to do nothing if the pointer isn't set yet.  
  
It's been like this for awhile, so back-patch to all supported branches.  

commit   : 055532badd16b01f54951559139cb664c456cb8f    
  
author   : Noah Misch <[email protected]>    
date     : Sat, 9 Dec 2017 00:58:55 -0800    
  
committer: Noah Misch <[email protected]>    
date     : Sat, 9 Dec 2017 00:58:55 -0800    

Notably, this permits linking to the 32-bit Perl binaries advertised on  
perl.org, namely Strawberry Perl and ActivePerl.  This has a side effect  
of permitting linking to binaries built with obsolete MSVC versions.  
  
By default, MSVC 2012 and later require a "safe exception handler table"  
in each binary.  MinGW-built, 32-bit DLLs lack the relevant exception  
handler metadata, so linking to them failed with error LNK2026.  Restore  
the semantics of MSVC 2010, which omits the table from a given binary if  
some linker input lacks metadata.  This has no effect on 64-bit builds  
or on MSVC 2010 and earlier.  Back-patch to 9.3 (all supported  
versions).  
  
Reported by Victor Wagner.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 140fa2fbad94bab0290851e25acdd727c9f67cb9    
  
author   : Noah Misch <[email protected]>    
date     : Fri, 8 Dec 2017 18:06:05 -0800    
  
committer: Noah Misch <[email protected]>    
date     : Fri, 8 Dec 2017 18:06:05 -0800    

Commits 5a5c2feca3fd858e70ea348822595547e6fa6c15 and  
b5178c5d08ca59e30f9d9428fa6fdb2741794e65 introduced support for modern  
MSVC-built, 32-bit Perl, but they broke use of MinGW-built, 32-bit Perl  
distributions like Strawberry Perl and modern ActivePerl.  Perl has no  
robust means to report whether it expects a -D_USE_32BIT_TIME_T ABI, so  
test this.  Back-patch to 9.3 (all supported versions).  
  
The chief alternative was a heuristic of adding -D_USE_32BIT_TIME_T when  
$Config{gccversion} is nonempty.  That banks on every gcc-built Perl  
using the same ABI.  gcc could change its default ABI the way MSVC once  
did, and one could build Perl with gcc and the non-default ABI.  
  
The GNU make build system could benefit from a similar test, without  
which it does not support MSVC-built Perl.  For now, just add a comment.  
Most users taking the special step of building Perl with MSVC probably  
build PostgreSQL with MSVC.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : a59b3428efa79a699b87355eb859877f205fb33d    
  
author   : Noah Misch <[email protected]>    
date     : Fri, 8 Dec 2017 18:04:45 -0800    
  
committer: Noah Misch <[email protected]>    
date     : Fri, 8 Dec 2017 18:04:45 -0800    

This simplifies back-patch of the next change to v9.5 and v9.6.  

commit   : ba8cc0ad05b050471e50c8d20ea24466bade3ecc    
  
author   : Peter Eisentraut <[email protected]>    
date     : Fri, 8 Dec 2017 11:16:23 -0500    
  
committer: Peter Eisentraut <[email protected]>    
date     : Fri, 8 Dec 2017 11:16:23 -0500    

Reported-by: Masahiko Sawada <[email protected]>  

commit   : 2b1bf3fa32fbe8dc955cb064fbf1be7573556392    
  
author   : Peter Eisentraut <[email protected]>    
date     : Wed, 15 Feb 2017 10:44:07 -0500    
  
committer: Peter Eisentraut <[email protected]>    
date     : Wed, 15 Feb 2017 10:44:07 -0500    

Reviewed-by: Magnus Hagander <[email protected]>  

commit   : b75644066091784eedaf32511782de9176ccbdbd    
  
author   : Robert Haas <[email protected]>    
date     : Wed, 6 Dec 2017 08:49:30 -0500    
  
committer: Robert Haas <[email protected]>    
date     : Wed, 6 Dec 2017 08:49:30 -0500    

When a worker is flagged as BGW_NEVER_RESTART and we fail to start it,  
or if it is not marked BGW_NEVER_RESTART but is terminated before  
startup succeeds, what BgwHandleStatus should be reported?  The  
previous code really hadn't considered this possibility (as indicated  
by the comments which ignore it completely) and would typically return  
BGWH_NOT_YET_STARTED, but that's not a good answer, because then  
there's no way for code using GetBackgroundWorkerPid() to tell the  
difference between a worker that has not started but will start  
later and a worker that has not started and will never be started.  
So, when this case happens, return BGWH_STOPPED instead.  Update the  
comments to reflect this.  
  
The preceding fix by itself is insufficient to fix the problem,  
because the old code also didn't send a notification to the process  
identified in bgw_notify_pid when startup failed.  That might've  
been technically correct under the theory that the status of the  
worker was BGWH_NOT_YET_STARTED, because the status would indeed not  
change when the worker failed to start, but now that we're more  
usefully reporting BGWH_STOPPED, a notification is needed.  
  
Without these fixes, code which starts background workers and then  
uses the recommended APIs to wait for those background workers to  
start would hang indefinitely if the postmaster failed to fork a  
worker.  
  
Amit Kapila and Robert Haas  
  
Discussion: http://postgr.es/m/CAA4eK1KDfKkvrjxsKJi3WPyceVi3dH1VCkbTJji2fuwKuB=3uw@mail.gmail.com  

commit   : a4116c460299aea7760dc13bd45df5bb5382ed6a    
  
author   : Robert Haas <[email protected]>    
date     : Tue, 5 Dec 2017 09:24:12 -0500    
  
committer: Robert Haas <[email protected]>    
date     : Tue, 5 Dec 2017 09:24:12 -0500    

This makes life easier for extension authors who wish to support  
Windows.  
  
Brian Cloutier, slightly amended by me.  
  
Discussion: http://postgr.es/m/CAJCy68fscdNhmzFPS4kyO00CADkvXvEa-28H-OtENk-pa2OTWw@mail.gmail.com  

commit   : 543d8c2f5d4c6b290534f22cc570f51ef75214e5    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 4 Dec 2017 17:02:52 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 4 Dec 2017 17:02:52 -0500    

This patch fixes a couple of low-probability bugs that could lead to  
reporting an irrelevant errno value (and hence possibly a wrong SQLSTATE)  
concerning directory-open or file-open failures.  It also fixes places  
where we took shortcuts in reporting such errors, either by using elog  
instead of ereport or by using ereport but forgetting to specify an  
errcode.  And it eliminates a lot of just plain redundant error-handling  
code.  
  
In service of all this, export fd.c's formerly-static function  
ReadDirExtended, so that external callers can make use of the coding  
pattern  
  
	dir = AllocateDir(path);  
	while ((de = ReadDirExtended(dir, path, LOG)) != NULL)  
  
if they'd like to treat directory-open failures as mere LOG conditions  
rather than errors.  Also fix FreeDir to be a no-op if we reach it  
with dir == NULL, as such a coding pattern would cause.  
  
Then, remove code at many call sites that was throwing an error or log  
message for AllocateDir failure, as ReadDir or ReadDirExtended can handle  
that job just fine.  Aside from being a net code savings, this gets rid of  
a lot of not-quite-up-to-snuff reports, as mentioned above.  (In some  
places these changes result in replacing a custom error message such as  
"could not open tablespace directory" with more generic wording "could not  
open directory", but it was agreed that the custom wording buys little as  
long as we report the directory name.)  In some other call sites where we  
can't just remove code, change the error reports to be fully  
project-style-compliant.  
  
Also reorder code in restoreTwoPhaseData that was acquiring a lock  
between AllocateDir and ReadDir; in the unlikely but surely not  
impossible case that LWLockAcquire changes errno, AllocateDir failures  
would be misreported.  There is no great value in opening the directory  
before acquiring TwoPhaseStateLock, so just do it in the other order.  
  
Also fix CheckXLogRemoved to guarantee that it preserves errno,  
as quite a number of call sites are implicitly assuming.  (Again,  
it's unlikely but I think not impossible that errno could change  
during a SpinLockAcquire.  If so, this function was broken for its  
own purposes as well as breaking callers.)  
  
And change a few places that were using not-per-project-style messages,  
such as "could not read directory" when "could not open directory" is  
more correct.  
  
Back-patch the exporting of ReadDirExtended, in case we have occasion  
to back-patch some fix that makes use of it; it's not needed right now  
but surely making it global is pretty harmless.  Also back-patch the  
restoreTwoPhaseData and CheckXLogRemoved fixes.  The rest of this is  
essentially cosmetic and need not get back-patched.  
  
Michael Paquier, with a bit of additional work by me  
  
Discussion: https://postgr.es/m/CAB7nPqRpOCxjiirHmebEFhXVTK7V5Jvw4bz82p7Oimtsm3TyZA@mail.gmail.com  

commit   : c122002218fb46f5a5771bc45e9a9d631093e8ed    
  
author   : Noah Misch <[email protected]>    
date     : Thu, 30 Nov 2017 00:57:22 -0800    
  
committer: Noah Misch <[email protected]>    
date     : Thu, 30 Nov 2017 00:57:22 -0800    

Invoking the Makefile without an explicit target was building every  
possible target instead of just the "all" target.  Back-patch to 9.3  
(all supported versions).  

commit   : 06ba5309682e32c997e22563c3a9184fba5131d9    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 27 Nov 2017 17:53:56 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 27 Nov 2017 17:53:56 -0500    

rewriteTargetListUD's processing is dependent on the relkind of the query's  
target table.  That was fine at the time it was made to act that way, even  
for queries on inheritance trees, because all tables in an inheritance tree  
would necessarily be plain tables.  However, the 9.5 feature addition  
allowing some members of an inheritance tree to be foreign tables broke the  
assumption that rewriteTargetListUD's output tlist could be applied to all  
child tables with nothing more than column-number mapping.  This led to  
visible failures if foreign child tables had row-level triggers, and would  
also break in cases where child tables belonged to FDWs that used methods  
other than CTID for row identification.  
  
To fix, delay running rewriteTargetListUD until after the planner has  
expanded inheritance, so that it is applied separately to the (already  
mapped) tlist for each child table.  We can conveniently call it from  
preprocess_targetlist.  Refactor associated code slightly to avoid the  
need to heap_open the target relation multiple times during  
preprocess_targetlist.  (The APIs remain a bit ugly, particularly around  
the point of which steps scribble on parse->targetList and which don't.  
But avoiding such scribbling would require a change in FDW callback APIs,  
which is more pain than it's worth.)  
  
Also fix ExecModifyTable to ensure that "tupleid" is reset to NULL when  
we transition from rows providing a CTID to rows that don't.  (That's  
really an independent bug, but it manifests in much the same cases.)  
  
Add a regression test checking one manifestation of this problem, which  
was that row-level triggers on a foreign child table did not work right.  
  
Back-patch to 9.5 where the problem was introduced.  
  
Etsuro Fujita, reviewed by Ildus Kurbangaliev and Ashutosh Bapat  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 510cc2e048f800e1764a6d6cbcf8fff4e3bda1fd    
  
author   : Magnus Hagander <[email protected]>    
date     : Mon, 27 Nov 2017 09:24:14 +0100    
  
committer: Magnus Hagander <[email protected]>    
date     : Mon, 27 Nov 2017 09:24:14 +0100    

Andreas Karlsson  

commit   : 9773f0527ffed36fabe6b72130fe9e9dbad9605b    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 26 Nov 2017 15:17:25 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 26 Nov 2017 15:17:25 -0500    

Originally, we palloc'd this buffer just barely big enough to hold the  
largest xlog record seen so far.  It turns out that that can result in  
valgrind complaints, because some compilers will emit code that assumes  
it can safely fetch padding bytes at the end of a struct, and those  
padding bytes were unallocated so far as aset.c was concerned.  We can  
fix that by MAXALIGN'ing the palloc request size, ensuring that it is big  
enough to include any possible padding that might've been omitted from  
the on-disk record.  
  
An additional objection to the original coding is that it could result in  
many repeated palloc cycles, in the worst case where we see a series of  
gradually larger xlog records.  We can ameliorate that cheaply by  
imposing a minimum buffer size that's large enough for most xlog records.  
BLCKSZ/2 was chosen after a bit of discussion.  
  
In passing, remove an obsolete comment in struct xl_heap_new_cid that the  
combocid field is free due to alignment considerations.  Perhaps that was  
true at some point, but it's not now.  
  
Back-patch to 9.5 where this code came in.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 997015ef231ac4b5aac6a2437e5fa8eaac253fbb    
  
author   : Joe Conway <[email protected]>    
date     : Sun, 26 Nov 2017 09:50:15 -0800    
  
committer: Joe Conway <[email protected]>    
date     : Sun, 26 Nov 2017 09:50:15 -0800    

The various has_*_privilege() functions all support an optional  
WITH GRANT OPTION added to the supported privilege types to test  
whether the privilege is held with grant option. That is, all except  
has_sequence_privilege() variations. Fix that.  
  
Back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : cd3bde814612ffebe11a754116a70010ae195784    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 25 Nov 2017 18:15:23 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 25 Nov 2017 18:15:23 -0500    

Missed this dependency in commits 7cce222c9 et al.  

commit   : 0a7e951810459c300ef403c6b891be20e4715388    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 25 Nov 2017 15:30:11 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 25 Nov 2017 15:30:11 -0500    

Traditionally IANA has distributed their timezone data in pure source  
form, replete with extensive historical comments.  As of release 2017c,  
they've added a compact single-file format that omits comments and  
abbreviates command keywords.  This form is way shorter than the pure  
source, even before considering its allegedly better compressibility.  
Hence, let's distribute the data in that form rather than pure source.  
  
I'm pushing this now, rather than at the next timezone database update,  
so that it's easy to confirm that this data file produces compiled zic  
output that's identical to what we were getting before.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 630aceda5be79551b6772ab230fddfc4edbb63eb    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 25 Nov 2017 14:42:10 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 25 Nov 2017 14:42:10 -0500    

hstoreUniquePairs() often called memcpy with equal source and destination  
pointers.  Although this is almost surely harmless in practice, it's  
undefined according to the letter of the C standard.  Some versions of  
valgrind will complain about it, and some versions of libc as well  
(cf. commit ad520ec4a).  Tweak the code to avoid doing that.  
  
Noted by Tomas Vondra.  Back-patch to all supported versions because  
of the hazard of libc assertions.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 497e79b96135ba6d37cf6b321ad485a2474cb053    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 25 Nov 2017 14:15:48 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 25 Nov 2017 14:15:48 -0500    

When nodeValuesscan.c was written, it was impossible to have a SubPlan in  
VALUES --- any sub-SELECT there would have to be uncorrelated and thereby  
would produce an InitPlan instead.  We therefore took a shortcut in the  
logic that throws away a ValuesScan's per-row expression evaluation data  
structures.  This was broken by the introduction of LATERAL however; a  
sub-SELECT containing a lateral reference produces a correlated SubPlan.  
  
The cleanest fix for this would be to give up the optimization of  
discarding the expression eval state.  But that still seems pretty  
unappetizing for long VALUES lists.  It seems to work to just prevent  
the subexpressions from hooking into the ValuesScan node's subPlan  
list, so let's do that and see how well it works.  (If this breaks,  
due to additional connections between the subexpressions and the outer  
query structures, we might consider compromises like throwing away data  
only for VALUES rows not containing SubPlans.)  
  
Per bug #14924 from Christian Duta.  Back-patch to 9.3 where LATERAL  
was introduced.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : df2361c5a0dbde431781be2dcdf961ca30ab8ce5    
  
author   : Dean Rasheed <[email protected]>    
date     : Fri, 24 Nov 2017 12:00:00 +0000    
  
committer: Dean Rasheed <[email protected]>    
date     : Fri, 24 Nov 2017 12:00:00 +0000    

This table summarizes which RLS policy expressions apply to each  
command type, and whether they apply to the old or new tuples (or  
both), which saves reading through a lot of text.  
  
Rod Taylor, hacked on by me. Reviewed by Fabien Coelho.  
  
Discussion: https://postgr.es/m/CAHz80e4HxJShm6m9ZWFrHW=pgd2KP=RZmfFnEccujtPMiAOW5Q@mail.gmail.com  

commit   : fa39617a64d4134c63b3f62ae12b0268542a79e5    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 24 Nov 2017 00:29:20 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 24 Nov 2017 00:29:20 -0500    

The query didn't really have a preferred index, leading to platform-  
specific choices of which one to use.  Adjust it to make sure tenk1_hundred  
is always chosen.  
  
Per buildfarm.  

commit   : 1695ce06860440103afb90f1ca10b0f4958da457    
  
author   : Noah Misch <[email protected]>    
date     : Thu, 23 Nov 2017 20:22:04 -0800    
  
committer: Noah Misch <[email protected]>    
date     : Thu, 23 Nov 2017 20:22:04 -0800    

This is necessary for ActivePerl 5.18 onwards and for Strawberry Perl.  
It is not sufficient for 32-bit builds with newer Visual Studio; these  
fail with error LINK2026.  Back-patch to 9.3 (all supported versions).  
  
Reported by Victor Wagner.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : c253b722f616d15c0b45c729465b4b85849cbcda    
  
author   : Andres Freund <[email protected]>    
date     : Thu, 23 Nov 2017 17:14:43 -0800    
  
committer: Andres Freund <[email protected]>    
date     : Thu, 23 Nov 2017 17:14:43 -0800    

When strict aggregate combine functions, used in multi-stage/parallel  
aggregation, returned NULL, we didn't check for that, invoking the  
combine function with NULL the next round, despite it being strict.  
  
The equivalent code invoking normal transition functions has a check  
for that situation, which did not get copied in a7de3dc5c346. Fix the  
bug by adding the equivalent check.  
  
Based on a quick look I could not find any strict combine functions in  
core actually returning NULL, and it doesn't seem very likely external  
users have done so. So this isn't likely to have caused issues in  
practice.  
  
Add tests verifying transition / combine functions returning NULL is  
tested.  
  
Reported-By: Andres Freund  
Author: Andres Freund  
Discussion: https://postgr.es/m/[email protected]  
Backpatch: 9.6, where parallel aggregation was introduced  

commit   : 7c84bc0b3d709f59720fa913b0d5997754d2691f    
  
author   : Robert Haas <[email protected]>    
date     : Tue, 21 Nov 2017 13:56:24 -0500    
  
committer: Robert Haas <[email protected]>    
date     : Tue, 21 Nov 2017 13:56:24 -0500    

Previously, any attempt to request a 3.x protocol version other than  
3.0 would lead to a hard connection failure, which made the minor  
protocol version really no different from the major protocol version  
and precluded gentle protocol version breaks.  Instead, when the  
client requests a 3.x protocol version where x is greater than 0, send  
the new NegotiateProtocolVersion message to convey that we support  
only 3.0.  This makes it possible to introduce new minor protocol  
versions without requiring a connection retry when the server is  
older.  
  
In addition, if the startup packet includes name/value pairs where  
the name starts with "_pq_.", assume that those are protocol options,  
not GUCs.  Include those we don't support (i.e. all of them, at  
present) in the NegotiateProtocolVersion message so that the client  
knows they were not understood.  This makes it possible for the  
client to request previously-unsupported features without bumping  
the protocol version at all; the client can tell from the server's  
response whether the option was understood.  
  
It will take some time before servers that support these new  
facilities become common in the wild; to speed things up and make  
things easier for a future 3.1 protocol version, back-patch to all  
supported releases.  
  
Robert Haas and Badrul Chowdhury  
  
Discussion: http://postgr.es/m/BN6PR21MB0772FFA0CBD298B76017744CD1730@BN6PR21MB0772.namprd21.prod.outlook.com  
Discussion: http://postgr.es/m/[email protected]  

commit   : fa9a69d3db69b3d65254987b43acf1ca977504c8    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 20 Nov 2017 18:05:02 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 20 Nov 2017 18:05:02 -0500    

David Carlier (from a patch being carried by OpenBSD packagers)  
  
Discussion: https://postgr.es/m/CA+XhMqzwFSGVU7MEnfhCecc8YdP98tigXzzpd0AAdwaGwaVXEA@mail.gmail.com  

commit   : 940bafa75a0417128279095673a22d6d9b9e8413    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 20 Nov 2017 17:57:46 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 20 Nov 2017 17:57:46 -0500    

Apparently there are still people out there who care about this old  
architecture.  They probably care about dusty versions of Postgres  
too, so back-patch to all supported branches.  
  
David Carlier (from a patch being carried by OpenBSD packagers)  
  
Discussion: https://postgr.es/m/CA+XhMqzwFSGVU7MEnfhCecc8YdP98tigXzzpd0AAdwaGwaVXEA@mail.gmail.com  

commit   : a96e2252833542ab8f79eb27a23941ab8cf0d7d1    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 18 Nov 2017 16:46:30 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 18 Nov 2017 16:46:30 -0500    

On gcc 7.2.0, comparing pointer to (Datum) 0 produces a warning.  
Treat it as a simple pointer to avoid that; this is more consistent  
with comparable code elsewhere, anyway.  
  
Tomas Vondra  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 0d9243903edc6940e44995c0d8d0956ad605d265    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 17 Nov 2017 12:46:52 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 17 Nov 2017 12:46:52 -0500    

The scripts in contrib/start-scripts/osx don't work at all on macOS  
10.10 (Yosemite) or later, because they depend on SystemStarter which  
Apple deprecated long ago and removed in 10.10.  Add a new subdirectory  
contrib/start-scripts/macos with scripts that use the newer launchd  
infrastructure.  
  
Since this problem is independent of which Postgres version you're using,  
back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 19648ce553360852ef6a3bd32019d969144e32b6    
  
author   : Robert Haas <[email protected]>    
date     : Thu, 16 Nov 2017 14:19:27 -0500    
  
committer: Robert Haas <[email protected]>    
date     : Thu, 16 Nov 2017 14:19:27 -0500    

The pending list must (for correctness) always be cleaned up by vacuum, and  
should (for the avoidance of surprising behavior) always be cleaned up  
by an explicit call to gin_clean_pending_list, but cleanup is optional  
when inserting.  The old logic got this backward: cleanup was forced  
if (stats == NULL), but that's going to be *false* when vacuuming and  
*true* for inserts.  
  
Masahiko Sawada, reviewed by me.  
  
Discussion: http://postgr.es/m/CAD21AoBLUSyiYKnTYtSAbC+F=XDjiaBrOUEGK+zUXdQ8owfPKw@mail.gmail.com  

commit   : 4a15f87d22773ba208c441142ac53ddeb090d1b8    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 14 Nov 2017 17:49:49 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 14 Nov 2017 17:49:49 -0500    

Our initial work with int128 neglected alignment considerations, an  
oversight that came back to bite us in bug #14897 from Vincent Lachenal.  
It is unsurprising that int128 might have a 16-byte alignment requirement;  
what's slightly more surprising is that even notoriously lax Intel chips  
sometimes enforce that.  
  
Raising MAXALIGN seems out of the question: the costs in wasted disk and  
memory space would be significant, and there would also be an on-disk  
compatibility break.  Nor does it seem very practical to try to allow some  
data structures to have more-than-MAXALIGN alignment requirement, as we'd  
have to push knowledge of that throughout various code that copies data  
structures around.  
  
The only way out of the box is to make type int128 conform to the system's  
alignment assumptions.  Fortunately, gcc supports that via its  
__attribute__(aligned()) pragma; and since we don't currently support  
int128 on non-gcc-workalike compilers, we shouldn't be losing any platform  
support this way.  
  
Although we could have just done pg_attribute_aligned(MAXIMUM_ALIGNOF) and  
called it a day, I did a little bit of extra work to make the code more  
portable than that: it will also support int128 on compilers without  
__attribute__(aligned()), if the native alignment of their 128-bit-int  
type is no more than that of int64.  
  
Add a regression test case that exercises the one known instance of the  
problem, in parallel aggregation over a bigint column.  
  
Back-patch of commit 751804998.  The code known to be affected only exists  
in 9.6 and later, but we do have some stuff using int128 in 9.5, so patch  
back to 9.5.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 6c35b3aa465e9afd859df5ad3b3e493e8e47c40e    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 14 Nov 2017 17:22:42 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 14 Nov 2017 17:22:42 -0500    

Generalize section 1 to handle stuff that is principally about the  
compiler (not libraries), such as attributes, and collect stuff there  
that had been dropped into various other parts of c.h.  Also, push  
all the gettext macros into section 8, so that section 0 is really  
just inclusions rather than inclusions and random other stuff.  
  
The primary goal here is to get pg_attribute_aligned() defined before  
section 3, so that we can use it with int128.  But this seems like good  
cleanup anyway.  
  
This patch just moves macro definitions around, and shouldn't result  
in any changes in generated code.  
  
Back-patch of commit 91aec93e6.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : ad083e4ede522548045989995b36f3fe2d16a984    
  
author   : Noah Misch <[email protected]>    
date     : Sun, 12 Nov 2017 18:43:32 -0800    
  
committer: Noah Misch <[email protected]>    
date     : Sun, 12 Nov 2017 18:43:32 -0800    

Also, add a warning to catch future instances of naming a nonexistent  
file as a prerequisite.  Back-patch to 9.3 (all supported versions).  

commit   : 8c92e66f1a168fdb0862b8d96db4fe0353effc9d    
  
author   : Noah Misch <[email protected]>    
date     : Sun, 12 Nov 2017 14:31:00 -0800    
  
committer: Noah Misch <[email protected]>    
date     : Sun, 12 Nov 2017 14:31:00 -0800    

Apart from calling write_stderr() on failure, the handler depends on no  
PostgreSQL facilities.  We have experienced crashes before reaching the  
former call site.  Given such an early crash, this change cannot hurt  
and may produce a helpful dump.  Absent an early crash, this change has  
no effect.  Back-patch to 9.3 (all supported versions).  
  
Takayuki Tsunakawa  
  
Discussion: https://postgr.es/m/0A3221C70F24FB45833433255569204D1F80CD13@G01JPEXMBYT05  

commit   : fd5da32fc62f96952a54696f8ab2ce913fe19bc0    
  
author   : Noah Misch <[email protected]>    
date     : Sun, 12 Nov 2017 13:03:15 -0800    
  
committer: Noah Misch <[email protected]>    
date     : Sun, 12 Nov 2017 13:03:15 -0800    

PostgreSQL running as a Windows service crashed upon calling  
write_stderr() before MemoryContextInit().  This fix completes work  
started in 5735efee15540765315aa8c1a230575e756037f7.  Messages this  
early contain only ASCII bytes; if we removed the CurrentMemoryContext  
requirement, the ensuing conversions would have no effect.  Back-patch  
to 9.3 (all supported versions).  
  
Takayuki Tsunakawa, reviewed by Michael Paquier.  
  
Discussion: https://postgr.es/m/0A3221C70F24FB45833433255569204D1F80CC73@G01JPEXMBYT05  

commit   : 1f44160eb720c2bb0fd9f9cafa784c2d53e95a44    
  
author   : Noah Misch <[email protected]>    
date     : Sat, 11 Nov 2017 14:39:06 -0800    
  
committer: Noah Misch <[email protected]>    
date     : Sat, 11 Nov 2017 14:39:06 -0800    

This suite had been a proper superset of the regular ecpg test suite,  
but the three newest tests didn't reach it.  To make this less likely to  
recur, delete the extra schedule file and pass the TCP-specific test on  
the command line.  Back-patch to 9.3 (all supported versions).  

commit   : 3c80348d24914d9ddf65d56d2c343a7f2b820705    
  
author   : Noah Misch <[email protected]>    
date     : Sat, 11 Nov 2017 14:33:02 -0800    
  
committer: Noah Misch <[email protected]>    
date     : Sat, 11 Nov 2017 14:33:02 -0800    

Since commit 868898739a8da9ab74c105b8349b7b5c711f265a, it has assumed  
"localhost" resolves to both ::1 and 127.0.0.1.  We gain nothing from  
that assumption, and it does not hold in a default installation of Red  
Hat Enterprise Linux 5.  Back-patch to 9.3 (all supported versions).  

commit   : 742471ef978c95443c8fd96118360d88b57a30fc    
  
author   : Noah Misch <[email protected]>    
date     : Sat, 11 Nov 2017 13:07:46 -0800    
  
committer: Noah Misch <[email protected]>    
date     : Sat, 11 Nov 2017 13:07:46 -0800    

To ensure stable output, catch one more configuration-specific error.  
Back-patch to 9.3, like the commit that added the test.  

commit   : 46fb15f48a2d76beccf8d422f699373b60e954f6    
  
author   : Noah Misch <[email protected]>    
date     : Sat, 11 Nov 2017 11:10:53 -0800    
  
committer: Noah Misch <[email protected]>    
date     : Sat, 11 Nov 2017 11:10:53 -0800    

When a value contained an XML declaration naming some other encoding,  
this function interpreted UTF8 bytes as the named encoding, yielding  
mojibake.  xml_parse() already has similar logic.  This would be  
necessary but not sufficient for non-UTF8 databases, so preserve  
behavior there until the xpath facility can support such databases  
comprehensively.  Back-patch to 9.3 (all supported versions).  
  
Pavel Stehule and Noah Misch  
  
Discussion: https://postgr.es/m/CAFj8pRC-dM=tT=QkGi+Achkm+gwPmjyOayGuUfXVumCxkDgYWg@mail.gmail.com  

commit   : d380d080fa0ad230d86bc5e4bc3512a199f68e43    
  
author   : Peter Eisentraut <[email protected]>    
date     : Fri, 10 Nov 2017 14:21:32 -0500    
  
committer: Peter Eisentraut <[email protected]>    
date     : Fri, 10 Nov 2017 14:21:32 -0500    

An LDAP URL without a host name such as "ldap://" or without a base DN  
such as "ldap://localhost" would cause a crash when reading pg_hba.conf.  
  
If no binddn is configured, an error message might end up trying to print a  
null pointer, which could crash on some platforms.  
  
Author: Thomas Munro <[email protected]>  
Reviewed-by: Michael Paquier <[email protected]>  

commit   : 859662c26cf9eac8bfa50a83913523606bdf3e28    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 10 Nov 2017 12:30:01 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 10 Nov 2017 12:30:01 -0500    

Make bloom WAL test compare psql output text, not just result codes;  
this was evidently the intent all along, but it was mis-coded.  
In passing, make sure we will notice any failure in setup steps.  
  
Alexander Korotkov, reviewed by Michael Paquier and Masahiko Sawada  
  
Discussion: https://postgr.es/m/CAPpHfdtohPdQ9rc5mdWjxq+3VsBNw534KV_5O65dTQrSdVJNgw@mail.gmail.com  

commit   : 0abc7cdb875e63ff110f292eb666078d7abd1e90    
  
author   : Peter Eisentraut <[email protected]>    
date     : Thu, 9 Nov 2017 17:06:32 -0500    
  
committer: Peter Eisentraut <[email protected]>    
date     : Thu, 9 Nov 2017 17:06:32 -0500    

This causes a warning when accidentally backpatching an XML-style  
empty-element tag like <xref linkend="abc"/>.  

commit   : 3c966ce65317e8c72f4368b98dd19e753a9eae73    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 9 Nov 2017 11:57:20 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 9 Nov 2017 11:57:20 -0500    

The header comment written into postgresql.auto.conf by ALTER SYSTEM  
should match what initdb put there originally.  
  
Feike Steenbergen  
  
Discussion: https://postgr.es/m/CAK_s-G0KcKdO=0hqZkwb3s+tqZuuHwWqmF5BDsmoO9FtX75r0g@mail.gmail.com  

commit   : 28d177e3f95e3aef72f53e9e55096b350d1d5d9b    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 9 Nov 2017 11:00:36 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 9 Nov 2017 11:00:36 -0500    

Upon further review, our Bonjour code doesn't actually work with the  
Avahi not-too-compatible compatibility library.  While you can get it  
to work on non-macOS platforms if you link to Apple's own mDNSResponder  
code, there don't seem to be many people who care about that.  Leaving in  
the AC_SEARCH_LIBS call seems more likely to encourage people to build  
broken configurations than to do anything very useful.  
  
Hence, remove the AC_SEARCH_LIBS call and put in a warning comment instead.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 08d440b5cb223f76723a955594b7b8fa555edfe3    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 8 Nov 2017 17:47:14 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 8 Nov 2017 17:47:14 -0500    

On macOS the relevant functions require no special library, but elsewhere  
we need to pull in libdns_sd.  
  
Back-patch to supported branches.  No docs change since the docs do not  
suggest that this is a Mac-only feature.  
  
Luke Lonergan  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : b89ad383da7dfcf1c5888076d60bb914c6169ec6    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 8 Nov 2017 16:50:13 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 8 Nov 2017 16:50:13 -0500    

The point of having separate ResourceOwnerEnlargeFoo and  
ResourceOwnerRememberFoo functions is so that resource allocation  
can happen in between.  Doing it in some other order is just wrong.  
  
OpenTemporaryFile() did open(), enlarge, remember, which would leak the  
open file if the enlarge step ran out of memory.  Because fd.c has its own  
layer of resource-remembering, the consequences look like they'd be limited  
to an intratransaction FD leak, but it's still not good.  
  
IncrBufferRefCount() did enlarge, remember, incr-refcount, which would blow  
up if the incr-refcount step ever failed.  It was safe enough when written,  
but since the introduction of PrivateRefCountHash, I think the assumption  
that no error could happen there is pretty shaky.  
  
The odds of real problems from either bug are probably small, but still,  
back-patch to supported branches.  
  
Thomas Munro and Tom Lane, per a comment from Andres Freund  

commit   : 1a93c2536a75e7759420e8f9a95e2076da9135df    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 7 Nov 2017 13:49:36 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 7 Nov 2017 13:49:36 -0500    

isdigit(), isspace(), etc are likely to give surprising results if passed a  
signed char.  We should always cast the argument to unsigned char to avoid  
that.  Error in commit 63d6b97fd, found by buildfarm member gaur.  
Back-patch to 9.3, like that commit.