PostgreSQL 9.6.3 commit log

Stamp 9.6.3.

commit   : ca9cfed883333d5801716eb01cf28b6b5be2b5cd    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 8 May 2017 17:15:12 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 8 May 2017 17:15:12 -0400    

Click here for diff

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

Further patch rangetypes_selfuncs.c's statistics slot management.

commit   : 935e77d527a018b652f247c7374c558871210db6    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 8 May 2017 15:02:57 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 8 May 2017 15:02:57 -0400    

Click here for diff

Values in a STATISTIC_KIND_RANGE_LENGTH_HISTOGRAM slot are float8,  
not of the type of the column the statistics are for.  
  
This bug is at least partly the fault of sloppy specification comments  
for get_attstatsslot()/free_attstatsslot(): the type OID they want is that  
of the stavalues entries, not of the underlying column.  (I double-checked  
other callers and they seem to get this right.)  Adjust the comments to be  
more correct.  
  
Per buildfarm.  
  
Security: CVE-2017-7484  

M src/backend/utils/adt/rangetypes_selfuncs.c
M src/backend/utils/cache/lsyscache.c
M src/include/catalog/pg_statistic.h

Last-minute updates for release notes.

commit   : 2d5e7b4a912d55d90c01732d318b94e4ae47027b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 8 May 2017 12:57:27 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 8 May 2017 12:57:27 -0400    

Click here for diff

Security: CVE-2017-7484, CVE-2017-7485, CVE-2017-7486  

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

Fix possibly-uninitialized variable.

commit   : cad15943225adbcadea51602b38b04d71d1183d2    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 8 May 2017 11:18:40 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 8 May 2017 11:18:40 -0400    

Click here for diff

Oversight in e2d4ef8de et al (my fault not Peter's).  Per buildfarm.  
  
Security: CVE-2017-7484  

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

Match pg_user_mappings limits to information_schema.user_mapping_options.

commit   : c928addfccd7f9905472dddd94e9cd10bc3f6808    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Mon, 8 May 2017 07:24:24 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 8 May 2017 07:24:24 -0700    

Click here for diff

Both views replace the umoptions field with NULL when the user does not  
meet qualifications to see it.  They used different qualifications, and  
pg_user_mappings documented qualifications did not match its implemented  
qualifications.  Make its documentation and implementation match those  
of user_mapping_options.  One might argue for stronger qualifications,  
but these have long, documented tenure.  pg_user_mappings has always  
exhibited this problem, so back-patch to 9.2 (all supported versions).  
  
Michael Paquier and Feike Steenbergen.  Reviewed by Jeff Janes.  
Reported by Andrew Wheelwright.  
  
Security: CVE-2017-7486  

M doc/src/sgml/catalogs.sgml
M src/backend/catalog/system_views.sql
M src/test/regress/expected/foreign_data.out
M src/test/regress/expected/rules.out
M src/test/regress/sql/foreign_data.sql

Restore PGREQUIRESSL recognition in libpq.

commit   : aafbd1df969135c185947c596c46608fc9f4a67c    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Mon, 8 May 2017 07:24:24 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 8 May 2017 07:24:24 -0700    

Click here for diff

Commit 65c3bf19fd3e1f6a591618e92eb4c54d0b217564 moved handling of the,  
already then, deprecated requiressl parameter into conninfo_storeval().  
The default PGREQUIRESSL environment variable was however lost in the  
change resulting in a potentially silent accept of a non-SSL connection  
even when set.  Its documentation remained.  Restore its implementation.  
Also amend the documentation to mark PGREQUIRESSL as deprecated for  
those not following the link to requiressl.  Back-patch to 9.3, where  
commit 65c3bf1 first appeared.  
  
Behavior has been more complex when the user provides both deprecated  
and non-deprecated settings.  Before commit 65c3bf1, libpq operated  
according to the first of these found:  
  
  requiressl=1  
  PGREQUIRESSL=1  
  sslmode=*  
  PGSSLMODE=*  
  
(Note requiressl=0 didn't override sslmode=*; it would only suppress  
PGREQUIRESSL=1 or a previous requiressl=1.  PGREQUIRESSL=0 had no effect  
whatsoever.)  Starting with commit 65c3bf1, libpq ignored PGREQUIRESSL,  
and order of precedence changed to this:  
  
  last of requiressl=* or sslmode=*  
  PGSSLMODE=*  
  
Starting now, adopt the following order of precedence:  
  
  last of requiressl=* or sslmode=*  
  PGSSLMODE=*  
  PGREQUIRESSL=1  
  
This retains the 65c3bf1 behavior for connection strings that contain  
both requiressl=* and sslmode=*.  It retains the 65c3bf1 change that  
either connection string option overrides both environment variables.  
For the first time, PGSSLMODE has precedence over PGREQUIRESSL; this  
avoids reducing security of "PGREQUIRESSL=1 PGSSLMODE=verify-full"  
configurations originating under v9.3 and later.  
  
Daniel Gustafsson  
  
Security: CVE-2017-7485  

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

Translation updates

commit   : 0294ac2a5df1ef6e8685fc0b653db5aa21860db4    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 8 May 2017 10:10:54 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 8 May 2017 10:10:54 -0400    

Click here for diff

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

M src/backend/po/fr.po
M src/backend/po/it.po
M src/backend/po/ko.po
M src/backend/po/ru.po
M src/bin/initdb/po/it.po
M src/bin/pg_basebackup/po/de.po
M src/bin/pg_basebackup/po/ja.po
M src/bin/pg_config/po/it.po
M src/bin/pg_config/po/ja.po
M src/bin/pg_controldata/po/it.po
M src/bin/pg_controldata/po/ja.po
M src/bin/pg_controldata/po/ru.po
M src/bin/pg_ctl/po/ja.po
M src/bin/pg_dump/po/fr.po
M src/bin/pg_dump/po/it.po
M src/bin/pg_dump/po/ja.po
M src/bin/pg_dump/po/ru.po
M src/bin/pg_resetxlog/po/ja.po
M src/bin/pg_resetxlog/po/ru.po
M src/bin/pg_rewind/po/it.po
M src/bin/pg_rewind/po/ja.po
M src/bin/psql/po/it.po
M src/bin/psql/po/ja.po
M src/bin/scripts/po/ja.po
M src/interfaces/ecpg/preproc/po/it.po
M src/interfaces/ecpg/preproc/po/ja.po
M src/interfaces/libpq/po/de.po
M src/interfaces/libpq/po/it.po
M src/interfaces/libpq/po/ja.po
M src/pl/plperl/po/ja.po
M src/pl/plpgsql/src/po/ja.po
M src/pl/plpython/po/fr.po
M src/pl/plpython/po/it.po
M src/pl/plpython/po/ja.po
M src/pl/plpython/po/ru.po

Add security checks to selectivity estimation functions

commit   : c33c42362256382ed398df9dcda559cd547c68a7    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 5 May 2017 12:18:48 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 5 May 2017 12:18:48 -0400    

Click here for diff

Some selectivity estimation functions run user-supplied operators over  
data obtained from pg_statistic without security checks, which allows  
those operators to leak pg_statistic data without having privileges on  
the underlying tables.  Fix by checking that one of the following is  
satisfied: (1) the user has table or column privileges on the table  
underlying the pg_statistic data, or (2) the function implementing the  
user-supplied operator is leak-proof.  If neither is satisfied, planning  
will proceed as if there are no statistics available.  
  
At least one of these is satisfied in most cases in practice.  The only  
situations that are negatively impacted are user-defined or  
not-leak-proof operators on a security-barrier view.  
  
Reported-by: Robert Haas <robertmhaas@gmail.com>  
Author: Peter Eisentraut <peter_e@gmx.net>  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
  
Security: CVE-2017-7484  

M doc/src/sgml/planstats.sgml
M src/backend/utils/adt/array_selfuncs.c
M src/backend/utils/adt/rangetypes_selfuncs.c
M src/backend/utils/adt/selfuncs.c
M src/include/utils/selfuncs.h
M src/test/regress/expected/privileges.out
M src/test/regress/sql/privileges.sql

Release notes for 9.6.3, 9.5.7, 9.4.12, 9.3.17, 9.2.21.

commit   : 3178f467c81823954f76603a03ad3edb7f54f588    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 7 May 2017 16:56:02 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 7 May 2017 16:56:02 -0400    

Click here for diff

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

Guard against null t->tm_zone in strftime.c.

commit   : fab2d0d7f45a5cdf0d63cf27c161f966e89ddc9e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 7 May 2017 12:33:12 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 7 May 2017 12:33:12 -0400    

Click here for diff

The upstream IANA code does not guard against null TM_ZONE pointers in this  
function, but in our code there is such a check in the other pre-existing  
use of t->tm_zone.  We do have some places that set pg_tm.tm_zone to NULL.  
I'm not entirely sure it's possible to reach strftime with such a value,  
but I'm not sure it isn't either, so be safe.  
  
Per Coverity complaint.  

M src/timezone/strftime.c

commit   : f754728170b7bd4624902bf0129a1c88f910ac3c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 7 May 2017 11:57:41 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 7 May 2017 11:57:41 -0400    

Click here for diff

Somehow, we'd missed ever doing this.  The consequences aren't too  
severe: basically, the timezone library would fall back on its hardwired  
notion of the DST transition dates to use for a POSIX-style zone name,  
rather than obeying US/Eastern which is the intended behavior.  The net  
effect would only be to obey current US DST law further back than it  
ought to apply; so it's not real surprising that nobody noticed.  
  
David Rowley, per report from Amit Kapila  
  
Discussion: https://postgr.es/m/CAA4eK1LC7CaNhRAQ__C3ht1JVrPzaAXXhEJRnR5L6bfYHiLmWw@mail.gmail.com  

M src/tools/msvc/Install.pm

Restore fullname[] contents before falling through in pg_open_tzfile().

commit   : 5042e9492b17f6f4029bb1aca7c1c0b8247c8c95    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 7 May 2017 11:34:31 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 7 May 2017 11:34:31 -0400    

Click here for diff

Fix oversight in commit af2c5aa88: if the shortcut open() doesn't work,  
we need to reset fullname[] to be just the name of the toplevel tzdata  
directory before we fall through into the pre-existing code.  This failed  
to be exposed in my (tgl's) testing because the fall-through path is  
actually never taken under normal circumstances.  
  
David Rowley, per report from Amit Kapila  
  
Discussion: https://postgr.es/m/CAA4eK1LC7CaNhRAQ__C3ht1JVrPzaAXXhEJRnR5L6bfYHiLmWw@mail.gmail.com  

M src/timezone/pgtz.c

pg_dump: Don't leak memory in buildDefaultACLCommands()

commit   : ef42c1103708cbbb77fff674f339d452a13aac14    
  
author   : Stephen Frost <sfrost@snowman.net>    
date     : Sat, 6 May 2017 22:58:22 -0400    
  
committer: Stephen Frost <sfrost@snowman.net>    
date     : Sat, 6 May 2017 22:58:22 -0400    

Click here for diff

buildDefaultACLCommands() didn't destroy the string buffer created in  
certain cases, leading to a memory leak.  Fix by destroying the buffer  
before returning from the function.  
  
Spotted by Coverity.  
  
Author: Michael Paquier  
  
Back-patch to 9.6 where buildDefaultACLCommands() was added.  

M src/bin/pg_dump/dumputils.c

RLS: Fix ALL vs. SELECT+UPDATE policy usage

commit   : 92b15224b4eac8eeae0616491ccf0c852fa2dff9    
  
author   : Stephen Frost <sfrost@snowman.net>    
date     : Sat, 6 May 2017 21:46:41 -0400    
  
committer: Stephen Frost <sfrost@snowman.net>    
date     : Sat, 6 May 2017 21:46:41 -0400    

Click here for diff

When we add the SELECT-privilege based policies to the RLS with check  
options (such as for an UPDATE statement, or when we have INSERT ...  
RETURNING), we need to be sure and use the 'USING' case if the policy is  
actually an 'ALL' policy (which could have both a USING clause and an  
independent WITH CHECK clause).  
  
This could result in policies acting differently when built using ALL  
(when the ALL had both USING and WITH CHECK clauses) and when building  
the policies independently as SELECT and UPDATE policies.  
  
Fix this by adding an explicit boolean to add_with_check_options() to  
indicate when the USING policy should be used, even if the policy has  
both USING and WITH CHECK policies on it.  
  
Reported by: Rod Taylor  
  
Back-patch to 9.5 where RLS was introduced.  

M src/backend/rewrite/rowsecurity.c

Document current_role.

commit   : a24a1a2ec44d71cf43bdafc2c17db370cd1908ea    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 6 May 2017 14:19:47 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 6 May 2017 14:19:47 -0400    

Click here for diff

This system function has been there a very long time, but somehow escaped  
being listed in func.sgml.  
  
Fabien Coelho and Tom Lane  
  
Discussion: https://postgr.es/m/alpine.DEB.2.20.1705061027580.3896@lancre  

M doc/src/sgml/func.sgml

Allow MSVC to build with Tcl 8.6.

commit   : 19a40337854ee83bd0fb1b65d0787e2c74065722    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 5 May 2017 12:05:34 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 5 May 2017 12:05:34 -0300    

Click here for diff

Commit eaba54c20c5 added support for Tcl 8.6 for configure-supported  
platforms after verifying that pltcl works without further changes, but  
the MSVC tooling wasn't updated accordingly.  Update MSVC to match,  
restructuring the code to avoid duplicating the logic for every Tcl  
version supported.  
  
Backpatch to all live branches, like eaba54c20c5.  In 9.4 and previous,  
change the patch to use backslashes rather than forward, as in the rest  
of the file.  
  
Reported by Paresh More, who also tested the patch I provided.  
Discussion: https://postgr.es/m/CAAgiCNGVw3ssBtSi3ZNstrz5k00ax=UV+_ZEHUeW_LMSGL2sew@mail.gmail.com  

M src/tools/msvc/Mkvcbuild.pm

Give nicer error message when connecting to a v10 server requiring SCRAM.

commit   : bd05ad8b052012155fd5de0c21029d5869ad5eb4    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 5 May 2017 11:24:02 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 5 May 2017 11:24:02 +0300    

Click here for diff

This is just to give the user a hint that they need to upgrade, if they try  
to connect to a v10 server that uses SCRAM authentication, with an older  
client.  
  
Commit to all stable branches, but not master.  
  
Discussion: https://www.postgresql.org/message-id/bbf45d92-3896-eeb7-7399-2111d517261b@pivotal.io  

M src/include/libpq/pqcomm.h
M src/interfaces/libpq/fe-auth.c

Fix cursor_to_xml in tableforest false mode

commit   : 071d13395cc2ea0b87aa5f135c87808d6dd60cd5    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 3 May 2017 21:25:01 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 3 May 2017 21:25:01 -0400    

Click here for diff

It only produced <row> elements but no wrapping <table> element.  
  
By contrast, cursor_to_xmlschema produced a schema that is now correct  
but did not previously match the XML data produced by cursor_to_xml.  
  
In passing, also fix a minor misunderstanding about moving cursors in  
the tests related to this.  
  
Reported-by: filip@jirsak.org  
Based-on-patch-by: Thomas Munro <thomas.munro@enterprisedb.com>  

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

Fix pfree-of-already-freed-tuple when rescanning a GiST index-only scan.

commit   : 855f0e9247a160bfad00c117ba7d97148cd2a0ec    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 4 May 2017 13:59:13 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 4 May 2017 13:59:13 -0400    

Click here for diff

GiST's getNextNearest() function attempts to pfree the previously-returned  
tuple if any (that is, scan->xs_hitup in HEAD, or scan->xs_itup in older  
branches).  However, if we are rescanning a plan node after ending a  
previous scan early, those tuple pointers could be pointing to garbage,  
because they would be pointing into the scan's pageDataCxt or queueCxt  
which has been reset.  In a debug build this reliably results in a crash,  
although I think it might sometimes accidentally fail to fail in  
production builds.  
  
To fix, clear the pointer field anyplace we reset a context it might  
be pointing into.  This may be overkill --- I think probably only the  
queueCxt case is involved in this bug, so that resetting in gistrescan()  
would be sufficient --- but dangling pointers are generally bad news,  
so let's avoid them.  
  
Another plausible answer might be to just not bother with the pfree in  
getNextNearest().  The reconstructed tuples would go away anyway in the  
context resets, and I'm far from convinced that freeing them a bit earlier  
really saves anything meaningful.  I'll stick with the original logic in  
this patch, but if we find more problems in the same area we should  
consider that approach.  
  
Per bug #14641 from Denis Smirnov.  Back-patch to 9.5 where this  
logic was introduced.  
  
Discussion: https://postgr.es/m/20170504072034.24366.57688@wrigleys.postgresql.org  

M src/backend/access/gist/gistget.c
M src/backend/access/gist/gistscan.c
M src/test/regress/expected/gist.out
M src/test/regress/sql/gist.sql

Remove useless and rather expensive stanza in matview regression test.

commit   : 56064d55128024a5ae55427025392bcfd1932609    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 3 May 2017 19:37:01 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 3 May 2017 19:37:01 -0400    

Click here for diff

This removes a test case added by commit b69ec7cc9, which was intended  
to exercise a corner case involving the rule used at that time that  
materialized views were unpopulated iff they had physical size zero.  
We got rid of that rule very shortly later, in commit 1d6c72a55, but  
kept the test case.  However, because the case now asks what VACUUM  
will do to a zero-sized physical file, it would be pretty surprising  
if the answer were ever anything but "nothing" ... and if things were  
indeed that broken, surely we'd find it out from other tests.  Since  
the test involves a table that's fairly large by regression-test  
standards (100K rows), it's quite slow to run.  Dropping it should  
save some buildfarm cycles, so let's do that.  
  
Discussion: https://postgr.es/m/32386.1493831320@sss.pgh.pa.us  

M src/test/regress/expected/matview.out
M src/test/regress/sql/matview.sql

Improve performance of timezone loading, especially pg_timezone_names view.

commit   : c521d5a8d7bb014171e328976643367c170dc8f3    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 2 May 2017 21:50:35 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 2 May 2017 21:50:35 -0400    

Click here for diff

tzparse() would attempt to load the "posixrules" timezone database file on  
each call.  That might seem like it would only be an issue when selecting a  
POSIX-style zone name rather than a zone defined in the timezone database,  
but it turns out that each zone definition file contains a POSIX-style zone  
string and tzload() will call tzparse() to parse that.  Thus, when scanning  
the whole timezone file tree as we do in the pg_timezone_names view,  
"posixrules" was read repetitively for each zone definition file.  Fix  
that by caching the file on first use within any given process.  (We cache  
other zone definitions for the life of the process, so there seems little  
reason not to cache this one as well.)  This probably won't help much in  
processes that never run pg_timezone_names, but even one additional SET  
of the timezone GUC would come out ahead.  
  
An even worse problem for pg_timezone_names is that pg_open_tzfile()  
has an inefficient way of identifying the canonical case of a zone name:  
it basically re-descends the directory tree to the zone file.  That's not  
awful for an individual "SET timezone" operation, but it's pretty horrid  
when we're inspecting every zone in the database.  And it's pointless too  
because we already know the canonical spelling, having just read it from  
the filesystem.  Fix by teaching pg_open_tzfile() to avoid the directory  
search if it's not asked for the canonical name, and backfilling the  
proper result in pg_tzenumerate_next().  
  
In combination these changes seem to make the pg_timezone_names view  
about 3x faster to read, for me.  Since a scan of pg_timezone_names  
has up to now been one of the slowest queries in the regression tests,  
this should help some little bit for buildfarm cycle times.  
  
Back-patch to all supported branches, not so much because it's likely  
that users will care much about the view's performance as because  
tracking changes in the upstream IANA timezone code is really painful  
if we don't keep all the branches in sync.  
  
Discussion: https://postgr.es/m/27962.1493671706@sss.pgh.pa.us  

M src/timezone/README
M src/timezone/localtime.c
M src/timezone/pgtz.c

Ensure commands in extension scripts see the results of preceding DDL.

commit   : d56b8b41b32b3f5c576d6fc2b2c9af3ae4b55511    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 2 May 2017 18:05:54 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 2 May 2017 18:05:54 -0400    

Click here for diff

Due to a missing CommandCounterIncrement() call, parsing of a non-utility  
command in an extension script would not see the effects of the immediately  
preceding DDL command, unless that command's execution ends with  
CommandCounterIncrement() internally ... which some do but many don't.  
Report by Philippe Beaudoin, diagnosis by Julien Rouhaud.  
  
Rather remarkably, this bug has evaded detection since extensions were  
invented, so back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/2cf7941e-4e41-7714-3de8-37b1a8f74dff@free.fr  

M src/backend/commands/extension.c
M src/test/modules/test_extensions/test_ext3–1.0.sql

Fix perl thinko in commit fed6df486dca

commit   : f06caa09d9c539a2336434e6b521b6541c3da624    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Tue, 2 May 2017 08:20:11 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Tue, 2 May 2017 08:20:11 -0400    

Click here for diff

Report and fix from Vaishnavi Prabakaran  
  
Backpatch to 9.4 like original.  

M src/tools/msvc/vcregress.pl

Update time zone data files to tzdata release 2017b.

commit   : 1fdc3f6e8afe580c30515c70a04d074d527ae780    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 1 May 2017 11:52:59 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 1 May 2017 11:52:59 -0400    

Click here for diff

DST law changes in Chile, Haiti, and Mongolia.  Historical corrections for  
Ecuador, Kazakhstan, Liberia, and Spain.  
  
The IANA crew continue their campaign to replace invented time zone  
abbrevations with numeric GMT offsets.  This update changes numerous zones  
in South America, the Pacific and Indian oceans, and some Asian and Middle  
Eastern zones.  I kept these abbreviations in the tznames/ data files,  
however, so that we will still accept them for input.  (We may want to  
start trimming those files someday, but I think we should wait for the  
upstream dust to settle before deciding what to do.)  
  
In passing, add MESZ (Mitteleuropaeische Sommerzeit) to the tznames lists;  
since we accept MEZ (Mitteleuropaeische Zeit) it seems rather strange not  
to take the other one.  And fix some incorrect, or at least obsolete,  
comments that certain abbreviations are not traceable to the IANA data.  

M src/timezone/data/africa
M src/timezone/data/antarctica
M src/timezone/data/asia
M src/timezone/data/australasia
M src/timezone/data/backward
M src/timezone/data/backzone
M src/timezone/data/europe
M src/timezone/data/northamerica
M src/timezone/data/southamerica
M src/timezone/known_abbrevs.txt
M src/timezone/tznames/America.txt
M src/timezone/tznames/Antarctica.txt
M src/timezone/tznames/Asia.txt
M src/timezone/tznames/Atlantic.txt
M src/timezone/tznames/Australia.txt
M src/timezone/tznames/Default
M src/timezone/tznames/Europe.txt
M src/timezone/tznames/Indian.txt
M src/timezone/tznames/Pacific.txt
M src/timezone/tznames/README

Allow vcregress.pl to run an arbitrary TAP test set

commit   : 66510630d8621a638b487fa5ae685bdc60240440    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 1 May 2017 10:12:02 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 1 May 2017 10:12:02 -0400    

Click here for diff

Currently only provision for running the bin checks in a single step is  
provided for. Now these tests can be run individually, as well as tests  
in other locations (e.g. src.test/recover).  
  
Also provide for suppressing unnecessary temp installs by setting the  
NO_TEMP_INSTALL environment variable just as the Makefiles do.  
  
Backpatch to 9.4.  

M src/tools/msvc/vcregress.pl

Sync our copy of the timezone library with IANA release tzcode2017b.

commit   : 6872d96a3bb893c987a3df623754c13deac8254f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 30 Apr 2017 15:13:51 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 30 Apr 2017 15:13:51 -0400    

Click here for diff

zic no longer mishandles some transitions in January 2038 when it  
attempts to work around Qt bug 53071.  This fixes a bug affecting  
Pacific/Tongatapu that was introduced in zic 2016e.  localtime.c  
now contains a workaround, useful when loading a file generated by  
a buggy zic.  
  
There are assorted cosmetic changes as well, notably relocation  
of a bunch of #defines.  

M src/timezone/README
M src/timezone/localtime.c
M src/timezone/pgtz.c
M src/timezone/private.h
M src/timezone/strftime.c
M src/timezone/tzfile.h
M src/timezone/zic.c

doc: Fix typo in 9.6 release notes

commit   : 0a65b18d2d17891766627da73633e808e66ecdd1    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 28 Apr 2017 15:30:54 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 28 Apr 2017 15:30:54 -0400    

Click here for diff

Author: Huong Dangminh <huo-dangminh@ys.jp.nec.com>  

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

Fix VALIDATE CONSTRAINT to consider NO INHERIT attribute.

commit   : 8a9c83bfaf889702401f532fbe2adaf604ca1bd6    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 28 Apr 2017 14:48:38 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 28 Apr 2017 14:48:38 -0400    

Click here for diff

Currently, trying to validate a NO INHERIT constraint on the parent will  
search for the constraint in child tables (where it is not supposed to  
exist), wrongly causing a "constraint does not exist" error.  
  
Amit Langote, per a report from Hans Buschmann.  
  
Discussion: http://postgr.es/m/20170421184012.24362.19@wrigleys.postgresql.org  

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

Don't use on-disk snapshots for exported logical decoding snapshot.

commit   : 29e8c881dd077fd94d3f35a341c266f72e9285f2    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Thu, 27 Apr 2017 15:28:24 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Thu, 27 Apr 2017 15:28:24 -0700    

Click here for diff

Logical decoding stores historical snapshots on disk, so that logical  
decoding can restart without having to reconstruct a snapshot from  
scratch (for which the resources are not guaranteed to be present  
anymore).  These serialized snapshots were also used when creating a  
new slot via the walsender interface, which can export a "full"  
snapshot (i.e. one that can read all tables, not just catalog ones).  
  
The problem is that the serialized snapshots are only useful for  
catalogs and not for normal user tables.  Thus the use of such a  
serialized snapshot could result in an inconsistent snapshot being  
exported, which could lead to queries returning wrong data.  This  
would only happen if logical slots are created while another logical  
slot already exists.  
  
Author: Petr Jelinek  
Reviewed-By: Andres Freund  
Discussion: https://postgr.es/m/f37e975c-908f-858e-707f-058d3b1eb214@2ndquadrant.com  
Backport: 9.4, where logical decoding was introduced.  

M src/backend/replication/logical/logical.c
M src/backend/replication/logical/snapbuild.c
M src/include/replication/snapbuild.h

Cope with glibc too old to have epoll_create1().

commit   : 53b157846024f28f8d48a6e0163c89a577f886a8    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 27 Apr 2017 17:13:29 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 27 Apr 2017 17:13:29 -0400    

Click here for diff

Commit fa31b6f4e supposed that we didn't have to worry about that  
anymore, but it seems that RHEL5 is like that, and that's still  
a supported platform.  Put back the prior coding under an #ifdef,  
adding an explicit fcntl() to retain the desired CLOEXEC property.  
  
Discussion: https://postgr.es/m/12307.1493325329@sss.pgh.pa.us  

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

Preserve required !catalog tuples while computing initial decoding snapshot.

commit   : 28afff347a5db51a02b269fa13677d6924a88e78    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Sun, 23 Apr 2017 20:41:29 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Sun, 23 Apr 2017 20:41:29 -0700    

Click here for diff

The logical decoding machinery already preserved all the required  
catalog tuples, which is sufficient in the course of normal logical  
decoding, but did not guarantee that non-catalog tuples were preserved  
during computation of the initial snapshot when creating a slot over  
the replication protocol.  
  
This could cause a corrupted initial snapshot being exported.  The  
time window for issues is usually not terribly large, but on a busy  
server it's perfectly possible to it hit it.  Ongoing decoding is not  
affected by this bug.  
  
To avoid increased overhead for the SQL API, only retain additional  
tuples when a logical slot is being created over the replication  
protocol.  To do so this commit changes the signature of  
CreateInitDecodingContext(), but it seems unlikely that it's being  
used in an extension, so that's probably ok.  
  
In a drive-by fix, fix handling of  
ReplicationSlotsComputeRequiredXmin's already_locked argument, which  
should only apply to ProcArrayLock, not ReplicationSlotControlLock.  
  
Reported-By: Erik Rijkers  
Analyzed-By: Petr Jelinek  
Author: Petr Jelinek, heavily editorialized by Andres Freund  
Reviewed-By: Andres Freund  
Discussion: https://postgr.es/m/9a897b86-46e1-9915-ee4c-da02e4ff6a95@2ndquadrant.com  
Backport: 9.4, where logical decoding was introduced.  

M src/backend/replication/logical/logical.c
M src/backend/replication/logical/snapbuild.c
M src/backend/replication/slot.c
M src/backend/replication/slotfuncs.c
M src/backend/replication/walsender.c
M src/backend/storage/ipc/procarray.c
M src/include/replication/logical.h
M src/include/storage/procarray.h

Make latch.c more paranoid about child-process cases.

commit   : 866452cd8b52b0231e159eab4201d86d9164ab69    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 27 Apr 2017 15:07:36 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 27 Apr 2017 15:07:36 -0400    

Click here for diff

Although the postmaster doesn't currently create a self-pipe or any  
latches, there's discussion of it doing so in future.  It's also  
conceivable that a shared_preload_libraries extension would try to  
create such a thing in the postmaster process today.  In that case  
the self-pipe FDs would be inherited by forked child processes.  
latch.c was entirely unprepared for such a case and could suffer an  
assertion failure, or worse try to use the inherited pipe if somebody  
called WaitLatch without having called InitializeLatchSupport in that  
process.  Make it keep track of whether InitializeLatchSupport has been  
called in the *current* process, and do the right thing if state has  
been inherited from a parent.  
  
Apply FD_CLOEXEC to file descriptors created in latch.c (the self-pipe,  
as well as epoll event sets).  This ensures that child processes spawned  
in backends, the archiver, etc cannot accidentally or intentionally mess  
with these FDs.  It also ensures that we end up with the right state  
for the self-pipe in EXEC_BACKEND processes, which otherwise wouldn't  
know to close the postmaster's self-pipe FDs.  
  
Back-patch to 9.6, mainly to keep latch.c looking similar in all branches  
it exists in.  
  
Discussion: https://postgr.es/m/8322.1493240739@sss.pgh.pa.us  

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

Allow multiple bgworkers to be launched per postmaster iteration.

commit   : e880df25ec35fab727678531d392403ce4226dd9    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 26 Apr 2017 16:17:29 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 26 Apr 2017 16:17:29 -0400    

Click here for diff

Previously, maybe_start_bgworker() would launch at most one bgworker  
process per call, on the grounds that the postmaster might otherwise  
neglect its other duties for too long.  However, that seems overly  
conservative, especially since bad effects only become obvious when  
many hundreds of bgworkers need to be launched at once.  On the other  
side of the coin is that the existing logic could result in substantial  
delay of bgworker launches, because ServerLoop isn't guaranteed to  
iterate immediately after a signal arrives.  (My attempt to fix that  
by using pselect(2) encountered too many portability question marks,  
and in any case could not help on platforms without pselect().)  
One could also question the wisdom of using an O(N^2) processing  
method if the system is intended to support so many bgworkers.  
  
As a compromise, allow that function to launch up to 100 bgworkers  
per call (and in consequence, rename it to maybe_start_bgworkers).  
This will allow any normal parallel-query request for workers  
to be satisfied immediately during sigusr1_handler, avoiding the  
question of whether ServerLoop will be able to launch more promptly.  
  
There is talk of rewriting the postmaster to use a WaitEventSet to  
avoid the signal-response-delay problem, but I'd argue that this change  
should be kept even after that happens (if it ever does).  
  
Backpatch to 9.6 where parallel query was added.  The issue exists  
before that, but previous uses of bgworkers typically aren't as  
sensitive to how quickly they get launched.  
  
Discussion: https://postgr.es/m/4707.1493221358@sss.pgh.pa.us  

M src/backend/postmaster/postmaster.c

postgres_fdw: Fix join push down with extensions

commit   : 86e640a6941b956d05c0380b754a92050f06bf43    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 25 Apr 2017 10:01:59 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 25 Apr 2017 10:01:59 -0400    

Click here for diff

Objects in an extension are shippable to a foreign server if the  
extension is part of the foreign server definition's shippable  
extensions list.  But this was not properly considered in some cases  
when checking whether a join condition can be pushed to a foreign server  
and the join condition uses an object from a shippable extension.  So  
the join would never be pushed down in those cases.  
  
So, the list of extensions needs to be made available in fpinfo of the  
relation being considered to be pushed down before any expressions are  
assessed for being shippable.  Fix foreign_join_ok() to do that for a  
join relation.  
  
David Rowley and Ashutosh Bapat, per report from David Rowley  
  
reduced version of patch 332bec1e6096679b04ec9717beb44a858495260f for  
backpatch to 9.6, first release with join push down  

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

Revert "Use pselect(2) not select(2), if available, to wait in postmaster's loop."

commit   : e615605239f6df491cd171ed6890b8c70566ef75    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 24 Apr 2017 18:29:55 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 24 Apr 2017 18:29:55 -0400    

Click here for diff

This reverts commit b9515b62879722e3497236f6e0d6783c3fc059a2.  
  
Buildfarm results suggest that some platforms have versions of pselect(2)  
that are not merely non-atomic, but flat out non-functional.  Revert the  
use-pselect patch to confirm this diagnosis (and exclude the no-SA_RESTART  
patch as the source of trouble).  If it's so, we should probably look into  
blacklisting specific platforms that have broken pselect.  
  
Discussion: https://postgr.es/m/9696.1493072081@sss.pgh.pa.us  

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

Use pselect(2) not select(2), if available, to wait in postmaster's loop.

commit   : b9515b62879722e3497236f6e0d6783c3fc059a2    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 24 Apr 2017 14:03:14 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 24 Apr 2017 14:03:14 -0400    

Click here for diff

Traditionally we've unblocked signals, called select(2), and then blocked  
signals again.  The code expects that the select() will be cancelled with  
EINTR if an interrupt occurs; but there's a race condition, which is that  
an already-pending signal will be delivered as soon as we unblock, and then  
when we reach select() there will be nothing preventing it from waiting.  
This can result in a long delay before we perform any action that  
ServerLoop was supposed to have taken in response to the signal.  As with  
the somewhat-similar symptoms fixed by commit 893902085, the main practical  
problem is slow launching of parallel workers.  The window for trouble is  
usually pretty short, corresponding to one iteration of ServerLoop; but  
it's not negligible.  
  
To fix, use pselect(2) in place of select(2) where available, as that's  
designed to solve exactly this problem.  Where not available, we continue  
to use the old way, and are no worse off than before.  
  
pselect(2) has been required by POSIX since about 2001, so most modern  
platforms should have it.  A bigger portability issue is that some  
implementations are said to be non-atomic, ie pselect() isn't really  
any different from unblock/select/reblock.  Still, we're no worse off  
than before on such a platform.  
  
There is talk of rewriting the postmaster to use a WaitEventSet and  
not do signal response work in signal handlers, at which point this  
could be reverted, since we'd be using a self-pipe to solve the race  
condition.  But that's not happening before v11 at the earliest.  
  
Back-patch to 9.6.  The problem exists much further back, but the  
worst symptom arises only in connection with parallel query, so it  
does not seem worth taking any portability risks in older branches.  
  
Discussion: https://postgr.es/m/9205.1492833041@sss.pgh.pa.us  

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

Run the postmaster's signal handlers without SA_RESTART.

commit   : dfa4baf91cee77520335f2d7d6eff7f968dfe29c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 24 Apr 2017 13:00:23 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 24 Apr 2017 13:00:23 -0400    

Click here for diff

The postmaster keeps signals blocked everywhere except while waiting  
for something to happen in ServerLoop().  The code expects that the  
select(2) will be cancelled with EINTR if an interrupt occurs; without  
that, followup actions that should be performed by ServerLoop() itself  
will be delayed.  However, some platforms interpret the SA_RESTART  
signal flag as meaning that they should restart rather than cancel  
the select(2).  Worse yet, some of them restart it with the original  
timeout delay, meaning that a steady stream of signal interrupts can  
prevent ServerLoop() from iterating at all if there are no incoming  
connection requests.  
  
Observable symptoms of this, on an affected platform such as HPUX 10,  
include extremely slow parallel query startup (possibly as much as  
30 seconds) and failure to update timestamps on the postmaster's sockets  
and lockfiles when no new connections arrive for a long time.  
  
We can fix this by running the postmaster's signal handlers without  
SA_RESTART.  That would be quite a scary change if the range of code  
where signals are accepted weren't so tiny, but as it is, it seems  
safe enough.  (Note that postmaster children do, and must, reset all  
the handlers before unblocking signals; so this change should not  
affect any child process.)  
  
There is talk of rewriting the postmaster to use a WaitEventSet and  
not do signal response work in signal handlers, at which point it might  
be appropriate to revert this patch.  But that's not happening before  
v11 at the earliest.  
  
Back-patch to 9.6.  The problem exists much further back, but the  
worst symptom arises only in connection with parallel query, so it  
does not seem worth taking any portability risks in older branches.  
  
Discussion: https://postgr.es/m/9205.1492833041@sss.pgh.pa.us  

M src/backend/postmaster/postmaster.c
M src/include/port.h
M src/port/pqsignal.c

Fix postmaster's handling of fork failure for a bgworker process.

commit   : 63f64d2824b290a75a82ac60c5b62a971b7c7a4e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 24 Apr 2017 12:16:58 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 24 Apr 2017 12:16:58 -0400    

Click here for diff

This corner case didn't behave nicely at all: the postmaster would  
(partially) update its state as though the process had started  
successfully, and be quite confused thereafter.  Fix it to act  
like the worker had crashed, instead.  
  
In passing, refactor so that do_start_bgworker contains all the  
state-change logic for bgworker launch, rather than just some of it.  
  
Back-patch as far as 9.4.  9.3 contains similar logic, but it's just  
enough different that I don't feel comfortable applying the patch  
without more study; and the use of bgworkers in 9.3 was so small  
that it doesn't seem worth the extra work.  
  
transam/parallel.c is still entirely unprepared for the possibility  
of bgworker startup failure, but that seems like material for a  
separate patch.  
  
Discussion: https://postgr.es/m/4905.1492813727@sss.pgh.pa.us  

M src/backend/postmaster/postmaster.c

Zero padding in replication origin's checkpointed on disk-state.

commit   : 39369b41451e432396aa3a913cc4c68bf0f4ee3c    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Sun, 23 Apr 2017 15:48:31 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Sun, 23 Apr 2017 15:48:31 -0700    

Click here for diff

This seems to be largely cosmetic, avoiding valgrind bleats and the  
like. The uninitialized padding influences the CRC of the on-disk  
entry, but because it's also used when verifying the CRC, that doesn't  
cause spurious failures.  Backpatch nonetheless.  
  
It's a bit unfortunate that contrib/test_decoding/sql/replorigin.sql  
doesn't exercise the checkpoint path, but checkpoints are fairly  
expensive on weaker machines, and we'd have to stop/start for that to  
be meaningful.  
  
Author: Andres Freund  
Discussion: https://postgr.es/m/20170422183123.w2jgiuxtts7qrqaq@alap3.anarazel.de  
Backpatch: 9.5, where replication origins were introduced  

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

Fix order of arguments to SubTransSetParent().

commit   : f5885488dacb62277c6452919e8961d27685675f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 23 Apr 2017 13:10:57 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 23 Apr 2017 13:10:57 -0400    

Click here for diff

ProcessTwoPhaseBuffer (formerly StandbyRecoverPreparedTransactions)  
mixed up the parent and child XIDs when calling SubTransSetParent to  
record the transactions' relationship in pg_subtrans.  
  
Remarkably, analysis by Simon Riggs suggests that this doesn't lead to  
visible problems (at least, not in non-Assert builds).  That might  
explain why we'd not noticed it before.  Nonetheless, it's surely wrong.  
  
This code was born broken, so back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/20110.1492905318@sss.pgh.pa.us  

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

Fix TAP infrastructure to support Mingw better

commit   : 11927e575dd2afc8361e785c34db2141156702d6    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Sun, 23 Apr 2017 09:39:43 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Sun, 23 Apr 2017 09:39:43 -0400    

Click here for diff

archive_command and restore_command need to refer to Windows paths, not  
Msys virtual file system paths, as postgres is completely unaware of the  
latter, so prefix them with the Windows path to the virtual file system  
root. Clean psql output of carriage returns.  

M src/test/perl/PostgresNode.pm

Make PostgresNode.pm check server status more carefully.

commit   : 9d5f0718d75772265b476e41f8a7e97dd8856710    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 22 Apr 2017 18:18:25 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 22 Apr 2017 18:18:25 -0400    

Click here for diff

PostgresNode blithely ignored the exit status of pg_ctl, and in general  
made no effort to be sure that the server was running when it should be.  
This caused it to miss server crashes, which is a serious shortcoming  
in a test scaffold.  Make it complain if pg_ctl fails, and modify the  
start and stop logic to complain if the server doesn't start, or doesn't  
stop, when expected.  
  
Also, have it turn off the "restart_after_crash" configuration parameter  
in created clusters, as bitter experience has shown that leaving that on  
can mask crashes too.  
  
We might at some point need variant functions that allow for, eg,  
server start failure to be expected.  But no existing test case appears  
to want that, and it surely shouldn't be the default behavior.  
  
Note that this *will* break the buildfarm, as it will expose known  
bugs that the previous testing failed to.  I'm committing it despite  
that, to verify that we get the expected failures in the buildfarm  
not just in manual testing.  
  
Back-patch into 9.6 where PostgresNode was introduced.  (The 9.6  
branch is not expected to show any failures.)  
  
Discussion: https://postgr.es/m/21432.1492886428@sss.pgh.pa.us  

M src/test/perl/PostgresNode.pm

Make PostgresNode::append_conf append a newline automatically.

commit   : 551cc9af57814a93f809bc907a21595c0771b1a6    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 22 Apr 2017 16:58:15 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 22 Apr 2017 16:58:15 -0400    

Click here for diff

Although the documentation for append_conf said clearly that it didn't  
add a newline, many test authors seem to have forgotten that ... or maybe  
they just consulted the example at the top of the POD documentation,  
which clearly shows adding a config entry without bothering to add a  
trailing newline.  The worst part of that is that it works, as long as  
you don't do it more than once, since the backend isn't picky about  
whether config files end with newlines.  So there's not a strong forcing  
function reminding test authors not to do it like that.  Upshot is that  
this is a terribly fragile way to go about things, and there's at least  
one existing test case that is demonstrably broken and not testing what  
it thinks it is.  
  
Let's just make append_conf append a newline, instead; that is clearly  
way safer than the old definition.  
  
I also cleaned up a few call sites that were unnecessarily ugly.  
(I left things alone in places where it's plausible that additional  
config lines would need to be added someday.)  
  
Back-patch the change in append_conf itself to 9.6 where it was added,  
as having a definitional inconsistency between branches would obviously  
be pretty hazardous for back-patching TAP tests.  The other changes are  
just cosmetic and don't need to be back-patched.  
  
Discussion: https://postgr.es/m/19751.1492892376@sss.pgh.pa.us  

M src/test/perl/PostgresNode.pm

commit   : 95a23165fd9d0a3e8d3d5b8637237d2b7d93783c    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 21 Apr 2017 19:42:01 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 21 Apr 2017 19:42:01 -0400    

Click here for diff

The reference "That is the topic of the next section." has been  
incorrect since the materialized views documentation got inserted  
between the section "rules-views" and "rules-update".  
  
Author: Zertrin <postgres_wiki@zertrin.org>  

M doc/src/sgml/rules.sgml

Avoid depending on non-POSIX behavior of fcntl(2).

commit   : f07f6b62c9a7853d7bac2de6316b1b0f96a688c4    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 21 Apr 2017 15:55:56 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 21 Apr 2017 15:55:56 -0400    

Click here for diff

The POSIX standard does not say that the success return value for  
fcntl(F_SETFD) and fcntl(F_SETFL) is zero; it says only that it's not -1.  
We had several calls that were making the stronger assumption.  Adjust  
them to test specifically for -1 for strict spec compliance.  
  
The standard further leaves open the possibility that the O_NONBLOCK  
flag bit is not the only active one in F_SETFL's argument.  Formally,  
therefore, one ought to get the current flags with F_GETFL and store  
them back with only the O_NONBLOCK bit changed when trying to change  
the nonblock state.  In port/noblock.c, we were doing the full pushup  
in pg_set_block but not in pg_set_noblock, which is just weird.  Make  
both of them do it properly, since they have little business making  
any assumptions about the socket they're handed.  The other places  
where we're issuing F_SETFL are working with FDs we just got from  
pipe(2), so it's reasonable to assume the FDs' properties are all  
default, so I didn't bother adding F_GETFL steps there.  
  
Also, while pg_set_block deserves some points for trying to do things  
right, somebody had decided that it'd be even better to cast fcntl's  
third argument to "long".  Which is completely loony, because POSIX  
clearly says the third argument for an F_SETFL call is "int".  
  
Given the lack of field complaints, these missteps apparently are not  
of significance on any common platforms.  But they're still wrong,  
so back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/30882.1492800880@sss.pgh.pa.us  

M src/backend/postmaster/postmaster.c
M src/backend/storage/ipc/latch.c
M src/bin/pg_test_fsync/pg_test_fsync.c
M src/port/noblock.c

Always build a custom plan node's targetlist from the path's pathtarget.

commit   : 6c73b390b4797c6b81ee4f5d17feda34cfde6ccd    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 17 Apr 2017 15:29:00 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 17 Apr 2017 15:29:00 -0400    

Click here for diff

We were applying the use_physical_tlist optimization to all relation  
scan plans, even those implemented by custom scan providers.  However,  
that's a bad idea for a couple of reasons.  The custom provider might  
be unable to provide columns that it hadn't expected to be asked for  
(for example, the custom scan might depend on an index-only scan).  
Even more to the point, there's no good reason to suppose that this  
"optimization" is a win for a custom scan; whatever the custom provider  
is doing is likely not based on simply returning physical heap tuples.  
(As a counterexample, if the custom scan is an interface to a column store,  
demanding all columns would be a huge loss.)  If it is a win, the custom  
provider could make that decision for itself and insert a suitable  
pathtarget into the path, anyway.  
  
Per discussion with Dmitry Ivanov.  Back-patch to 9.5 where custom scan  
support was introduced.  The argument that the custom provider can adjust  
the behavior by changing the pathtarget only applies to 9.6+, but on  
balance it seems more likely that use_physical_tlist will hurt custom  
scans than help them.  
  
Discussion: https://postgr.es/m/e29ddd30-8ef9-4da5-a50b-2bb7b8c7198d@postgrespro.ru  

M src/backend/optimizer/plan/createplan.c

Fix compiler warning

commit   : 1ec36a9eb4c29dc49838319d1e666f66961d757c    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Sun, 16 Apr 2017 20:49:40 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Sun, 16 Apr 2017 20:49:40 -0400    

Click here for diff

Introduced by 41306a511c01dd299115cf447858a00e34aebbf6, happens with gcc  
4.7.2.  

M src/backend/catalog/objectaddress.c

Provide a way to control SysV shmem attach address in EXEC_BACKEND builds.

commit   : a30f146db4e75379c5b5e733027a0013e542d3ed    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 15 Apr 2017 17:27:38 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 15 Apr 2017 17:27:38 -0400    

Click here for diff

In standard non-Windows builds, there's no particular reason to care what  
address the kernel chooses to map the shared memory segment at.  However,  
when building with EXEC_BACKEND, there's a risk that the chosen address  
won't be available in all child processes.  Linux with ASLR enabled (which  
it is by default) seems particularly at risk because it puts shmem segments  
into the same area where it maps shared libraries.  We can work around  
that by specifying a mapping address that's outside the range where  
shared libraries could get mapped.  On x86_64 Linux, 0x7e0000000000  
seems to work well.  
  
This is only meant for testing/debugging purposes, so it doesn't seem  
necessary to go as far as providing a GUC (or any user-visible  
documentation, though we might change that later).  Instead, it's just  
controlled by setting an environment variable PG_SHMEM_ADDR to the  
desired attach address.  
  
Back-patch to all supported branches, since the point here is to  
remove intermittent buildfarm failures on EXEC_BACKEND animals.  
Owners of affected animals will need to add a suitable setting of  
PG_SHMEM_ADDR to their build_env configuration.  
  
Discussion: https://postgr.es/m/7036.1492231361@sss.pgh.pa.us  

M src/backend/port/sysv_shmem.c

Avoid passing function pointers across process boundaries.

commit   : 9c225acf0b97a7a3a5ca1a12ee0e89c98cf16442    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 15 Apr 2017 16:23:27 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 15 Apr 2017 16:23:27 -0400    

Click here for diff

This back-patches commit 32470825d36d99a81347ee36c181d609c952c061  
into 9.6, primarily to make buildfarm member culicidae happy.  
Unlike the HEAD patch, avoid changing the existing API of  
CreateParallelContext; instead we just switch to using  
CreateParallelContextForExternalFunction, even for core functions.  
  
Petr Jelinek, with a bunch of basically-cosmetic adjustments by me  
  
Discussion: https://postgr.es/m/548f9c1d-eafa-e3fa-9da8-f0cc2f654e60@2ndquadrant.com  

M src/backend/access/transam/README.parallel
M src/backend/access/transam/parallel.c
M src/backend/executor/execParallel.c
M src/backend/postmaster/bgworker.c
M src/include/executor/execParallel.h

Further fix pg_trgm's extraction of trigrams from regular expressions.

commit   : d51279433cdf30d62e92bb5f5f1790e9014a0342    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 14 Apr 2017 14:52:03 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 14 Apr 2017 14:52:03 -0400    

Click here for diff

Commit 9e43e8714 turns out to have been insufficient: not only is it  
necessary to track tentative parent links while considering a set of  
arc removals, but it's necessary to track tentative flag additions  
as well.  This is because we always merge arc target states into  
arc source states; therefore, when considering a merge of the final  
state with some other, it is the other state that will acquire a new  
TSTATE_FIN bit.  If there's another arc for the same color trigram  
that would cause merging of that state with the initial state, we  
failed to recognize the problem.  The test cases for the prior commit  
evidently only exercised situations where a tentative merge with the  
initial state occurs before one with the final state.  If it goes the  
other way around, we'll happily merge the initial and final states,  
either producing a broken final graph that would never match anything,  
or triggering the Assert added by the prior commit.  
  
It's tempting to consider switching the merge direction when the merge  
involves the final state, but I lack the time to analyze that idea in  
detail.  Instead just keep track of the flag changes that would result  
from proposed merges, in the same way that the prior commit tracked  
proposed parent links.  
  
Along the way, add some more debugging support, because I'm not entirely  
confident that this is the last bug here.  And tweak matters so that  
the transformed.dot file uses small integers rather than pointer values  
to identify states; that makes it more readable if you're just eyeballing  
it rather than fooling with Graphviz.  And rename a couple of identically  
named struct fields to reduce confusion.  
  
Per report from Corey Csuhta.  Add a test case based on his example.  
(Note: this case does not trigger the bug under 9.3, apparently because  
its different measurement of costs causes it to stop merging states before  
it hits the failure.  I spent some time trying to find a variant that would  
fail in 9.3, without success; but I'm sure such cases exist.)  
  
Like the previous patch, back-patch to 9.3 where this code was added.  
  
Report: https://postgr.es/m/E2B01A4B-4530-406B-8D17-2F67CF9A16BA@csuhta.com  

M contrib/pg_trgm/expected/pg_trgm.out
M contrib/pg_trgm/sql/pg_trgm.sql
M contrib/pg_trgm/trgm_regexp.c

Fix regexport.c to behave sanely with lookaround constraints.

commit   : a70b18b89459c137d7c2554133981b0752450e4e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 13 Apr 2017 17:18:35 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 13 Apr 2017 17:18:35 -0400    

Click here for diff

regexport.c thought it could just ignore LACON arcs, but the correct  
behavior is to treat them as satisfiable while consuming zero input  
(rather reminiscently of commit 9f1e642d5).  Otherwise, the emitted  
simplified-NFA representation may contain no paths leading from initial  
to final state, which unsurprisingly confuses pg_trgm, as seen in  
bug #14623 from Jeff Janes.  
  
Since regexport's output representation has no concept of an arc that  
consumes zero input, recurse internally to find the next normal arc(s)  
after any LACON transitions.  We'd be forced into changing that  
representation if a LACON could be the last arc reaching the final  
state, but fortunately the regex library never builds NFAs with such  
a configuration, so there always is a next normal arc.  
  
Back-patch to 9.3 where this logic was introduced.  
  
Discussion: https://postgr.es/m/20170413180503.25948.94871@wrigleys.postgresql.org  

M contrib/pg_trgm/expected/pg_trgm.out
M contrib/pg_trgm/sql/pg_trgm.sql
M src/backend/regex/regexport.c

Move pg_stat_progress_vacuum to the table of Dynamic Statistics Views in doc.

commit   : 5c63dab83836f9287e3809d5193117ea3bdd9adb    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Thu, 13 Apr 2017 12:09:14 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Thu, 13 Apr 2017 12:09:14 +0900    

Click here for diff

Previously the description about pg_stat_progress_vacuum was in the table  
of "Collected Statistics Views" in the doc. But since it repors dynamic  
information, i.e., the current progress of VACUUM, its description should be  
in the table of "Dynamic Statistics Views".  
  
Back-patch to 9.6 where pg_stat_progress_vacuum was added.  
  
Author: Amit Langote  
Discussion: http://postgr.es/m/7ab51b59-8d4d-6193-c60a-b75f222efb12@lab.ntt.co.jp  

M doc/src/sgml/monitoring.sgml

Improve castNode notation by introducing list-extraction-specific variants.

commit   : be182d57021033a55319ab5de737fe2294106ae0    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Apr 2017 13:51:29 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Apr 2017 13:51:29 -0400    

Click here for diff

This extends the castNode() notation introduced by commit 5bcab1114 to  
provide, in one step, extraction of a list cell's pointer and coercion to  
a concrete node type.  For example, "lfirst_node(Foo, lc)" is the same  
as "castNode(Foo, lfirst(lc))".  Almost half of the uses of castNode  
that have appeared so far include a list extraction call, so this is  
pretty widely useful, and it saves a few more keystrokes compared to the  
old way.  
  
As with the previous patch, back-patch the addition of these macros to  
pg_list.h, so that the notation will be available when back-patching.  
  
Patch by me, after an idea of Andrew Gierth's.  
  
Discussion: https://postgr.es/m/14197.1491841216@sss.pgh.pa.us  

M src/include/nodes/pg_list.h

Fix planner error (or assert trap) with nested set operations.

commit   : c0a493e17cc3b99b6d625d5818dc9b504a54d360    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 7 Apr 2017 12:18:38 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 7 Apr 2017 12:18:38 -0400    

Click here for diff

As reported by Sean Johnston in bug #14614, since 9.6 the planner can fail  
due to trying to look up the referent of a Var with varno 0.  This happens  
because we generate such Vars in generate_append_tlist, for lack of any  
better way to describe the output of a SetOp node.  In typical situations  
nothing really cares about that, but given nested set-operation queries  
we will call estimate_num_groups on the output of the subquery, and that  
wants to know what a Var actually refers to.  That logic used to look at  
subquery->targetList, but in commit 3fc6e2d7f I'd switched it to look at  
subroot->processed_tlist, ie the actual output of the subquery plan not the  
parser's idea of the result.  It seemed like a good idea at the time :-(.  
As a band-aid fix, change it back.  
  
Really we ought to have an honest way of naming the outputs of SetOp steps,  
which suggests that it'd be a good idea for the parser to emit an RTE  
corresponding to each one.  But that's a task for another day, and it  
certainly wouldn't yield a back-patchable fix.  
  
Report: https://postgr.es/m/20170407115808.25934.51866@wrigleys.postgresql.org  

M src/backend/optimizer/prep/prepunion.c
M src/test/regress/expected/union.out
M src/test/regress/sql/union.sql

Silence compiler warning in sepgsql

commit   : dd93afca3a0a4c18ac17ee14f7874994f4ced9b5    
  
author   : Joe Conway <mail@joeconway.com>    
date     : Thu, 6 Apr 2017 14:21:31 -0700    
  
committer: Joe Conway <mail@joeconway.com>    
date     : Thu, 6 Apr 2017 14:21:31 -0700    

Click here for diff

<selinux/label.h> includes <stdbool.h>, which creates an incompatible  
We don't care if <stdbool.h> redefines "true"/"false"; those are close  
enough.  
  
Complaint and initial patch by Mike Palmiotto. Final approach per  
Tom Lane's suggestion, as discussed on hackers. Backpatching to  
all supported branches.  
  
Discussion: https://postgr.es/m/flat/623bcaae-112e-ced0-8c22-a84f75ae0c53%40joeconway.com  

M contrib/sepgsql/label.c

Remove dead code and fix comments in fast-path function handling.

commit   : b3721f7d13aa527961688b98dbc09acff30c938c    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 6 Apr 2017 09:09:39 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 6 Apr 2017 09:09:39 +0300    

Click here for diff

HandleFunctionRequest() is no longer responsible for reading the protocol  
message from the client, since commit 2b3a8b20c2. Fix the outdated  
comments.  
  
HandleFunctionRequest() now always returns 0, because the code that used  
to return EOF was moved in 2b3a8b20c2. Therefore, the caller no longer  
needs to check the return value.  
  
Reported by Andres Freund. Backpatch to all supported versions, even though  
this doesn't have any user-visible effect, to make backporting future  
patches in this area easier.  
  
Discussion: https://www.postgresql.org/message-id/20170405010525.rt5azbya5fkbhvrx@alap3.anarazel.de  

M src/backend/tcop/fastpath.c
M src/backend/tcop/postgres.c
M src/include/tcop/fastpath.h

Fix integer-overflow problems in interval comparison.

commit   : fd52b88343308fabb13d6355db3c2565cdf91302    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 5 Apr 2017 23:51:28 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 5 Apr 2017 23:51:28 -0400    

Click here for diff

When using integer timestamps, the interval-comparison functions tried  
to compute the overall magnitude of an interval as an int64 number of  
microseconds.  As reported by Frazer McLean, this overflows for intervals  
exceeding about 296000 years, which is bad since we nominally allow  
intervals many times larger than that.  That results in wrong comparison  
results, and possibly in corrupted btree indexes for columns containing  
such large interval values.  
  
To fix, compute the magnitude as int128 instead.  Although some compilers  
have native support for int128 calculations, many don't, so create our  
own support functions that can do 128-bit addition and multiplication  
if the compiler support isn't there.  These support functions are designed  
with an eye to allowing the int128 code paths in numeric.c to be rewritten  
for use on all platforms, although this patch doesn't do that, or even  
provide all the int128 primitives that will be needed for it.  
  
Back-patch as far as 9.4.  Earlier releases did not guard against overflow  
of interval values at all (commit 146604ec4 fixed that), so it seems not  
very exciting to worry about overly-large intervals for them.  
  
Before 9.6, we did not assume that unreferenced "static inline" functions  
would not draw compiler warnings, so omit functions not directly referenced  
by timestamp.c, the only present consumer of int128.h.  (We could have  
omitted these functions in HEAD too, but since they were written and  
debugged on the way to the present patch, and they look likely to be needed  
by numeric.c, let's keep them in HEAD.)  I did not bother to try to prevent  
such warnings in a --disable-integer-datetimes build, though.  
  
Before 9.5, configure will never define HAVE_INT128, so the part of  
int128.h that exploits a native int128 implementation is dead code in the  
9.4 branch.  I didn't bother to remove it, thinking that keeping the file  
looking similar in different branches is more useful.  
  
In HEAD only, add a simple test harness for int128.h in src/tools/.  
  
In back branches, this does not change the float-timestamps code path.  
That's not subject to the same kind of overflow risk, since it computes  
the interval magnitude as float8.  (No doubt, when this code was originally  
written, overflow was disregarded for exactly that reason.)  There is a  
precision hazard instead :-(, but we'll avert our eyes from that question,  
since no complaints have been reported and that code's deprecated anyway.  
  
Kyotaro Horiguchi and Tom Lane  
  
Discussion: https://postgr.es/m/1490104629.422698.918452336.26FA96B7@webmail.messagingengine.com  

M src/backend/utils/adt/timestamp.c
A src/include/common/int128.h
M src/test/regress/expected/interval.out
M src/test/regress/sql/interval.sql

Back-patch checkpoint clarification docs and pg_basebackup updates

commit   : b88b929a707145964b707257049f8dbfd58f0da5    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Sat, 1 Apr 2017 17:20:05 +0200    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Sat, 1 Apr 2017 17:20:05 +0200    

Click here for diff

This backpatches 51e26c9 and 7220c7b, including both documentation  
updates clarifying the checkpoints at the beginning of base backups and  
the messages in verbose and progress mdoe of pg_basebackup.  
  
Author: Michael Banck  
Discussion: https://postgr.es/m/21444.1488142764%40sss.pgh.pa.us  

M doc/src/sgml/backup.sgml
M doc/src/sgml/ref/pg_basebackup.sgml
M src/bin/pg_basebackup/pg_basebackup.c

Fix parallel query so it doesn't spoil row estimates above Gather.

commit   : fb1879c374581c0f0e251e94c0087c8385b91f5b    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 31 Mar 2017 21:01:20 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 31 Mar 2017 21:01:20 -0400    

Click here for diff

Commit 45be99f8cd5d606086e0a458c9c72910ba8a613d removed GatherPath's  
num_workers field, but this is entirely bogus.  Normally, a path's  
parallel_workers flag is supposed to indicate the number of workers  
that it wants, and should be 0 for a non-partial path.  In that  
commit, I mistakenly thought that GatherPath could also use that field  
to indicate the number of workers that it would try to start, but  
that's disastrous, because then it can propagate up to higher nodes in  
the plan tree, which will then get incorrect rowcounts because the  
parallel_workers flag is involved in computing those values.  Repair  
by putting the separate field back.  
  
Report by Tomas Vondra.  Patch by me, reviewed by Amit Kapila.  
  
Discussion: http://postgr.es/m/f91b4a44-f739-04bd-c4b6-f135bd643669@2ndquadrant.com  

M src/backend/nodes/outfuncs.c
M src/backend/optimizer/plan/createplan.c
M src/backend/optimizer/util/pathnode.c
M src/include/nodes/relation.h

Don't use bgw_main even to specify in-core bgworker entrypoints.

commit   : 9b6e8d8f86acde571d967f85c8b8ae695a3ddba8    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 31 Mar 2017 20:35:51 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 31 Mar 2017 20:35:51 -0400    

Click here for diff

On EXEC_BACKEND builds, this can fail if ASLR is in use.  
  
Backpatch to 9.5.  On master, completely remove the bgw_main field  
completely, since there is no situation in which it is safe for an  
EXEC_BACKEND build.  On 9.6 and 9.5, leave the field intact to avoid  
breaking things for third-party code that doesn't care about working  
under EXEC_BACKEND.  Prior to 9.5, there are no in-core bgworker  
entrypoints.  
  
Petr Jelinek, reviewed by me.  
  
Discussion: http://postgr.es/m/09d8ad33-4287-a09b-a77f-77f8761adb5e@2ndquadrant.com  

M src/backend/access/transam/parallel.c
M src/backend/postmaster/bgworker.c
M src/include/access/parallel.h
M src/test/modules/worker_spi/worker_spi.c

Simplify the example of VACUUM in documentation.

commit   : fa0d1fd8955ca22642890421721bcc2de6a54c2b    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Fri, 31 Mar 2017 01:31:15 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Fri, 31 Mar 2017 01:31:15 +0900    

Click here for diff

Previously a detailed activity report by VACUUM VERBOSE ANALYZE was  
described as an example of VACUUM in docs. But it had been obsolete  
for a long time. For example, commit feb4f44d296b88b7f0723f4a4f3945a371276e0b  
updated the content of that activity report in 2003, but we had  
forgotten to update the example.  
  
So basically we need to update the example. But since no one cared  
about the details of VACUUM output and complained about that mistake  
for such long time, per discussion on hackers, we decided to get rid  
of the detailed activity report from the example and simplify it.  
  
Back-patch to all supported versions.  
  
Reported by Masahiko Sawada, patch by me.  
Discussion: https://postgr.es/m/CAD21AoAGA2pB3p-CWmTkxBsbkZS1bcDGBLcYVcvcDxspG_XAfA@mail.gmail.com  

M doc/src/sgml/ref/vacuum.sgml

Suppress implicit-conversion warnings seen with newer clang versions.

commit   : 8433e0b40e0d840b8daa80eb9788fafcf2dc5aab    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 28 Mar 2017 13:16:19 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 28 Mar 2017 13:16:19 -0400    

Click here for diff

We were assigning values near 255 through "char *" pointers.  On machines  
where char is signed, that's not entirely kosher, and it's reasonable  
for compilers to warn about it.  
  
A better solution would be to change the pointer type to "unsigned char *",  
but that would be vastly more invasive.  For the moment, let's just apply  
this simple backpatchable solution.  
  
Aleksander Alekseev  
  
Discussion: https://postgr.es/m/20170220141239.GD12278@e733.localdomain  
Discussion: https://postgr.es/m/2839.1490714708@sss.pgh.pa.us  

M src/backend/access/transam/xlog.c
M src/backend/access/transam/xloginsert.c
M src/bin/pg_resetxlog/pg_resetxlog.c

Fix unportable disregard of alignment requirements in RADIUS code.

commit   : c804c00d38f6a848f0d7e57a05ea5468fc5762b2    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 26 Mar 2017 17:35:35 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 26 Mar 2017 17:35:35 -0400    

Click here for diff

The compiler is entitled to store a char[] local variable with no  
particular alignment requirement.  Our RADIUS code cavalierly took such  
a local variable and cast its address to a struct type that does have  
alignment requirements.  On an alignment-picky machine this would lead  
to bus errors.  To fix, declare the local variable honestly, and then  
cast its address to char * for use in the I/O calls.  
  
Given the lack of field complaints, there must be very few if any  
people affected; but nonetheless this is a clear portability issue,  
so back-patch to all supported branches.  
  
Noted while looking at a Coverity complaint in the same code.  

M src/backend/libpq/auth.c

plpgsql: Don't generate parallel plans for RETURN QUERY.

commit   : 5674a258fd7e6eb496a4e91b0907077dfa7ee336    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 24 Mar 2017 12:30:39 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 24 Mar 2017 12:30:39 -0400    

Click here for diff

Commit 7aea8e4f2daa4b39ca9d1309a0c4aadb0f7ed81b allowed a parallel  
plan to be generated when for a RETURN QUERY or RETURN QUERY EXECUTE  
statement in a PL/pgsql block, but that's a bad idea because plplgsql  
asks the executor for 50 rows at a time.  That means that we'll always  
be running serially a plan that was intended for parallel execution,  
which is not a good idea.  Fix by not requesting a parallel plan from  
the outset.  
  
Per discussion, back-patch to 9.6.  There is a slight risk that, due  
to optimizer error, somebody could have a case where the parallel plan  
executed serially is actually faster than the supposedly-best serial  
plan, but the consensus seems to be that that's not sufficient  
justification for leaving 9.6 unpatched.  
  
Discussion: http://postgr.es/m/CA+TgmoZ_ZuH+auEeeWnmtorPsgc_SmP+XWbDsJ+cWvWBSjNwDQ@mail.gmail.com  
Discussion: http://postgr.es/m/CA+TgmobXEhvHbJtWDuPZM9bVSLiTj-kShxQJ2uM5GPDze9fRYA@mail.gmail.com  

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

Fix pgbench options -C and -R together

commit   : 2ed391f95b34bb88b4d092f0a1d68ce3903df375    
  
author   : Teodor Sigaev <teodor@sigaev.ru>    
date     : Fri, 24 Mar 2017 19:23:13 +0300    
  
committer: Teodor Sigaev <teodor@sigaev.ru>    
date     : Fri, 24 Mar 2017 19:23:13 +0300    

Click here for diff

The bug is that prior to --rate doCustom was always disconnect/reconnect  
without exiting, but with rate it returns if it has to wait. However threadRun  
test whether there is a connection before recalling doCustom, so it was never  
called.  
  
Bug is not existed in head branch because of refactoring at  
12788ae49e1933f463bc59a6efe46c4a01701b76, patch only 9.6  
  
Author: Fabien Coelho  
Reviewed-by: me  
  
https://commitfest.postgresql.org/13/970/  

M src/bin/pgbench/pgbench.c

Fix backup canceling

commit   : 8de6278d3b7c810fe5d31486491189d88550a2a6    
  
author   : Teodor Sigaev <teodor@sigaev.ru>    
date     : Fri, 24 Mar 2017 13:55:02 +0300    
  
committer: Teodor Sigaev <teodor@sigaev.ru>    
date     : Fri, 24 Mar 2017 13:55:02 +0300    

Click here for diff

Assert-enabled build crashes but without asserts it works by wrong way:  
it may not reset forcing full page write and preventing from starting  
exclusive backup with the same name as cancelled.  
Patch replaces pair of booleans  
nonexclusive_backup_running/exclusive_backup_running to single enum to  
correctly describe backup state.  
  
Backpatch to 9.6 where bug was introduced  
  
Reported-by: David Steele  
Authors: Michael Paquier, David Steele  
Reviewed-by: Anastasia Lubennikova  
  
https://commitfest.postgresql.org/13/1068/  

M src/backend/access/transam/xlog.c
M src/backend/access/transam/xlogfuncs.c
M src/include/access/xlog.h

Revert Windows service check refactoring, and replace with a different fix.

commit   : 4ae0805bbaa4011a65c6b40b9d138aa72f29b8a2    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 24 Mar 2017 12:39:01 +0200    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 24 Mar 2017 12:39:01 +0200    

Click here for diff

This reverts commit 38bdba54a64bacec78e3266f0848b0b4a824132a, "Fix and  
simplify check for whether we're running as Windows service". It turns out  
that older versions of MinGW - like that on buildfarm member narwhal - do  
not support the CheckTokenMembership() function. This replaces the  
refactoring with a much smaller fix, to add a check for SE_GROUP_ENABLED to  
pgwin32_is_service().  
  
Only apply to back-branches, and keep the refactoring in HEAD. It's  
unlikely that anyone is still really using such an old version of MinGW -  
aside from narwhal - but let's not change the minimum requirements in  
minor releases.  
  
Discussion: https://www.postgresql.org/message-id/16609.1489773427@sss.pgh.pa.us  
Patch: https://www.postgresql.org/message-id/CAB7nPqSvfu%3DKpJ%3DNX%2BYAHmgAmQdzA7N5h31BjzXeMgczhGCC%2BQ%40mail.gmail.com  

M src/port/win32security.c

Fix support for some operators (&<, &>, $<|, |&>) in box operator class of SP-GiST.

commit   : a4d07d2e9d94d4516d55ad074236627ab78aa7ca    
  
author   : Teodor Sigaev <teodor@sigaev.ru>    
date     : Tue, 21 Mar 2017 16:24:10 +0300    
  
committer: Teodor Sigaev <teodor@sigaev.ru>    
date     : Tue, 21 Mar 2017 16:24:10 +0300    

Click here for diff

Bug exists since initial commit of box opclass for SP-GiST,  
so backpath to 9.6  
  
Author: Nikita Glukhov with minor editorization of tests by me  
Reviewed-by: Kyotaro Horiguchi, Anastasia Lubennikova  
  
https://commitfest.postgresql.org/13/981/  

M src/backend/utils/adt/geo_spgist.c
M src/test/regress/expected/box.out
M src/test/regress/expected/sanity_check.out
M src/test/regress/sql/box.sql

Revert unintentional change in increasing usage count during pin of buffers, this makes buffer access strategy have no effect. Change was a part of commit 48354581a49c30f5757c203415aa8412d85b0f70 during 9.6 release cycle, so backpath to 9.6

commit   : 09f8bb5b3617269eb750b395fb561a2e532af221    
  
author   : Teodor Sigaev <teodor@sigaev.ru>    
date     : Mon, 20 Mar 2017 18:49:41 +0300    
  
committer: Teodor Sigaev <teodor@sigaev.ru>    
date     : Mon, 20 Mar 2017 18:49:41 +0300    

Click here for diff

Reported-by: Jim Nasby  
Author: Alexander Korotkov  
Reviewed-by: Jim Nasby, Andres Freund  
  
https://commitfest.postgresql.org/13/1029/  

M src/backend/storage/buffer/bufmgr.c

commit   : 09079b72b7fd354f9d18833bdb7ac15e9cc35a86    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Sat, 18 Mar 2017 23:44:30 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Sat, 18 Mar 2017 23:44:30 -0400    

Click here for diff

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

Fix WaitEventSetWait() to handle write-ready waits properly on Windows.

commit   : 8e6333e1cb7747388a694810a8b956cfb6704bdd    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 17 Mar 2017 14:58:06 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 17 Mar 2017 14:58:06 -0400    

Click here for diff

Windows apparently will not detect socket write-ready events unless a  
preceding send attempt returned WSAEWOULDBLOCK.  In many usage patterns  
that's satisfied by the caller of WaitEvenSetWait(), but not always.  
  
Apply the same solution that we already had in pgwin32_select(), namely to  
perform a dummy WSASend() call with len=0.  This will return WSAEWOULDBLOCK  
if there's no buffer space (even though it could legitimately do nothing  
and report success, which makes me a bit nervous about this solution;  
but since it's been working fine in libpq, let's roll with it).  
  
In passing, improve the comments about this in pgwin32_select(), and remove  
duplicated code there.  
  
Back-patch to 9.6 where WaitEventSetWait() was introduced.  We might need  
to back-patch something similar into predecessor code.  But given the lack  
of complaints so far, it's not clear that the case ever gets exercised  
in the back branches, so I'm not going to expend effort on it right now.  
  
This should resolve recurring failures on buildfarm member bowerbird,  
which has been failing since 1e8a85009 went in.  
  
Diagnosis and patch by Petr Jelinek, cosmetic adjustments by me.  
  
Discussion: https://postgr.es/m/5b6a6d6d-fb45-0afb-2e95-5600063c3dbd@2ndquadrant.com  

M src/backend/port/win32/socket.c
M src/backend/storage/ipc/latch.c

Repair test for vacuum reltuples fix.

commit   : 733488dc6bbfb5027be9fdfcde1ee579c65187fe    
  
author   : Andrew Gierth <rhodiumtoad@postgresql.org>    
date     : Fri, 17 Mar 2017 14:35:54 +0000    
  
committer: Andrew Gierth <rhodiumtoad@postgresql.org>    
date     : Fri, 17 Mar 2017 14:35:54 +0000    

Click here for diff

Concurrent auto-analyze could be holding a snapshot, affecting the  
removal of deleted row versions.  Remove the deletion to avoid this  
happening.  Per buildfarm.  
  
In passing, make the test independent of assumptions of physical row  
order, just out of sheer paranoia.  

M src/test/isolation/expected/vacuum-reltuples.out
M src/test/isolation/specs/vacuum-reltuples.spec

commit   : d0aebf02b0a076c438837bafbb502c14575a0d37    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 17 Mar 2017 09:32:34 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 17 Mar 2017 09:32:34 -0400    

Click here for diff

David Christensen  
  
Discussion: http://postgr.es/m/82299377-1480-4439-9ABA-5828D71AA22E@endpoint.com  

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

Fix and simplify check for whether we're running as Windows service.

commit   : 38bdba54a64bacec78e3266f0848b0b4a824132a    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 17 Mar 2017 11:14:01 +0200    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 17 Mar 2017 11:14:01 +0200    

Click here for diff

If the process token contains SECURITY_SERVICE_RID, but it has been  
disabled by the SE_GROUP_USE_FOR_DENY_ONLY attribute, win32_is_service()  
would incorrectly report that we're running as a service. That situation  
arises, e.g. if postmaster is launched with a restricted security token,  
with the "Log in as Service" privilege explicitly removed.  
  
Replace the broken code with CheckProcessTokenMembership(), which does  
this correctly. Also replace similar code in win32_is_admin(), even  
though it got this right, for simplicity and consistency.  
  
Per bug #13755, reported by Breen Hagan. Back-patch to all supported  
versions. Patch by Takayuki Tsunakawa, reviewed by Michael Paquier.  
  
Discussion: https://www.postgresql.org/message-id/20151104062315.2745.67143%40wrigleys.postgresql.org  

M src/port/win32security.c

Avoid having vacuum set reltuples to 0 on non-empty relations in the presence of page pins, which leads to serious estimation errors in the planner. This particularly affects small heavily-accessed tables, especially where locking (e.g. from FK constraints) forces frequent vacuums for mxid cleanup.

commit   : 9b626f6c334f95f1052b22b13d9ddbcc4de5fc4f    
  
author   : Andrew Gierth <rhodiumtoad@postgresql.org>    
date     : Thu, 16 Mar 2017 22:31:49 +0000    
  
committer: Andrew Gierth <rhodiumtoad@postgresql.org>    
date     : Thu, 16 Mar 2017 22:31:49 +0000    

Click here for diff

Fix by keeping separate track of pages whose live tuples were actually  
counted vs. pages that were only scanned for freezing purposes.  Thus,  
reltuples can only be set to 0 if all pages of the relation were  
actually counted.  
  
Backpatch to all supported versions.  
  
Per bug #14057 from Nicolas Baccelli, analyzed by me.  
  
Discussion: https://postgr.es/m/20160331103739.8956.94469@wrigleys.postgresql.org  

M src/backend/commands/vacuumlazy.c
A src/test/isolation/expected/vacuum-reltuples.out
M src/test/isolation/isolation_schedule
A src/test/isolation/specs/vacuum-reltuples.spec

Fix ancient get_object_address_opf_member bug

commit   : 41306a511c01dd299115cf447858a00e34aebbf6    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 16 Mar 2017 12:51:08 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 16 Mar 2017 12:51:08 -0300    

Click here for diff

The original coding was trying to use a TypeName as a string Value,  
which doesn't work; an oversight in my commit a61fd533.  Repair.  
  
Also, make sure we cover the broken case in the relevant test script.  
  
Backpatch to 9.5.  
  
Discussion: https://postgr.es/m/20170315151829.bhxsvrp75xdxhm3n@alvherre.pgsql  

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

Fix failure to use clamp_row_est() for parallel joins.

commit   : 5feb78ae885ce7ab134aad1d12875bd5103e5842    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Wed, 15 Mar 2017 12:28:54 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Wed, 15 Mar 2017 12:28:54 -0400    

Click here for diff

Commit 0c2070cefa0e5d097b715c9a3b9b5499470019aa neglected to use  
clamp_row_est() where it should have done so.  
  
Patch by me.  Report by Amit Kapila.  
  
Discussion: http://postgr.es/m/CAA4eK1KPm8RYa1Kun3ZmQj9pb723b-EFN70j47Pid1vn3ByquA@mail.gmail.com  

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

Spelling fixes

commit   : 18dc2aee5f303447bef48dee596a664d90f6939a    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 14 Mar 2017 12:57:10 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 14 Mar 2017 12:57:10 -0400    

Click here for diff

From: Josh Soref <jsoref@gmail.com>  

M contrib/ltree/ltxtquery_io.c
M doc/src/sgml/biblio.sgml
M doc/src/sgml/release-8.4.sgml
M doc/src/sgml/release-9.0.sgml
M doc/src/sgml/release-9.1.sgml
M doc/src/sgml/release-9.2.sgml
M doc/src/sgml/release-9.3.sgml
M doc/src/sgml/release-9.4.sgml
M doc/src/sgml/release-9.6.sgml
M doc/src/sgml/release-old.sgml
M src/backend/access/transam/xlog.c
M src/backend/executor/nodeAgg.c
M src/backend/optimizer/geqo/geqo_erx.c
M src/backend/port/dynloader/linux.c
M src/backend/replication/walreceiverfuncs.c
M src/interfaces/libpq/bcc32.mak
M src/test/regress/expected/tsdicts.out
M src/test/regress/sql/tsdicts.sql

Fix failure to mark init buffers as BM_PERMANENT.

commit   : 36fcb36b8b1858a588912a02f0ca9489b99ca423    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Tue, 14 Mar 2017 11:51:11 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Tue, 14 Mar 2017 11:51:11 -0400    

Click here for diff

This could result in corruption of the init fork of an unlogged index  
if the ambuildempty routine for that index used shared buffers to  
create the init fork, which was true for brin, gin, gist, and hash  
indexes.  
  
Patch by me, based on an earlier patch by Michael Paquier, who also  
reviewed this one.  This also incorporates an idea from Artur  
Zakirov.  
  
Discussion: http://postgr.es/m/CACYUyc8yccE4xfxhqxfh_Mh38j7dRFuxfaK1p6dSNAEUakxUyQ@mail.gmail.com  

M src/backend/storage/buffer/bufmgr.c
M src/include/storage/buf_internals.h

Remove unnecessary dependency on statement_timeout in prepared_xacts test.

commit   : 033dcdcd8a08f90d3569fc70a2cffe9c10b6be1d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 13 Mar 2017 16:46:32 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 13 Mar 2017 16:46:32 -0400    

Click here for diff

Rather than waiting around for statement_timeout to expire, we can just  
try to take the table's lock in nowait mode.  This saves some fraction  
under 4 seconds when running this test with prepared xacts available,  
and it guards against timeout-expired-anyway failures on very slow  
machines when prepared xacts are not available, as seen in a recent  
failure on axolotl for instance.  
  
This approach could fail if autovacuum were to take an exclusive lock  
on the test table concurrently, but there's no reason for it to do so.  
  
Since the main point here is to improve stability in the buildfarm,  
back-patch to all supported branches.  

M src/test/regress/expected/prepared_xacts.out
M src/test/regress/expected/prepared_xacts_1.out
M src/test/regress/sql/prepared_xacts.sql

Ecpg should support COMMIT PREPARED and ROLLBACK PREPARED.

commit   : f08a90ecd27cedbb53bd082d2fc1b5461f92ab16    
  
author   : Michael Meskes <meskes@postgresql.org>    
date     : Mon, 13 Mar 2017 20:44:13 +0100    
  
committer: Michael Meskes <meskes@postgresql.org>    
date     : Mon, 13 Mar 2017 20:44:13 +0100    

Click here for diff

The problem was that "begin transaction" was issued automatically  
before executing COMMIT/ROLLBACK PREPARED if not in auto commit. This fix by  
Masahiko Sawada fixes this.  

M src/interfaces/ecpg/ecpglib/misc.c

Fix pg_file_write() error handling.

commit   : 08c6d42c8c63c62aeaaf71cd6375baef798c5924    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sun, 12 Mar 2017 19:35:31 -0400    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sun, 12 Mar 2017 19:35:31 -0400    

Click here for diff

Detect fclose() failures; given "ln -s /dev/full $PGDATA/devfull",  
"pg_file_write('devfull', 'x', true)" now fails as it should.  Don't  
leak a stream when fwrite() fails.  Remove a born-ineffective test that  
aimed to skip zero-length writes.  Back-patch to 9.2 (all supported  
versions).  

M contrib/adminpack/adminpack.c

commit   : 8469923f3ea893ee0261a234e2e5136663064d52    
  
author   : Joe Conway <mail@joeconway.com>    
date     : Sat, 11 Mar 2017 13:32:26 -0800    
  
committer: Joe Conway <mail@joeconway.com>    
date     : Sat, 11 Mar 2017 13:32:26 -0800    

Click here for diff

When using unnamed connections with dblink, every time a new  
connection is made, the old one is leaked. Fix that.  
  
This has been an issue probably since dblink was first committed.  
Someone complained almost ten years ago, but apparently I decided  
not to pursue it at the time, and neither did anyone else, so it  
slipped between the cracks. Now that someone else has complained,  
fix in all supported branches.  
  
Discussion: (orig) https://postgr.es/m/flat/F680AB59-6D6F-4026-9599-1BE28880273D%40decibel.org#F680AB59-6D6F-4026-9599-1BE28880273D@decibel.org  
Discussion: (new) https://postgr.es/m/flat/0A3221C70F24FB45833433255569204D1F6ADF8C@G01JPEXMBYT05  
Reported by: Jim Nasby and Takayuki Tsunakawa  

M contrib/dblink/dblink.c

Sanitize newlines in object names in "pg_restore -l" output.

commit   : 4cdd81d9015857eb5c81fe57e95b4c3e52d9614b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 10 Mar 2017 14:15:09 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 10 Mar 2017 14:15:09 -0500    

Click here for diff

Commits 89e0bac86 et al replaced newlines with spaces in object names  
printed in SQL comments, but we neglected to consider that the same  
names are also printed by "pg_restore -l", and a newline would render  
the output unparseable by "pg_restore -L".  Apply the same replacement  
in "-l" output.  Since "pg_restore -L" doesn't actually examine any  
object names, only the dump ID field that starts each line, this is  
enough to fix things for its purposes.  
  
The previous fix was treated as a security issue, and we might have  
done that here as well, except that the issue was reported publicly  
to start with.  Anyway it's hard to see how this could be exploited  
for SQL injection; "pg_restore -L" doesn't do much with the file  
except parse it for leading integers.  
  
Per bug #14587 from Milos Urbanek.  Back-patch to all supported versions.  
  
Discussion: https://postgr.es/m/20170310155318.1425.30483@wrigleys.postgresql.org  

M src/bin/pg_dump/pg_backup_archiver.c

Fix a potential double-free in ecpg.

commit   : d0fef065446e900aaca1382b641d9449396c41f4    
  
author   : Michael Meskes <meskes@postgresql.org>    
date     : Fri, 10 Mar 2017 10:32:41 +0100    
  
committer: Michael Meskes <meskes@postgresql.org>    
date     : Fri, 10 Mar 2017 10:32:41 +0100    

Click here for diff

M src/interfaces/ecpg/preproc/pgc.l

Fix timestamptz regression test to still work with latest IANA zone data.

commit   : d8ec6b9c8c265c2f29b1c0e0e4205895baaa326d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 9 Mar 2017 17:20:11 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 9 Mar 2017 17:20:11 -0500    

Click here for diff

The IANA timezone crew continues to chip away at their project of removing  
timezone abbreviations that have no real-world currency from their  
database.  The tzdata2017a update removes all such abbreviations for  
South American zones, as well as much of the Pacific.  This breaks some  
test cases in timestamptz.sql that were expecting America/Santiago and  
America/Caracas to have non-numeric abbreviations.  
  
The test cases involving America/Santiago seem to have selected that  
zone more or less at random, so just replace it with America/New_York,  
which is of similar longitude.  The cases involving America/Caracas are  
harder since they were chosen to test a time-varying zone abbreviation  
around a point where it changed meaning in the backwards direction.  
Fortunately, Europe/Moscow has a similar case in 2014, and the MSK/MSD  
abbreviations are well enough attested that IANA seems unlikely to  
decide to remove them from the database in future.  
  
With these changes, this regression test should pass when using any IANA  
zone database from 2015 or later.  One could wish that there were a few  
years more daylight on how out-of-date your zone database can be ... but  
really the --with-system-tzdata option is only meant for use on platforms  
where the zone database is kept up-to-date pretty faithfully, so I do not  
think this is a big objection.  
  
Discussion: https://postgr.es/m/6749.1489087470@sss.pgh.pa.us  

M src/test/regress/expected/timestamptz.out
M src/test/regress/sql/timestamptz.sql

Use doubly-linked block lists in aset.c to reduce large-chunk overhead.

commit   : e0a6ed8a2525b10bf86285f3d6e56b3672457cda    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 8 Mar 2017 12:21:12 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 8 Mar 2017 12:21:12 -0500    

Click here for diff

Large chunks (those too large for any palloc freelist) are managed as  
separate blocks.  Formerly, realloc'ing or pfree'ing such a chunk required  
O(N) time in a context with N blocks, since we had to traipse down the  
singly-linked block list to locate the block's predecessor before we could  
fix the list links.  This can result in O(N^2) runtime in situations where  
large numbers of such chunks are manipulated within one context.  Cases  
like that were not foreseen in the original design of aset.c, and indeed  
didn't arise until fairly recently.  But such problems can now occur in  
reorderbuffer.c and in hash joining, both of which make repeated large  
requests without scaling up their request size as they do so, and which  
will free their requests in not-necessarily-LIFO order.  
  
To fix, change the block list from singly-linked to doubly-linked.  
This adds another 4 or 8 bytes to ALLOC_BLOCKHDRSZ, but that doesn't  
seem like unacceptable overhead, since aset.c's blocks are normally  
8K or more, and never less than 1K in current practice.  
  
In passing, get rid of some redundant AllocChunkGetPointer() calls in  
AllocSetRealloc (the compiler might be smart enough to optimize these  
away anyway, but no need to assume that) and improve AllocSetCheck's  
checking of block header fields.  
  
Back-patch to 9.4 where reorderbuffer.c appeared.  We could take this  
further back, but currently there's no evidence that it would be useful.  
  
Discussion: https://postgr.es/m/CAMkU=1x1hvue1XYrZoWk_omG0Ja5nBvTdvgrOeVkkeqs71CV8g@mail.gmail.com  

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

pg_xlogdump: Remove extra newline in error message

commit   : feb4d35406dddeda0fa6f4e16ea3c64dbd898a0e    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 8 Mar 2017 09:57:17 -0500    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 8 Mar 2017 09:57:17 -0500    

Click here for diff

fatal_error() already prints out a trailing newline.  

M src/bin/pg_xlogdump/pg_xlogdump.c

Fix grammar

commit   : c6117eecec4281432f240028bc9ab3c4ad253efe    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Tue, 7 Mar 2017 22:45:45 -0500    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Tue, 7 Mar 2017 22:45:45 -0500    

Click here for diff

Reported by Jeremy Finzel  

M doc/src/sgml/wal.sgml

Fix pgbench's failure to honor the documented long-form option "--builtin".

commit   : 0e2c85d130b85549da469e8a16ee1c863e2f3da4    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 7 Mar 2017 11:36:35 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 7 Mar 2017 11:36:35 -0500    

Click here for diff

Not only did it not accept --builtin as a synonym for -b, but what it did  
accept as a synonym was --tpc-b (huh?), which it got even further wrong  
by marking as no_argument, so that if you did try that you got a core  
dump.  I suppose this is leftover from some early design for the new  
switches added by commit 8bea3d221, but it's still pretty sloppy work.  
  
Per bug #14580 from Stepan Pesternikov.  Back-patch to 9.6 where the  
error was introduced.  
  
Report: https://postgr.es/m/20170307123347.25054.73207@wrigleys.postgresql.org  

M src/bin/pgbench/pgbench.c

pg_dump: Properly handle public schema ACLs with --clean

commit   : e961341cc1491ddf41e9408d9b1d3342df9ea2c2    
  
author   : Stephen Frost <sfrost@snowman.net>    
date     : Mon, 6 Mar 2017 23:29:08 -0500    
  
committer: Stephen Frost <sfrost@snowman.net>    
date     : Mon, 6 Mar 2017 23:29:08 -0500    

Click here for diff

pg_dump has always handled the public schema in a special way when it  
comes to the "--clean" option.  To wit, we do not drop or recreate the  
public schema in "normal" mode, but when we are run in "--clean" mode  
then we do drop and recreate the public schema.  
  
When running in "--clean" mode, the public schema is dropped and then  
recreated and it is recreated with the normal schema-default privileges  
of "nothing".  This is unlike how the public schema starts life, which  
is to have CREATE and USAGE GRANT'd to the PUBLIC role, and that is what  
is recorded in pg_init_privs.  
  
Due to this, in "--clean" mode, pg_dump would mistakenly only dump out  
the set of privileges required to go from the initdb-time privileges on  
the public schema to whatever the current-state privileges are.  If the  
privileges were not changed from initdb time, then no privileges would  
be dumped out for the public schema, but with the schema being dropped  
and recreated, the result was that the public schema would have no ACLs  
on it instead of what it should have, which is the initdb-time  
privileges.  
  
Practically speaking, this meant that pg_dump with --clean mode dumping  
a database where the ACLs on the public schema were not changed from the  
default would, upon restore, result in a public schema with *no*  
privileges GRANT'd, not matching the state of the existing database  
(where the initdb-time privileges would have been CREATE and USAGE to  
the PUBLIC role for the public schema).  
  
To fix, adjust the query in getNamespaces() to ignore the pg_init_privs  
entry for the public schema when running in "--clean" mode, meaning that  
the privileges for the public schema would be dumped, correctly, as if  
it was going from a newly-created schema to the current state (which is,  
indeed, what will happen during the restore thanks to the DROP/CREATE).  
  
Only the public schema is handled in this special way by pg_dump, no  
other initdb-time objects are dropped/recreated in --clean mode.  
  
Back-patch to 9.6 where the bug was introduced.  
  
Discussion: https://postgr.es/m/3534542.o3cNaKiDID%40techfox  

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

Repair incorrect pg_dump labeling for some comments and security labels.

commit   : 8ea8178cd451a23dc9fd51e4e091426cdab6bec6    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 6 Mar 2017 19:33:59 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 6 Mar 2017 19:33:59 -0500    

Click here for diff

We attached no schema label to comments for procedural languages, casts,  
transforms, operator classes, operator families, or text search objects.  
The first three categories of objects don't really have schemas, but  
pg_dump treats them as if they do, and it seems like the TocEntry fields  
for their comments had better match the TocEntry fields for the parent  
objects.  (As an example of a possible hazard, the type names in a CAST  
will be formatted with the assumption of a particular search_path, so  
failing to ensure that this same path is active for the COMMENT ON command  
could lead to an error or to attaching the comment to the wrong cast.)  
In the last six cases, this was a flat-out error --- possibly mine to  
begin with, but it was a long time ago.  
  
The security label for a procedural language was likewise not correctly  
labeled as to schema, and both the comment and security label for a  
procedural language were not correctly labeled as to owner.  
  
In simple cases the restore would accidentally work correctly anyway, since  
these comments and security labels would normally get emitted right after  
the owning object, and so the search path and active user would be correct  
anyhow.  But it could fail in corner cases; for example a schema-selective  
restore would omit comments it should include.  
  
Giuseppe Broccolo noted the oversight, and proposed the correct fix, for  
text search dictionary objects; I found the rest by cross-checking other  
dumpComment() calls.  These oversights are ancient, so back-patch all  
the way.  
  
Discussion: https://postgr.es/m/CAFzmHiWwwzLjzwM4x5ki5s_PDMR6NrkipZkjNnO3B0xEpBgJaA@mail.gmail.com  

M src/bin/pg_dump/pg_dump.c

pg_upgrade: Fix large object COMMENTS, SECURITY LABELS

commit   : 65a3f233b2cf9aa7750d0c634654a65f4c5579c4    
  
author   : Stephen Frost <sfrost@snowman.net>    
date     : Mon, 6 Mar 2017 17:04:06 -0500    
  
committer: Stephen Frost <sfrost@snowman.net>    
date     : Mon, 6 Mar 2017 17:04:06 -0500    

Click here for diff

When performing a pg_upgrade, we copy the files behind pg_largeobject  
and pg_largeobject_metadata, allowing us to avoid having to dump out and  
reload the actual data for large objects and their ACLs.  
  
Unfortunately, that isn't all of the information which can be associated  
with large objects.  Currently, we also support COMMENTs and SECURITY  
LABELs with large objects and these were being silently dropped during a  
pg_upgrade as pg_dump would skip everything having to do with a large  
object and pg_upgrade only copied the tables mentioned to the new  
cluster.  
  
As the file copies happen after the catalog dump and reload, we can't  
simply include the COMMENTs and SECURITY LABELs in pg_dump's binary-mode  
output but we also have to include the actual large object definition as  
well.  With the definition, comments, and security labels in the pg_dump  
output and the file copies performed by pg_upgrade, all of the data and  
metadata associated with large objects is able to be successfully pulled  
forward across a pg_upgrade.  
  
In 9.6 and master, we can simply adjust the dump bitmask to indicate  
which components we don't want.  In 9.5 and earlier, we have to put  
explciit checks in in dumpBlob() and dumpBlobs() to not include the ACL  
or the data when in binary-upgrade mode.  
  
Adjustments made to the privileges regression test to allow another test  
(large_object.sql) to be added which explicitly leaves a large object  
with a comment in place to provide coverage of that case with  
pg_upgrade.  
  
Back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/20170221162655.GE9812@tamriel.snowman.net  

M src/bin/pg_dump/pg_backup.h
M src/bin/pg_dump/pg_backup_archiver.c
M src/bin/pg_dump/pg_dump.c
A src/test/regress/expected/large_object.out
M src/test/regress/expected/privileges.out
M src/test/regress/parallel_schedule
M src/test/regress/serial_schedule
A src/test/regress/sql/large_object.sql
M src/test/regress/sql/privileges.sql

Avoid dangling pointer to relation name in RLS code path in DoCopy().

commit   : 943140d572adc94b957d123aa4c35ec88e40e869    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 6 Mar 2017 16:50:47 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 6 Mar 2017 16:50:47 -0500    

Click here for diff

With RLS active, "COPY tab TO ..." failed under -DRELCACHE_FORCE_RELEASE,  
and would sometimes fail without that, because it used the relation name  
directly from the relcache as part of the parsetree it's building.  That  
becomes a potentially-dangling pointer as soon as the relcache entry is  
closed, a bit further down.  Typical symptom if the relcache entry chanced  
to get cleared would be "relation does not exist" error with a garbage  
relation name, or possibly a core dump; but if you were really truly  
unlucky, the COPY might copy from the wrong table.  
  
Per report from Andrew Dunstan that regression tests fail with  
-DRELCACHE_FORCE_RELEASE.  The core tests now pass for me (but have  
not tried "make check-world" yet).  
  
Discussion: https://postgr.es/m/7b52f900-0579-cda9-ae2e-de5da17090e6@2ndQuadrant.com  

M src/backend/commands/copy.c

In rebuild_relation(), don't access an already-closed relcache entry.

commit   : 68f7b91e509d9ac95a376805df22bc9b51e71255    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 4 Mar 2017 16:09:33 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 4 Mar 2017 16:09:33 -0500    

Click here for diff

This reliably fails with -DRELCACHE_FORCE_RELEASE, as reported by  
Andrew Dunstan, and could sometimes fail in normal operation, resulting  
in a wrong persistence value being used for the transient table.  
It's not immediately clear to me what effects that might have beyond  
the risk of a crash while accessing OldHeap->rd_rel->relpersistence,  
but it's probably not good.  
  
Bug introduced by commit f41872d0c, and made substantially worse by  
commit 85b506bbf, which added a second such access significantly  
later than the heap_close.  I doubt the first reference could fail  
in a production scenario, but the second one definitely could.  
  
Discussion: https://postgr.es/m/7b52f900-0579-cda9-ae2e-de5da17090e6@2ndQuadrant.com  

M src/backend/commands/cluster.c

Update documentation of tsquery_phrase().

commit   : b0344f877f8c0f58e002d55349b233e436df8358    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 2 Mar 2017 09:34:35 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 2 Mar 2017 09:34:35 -0500    

Click here for diff

Missed in commit 028350f61.  Noted by Eiji Seki.  

M doc/src/sgml/func.sgml

Handle unaligned SerializeSnapshot() buffer.

commit   : 0cc864b002b0b4a5970e2fdc9445216d0a23b7d6    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Thu, 2 Mar 2017 00:03:27 -0500    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Thu, 2 Mar 2017 00:03:27 -0500    

Click here for diff

Likewise in RestoreSnapshot().  Do so by copying between the user buffer  
and a stack buffer of known alignment.  Back-patch to 9.6, where this  
last applies cleanly.  In master, the select_parallel test dies with  
SIGBUS on "Oracle Solaris 10 1/13 s10s_u11wos_24a SPARC", building  
32-bit with gcc 4.9.2.  In 9.6 and 9.5, the buffers in question happen  
to be sufficiently-aligned, and this change is mere insurance against  
future 9.6 changes or extension code compromising that.  

M src/backend/utils/time/snapmgr.c

Fix timeouts in PostgresNode::psql

commit   : 3a1a422fa57a193f5dda93ea1b7941fdac42ac96    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 1 Mar 2017 13:52:38 -0500    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 1 Mar 2017 13:52:38 -0500    

Click here for diff

Newer Perl or IPC::Run versions default to appending the filename to string  
exceptions, e.g. the exception  
  
    psql timed out  
  
 is thrown as  
  
    psql timed out at /usr/share/perl5/vendor_perl/IPC/Run.pm line 2961.  
  
To handle this, match exceptions with !~ rather than ne.  
  
From: Craig Ringer <craig@2ndquadrant.com>  
Reviewed-by: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org>  

M src/test/perl/PostgresNode.pm

Fix incorrect variable datatype

commit   : 965956a03305fb8517c584ffffd37515344f4101    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Tue, 28 Feb 2017 12:16:42 +0100    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Tue, 28 Feb 2017 12:16:42 +0100    

Click here for diff

Both datatypes map to the same underlying one which is why it still  
worked, but we should use the correct type.  
  
Author: Kyotaro HORIGUCHI  

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

pg_upgrade docs: clarify instructions on standby extensions

commit   : f97f4fc028ccc284683ba400a51d59e534901336    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Sat, 25 Feb 2017 12:59:23 -0500    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Sat, 25 Feb 2017 12:59:23 -0500    

Click here for diff

Previously the pg_upgrade standby upgrade instructions said not to  
execute pgcrypto.sql, but it should have referenced the extension  
command "CREATE EXTENSION pgcrypto".  This patch makes that doc change.  
  
Reported-by: a private bug report  
  
Backpatch-through: 9.4, where standby instructions were added  

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

Fix unportable definition of BSWAP64() macro.

commit   : cb8ef68b93312e3977f3e60676ded9a553c14064    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 24 Feb 2017 15:21:39 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 24 Feb 2017 15:21:39 -0500    

Click here for diff

We have a portable way of writing uint64 constants, but whoever wrote  
this macro didn't know about it.  
  
While at it, fix unsafe under-parenthesization of arguments.  That might  
be moot, because there are already good reasons not to use the macro on  
anything more complicated than a simple variable, but it's still poor  
practice.  
  
Per buildfarm warnings.  

M src/include/port/pg_bswap.h

Fix contrib/pg_trgm's extraction of trigrams from regular expressions.

commit   : 16500d2278ab3ddc03a3f6f44c7c2c00def2c1fc    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 22 Feb 2017 15:04:07 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 22 Feb 2017 15:04:07 -0500    

Click here for diff

The logic for removing excess trigrams from the result was faulty.  
It intends to avoid merging the initial and final states of the NFA,  
which is necessary, but in testing whether removal of a specific trigram  
would cause that, it failed to consider the combined effects of all the  
state merges that that trigram's removal would cause.  This could result  
in a broken final graph that would never match anything, leading to GIN  
or GiST indexscans not finding anything.  
  
To fix, add a "tentParent" field that is used only within this loop,  
and set it to show state merges that we are tentatively going to do.  
While examining a particular arc, we must chase up through tentParent  
links as well as regular parent links (the former can only appear atop  
the latter), and we must account for state init/fin flag merges that  
haven't actually been done yet.  
  
To simplify the latter, combine the separate init and fin bool fields  
into a bitmap flags field.  I also chose to get rid of the "children"  
state list, which seems entirely inessential.  
  
Per bug #14563 from Alexey Isayko, which the added test cases are based on.  
Back-patch to 9.3 where this code was added.  
  
Report: https://postgr.es/m/20170222111446.1256.67547@wrigleys.postgresql.org  
Discussion: https://postgr.es/m/8816.1487787594@sss.pgh.pa.us  

M contrib/pg_trgm/expected/pg_trgm.out
M contrib/pg_trgm/sql/pg_trgm.sql
M contrib/pg_trgm/trgm_regexp.c

Make walsender always initialize the buffers.

commit   : 9fab155c68a4e2164c39f61bc849ad669ad54f2c    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Wed, 22 Feb 2017 03:11:58 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Wed, 22 Feb 2017 03:11:58 +0900    

Click here for diff

Walsender uses the local buffers for each outgoing and incoming message.  
Previously when creating replication slot, walsender forgot to initialize  
one of them and which can cause the segmentation fault error. To fix this  
issue, this commit changes walsender so that it always initialize them  
before it executes the requested replication command.  
  
Back-patch to 9.4 where replication slot was introduced.  
  
Problem report and initial patch by Stas Kelvich, modified by me.  
Report: https://www.postgresql.org/message-id/A1E9CB90-1FAC-4CAD-8DBA-9AA62A6E97C5@postgrespro.ru  

M src/backend/replication/walsender.c

Fix sloppy handling of corner-case errors in fd.c.

commit   : 62ed08422cba0c1bf4ad1e721c13cd6ac9ed29a0    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 21 Feb 2017 17:51:27 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 21 Feb 2017 17:51:27 -0500    

Click here for diff

Several places in fd.c had badly-thought-through handling of error returns  
from lseek() and close().  The fact that those would seldom fail on valid  
FDs is probably the reason we've not noticed this up to now; but if they  
did fail, we'd get quite confused.  
  
LruDelete and LruInsert actually just Assert'd that lseek never fails,  
which is pretty awful on its face.  
  
In LruDelete, we indeed can't throw an error, because that's likely to get  
called during error abort and so throwing an error would probably just lead  
to an infinite loop.  But by the same token, throwing an error from the  
close() right after that was ill-advised, not to mention that it would've  
left the LRU state corrupted since we'd already unlinked the VFD from the  
list.  I also noticed that really, most of the time, we should know the  
current seek position and it shouldn't be necessary to do an lseek here at  
all.  As patched, if we don't have a seek position and an lseek attempt  
doesn't give us one, we'll close the file but then subsequent re-open  
attempts will fail (except in the somewhat-unlikely case that a  
FileSeek(SEEK_SET) call comes between and allows us to re-establish a known  
target seek position).  This isn't great but it won't result in any state  
corruption.  
  
Meanwhile, having an Assert instead of an honest test in LruInsert is  
really dangerous: if that lseek failed, a subsequent read or write would  
read or write from the start of the file, not where the caller expected,  
leading to data corruption.  
  
In both LruDelete and FileClose, if close() fails, just LOG that and mark  
the VFD closed anyway.  Possibly leaking an FD is preferable to getting  
into an infinite loop or corrupting the VFD list.  Besides, as far as I can  
tell from the POSIX spec, it's unspecified whether or not the file has been  
closed, so treating it as still open could be the wrong thing anyhow.  
  
I also fixed a number of other places that were being sloppy about  
behaving correctly when the seekPos is unknown.  
  
Also, I changed FileSeek to return -1 with EINVAL for the cases where it  
detects a bad offset, rather than throwing a hard elog(ERROR).  It seemed  
pretty inconsistent that some bad-offset cases would get a failure return  
while others got elog(ERROR).  It was missing an offset validity check for  
the SEEK_CUR case on a closed file, too.  
  
Back-patch to all supported branches, since all this code is fundamentally  
identical in all of them.  
  
Discussion: https://postgr.es/m/2982.1487617365@sss.pgh.pa.us  

M src/backend/storage/file/fd.c

doc: Update URL for plr

commit   : efc286643f33ce2949e5210338cb5cca0426eb04    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 21 Feb 2017 12:34:25 -0500    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 21 Feb 2017 12:34:25 -0500    

Click here for diff

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

Fix documentation of to_char/to_timestamp TZ, tz, OF formatting patterns.

commit   : c05ef567d694ad9c51830991919b35ad993a59ad    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 20 Feb 2017 10:05:00 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 20 Feb 2017 10:05:00 -0500    

Click here for diff

These are only supported in to_char, not in the other direction, but the  
documentation failed to mention that.  Also, describe TZ/tz as printing the  
time zone "abbreviation", not "name", because what they print is elsewhere  
referred to that way.  Per bug #14558.  

M doc/src/sgml/func.sgml

Make src/interfaces/libpq/test clean up after itself.

commit   : bde7d6d79464c453ddafd18c5f4e808c17c4f04f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 19 Feb 2017 17:18:10 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 19 Feb 2017 17:18:10 -0500    

Click here for diff

It failed to remove a .o file during "make clean", and it lacked  
a .gitignore file entirely.  

A src/interfaces/libpq/test/.gitignore
M src/interfaces/libpq/test/Makefile

Adjust PL/Tcl regression test to dodge a possible bug or zone dependency.

commit   : d27a48ad63f4b09d0ce44d221f14e447c91942e5    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 19 Feb 2017 16:14:52 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 19 Feb 2017 16:14:52 -0500    

Click here for diff

One case in the PL/Tcl tests is observed to fail on RHEL5 with a Turkish  
time zone setting.  It's not clear if this is an old Tcl bug or something  
odd about the zone data, but in any case that test is meant to see if the  
Tcl [clock] command works at all, not what its corner-case behaviors are.  
Therefore we have no need to test exactly which week a Sunday midnight is  
considered to fall into.  Probe the following Tuesday instead.  
  
Discussion: https://postgr.es/m/797.1487517822@sss.pgh.pa.us  

M src/pl/tcl/expected/pltcl_setup.out
M src/pl/tcl/sql/pltcl_setup.sql

Fix help message for pg_basebackup -R

commit   : 17298748a39e33f94fa4a82450bad98de8ae8d0b    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Sat, 18 Feb 2017 13:45:14 +0100    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Sat, 18 Feb 2017 13:45:14 +0100    

Click here for diff

The recovery.conf file that's generated is specifically for replication,  
and not needed (or wanted) for regular backup restore, so indicate that  
in the message.  

M src/bin/pg_basebackup/pg_basebackup.c

Document usage of COPT environment variable for adjusting configure flags.

commit   : 365ee96d535e91d9808d21a8a78c8664cfc44d5e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 17 Feb 2017 16:11:02 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 17 Feb 2017 16:11:02 -0500    

Click here for diff

Also add to the existing rather half-baked description of PROFILE,  
which does exactly the same thing, but I think people use it differently.  
  
Discussion: https://postgr.es/m/16461.1487361849@sss.pgh.pa.us  

M doc/src/sgml/installation.sgml
M src/Makefile.global.in

pg_dump: Fix typo in query

commit   : 4e8b2fd335a913a09f32cc0f51b6f03405631cbb    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 17 Feb 2017 15:06:34 -0500    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 17 Feb 2017 15:06:34 -0500    

Click here for diff

This could lead to incorrect dumping of language privileges in some  
cases, which is probably a rare situation.  

M src/bin/pg_dump/pg_dump.c

Doc: remove duplicate index entry.

commit   : 7ba903abb24a2791f38fb96b2aca3bbb6d5ab614    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 16 Feb 2017 11:30:07 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 16 Feb 2017 11:30:07 -0500    

Click here for diff

This causes a warning with the old html-docs toolchain, though not with the  
new.  I had originally supposed that we needed both <indexterm> entries to  
get both a primary index entry and a see-also link; but evidently not,  
as pointed out by Fabien Coelho.  
  
Discussion: https://postgr.es/m/alpine.DEB.2.20.1702161616060.5445@lancre  

M doc/src/sgml/syntax.sgml

Formatting and docs corrections for logical decoding output plugins.

commit   : 6abf99b01d5a153684716d445fce204fc222975c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 15 Feb 2017 18:15:47 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 15 Feb 2017 18:15:47 -0500    

Click here for diff

Make the typedefs for output plugins consistent with project style;  
they were previously not even consistent with each other as to layout  
or inclusion of parameter names.  Make the documentation look the same,  
and fix errors therein (missing and misdescribed parameters).  
  
Back-patch because of the documentation bugs.  

M doc/src/sgml/logicaldecoding.sgml
M src/include/replication/output_plugin.h

Doc: fix typo in logicaldecoding.sgml.

commit   : b1dc2af1a2210f2fa544c175ba846321de98f93c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 15 Feb 2017 17:31:02 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 15 Feb 2017 17:31:02 -0500    

Click here for diff

There's no such field as OutputPluginOptions.output_mode;  
it's actually output_type.  Noted by T. Katsumata.  
  
Discussion: https://postgr.es/m/20170215072115.6101.29870@wrigleys.postgresql.org  

M doc/src/sgml/logicaldecoding.sgml

Make sure that hash join's bulk-tuple-transfer loops are interruptible.

commit   : 354dfa235b4dfb01e23cee6ad8ec5fe6904004fc    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 15 Feb 2017 16:40:05 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 15 Feb 2017 16:40:05 -0500    

Click here for diff

The loops in ExecHashJoinNewBatch(), ExecHashIncreaseNumBatches(), and  
ExecHashRemoveNextSkewBucket() are all capable of iterating over many  
tuples without ever doing a CHECK_FOR_INTERRUPTS, so that the backend  
might fail to respond to SIGINT or SIGTERM for an unreasonably long time.  
Fix that.  In the case of ExecHashJoinNewBatch(), it seems useful to put  
the added CHECK_FOR_INTERRUPTS into ExecHashJoinGetSavedTuple() rather  
than directly in the loop, because that will also ensure that both  
principal code paths through ExecHashJoinOuterGetTuple() will do a  
CHECK_FOR_INTERRUPTS, which seems like a good idea to avoid surprises.  
  
Back-patch to all supported branches.  
  
Tom Lane and Thomas Munro  
  
Discussion: https://postgr.es/m/6044.1487121720@sss.pgh.pa.us  

M src/backend/executor/nodeHash.c
M src/backend/executor/nodeHashjoin.c

Fix tab completion for "ALTER SYSTEM SET variable ...".

commit   : a3f4c8e50e8e00fc88c44d5ff7a99c1ce88256be    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 15 Feb 2017 15:23:19 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 15 Feb 2017 15:23:19 -0500    

Click here for diff

It wouldn't complete "TO" after the variable name, which is certainly  
minor enough.  But since we do complete "TO" after "SET variable ...",  
and since this case used to work pre-9.6, I think this is a bug.  
  
Also, fix the query used to collect the variable names; whoever last  
touched it evidently didn't understand how the pieces are supposed  
to fit together.  It accidentally worked anyway, because readline  
ignores irrelevant completions, but it was randomly unlike the ones  
around it, and could be a source of actual bugs if someone copied  
it as a prototype for another query.  

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

Fix YA unwanted behavioral difference with operator_precedence_warning.

commit   : 8350aae4f18a158980c17f56c39a707f4ac168cc    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 15 Feb 2017 14:44:00 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 15 Feb 2017 14:44:00 -0500    

Click here for diff

Jeff Janes noted that the error cursor position shown for some errors  
would vary when operator_precedence_warning is turned on.  We'd prefer  
that option to have no undocumented effects, so this isn't desirable.  
To fix, make sure that an AEXPR_PAREN node has the same exprLocation  
as its child node.  
  
(Note: it would be a little cheaper to use @2 here instead of an  
exprLocation call, but there are cases where that wouldn't produce  
the identical answer, so don't do it like that.)  
  
Back-patch to 9.5 where this feature was introduced.  
  
Discussion: https://postgr.es/m/CAMkU=1ykK+VhhcQ4Ky8KBo9FoaUJH3f3rDQB8TkTXi-ZsBRUkQ@mail.gmail.com  

M src/backend/parser/gram.y

Corrections and improvements to generic parallel query documentation.

commit   : 3e51859ebc910744e04bc35907fa3d29fd68eb4b    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Tue, 14 Feb 2017 09:37:31 -0500    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Tue, 14 Feb 2017 09:37:31 -0500    

Click here for diff

David Rowley, reviewed by Brad DeJong, Amit Kapila, and me.  
  
Discussion: http://postgr.es/m/CAKJS1f81fob-M6RJyTVv3SCasxMuQpj37ReNOJ=tprhwd7hAVg@mail.gmail.com  

M doc/src/sgml/parallel.sgml

Ignore tablespace ACLs when ignoring schema ACLs.

commit   : 4d43d5d35d544d39ee59e3ef56cd01faf5be3016    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sun, 12 Feb 2017 16:03:41 -0500    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sun, 12 Feb 2017 16:03:41 -0500    

Click here for diff

The ALTER TABLE ALTER TYPE implementation can issue DROP INDEX and  
CREATE INDEX to refit existing indexes for the new column type.  Since  
this CREATE INDEX is an implementation detail of an index alteration,  
the ensuing DefineIndex() should skip ACL checks specific to index  
creation.  It already skips the namespace ACL check.  Make it skip the  
tablespace ACL check, too.  Back-patch to 9.2 (all supported versions).  
  
Reviewed by Tom Lane.  

M src/backend/commands/indexcmds.c
M src/test/regress/input/tablespace.source
M src/test/regress/output/tablespace.source

Blind try to fix portability issue in commit 8f93bd851 et al.

commit   : fc96a5fbc69918ad23f5c5afbe8134aa53d397ef    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 9 Feb 2017 15:49:57 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 9 Feb 2017 15:49:57 -0500    

Click here for diff

The S/390 members of the buildfarm are showing failures indicating  
that they're having trouble with the rint() calls I added yesterday.  
There's no good reason for that, and I wonder if it is a compiler bug  
similar to the one we worked around in d9476b838.  Try to fix it using  
the same method as before, namely to store the result of rint() back  
into a "double" variable rather than immediately converting to int64.  
(This isn't entirely waving a dead chicken, since on machines with  
wider-than-double float registers, the extra store forces a width  
conversion.  I don't know if S/390 is like that, but it seems worth  
trying.)  
  
In passing, merge duplicate ereport() calls in float8_timestamptz().  
  
Per buildfarm.  

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

Fix roundoff problems in float8_timestamptz() and make_interval().

commit   : 404756fe89f62735f6075abb594b54be9c262b27    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 8 Feb 2017 18:04:59 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 8 Feb 2017 18:04:59 -0500    

Click here for diff

When converting a float value to integer microseconds, we should be careful  
to round the value to the nearest integer, typically with rint(); simply  
assigning to an int64 variable will truncate, causing apparently off-by-one  
values in cases that should work.  Most places in the datetime code got  
this right, but not these two.  
  
float8_timestamptz() is new as of commit e511d878f (9.6).  Previous  
versions effectively depended on interval_mul() to do roundoff correctly,  
which it does, so this fixes an accuracy regression in 9.6.  
  
The problem in make_interval() dates to its introduction in 9.4.  Aside  
from being careful to round not truncate, let's incorporate the hours and  
minutes inputs into the result with exact integer arithmetic, rather than  
risk introducing roundoff error where there need not have been any.  
  
float8_timestamptz() problem reported by Erik Nordström, though this is  
not his proposed patch.  make_interval() problem found by me.  
  
Discussion: https://postgr.es/m/CAHuQZDS76jTYk3LydPbKpNfw9KbACmD=49dC4BrzHcfPv6yA1A@mail.gmail.com  

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

Correct thinko in last-minute release note item.

commit   : ae8a602c32f839af8e467230fedb8e0c48540666    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 7 Feb 2017 10:24:25 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 7 Feb 2017 10:24:25 -0500    

Click here for diff

The CREATE INDEX CONCURRENTLY bug can only be triggered by row updates,  
not inserts, since the problem would arise from an update incorrectly  
being made HOT.  Noted by Alvaro.  

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